Trong các hệ thống hiện đại, Redis thường được sử dụng như một phần cốt lõi để cache, quản lý session, hoặc xử lý hàng đợi. Tuy nhiên, nếu chỉ triển khai Redis đơn lẻ, hệ thống sẽ dễ rơi vào tình trạng “single point of failure”, nghĩa là chỉ cần Redis master gặp sự cố, toàn bộ ứng dụng có thể bị gián đoạn. Để giải quyết vấn đề đó, Redis Sentinel ra đời như một giải pháp nhẹ, hiệu quả và dễ triển khai giúp Redis luôn duy trì tính sẵn sàng (high availability).
Đọc bài viết này để hiểu rõ hơn về:
- Tổng quan về Redis Sentinel
- Cách triển khai Redis Sentinel
- Ưu điểm và nhược điểm của Redis Sentinel
- So sánh Redis Sentinel với Redis Cluster
Redis Sentinel là gì?
Redis là một hệ thống cơ sở dữ liệu in-memory mã nguồn mở, nổi tiếng với tốc độ truy xuất siêu nhanh và khả năng xử lý dữ liệu theo thời gian thực. Nhờ hỗ trợ đa dạng kiểu dữ liệu và dễ tích hợp, Redis thường được sử dụng trong các ứng dụng web hiện đại để cache dữ liệu, quản lý session, xử lý hàng đợi và nhiều trường hợp khác.
Tuy nhiên, khi triển khai Redis ở môi trường thực tế, đặc biệt là production thì có một vấn đề lớn cần quan tâm là độ sẵn sàng của hệ thống. Nếu Redis chỉ chạy dưới dạng đơn lẻ (standalone), khi server đó gặp sự cố, toàn bộ ứng dụng phụ thuộc vào nó sẽ ngừng hoạt động. Để giải quyết vấn đề này, Redis hỗ trợ cơ chế replication cho phép tạo ra các bản sao (replica) của dữ liệu từ node master đến các node slave. Và đây chính là lúc Redis Sentinel phát huy vai trò của mình.
Redis Sentinel là một thành phần trong hệ sinh thái Redis, được thiết kế để giám sát các Redis instance, phát hiện lỗi và tự động chuyển đổi dự phòng (failover) khi node master bị sự cố. Ngoài ra, Sentinel còn cung cấp thông tin định tuyến cho client, giúp ứng dụng luôn kết nối được với Redis master hiện tại mà không cần can thiệp thủ công.
Đọc chi tiết: Redis là gì: Tổng hợp tính năng hữu ích nhất của Redis
Các thành phần trong Redis Sentinel
Redis Sentinel hoạt động trên mô hình master-replica (trước đây gọi là master–slave), với mục tiêu chính là đảm bảo hệ thống Redis luôn sẵn sàng hoạt động kể cả khi xảy ra sự cố. Các thành phần của Redis sentinel gồm:
- Master: là node chính và là nơi thực hiện các thao tác đọc và ghi dữ liệu. Trong một hệ thống Redis sử dụng Sentinel, tại mỗi thời điểm chỉ có một node được đóng vai trò master. Sentinel luôn theo dõi trạng thái của master này. Nếu master gặp sự cố (mất kết nối, dừng hoạt động…), Sentinel sẽ tự động chọn một replica để thay thế làm master mới.
- Replica: là các bản sao (slave) của master, chứa dữ liệu được đồng bộ từ master thông qua cơ chế replication. Replica có thể phục vụ các thao tác đọc (read) nhằm giảm tải cho master. Khi master gặp sự cố, một trong các replica sẽ được Sentinel chọn để thăng cấp thành master mới. Số lượng replica có thể từ 1 trở lên tùy theo yêu cầu về độ tin cậy và hiệu năng của hệ thống.
- Sentinel nodes: là các tiến trình giám sát độc lập, có nhiệm vụ theo dõi trạng thái của master và replica. Sentinel không lưu trữ dữ liệu Redis mà chỉ thực hiện các chức năng giám sát, phát hiện lỗi và điều phối quá trình failover. Ngoài chức năng giám sát, Sentinel còn đóng vai trò như một cơ chế định tuyến động (service discovery), nghĩa là các client có thể hỏi Sentinel để biết hiện tại Redis master là node nào, từ đó kết nối đúng địa chỉ mà không cần cấu hình lại thủ công mỗi khi có thay đổi.
Mối quan hệ giữa các thành phần trong Redis Sentinel. Nguồn: dev.to
Cơ chế hoạt động của Redis Sentinel
Sentinel hoạt động dựa trên cơ chế “đồng thuận theo số đông” (quorum consensus), nghĩa là chỉ khi đa số Sentinel đồng ý rằng master thực sự đã gặp sự cố thì quá trình failover mới được tiến hành. Qua đó giúp ngăn chặn tình huống “split-brain”, tức là khi hai node cùng tự nhận mình là master do không được kiểm soát chặt chẽ. Nói cách khác, Redis Sentinel đóng vai trò như một “người giám sát thông minh” đảm bảo hệ thống Redis luôn duy trì được tính ổn định và sẵn sàng, kể cả khi có sự cố xảy ra.
Quá trình hoạt động gồm các bước sau:
- Giám sát liên tục: Mỗi Sentinel sẽ gửi tín hiệu “ping” định kỳ đến các Redis node (master và replica) để kiểm tra xem chúng còn sống không. Mặc định, ping được gửi mỗi giây và nếu node không phản hồi sau 30 giây, nó sẽ bị nghi là lỗi.
- Phát hiện lỗi: Nếu một Sentinel thấy master không phản hồi trong một khoảng thời gian nhất định, nó sẽ tạm thời đánh dấu node đó là “có vấn đề” (subjectively down). Tuy nhiên, để chắc chắn, Sentinel sẽ “hỏi ý kiến” các Sentinel khác.
- Đồng thuận & xác nhận lỗi: Nếu đủ số lượng Sentinel đồng ý rằng master đã chết (đạt quorum), hệ thống sẽ xác định master thật sự lỗi (objectively down).
- Thực hiện failover: Một Sentinel được chọn làm “leader” thông qua thuật toán đồng thuận (dựa trên Raft) và bắt đầu quá trình failover: chọn một replica có ưu tiên cao nhất và dữ liệu mới nhất làm master mới, sau đó cập nhật lại cấu hình cho các replica còn lại trỏ về master mới.
- Cập nhật cho client: Sau khi chuyển đổi xong, Sentinel sẽ thông báo để client biết địa chỉ Redis master mới, giúp ứng dụng tiếp tục hoạt động mà không bị gián đoạn.
Để dễ hình dung hơn, hãy tưởng tượng bạn có một Redis master và hai bản sao (replica). Ba “người gác cổng” là các Redis Sentinel sẽ liên tục theo dõi tình trạng Redis. Nếu Redis master ngừng hoạt động và Sentinel nhận thấy điều đó, chúng nhanh chóng hội ý với nhau (dựa trên số lượng đủ gọi là quorum) và bầu chọn một replica mới lên làm master. Toàn bộ việc này xảy ra là tự động và không cần con người can thiệp.
Các tính năng chính của Redis Sentinel
- Giám sát (Monitoring): Sentinel liên tục theo dõi và kiểm tra xem Redis master và replica có đang hoạt động bình thường hay không bằng cách sử dụng các tín hiệu ping định kỳ để phát hiện sự cố kịp thời.
- Thông báo (Notification): Khi phát hiện có vấn đề (ví dụ như Redis master không phản hồi), Sentinel có thể gửi thông báo tới quản trị viên hệ thống hoặc các chương trình bên ngoài thông qua API. Nhờ đó, ta luôn biết khi nào Redis gặp sự cố để kịp thời xử lý.
- Tự động chuyển đổi dự phòng (Automatic Failover): Nếu master bị lỗi, Sentinel sẽ kích hoạt quá trình “failover”, nghĩa là chọn một Redis replica còn sống để thay thế làm master mới. Các replica còn lại sẽ tự động được cấu hình lại để kết nối với master mới và các ứng dụng sử dụng Redis cũng sẽ được cập nhật địa chỉ mới để kết nối lại đúng nơi. Quá trình này chỉ diễn ra khi có sự đồng thuận từ đa số các Sentinel instance (gọi là quorum) và thường yêu cầu ít nhất 3 Sentinel để đảm bảo tính tin cậy. Việc chuyển đổi này giúp hệ thống tiếp tục hoạt động mà không cần sự can thiệp của con người.
- Cung cấp thông tin cấu hình: Sentinel giúp các client biết được Redis master hiện tại là ai, để chúng luôn kết nối đúng node. Thay vì kết nối cứng vào một địa chỉ Redis cụ thể, client có thể hỏi Sentinel để luôn kết nối đúng node master ngay cả khi failover vừa xảy ra.
Cách triển khai Redis Sentinel
Chuẩn bị trước khi triển khai
Về cơ bản, một hệ thống Sentinel cần có:
- Một Redis master: node chính để ghi và đọc dữ liệu.
- Ít nhất một Redis replica: để sao lưu dữ liệu và sẵn sàng thay thế nếu master gặp sự cố
- Tối thiểu ba tiến trình Sentinel: Để đảm bảo khả năng giám sát, bầu chọn leader và thực hiện failover một cách chính xác, Redis Sentinel cần ít nhất ba tiến trình độc lập. Việc này giúp đạt được đồng thuận số đông (quorum) khi quyết định chuyển đổi master. Để tránh điểm lỗi đơn (single point of failure), các Sentinel nên được triển khai trên những server khác nhau để đảm bảo tính sẵn sàng cao (high availability).
Tạo file cấu hình mẫu cho Sentinel
Ví dụ như để khởi chạy một Redis master chạy ở cổng mặc định 6379, ta dùng file cấu hình redis-master.conf như sau:
bind 127.0.0.1protected-mode yes
port 6379dir ./dbfilename dump.rdb
save 900 1save 300 10save 60 10000Trong đó:
- bind 127.0.0.1: chỉ định Redis chỉ lắng nghe kết nối từ localhost (tăng bảo mật)
- protected-mode yes: bật chế độ bảo vệ, yêu cầu authentication hoặc bind cụ thể
- port 6379: chỉ định Redis sẽ chạy trên cổng 6379 là cổng mặc định nên có thể bỏ qua, nhưng khai báo rõ vẫn tốt để dễ quản lý.
- dir ./: chỉ định thư mục hiện tại (./) làm nơi lưu các file dữ liệu như snapshot (dump.rdb) hoặc log nếu bạn bật tính năng lưu trữ.
- save: cấu hình tự động lưu snapshot theo điều kiện (thời gian và số lượng thay đổi)
Ví dụ để thiết lập một Redis replica kết nối đến master, ta cấu hình trong file redis-replica.conf như sau:
bind 127.0.0.1protected-mode yes
port 6380replicaof 127.0.0.1 6379
replica-read-only yes| bind 127.0.0.1protected-mode yes port 6380replicaof 127.0.0.1 6379 replica-read-only yes |
Trong đó:
- bind 127.0.0.1: tương tự như master, chỉ lắng nghe localhost.
- 6380: là cổng mà replica sẽ chạy.
- replicaof 127.0.0.1 6379: replica sẽ sao chép dữ liệu từ master tại địa chỉ 127.0.0.1 và cổng 6379.
- replica-read-only yes: đảm bảo replica chỉ phục vụ read operations.
Cấu hình Sentinel
Tiếp theo, ta cần cấu hình một file sentinel.conf để Sentinel giám sát master. Ví dụ để Sentinel theo dõi một Redis master tại 127.0.0.1:6379, ta dùng:
port 26379bind 127.0.0.1
sentinel monitor mymaster 127.0.0.1 6379 2sentinel down-after-milliseconds mymaster 5000sentinel failover-timeout mymaster 10000sentinel parallel-syncs mymaster 1Trong đó:
- port 26379: cổng mặc định của Sentinel
- bind 127.0.0.1: địa chỉ Sentinel lắng nghe
- sentinel monitor mymaster 127.0.0.1 6379 2: theo dõi master tên là mymaster tại địa chỉ 127.0.0.1:6379, cần 2 Sentinel đồng thuận để failover.
- down-after-milliseconds mymaster 5000: nếu master không phản hồi trong 5 giây, Sentinel sẽ đánh dấu là lỗi tạm thời.
- failover-timeout: thời gian tối đa để hoàn tất quá trình chuyển đổi master (10 giây).
- parallel-syncs: số replica được phép đồng bộ song song với master mới (ở đây là 1).
Khởi chạy Redis và Sentinel
Sau khi cấu hình xong, ta chạy các tiến trình bằng lệnh:
redis-server redis-master.confredis-server redis-replica.confredis-sentinel sentinel.confNếu có nhiều Sentinel, bạn nên tạo các bản sao cấu hình sentinel-2.conf, sentinel-3.conf (chỉ thay port) và khởi chạy tương tự.
Kiểm tra trạng thái hoặc mô phỏng failover
Ví dụ như để kiểm tra Redis master hiện tại từ Sentinel, ta dùng:
redis-cli -p 26379 SENTINEL get-master-addr-by-name mymasterTrong đó:
- -p 26379: là cổng Sentinel đang chạy.
- get-master-addr-by-name: là lệnh yêu cầu Sentinel trả về địa chỉ IP và cổng của master hiện tại.
Khi ta tắt Redis master (bằng pkill, Ctrl+C hoặc docker stop), Sentinel sẽ tự động phát hiện sự cố và tiến hành failover.
Các lệnh kiểm tra khác:
# Kiểm tra tất cả masters được giám sátredis-cli -p 26379 SENTINEL masters
# Kiểm tra các replica của masterredis-cli -p 26379 SENTINEL replicas mymaster
# Kiểm tra trạng thái của các Sentinel khác redis-cli -p 26379 SENTINEL sentinels mymaster
# Trigger failover thủ công (để test)redis-cli -p 26379 SENTINEL failover mymasterĐọc chi tiết: Redis CLI là gì: Thực hành dùng dòng lệnh để tương tác với Redis
Ưu điểm và hạn chế của Redis Sentinel
| Ưu điểm | Hạn chế |
| Tự động giám sát và chuyển đổi master khi gặp sự cố, giúp đảm bảo hệ thống Redis luôn sẵn sàng hoạt động. | Không hỗ trợ phân mảnh dữ liệu (sharding), không phù hợp với các hệ thống cần mở rộng quy mô dữ liệu theo chiều ngang như Redis Cluster. |
| Dễ triển khai và không yêu cầu phần mềm trung gian hay proxy đi kèm. | Chỉ giám sát và thực hiện failover ở mức node, không đảm bảo toàn vẹn dữ liệu. Nếu quá trình replication giữa master và replica chưa kịp đồng bộ (do bản chất bất đồng bộ), có thể xảy ra mất dữ liệu tạm thời khi master gặp sự cố. |
| Cấu hình đơn giản, dễ hiểu, có thể áp dụng ngay cả trong môi trường phát triển hoặc sản phẩm nhỏ đến trung bình. | Client cần hỗ trợ cơ chế kết nối thông qua Sentinel, nếu không sẽ phải xử lý thủ công mỗi khi master thay đổi. |
| Hoạt động độc lập với Redis, nên dễ dàng mở rộng và triển khai trên nhiều môi trường khác nhau. | Không phù hợp khi chạy trên cùng máy với Redis. Nếu máy chủ chết thì cả Redis và Sentinel đều “biến mất”, mất tác dụng failover. |
| Phù hợp với các hệ thống real-time, có yêu cầu uptime cao nhưng chưa đến mức cần chia nhỏ dữ liệu theo cluster. | Việc thiết lập quorum cần tối thiểu 3 Sentinel, nếu không dễ xảy ra tình trạng không bầu được master mới hoặc sự cố split-brain (khi nhiều node cùng nhận làm master do thiếu đồng thuận). |
| Hỗ trợ gửi cảnh báo (notification) khi Redis gặp sự cố, giúp bạn phản ứng kịp thời trong môi trường production. | Không cung cấp cơ chế bảo mật nâng cao hoặc xác thực giữa Sentinel và Redis, cần bổ sung nếu triển khai trong môi trường nhạy cảm. |
Redis Sentinel vs Redis Cluster
| Tiêu chí | Redis Sentinel | Redis Cluster |
| Mục tiêu chính | Được thiết kế để đảm bảo tính sẵn sàng cao cho Redis. Khi Redis master gặp sự cố, Sentinel sẽ tự động phát hiện và chỉ định một replica lên thay thế. Tập trung vào tính ổn định, không mở rộng dữ liệu. | Hướng đến khả năng mở rộng quy mô dữ liệu (scalability) và độ sẵn sàng. Cluster chia dữ liệu thành các phần nhỏ (shard) và phân phối chúng qua nhiều master. Mỗi master có replica để dự phòng. |
| Kiến trúc hệ thống | Bao gồm 1 Redis master, 1 hoặc nhiều replica và tối thiểu 3 tiến trình Sentinel chạy độc lập để giám sát hệ thống và thực hiện failover khi cần thiết. | Bao gồm nhiều master, mỗi master quản lý một phần dữ liệu riêng. Mỗi master có ít nhất 1 replica đi kèm. Để Redis Cluster hoạt động cần có tối thiểu 3 master node. Tuy nhiên, để hệ thống có thể tự động failover khi một master bị lỗi, Redis khuyến nghị triển khai ít nhất 6 node (3 master + 3 replica). |
| Khả năng tự động chuyển đổi (failover) | Có – Khi master không phản hồi, Sentinel tự động bầu chọn một replica để trở thành master mới, cập nhật cấu hình cho các Sentinel và client khác. Toàn bộ quá trình diễn ra tự động mà không cần thao tác thủ công. | Có – Nếu một master trong cluster bị lỗi, một replica của nó sẽ tự động lên thay. Cluster cũng tự cập nhật routing nội bộ để client kết nối lại đúng node mới. |
| Khả năng phân mảnh dữ liệu (sharding) | Không hỗ trợ – Toàn bộ dữ liệu nằm trên một Redis master. Replica chỉ là bản sao phục vụ cho việc dự phòng, không tăng khả năng lưu trữ. | Có – Redis Cluster phân chia dữ liệu thành 16,384 hash slots, phân phối đều giữa các master. Điều này giúp dữ liệu có thể được chia và lưu trữ hiệu quả ở nhiều máy. |
| Cách client kết nối | Client không kết nối trực tiếp vào Redis, mà sẽ hỏi Sentinel địa chỉ master hiện tại. Khi failover xảy ra, Sentinel trả về địa chỉ mới, giúp ứng dụng không bị gián đoạn. | Client phải hỗ trợ Redis Cluster protocol, để biết cách định tuyến từng key đến đúng node theo hash slot. Khi truy vấn nhầm node, Redis sẽ trả về phản hồi MOVED hoặc ASK, hướng dẫn client chuyển sang node phù hợp. Do đó, client cần hỗ trợ giao thức Cluster để xử lý các redirect này tự động. Một số thư viện client cần cấu hình thêm để hoạt động trơn tru. |
| Độ phức tạp triển khai và vận hành | Dễ triển khai hơn, cấu hình đơn giản, dễ debug. Phù hợp với các đội kỹ thuật nhỏ hoặc ứng dụng không yêu cầu mở rộng dữ liệu. | Phức tạp hơn do cần thiết lập nhiều node, đồng bộ slot, giám sát tình trạng phân mảnh và xử lý tình huống mất node phức tạp hơn. |
| Khả năng mở rộng hệ thống | Khả năng mở rộng hạn chế, chỉ mở rộng theo chiều dọc (nâng cấp RAM, CPU cho Redis master). Không thể chia nhỏ dữ liệu để chạy trên nhiều máy. | Có khả năng mở rộng theo chiều ngang. Chỉ cần thêm master vào cluster và redis sẽ tự động phân phối dữ liệu. Rất phù hợp với ứng dụng lớn hoặc đang tăng trưởng nhanh. |
| Trường hợp sử dụng | Khi cần tính sẵn sàng cao cho Redis nhưng không cần chia nhỏ dữ liệu. Thích hợp cho các ứng dụng vừa và nhỏ, như cache, session store, queue hoặc các hệ thống đơn giản. | Khi cần xử lý khối lượng dữ liệu lớn, nhiều request đồng thời, hoặc cần hệ thống có thể mở rộng dễ dàng mà không lo quá tải Redis đơn. Phù hợp cho hệ thống phân tán, xử lý real-time quy mô lớn. |
Đọc chi tiết: Redis Cluster là gì: Hướng dẫn sử dụng cơ bản cho người mới
Các câu hỏi phổ biến về Redis Sentinel
Redis Sentinel có phải là giải pháp high availability (HA) hoàn chỉnh không?
Không hoàn toàn. Redis Sentinel cung cấp tính sẵn sàng cao (HA) ở mức cơ bản: giám sát Redis master, tự động chuyển đổi sang replica khi phát hiện lỗi, và cập nhật lại thông tin cho các client. Tuy nhiên, nó không bảo vệ dữ liệu khỏi mất mát nếu master chết trước khi ghi xong dữ liệu vào disk, và không hỗ trợ phân mảnh dữ liệu. Vì vậy, với các hệ thống lớn hoặc yêu cầu toàn vẹn dữ liệu cao, Sentinel nên kết hợp với các cơ chế backup, persistence hoặc cân nhắc dùng Redis Cluster.
Có thể triển khai Redis Sentinel trong môi trường Docker không?
Có thể, nhưng cần thiết kế cẩn thận. Redis Sentinel sử dụng tên host và địa chỉ IP thực để giao tiếp với Redis và các Sentinel khác, nên khi chạy trong Docker ta cần đảm bảo:
- Mỗi container Redis/Sentinel có IP hoặc hostname tĩnh (sử dụng Docker Compose với mạng bridge đặt tên rõ ràng).
- Tránh sử dụng localhost vì mỗi container có localhost riêng.
- Dùng
--sentinel announce-ipvàannounce-portnếu chạy trong môi trường NAT hoặc load balancer để các Sentinel/Redis biết địa chỉ thực của nhau.
Ngoài ra, ta nên tách riêng Redis và Sentinel trên các container độc lập và lý tưởng nhất là trên các node khác nhau (nếu chạy trên Kubernetes hoặc cluster).
Đọc chi tiết: Tối ưu hóa Redis với Docker: Hướng dẫn cơ bản cho người mới
Có thể kết hợp Redis Sentinel với Redis Cluster không?
Không nên. Redis Sentinel và Redis Cluster là hai kiến trúc hoạt động khác nhau, phục vụ mục tiêu khác nhau: Sentinel quản lý failover cho một Redis master duy nhất (HA), còn cluster dùng nhiều Redis master để chia nhỏ dữ liệu (scalability). Chúng không tương thích với nhau và không nên kết hợp. Nếu bạn đã sử dụng Redis Cluster, hệ thống đã có cơ chế tự failover tích hợp. Trường hợp bạn cần cả failover lẫn sharding, hãy dùng Redis Cluster đúng cách thay vì kết hợp thêm Sentinel.
Tổng kết
Redis Sentinel là một công cụ mạnh mẽ nhưng không phức tạp, giúp giám sát Redis, tự động phát hiện lỗi và chuyển đổi master một cách an toàn, mà không cần phải can thiệp thủ công. Với những hệ thống vừa và nhỏ, hoặc các ứng dụng không yêu cầu phân mảnh dữ liệu, Sentinel là giải pháp lý tưởng để đảm bảo Redis luôn sẵn sàng phục vụ. Tuy vậy, hãy hiểu rõ điểm mạnh và giới hạn của Sentinel để triển khai đúng nơi, đúng thời điểm. Nếu bạn cần cả tính sẵn sàng và khả năng mở rộng, hãy cân nhắc Redis Cluster hoặc giải pháp kết hợp phù hợp hơn.
ITviec hy vọng bài viết đã giúp bạn nắm vững kiến thức nền tảng về Redis Sentinel và tự tin triển khai nó trong hệ thống của mình.
