How Upstash Keeps Your Redis Up When an Availability Zone Isn't

Upstash · 2026 · 3. Quy mô lớn · Độ khó: Trung bình — bài gốc

Bài của nhà cung cấp, có phần quảng bá gói "Prod Pack"; mọi nhận định là theo Upstash. Bài mô tả thiết kế, không có số liệu đo.

Bối cảnh

• Tháng 5/2026, sự cố làm mát ở một AZ của AWS us-east-1 (use1-az4) làm Coinbase chỉ cho huỷ lệnh trong bảy giờ (Coinbase 2026), FanDuel và CME Direct cũng gián đoạn. Theo Upstash, gốc chung là "database nằm trong một AZ".
• "Cứ promote replica" là cách mất dữ liệu: replica trễ vài giây vẫn trả lời, promote bừa là bỏ đi vài giây ghi đã xác nhận.

Thay đổi chính (thiết kế failover)

• Phát hiện: replica gossip với nhau; cụm không phát hiện "mất AZ" mà phát hiện một thành viên im lặng. Một kiểm tra nền định kỳ riêng để bắt split-brain.
• Bầu primary không mất ghi: mỗi lệnh ghi mang số thứ tự tăng dần; replica đã thấy nhiều ghi nhất thắng. Hoà thì ưu tiên primary cũ, rồi chọn tất định để mọi node tự ra cùng kết quả; chỉ một cuộc bầu chạy một lúc.
• Kiểm an toàn: không replica nào đủ gần primary cũ thì thử lại vài lần rồi tạm dừng ghi, thay vì promote một replica thiếu dữ liệu. Chọn tính đúng hơn sẵn sàng, có chủ đích.
• Sau phân vùng mạng mà hai bên cùng ghi: bên thắng kéo bản ghi của bên kia về và trộn: key chỉ một bên đụng thì giữ; key scalar cả hai cùng ghi thì bản có timestamp mới hơn thắng; kiểu tập hợp (hash, set) so theo từng field. Hai client ghi cùng một key scalar gần như cùng lúc ở hai phía thì một bản mất.
• Giữ replica theo kịp: khi backup trễ, primary áp backpressure lên ghi: làm chậm ghi mới một lượng nhỏ, tăng dần theo độ trễ, có trần. Replica nối lại thì stream phần thiếu từ queue trong RAM nếu còn, không thì copy toàn bộ.
• Đọc từ replica mà không cũ: proxy chỉ đọc cục bộ khi (1) replica đã sync xong và gần hiện tại, (2) client không ở giữa MULTI, (3) lần ghi mới nhất của chính client đã áp ở replica đó; thiếu một điều kiện thì chuyển sang primary. Bảo đảm read-your-writes ngay cả khi đọc ở AZ khác.
• Multi-AZ: mặc định các replica có thể nằm cùng một AZ; bật Prod Pack thì cặp primary trải hai AZ, thêm một read replica ở AZ khác, và DNS đổi sang endpoint biết HA, vì replica sống mà "cửa trước" chết thì cũng như không.
• Chi phí xuyên AZ: proxy đặt cạnh replica và ưu tiên đọc cục bộ; chỉ nén traffic replication khi hai node khác AZ.

Bài học cho SWE

• Failover đúng = chọn bản mới nhất theo số thứ tự ghi, và từ chối promote khi không có bản đủ mới (Độ tin cậy và multi-region).
• Làm chậm ghi khi replica trễ là backpressure ở tầng replication, để failover luôn rẻ và không mất dữ liệu (Load shedding, rate limit và backpressure).
• Đọc từ replica cần điều kiện rõ (đã áp ghi của chính client) mới giữ được read-your-writes (Scale dọc trước khi scale ngang).
• Nhiều AZ cho dữ liệu chưa đủ; endpoint/DNS cũng phải nhiều AZ.

Liên quan

• Failover, replica và dự phòng dữ liệu
• Scale dọc trước khi scale ngang
• Tự động hoá vận hành và auto-remediation
• Cùng sự cố AZ: Coinbase 2026