Trong kiến trúc hệ thống phân tán sử dụng Redis, khi nào chúng ta nên lựa chọn Redis Sentinel thay vì Redis Cluster và những giới hạn kiến trúc nào cần lưu ý khi vận hành ở môi trường Production?

Question

Accepted Answer

Phân biệt Redis Sentinel và Redis Cluster
Cả Redis Sentinel và Redis Cluster đều là các giải pháp đảm bảo tính sẵn sàng cao (High Availability) cho Redis, nhưng chúng được thiết kế cho các mô hình kiến trúc và bài toán vận hành hoàn toàn khác nhau.
1. Redis Sentinel (Master-Replica with Failover)

Kiến trúc: Gồm một hoặc nhiều Redis Master node, các Redis Replica node đồng bộ dữ liệu theo thời gian thực, và một hệ thống giám sát độc lập gọi là Sentinel (thường chạy tối thiểu 3 node Sentinel để tránh hiện tượng Split-Brain).
Cơ chế hoạt động: Sentinel liên tục kiểm tra sức khỏe của Master và Replica. Khi Master gặp sự cố sập nguồn hoặc mất kết nối mạng, các Sentinel sẽ tiến hành bầu chọn (Quorum) để thăng cấp một Replica lên làm Master mới, đồng thời cấu hình lại các Replica còn lại trỏ về Master mới và thông báo cho ứng dụng Client biết địa chỉ mới thông qua Service Discovery.
Giới hạn: Toàn bộ dữ liệu của hệ thống bị giới hạn trong dung lượng RAM của một máy chủ duy nhất (Single Master Node). Mặc dù có thể scale chiều đọc bằng cách thêm Replica, nhưng không thể scale chiều ghi (Write Scalability).

2. Redis Cluster (Distributed Sharding Architecture)

Kiến trúc: Phân tán dữ liệu trên nhiều cụm Master node khác nhau (tối thiểu khuyến nghị 3 Master node và mỗi Master đi kèm ít nhất 1 Replica). Dữ liệu được chia nhỏ thành 16,384 Hash Slots dựa trên thuật toán CRC16.
Cơ chế hoạt động: Không có node trung gian điều phối, các node trong Cluster tự kết nối với nhau qua cổng gossip protocol để kiểm tra trạng thái sống còn. Client có thể kết nối tới bất kỳ node nào trong Cluster; nếu dữ liệu không nằm trên node đó, node sẽ trả về thông báo chuyển hướng (MOVED hoặc ASK) để Client tự động chuyển truy vấn đến đúng node chứa Hash Slot.
Giới hạn: Phức tạp trong vận hành, không hỗ trợ tối ưu các câu lệnh đa khóa (Multi-key operations) trừ khi sử dụng kỹ thuật Hash Tags ({user1000}.profile và {user1000}.settings để ép buộc nằm chung một Hash Slot), việc cấu hình sao lưu và khôi phục phức tạp hơn so với Sentinel.

Tiêu chí lựa chọn và Lưu ý thực chiến cho cấp độ Middle

Khi nào chọn Sentinel: Khi tổng dung lượng dữ liệu của hệ thống nhỏ hơn dung lượng RAM vật dụng cho phép của một máy chủ đơn lẻ (ví dụ dưới 30GB đến 50GB), hoặc ứng dụng tập trung vào các bài toán Session Store, Rate Limiting đơn giản với lưu lượng ghi vừa phải.
Khi nào chọn Cluster: Khi hệ thống cần lưu trữ dữ liệu vượt quá dung lượng RAM của một máy chủ đơn lẻ, hoặc cần phân tách tải ghi (Write Load) ra nhiều phân vùng độc lập.
Lưu ý Production: Tránh cấu hình Redis Sentinel hoặc Redis Cluster trên cùng một máy chủ vật lý hoặc cùng một Availability Zone (AZ) trên Cloud để phòng tránh rủi ro sập toàn bộ hệ thống khi phần cứng hoặc trung tâm dữ liệu gặp sự cố mất điện cục bộ.

Trong kiến trúc hệ thống phân tán sử dụng Redis, khi nào chúng ta nên lựa chọn Redis Sentinel thay vì Redis Cluster và những giới hạn kiến trúc nào cần lưu ý khi vận hành ở môi trường Production?

Phân biệt Redis Sentinel và Redis Cluster

Làm Chủ Phỏng Vấn & Nâng Cao Trình Độ Chuyên Nghiệp

Tải Tuyển Tập 100+ Câu Hỏi Phỏng Vấn Chuyên Sâu (PDF)

Cần Mentor Phỏng Vấn Thử 1-1 & Tối Ưu CV?

Kiểm Tra CV Chuẩn ATS Miễn Phí

Câu hỏi nosql liên quan cùng chủ đề