REDISVAULT_BLUEPRINT // SENTINEL-QUORUM • Cụm 3 Node Chống Sập Tự Động (<5s)

Thiết Kế Cụm 3 Node Redis / Valkey Sentinel HA Chống Split-Brain & Tự Failover <5 Giây — RedisVault

Mô hình 2 máy chủ không bao giờ đạt đa số phiếu bầu (quorum) khi đứt cáp mạng — chắc chắn dẫn tới lỗi Split-Brain ghi đè mất dữ liệu. Dựng chuẩn 3 node DDR5 đối xứng với Quorum=2 giúp tự động chuyển mạch dưới 5 giây mà rẻ hơn 85% so với AWS Multi-AZ. — Phân tích định lượng bởi RedisVault.

Trong bản thiết kế SENTINEL-QUORUM của RedisVault, chúng tôi tách biệt giới hạn maxmemory khỏi vùng đệm nhân bản trang nhớ POSIX fork() 4 KB và bộ đệm kết nối mạng để đảm bảo tiến trình không bị OOM-Killer ngắt đột ngột khi ghi đĩa.

Bảng Định Cỡ RAM & Đệm CoW Cho SENTINEL-QUORUM Trên RedisVault

Quy Mô Triển Khai maxmemory fork() CoW Reserve Cấu Hình Máy Chủ Tối Thiểu Thông Lượng Dự Kiến
3x 8GB Sentinel Cluster (1M–3M Keys) 3.2 GB/node +2.4 GB/node 3x Hostinger KVM 2 ($17.97/tháng total) <3.5s Failover
3x 16GB Production HA (5M Keys) 6.2 GB/node +4.6 GB/node 3x Hostinger KVM 4 ($31.47/tháng total) <4.0s Failover
3x 32GB Enterprise HA (15M Keys) 14.5 GB/node +10.2 GB/node 3x Hostinger KVM 8 ($59.97/tháng total) Private VPC Sync
3x 64GB Heavy Queue HA (40M Keys) 31.5 GB/node +22.0 GB/node 3x UltaHost 64GB VDS ($204/tháng total) 10Gbps Diskless Sync

Mẫu Cấu Hình Thực Thi SENTINEL-QUORUM Từ RedisVault

redis-sentinel-ha-cluster.conf — RedisVault Verified Template Mở trong Studio tương tác RedisVault → 
# /etc/redis/sentinel.conf (Deploy identically across Node 1, Node 2 & Node 3 on Port 26379)
port 26379
bind 10.10.0.11
sentinel monitor rv-primary 10.10.0.11 6379 2
sentinel auth-pass rv-primary YOUR_64_CHAR_RANDOM_SECRET
sentinel down-after-milliseconds rv-primary 3000
sentinel failover-timeout rv-primary 15000
sentinel parallel-syncs rv-primary 1

# Fence isolated old Primary inside redis.conf to prevent Split-Brain writes:
# min-replicas-to-write 1
# min-replicas-max-lag 10

Nguyên Tắc Tối Ưu Hóa Nhân Linux Cho SENTINEL-QUORUM Trên RedisVault

  1. Bắt buộc thuê cả 3 VPS có dung lượng RAM bằng hệt nhau! Ngay khi Master chết, máy Replica được đôn lên làm Master mới sẽ lập tức gánh 100% tải ghi cộng thêm lệnh fork() đồng bộ cho các node còn lại.
  2. Tăng repl-backlog-size lên 256mb–1gb để khi mạng chập chờn vài giây, các node chỉ đồng bộ phần chênh lệch (Partial PSYNC2) thay vì phải chép lại toàn bộ nhiều GB từ đầu.
  3. Bật min-replicas-to-write 1 và min-replicas-max-lag 10 trên Master để tự khóa ghi nếu Master bị cô lập mạng, chặn đứng thảm họa mất dữ liệu Split-Brain.
  1. SENTINEL-QUORUM — Sơ đồ 4 vùng phân bổ RAM Linux trên RedisVault gồm dữ liệu khóa thô, hao hụt con trỏ jemalloc, vùng đệm nhân bản fork BGSAVE Copy-on-Write và bộ đệm nhân hệ điều hành
    Hình 1 (RedisVault): Lý do đặt maxmemory vượt 50% RAM vật lý trên hàng đợi ghi nhiều dẫn tới lỗi tràn bộ nhớ Linux OOM-Killer.

Hạ Tầng Khuyến Nghị Cho SENTINEL-QUORUM (Đối Chiếu Giá Ngày 2026-11-12 Trên RedisVault)

Các mức giá dưới đây được đối chiếu từ trang bảng giá chính thức ngày 2026-11-12 (hostinger.com/vps-hosting, vultr.com/pricing, ultahost.com/vps-hosting, interserver.net/vps, chemicloud.com/web-hosting) và có thể thay đổi theo chu kỳ thanh toán; hãy kiểm tra lại tại bước thanh toán. Nếu dự án cần SLA quản trị trọn gói không tự vận hành Linux, hãy cân nhắc AWS ElastiCache hoặc Upstash.

Giải Đáp Kỹ Thuật SENTINEL-QUORUM Trên RedisVault

Khi nào nên dùng cụm 3 node Sentinel, và khi nào mới cần dựng Redis Cluster chia mảnh? — RedisVault SENTINEL-QUORUM

Hãy ưu tiên Sentinel 3 node chừng nào tổng dữ liệu còn nằm vừa trong 1 máy chủ (dưới 64–128 GB RAM). Redis Cluster đòi hỏi tối thiểu 6 node và làm lỗi toàn bộ lệnh Lua đa khóa nếu bạn không sửa code gắn {hash_tag} phức tạp!

Node thứ 3 chỉ chạy tiến trình bầu cử Sentinel trên VPS nhỏ giá rẻ được không? — RedisVault SENTINEL-QUORUM

Hoàn toàn được! Để tiết kiệm tối đa, bạn có thể chạy 1 Master lớn + 1 Replica lớn + 1 VPS nhỏ chỉ chạy tiến trình trọng tài redis-sentinel (không lưu dữ liệu) để vẫn giữ đủ 3 phiếu bầu Quorum=2.