Sự cố rủi ro: Khi máy chủ Redis độc lập bất ngờ sập
Hệ thống của bạn đang chịu tải 10.000 lượt truy cập đồng thời trong khung giờ vàng săn sale. Mọi session đăng nhập và giỏ hàng đều nằm trên RAM của Redis để đảm bảo phản hồi dưới 5ms. Đột nhiên máy chủ Redis hết bộ nhớ hoặc kernel tự động kill tiến trình. Ứng dụng lập tức trả lỗi 500 hàng loạt. Người dùng không thể thanh toán.
Đây là kịch bản điển hình của điểm nghẽn đơn lẻ (Single Point of Failure – SPOF). Nếu chỉ chạy một node Redis duy nhất, bạn phải chờ kỹ sư nhận cảnh báo, SSH vào server và khởi động lại dịch vụ. Quá trình đó thường mất từ 15 đến 30 phút. Giải pháp triệt để là triển khai kiến trúc tính sẵn sàng cao (High Availability) với cơ chế tự động Failover.
Cơ chế hoạt động của Redis Sentinel
Redis Sentinel đóng vai trò như một hệ thống trọng tài độc lập, không tham gia lưu trữ dữ liệu của người dùng. Mô hình bao gồm ba thành phần:
- Redis Master: Nhận toàn bộ thao tác ghi (Write) và xử lý đọc (Read). Chỉ có đúng một Master hoạt động tại một thời điểm.
- Redis Replica (Slave): Đồng bộ dữ liệu liên tục từ Master theo thời gian thực và sẵn sàng chia tải cho các truy vấn đọc.
- Redis Sentinel: Nhóm tiến trình giám sát trạng thái sức khỏe của Master và Replica qua các gói tin ping định kỳ.
Nếu Master ngừng phản hồi quá thời gian quy định (thường là 5 giây), một Sentinel sẽ gắn nhãn nó là lỗi cục bộ (Subjectively Down – sdown). Sentinel này lập tức gửi tín hiệu thăm dò đến các Sentinel khác. Khi đủ số lượng phiếu đồng thuận (Quorum), sự cố được xác nhận trên toàn cụm (Objectively Down – odown).
Ngay sau đó, nhóm Sentinel tự bầu ra một Leader để kích hoạt tiến trình Failover. Trọng tài sẽ chọn một Replica có độ trễ đồng bộ thấp nhất để thăng cấp lên làm Master mới. Toàn bộ chu trình chỉ mất khoảng 5 đến 7 giây mà không cần con người gõ bất kỳ dòng lệnh can thiệp nào.
Lưu ý: Bạn cần tối thiểu 3 node Sentinel trên môi trường thực tế. Số lượng node lẻ giúp cụm luôn đạt được đa số phiếu (Quorum = 2), tránh hiện tượng phân mảnh não (split-brain) khi xảy ra sự cố gián đoạn mạng.
Thực hành: Dựng cụm Redis Sentinel bằng Docker Compose
Một lỗi phổ biến khi dựng mô hình này trên Docker là mount chung một file sentinel.conf cho cả 3 container. Khi khởi động, Sentinel sẽ tự động tạo một mã myid duy nhất và ghi đè trực tiếp vào file cấu hình. Dùng chung file sẽ gây tranh chấp ID và làm hỏng cả cụm. Dưới đây là cách thiết lập chuẩn xác với 3 file cấu hình độc lập.
1. Chuẩn bị cấu trúc thư mục
Khởi tạo thư mục dự án và các file cấu hình riêng cho từng Sentinel:
mkdir -p redis-sentinel-ha/sentinel && cd redis-sentinel-ha
touch sentinel/sentinel-1.conf sentinel/sentinel-2.conf sentinel/sentinel-3.conf
2. Cấu hình file sentinel-1.conf
Thêm nội dung sau vào file sentinel/sentinel-1.conf (làm tương tự cho file sentinel-2.conf và sentinel-3.conf):
port 26379
dir /tmp
sentinel monitor mymaster redis-master 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 10000
sentinel parallel-syncs mymaster 1
Ý nghĩa kỹ thuật của từng tham số cấu hình:
sentinel monitor mymaster redis-master 6379 2: Đặt tên nhóm giám sát là mymaster, trỏ tới hostname redis-master cổng 6379, yêu cầu tối thiểu 2 Sentinel xác nhận để kích hoạt failover.down-after-milliseconds mymaster 5000: Coi Master mất kết nối nếu không phản hồi ping trong 5.000ms (5 giây).failover-timeout mymaster 10000: Hạn mức 10 giây cho toàn bộ tiến trình đổi vai trò Master. Quá thời gian này, Sentinel khác sẽ thử lại.parallel-syncs mymaster 1: Số lượng Replica được phép đồng bộ dữ liệu cùng lúc với Master mới. Giữ giá trị 1 để tránh làm nghẽn băng thông mạng.
3. Thiết lập docker-compose.yml
Mô hình gồm 1 Master, 1 Replica và 3 Sentinel giao tiếp qua mạng bridge nội bộ:
version: '3.8'
networks:
redis-net:
driver: bridge
services:
redis-master:
image: redis:7-alpine
container_name: redis-master
ports:
- "6379:6379"
networks:
- redis-net
redis-replica:
image: redis:7-alpine
container_name: redis-replica
ports:
- "6380:6379"
command: redis-server --replicaof redis-master 6379
depends_on:
- redis-master
networks:
- redis-net
sentinel-1:
image: redis:7-alpine
container_name: sentinel-1
command: redis-sentinel /etc/redis/sentinel.conf
volumes:
- ./sentinel/sentinel-1.conf:/etc/redis/sentinel.conf
ports:
- "26379:26379"
depends_on:
- redis-master
- redis-replica
networks:
- redis-net
sentinel-2:
image: redis:7-alpine
container_name: sentinel-2
command: redis-sentinel /etc/redis/sentinel.conf
volumes:
- ./sentinel/sentinel-2.conf:/etc/redis/sentinel.conf
ports:
- "26380:26379"
depends_on:
- redis-master
- redis-replica
networks:
- redis-net
sentinel-3:
image: redis:7-alpine
container_name: sentinel-3
command: redis-sentinel /etc/redis/sentinel.conf
volumes:
- ./sentinel/sentinel-3.conf:/etc/redis/sentinel.conf
ports:
- "26381:26379"
depends_on:
- redis-master
- redis-replica
networks:
- redis-net
4. Khởi chạy và xác thực trạng thái cụm
Bật toàn bộ hệ thống bằng lệnh:
docker compose up -d
Kiểm tra trạng thái nhận diện Master từ phía Sentinel:
docker exec -it sentinel-1 redis-cli -p 26379 sentinel master mymaster
Hãy chú ý hai dòng thông số quan trọng trong kết quả trả về: num-slaves phải bằng 1 và num-other-sentinels phải bằng 2. Lúc này cả 3 Sentinel đã bắt tay thành công.
5. Kiểm thử kịch bản tự động Failover
Mô phỏng sự cố bằng cách tắt ngang container Master:
docker stop redis-master
Theo dõi dòng sự kiện trong log của Sentinel:
docker logs -f sentinel-1
Các sự kiện cốt lõi sẽ diễn ra theo đúng thứ tự kỹ thuật:
+sdown master mymaster 172.x.x.x 6379: Hết 5 giây không nhận được PONG, Sentinel-1 đánh dấu Master lỗi cục bộ.+odown master mymaster 172.x.x.x 6379 #quorum 2/2: Nhận đủ 2 phiếu đồng thuận, xác nhận sự cố diện rộng.+try-failover master mymaster...: Bắt đầu quy trình chuyển giao quyền điều hành.+switch-master mymaster redis-master 6379 redis-replica 6379: Thăng cấp replica lên làm Master mới.
Kiểm tra lại vai trò hiện tại của redis-replica:
docker exec -it redis-replica redis-cli role
Dòng đầu tiên xuất ra là master. Hệ thống đã tự động phục hồi trong khoảng 6 giây. Khi bạn bật lại container redis-master cũ bằng lệnh docker start redis-master, Sentinel sẽ tự động hạ cấp node này xuống làm Replica nhận dữ liệu từ Master mới.
Tổng kết
Redis Sentinel là giải pháp cân bằng tốt giữa chi phí vận hành và độ tin cậy cho các hệ thống vừa và nhỏ. Bạn không cần chuyển sang kiến trúc Redis Cluster phức tạp nếu chỉ có nhu cầu bảo vệ luồng đọc/ghi trước sự cố sập node. Với việc cấu hình tách biệt file và tận dụng mạng nội bộ trong Docker Compose, bạn có một môi trường kiểm thử failover chuẩn xác trước khi đưa lên production.

