I. Kiến trúc Master-Slave trong Redis

Kiến trúc Redis tương tự MySQL, hỗ trợ mô hình master-slave để sao lưu dữ liệu qua nhiều máy chủ. Các ứng dụng thường kết nối đến load balancer (LB) ảo, sau đó LB phân phối yêu cầu đến các máy chủ Redis cụ thể.

Đặc điểm sao chép master-slave

• Một master có thể có nhiều slave
• Một slave chỉ thuộc về một master
• Dữ liệu di chuyển theo chiều đơn (master → slave)
• Master cho phép ghi dữ liệu
• Slave chỉ đọc dữ liệu

Vấn đề về kích hoạt dữ liệu bền vững

Ví dụ gây mất toàn bộ dữ liệu:

1. Node A (master) tắt tính năng dữ liệu bền vững, node B và C (slave) sao chép từ A
2. A bị sập, dịch vụ khởi động lại nhanh nhưng không còn dữ liệu do tắt bền vững
3. B và C xóa dữ liệu cục bộ vì nhận dữ liệu trống từ A

Tắt dữ liệu bền vững trên master đồng thời bật tự động khởi động là hành vi nguy hiểm, ngay cả khi dùng Sentinel. Master có thể khởi động lại nhanh hơn thời gian phát hiện của Sentinel, dẫn đến mất dữ liệu. Luôn đảm bảo master có dữ liệu bền vững khi tự động khởi động.

Quy trình sao chép trong Redis

Redis phân biệt hai kiểu sao chép: toàn phần và từng phần Quá trình sao chép không làm chậm hoạt động của master Lưu ý: Khởi động lại master gây sao chép toàn phần, slave khởi động lại chỉ cần sao chép từng phần

Quy trình sao chép toàn phần (Full resync)

1. Kết nối giữa master-slave, slave gửi lệnh PSYNC (hoặc SYNC trước phiên bản 2.8)
2. Master phản hồi FULLRESYNC kèm mã định danh và offset
3. Slave lưu thông tin master
4. Master tạo file RDB bằng BGSAVE và ghi lại thao tác vào buffer
5. Gửi file RDB đến slave
6. Truyền dữ liệu buffer mới đến slave
7. Xóa dữ liệu cũ trên slave
8. Nạp file RDB vào slave
9. Đồng bộ buffer từ master

Quy trình sao chép từng phần (Partial resync)

Sau lần sao chép đầu tiên, slave chỉ cần gửi offset hiện tại (tương tự binlog của MySQL). Master sẽ truyền dữ liệu mới và buffer tích lũy đến slave để cập nhật.

Triển khai kiến trúc master-slave

Triển khai đơn giản bằng cách thực thi lệnh trên slave:

REPLICAOF 192.168.80.11 6379

config set masterauth + mật_khẩu_master

Hoặc chỉnh sửa tệp cấu hình.

Kiểm tra cấu hình sao chép bằng lệnh INFO replication.

Sao chép tầng (Cascading replication)

Mở rộng kiến trúc bằng cách thêm node tầng giữa.

Xác minh dữ liệu đồng bộ.

Tối ưu cấu hình sao chép

• repl-diskless-sync: Bỏ qua lưu trữ RDB trên đĩa (mặc định là không)
• repl-backlog-size: Kích thước buffer sao chép (tính bằng MB)
• slave-priority: Ưu tiên chọn master mới khi failover
• min-replicas-to-write: Số slave tối thiểu để cho phép ghi

II. Hệ thống giám sát Sentinel

Nguyên lý hoạt động của Sentinel

(1) Giám sát trạng thái

• Kiểm tra định kỳ: Mỗi giây, Sentinel gửi lệnh PING đến tất cả node. Nếu không nhận phản hồi trong down-after-milliseconds, node bị đánh dấu là Subjectively Down (SDOWN).
• Xác nhận sự cố: Khi ≥ 50% Sentinel đồng thuận SDOWN, node được đánh dấu là Objectively Down (ODOWN) và bắt đầu failover.

(2) Giao tiếp giữa các Sentinel

• Gossip protocol: Các Sentinel chia sẻ trạng thái qua Pub/Sub.
• Bầu cử leader: Dùng thuật toán Raft để chọn Sentinel lãnh đạo điều phối failover.

(3) Quy trình failover

1. Chọn master mới: Dựa trên:
   • Độ ưu tiên (slave-priority)
   • Offset sao chép (chọn node có dữ liệu mới nhất)
   • ID node (theo thứ tự từ điển)
2. Thay đổi cấu hình: Node được chọn chạy SLAVEOF NO ONE và các slave khác cập nhật master mới.
3. Thông báo thay đổi: Cập nhật cấu hình Sentinel và thông báo địa chỉ master mới.

(4) Tương tác với client

• Client lấy địa chỉ master từ Sentinel thay vì kết nối trực tiếp.
• Đăng ký sự kiện +switch-master để cập nhật thay đổi.

Cấu hình Sentinel

bind 0.0.0.0  
port 26379  
daemonize yes  
pidfile "redis-sentinel.pid"  
logfile "sentinel_26379.log"  
dir "/tmp"  

sentinel monitor mymaster 10.0.0.8 6379 2  
# Tên nhóm, địa chỉ master, số phiếu cần đạt

sentinel auth-pass mymaster 123456  
# Mật khẩu nhóm (phải đặt sau dòng monitor)

sentinel down-after-milliseconds mymaster 30000  
# Thời gian chờ xác nhận SDOWN (30 giây)

sentinel parallel-syncs mymaster 1  
# Số slave đồng bộ song song

sentinel failover-timeout mymaster 180000  
# Thời gian giới hạn failover

sentinel deny-scripts-reconfig yes  # Tắt thay đổi script qua Sentinel

Thay đổi quyền tệp cấu hình:

root@redis-master:/apps/redis/etc# chown redis.redis sentinel.conf

Tạo file dịch vụ systemd:

vim /lib/systemd/system/redis-sentinel.service

[Unit]
Description=Redis Sentinel
After=network.target

[Service]
ExecStart=/apps/redis/bin/redis-sentinel /apps/redis/etc/sentinel.conf --supervised systemd
ExecStop=/bin/kill -s QUIT $MAINPID
User=redis
Group=redis
RuntimeDirectory=redis
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target

Sao chép cấu hình đến các node khác và khởi động lại dịch vụ. Kiểm tra trạng thái bằng:

redis-cli -p 26379

Hệ thống giám sát Sentinel đã hoàn tất cài đặt.