Redis (Phần 2) - Kiến trúc và khả năng mở rộng

Trong Phần 1, chúng ta đã hiểu tại sao Redis lại nhanh và cách nó hoạt động bên trong. Nhưng ở môi trường production thực tế, chúng ta hiếm khi chỉ chạy một con Redis duy nhất.

Nếu con Redis đó sập (chết phần cứng, đứt cáp mạng), toàn bộ ứng dụng của bạn sẽ đi đứt. Hoặc nếu dữ liệu phình to lên 500GB, một con server không thể gánh nổi.

Đây là lúc chúng ta cần nói về Kiến trúc của Redis.

---

Phần II: Các mô hình kiến trúc Redis

1. Mô hình Master-Replica (Replication)

Để giải quyết vấn đề mất dữ liệu hoặc sập server khi chạy một con Redis duy nhất, khái niệm Replication ra đời.

1.1 Vấn đề Data Consistency (Tính nhất quán dữ liệu)

Trong kiến trúc Master-Replica của Redis, quá trình nhân bản (replication) mặc định là bất đồng bộ (asynchronous). Điều này dẫn đến các thách thức về Data Consistency (Tính nhất quán dữ liệu):

---

2. Redis Sentinel (High Availability)

Lưu ý: Sentinel không phải là một kiến trúc độc lập thay thế cho Master-Replica. Thực chất, nó là một lớp quản lý (management layer) được gắn thêm vào trên nền tảng kiến trúc Master-Replica.

Ở phần trước, nhược điểm chí mạng của Master-Replica là bạn phải tự tay can thiệp khi Master sập. Để tự động hóa quá trình "thức dậy lúc 3h sáng" đó, Redis cung cấp công cụ Sentinel.

Redis Sentinel bao gồm các tiến trình chạy ngầm làm nhiệm vụ "lính gác". Chúng giám sát liên tục hệ thống Master-Replica hiện tại của bạn.

Một câu hỏi kinh điển thường gặp khi thiết kế hệ thống là: Giữa nhiều node Replica, Sentinel sẽ chọn node nào để làm Master mới?

💡 Tiêu chí bầu chọn Master mới của Sentinel: Sentinel sẽ không chọn ngẫu nhiên mà đánh giá các Replica dựa trên các tiêu chí sau (theo thứ tự ưu tiên):

1. Tình trạng kết nối: Bỏ qua các Replica đang bị mất kết nối hoặc phản hồi quá chậm.
2. Replica Priority (Độ ưu tiên): Chọn node có replica-priority thấp nhất (do bạn thiết lập trong file cấu hình). Lưu ý: Nếu gán replica-priority = 0, node đó sẽ không bao giờ được lên làm Master.
3. Replication Offset (Mức độ cập nhật dữ liệu): Nếu các node có cùng priority, Sentinel sẽ chọn node có offset lớn nhất. Nói cách khác, Replica nào đồng bộ được nhiều dữ liệu nhất từ Master cũ (tức là dữ liệu mới nhất) sẽ thắng.
4. Run ID: Nếu cả priority và offset đều bằng nhau, Sentinel sẽ chọn Replica có Run ID (chuỗi định danh ngẫu nhiên khi khởi động) theo thứ tự từ điển nhỏ nhất.

Ưu điểm:

• High Availability (Tính sẵn sàng cao): Chết Master hệ thống tự phục hồi trong vài giây, không cần can thiệp bằng tay.

Nhược điểm:

• Hơi tốn tài nguyên: Bạn cần chạy ít nhất 3 node Sentinel để tránh hiện tượng Split-Brain (Chia rẽ phiếu bầu).
• Vẫn chưa giải quyết được bài toán Scale-out ghi: Tất cả lệnh Write vẫn chỉ đổ về một con Master duy nhất.

---

3. Redis Cluster (Sharding & Khả năng mở rộng)

Redis Cluster là kiến trúc phù hợp khi cần mở rộng dung lượng, throughput và khả năng chịu lỗi bằng cách chia nhỏ dữ liệu thành nhiều hash slot nằm trên nhiều Master khác nhau.

3. Gossip Protocol & Failover (Tự động phục hồi lỗi):

Khác với mô hình Master-Replica truyền thống phải dựa vào một bên thứ 3 (như Sentinel) để giám sát, các node trong Redis Cluster tự quản lý lẫn nhau thông qua một giao thức mạng ngang hàng (P2P) gọi là Gossip Protocol.

• Gossip Protocol hoạt động như thế nào? Giống như cách những lời đồn (gossip) lan truyền trong đám đông, cứ mỗi giây, một node sẽ "ping" tới một vài node ngẫu nhiên khác trong Cluster để trao đổi thông tin cấu hình và trạng thái. Nếu Node A phát hiện Master B không phản hồi, nó sẽ tạm đánh dấu B là PFAIL (Possible Failure - Nghi ngờ sập) và "bơm" tin đồn này cho các node khác. Khi có quá nửa số Master trong cụm cùng xác nhận B không phản hồi, Master B chính thức bị dán nhãn là FAIL (Đã sập).

• Quá trình Failover (Bầu Master mới):

  1. Khi Master B bị dán nhãn FAIL, các Replica của B (ví dụ: Replica B1, B2) sẽ nhận ra sếp của mình đã chết và chúng bắt đầu một cuộc "bầu cử".
  2. Các Replica này gửi thông điệp xin phiếu bầu (vote) tới tất cả các Master còn sống trong Cluster (như Master A, Master C).
  3. Để tránh tình trạng phiếu bầu bị chia nhỏ, Replica nào có Replication Offset lớn nhất (tức là nắm giữ dữ liệu cập nhật mới nhất từ Master cũ) sẽ được "châm chước" cho xin vote trước.
  4. Ngay khi Replica B1 nhận được sự đồng thuận của quá nửa số Master còn sống, nó chính thức được "promote" lên làm Master mới.
  5. B1 tự động tiếp quản lại toàn bộ hash slots mà B để lại, sau đó gửi bản tin Gossip thông báo cho toàn mạng lưới: "Từ giờ tôi là Master mới quản lý các slot này!". Toàn hệ thống được cập nhật cấu hình và tiếp tục hoạt động bình thường.

4. Ưu điểm:

• Scale ngang rất tốt: Tăng dung lượng lưu trữ vượt quá giới hạn RAM của một máy vật lý.
• Tăng Throughput: Tải được chia đều ra nhiều máy chủ khác nhau.
• Tự động Failover: Tự phục hồi khi có node chết mà không cần dùng đến Sentinel.
• Không cần Proxy trung tâm: Kiến trúc phi tập trung giúp loại bỏ điểm nghẽn (bottleneck).

5. Nhược điểm:

• Kiến trúc và vận hành phức tạp hơn rất nhiều so với Redis đơn lẻ hay Master-Replica.
• Bị giới hạn thao tác Multi-key: Không thể gọi lệnh trên nhiều key cùng lúc (như MGET, MSET, SUNION) nếu các key nằm trên những slot khác nhau.
• Vẫn có khả năng mất một ít dữ liệu khi Failover do quá trình đồng bộ từ Master xuống Replica là bất đồng bộ.
• Quá trình chuyển đổi, chia lại dữ liệu (Resharding) khá phức tạp.
• Không phù hợp với các truy vấn phức tạp.

---

4. Tổng kết: So sánh 3 Kiến trúc Redis

Để dễ hình dung và ra quyết định thiết kế hệ thống, dưới đây là bảng so sánh tổng quan giữa 3 kiến trúc phổ biến nhất:

Tiêu chí	Master-Replica	Redis Sentinel	Redis Cluster
Mục đích chính	Phân tải đọc (Read Scale)	Phục hồi lỗi tự động (High Availability)	Mở rộng toàn diện (Scale-out Write & Storage)
Tự động Failover	❌ Không (Cần làm bằng tay)	✅ Có (Mất vài giây)	✅ Có (Tự động thông qua Gossip)
Khả năng Scale Đọc (Read)	✅ Tốt (Thêm Replica)	✅ Tốt (Giống Master-Replica)	✅ Rất tốt (Phân tán trên nhiều Master)
Khả năng Scale Ghi (Write)	❌ Kém (Chỉ ghi ở 1 Master)	❌ Kém (Chỉ ghi ở 1 Master)	✅ Rất tốt (Ghi phân tán trên nhiều Master)
Dung lượng lưu trữ	Bị giới hạn bởi RAM của 1 máy	Bị giới hạn bởi RAM của 1 máy	🚀 Vô hạn (Bằng tổng RAM các máy cộng lại)
Độ phức tạp vận hành	⭐ Dễ	⭐⭐ Trung bình (Cần duy trì số lẻ node)	⭐⭐⭐ Khó (Cấu hình slot, routing phức tạp)
Hỗ trợ lệnh Multi-key	✅ Hỗ trợ đầy đủ	✅ Hỗ trợ đầy đủ	⚠️ Hạn chế (Các key phải nằm cùng hash slot)
Tính nhất quán dữ liệu	⚠️ Eventual (Có thể đọc trễ data ở Replica)	⚠️ Eventual (Nguy cơ mất data lúc Failover)	⚠️ Eventual (Nguy cơ mất data lúc Failover)
Use-case khuyên dùng	App nhỏ, chấp nhận hệ thống có thể bị downtime một lúc	App Production tiêu chuẩn (E-commerce, SaaS)	Siêu hệ thống, Big Data (Discord, Twitter, v.v.)

💡 Chốt lại, tôi nên chọn cái nào?

• Hầu hết các dự án ở môi trường Production tiêu chuẩn sẽ ưu tiên dùng Redis Sentinel (hoặc mua các dịch vụ Managed Redis có sẵn High Availability trên Cloud). Nó cân bằng hoàn hảo giữa tính ổn định, dễ vận hành và chi phí.
• Chỉ đụng tới Redis Cluster khi bạn có bài toán thực sự khổng lồ (hàng trăm GB Cache, hoặc chịu tải hàng trăm nghìn lượt Write mỗi giây) mà việc nhồi thêm RAM vào một con server (Scale-up) là bất khả thi hoặc quá tốn kém.

Phần tiếp theo (Phần 3) sẽ là nơi chúng ta áp dụng Redis vào giải quyết các bài toán lập trình cụ thể như: Distributed Lock, Rate Limiting, Pub/Sub, ...