Active-Active Shared-Nothing Database Architecture

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

Bài khái niệm, kể qua một tình huống giả định (công ty "Acme Widgets"), không phải một hệ thống cụ thể của CapitalOne. Nhận định là "theo tác giả CapitalOne".

Bối cảnh

Một DB sập kéo theo nhiều service; CTO hỏi "năm 2020 rồi, sao không chạy DB active-active?". Bài giải thích vì sao active-active shared-nothing (AASN) ở tầng DB, tức là hai bản DB ở hai vùng, cùng nhận ghi, nhân bản hai chiều, không chia sẻ gì, hiếm khi chỉ là bật một tuỳ chọn.

Nội dung chính

• AASN khác high availability: HA có thể đạt bằng hot standby ở vùng khác (active/passive). Theo tác giả, AASN thường bị nhầm với HA.
• Active/passive và brown-out: khi failover phải chờ standby bắt kịp; khoảng đó gọi là brown-out. Muốn hết brown-out thì phải nhân bản đồng bộ, vốn đắt (mạng xuyên vùng độ trễ thấp) và làm chậm mọi commit. Nên thực tế nhân bản là bất đồng bộ và brown-out là không tránh được.
• Ba ràng buộc của AASN: chỉ nhất quán cuối cùng; xung đột khi cùng một bản ghi được sửa ở cả hai nơi; hỏng dữ liệu âm thầm khi một bản cập nhật đến muộn đè lên bản mới hơn.
• Cách giải xung đột (từ đơn giản tới phức tạp): ai đến sau thắng; theo timestamp (cần đồng hồ đồng bộ); theo trọng số vùng; theo trọng số ứng dụng. Theo tác giả, mọi cách đều là vứt bỏ một thay đổi, nên không cách nào trong suốt với nghiệp vụ.
• Hợp với AASN hay không tuỳ loại kho, từ kém phù hợp nhất tới phù hợp nhất: System of Record (đơn hàng, số dư; kém phù hợp nhất) → System of Reference (phân tích) → read-only → nội dung tĩnh → cache → session state (không cần cả bản sao).
• Năm mẫu thiết kế:
  1. nhiều master nhưng chỉ một active (rút ngắn brown-out, không hết hẳn);
  2. một master nhiều reader;
  3. một "feeder" master cùng các reader active;
  4. nhiều master do ứng dụng tự ghi vào từng DB, không nhân bản giữa DB, nên không có xung đột (theo tác giả là thực tế nhất);
  5. như mẫu 4 nhưng ghi qua bộ đệm. Mẫu này không bảo đảm thứ tự, chỉ hợp với cache hoặc dữ liệu tham chiếu, không bao giờ dùng cho System of Record.

Bài học cho SWE

• Active-active ở tầng DB là quyết định của ứng dụng, không phải của DB: phải biết bản ghi nào có thể bị sửa ở hai nơi và chấp nhận mất thay đổi nào (Độ tin cậy và multi-region).
• Phân loại kho dữ liệu (system of record hay cache, session) trước khi chọn mô hình nhân bản (Chọn database theo workload).
• So với thực tế trong wiki: Goldman Sachs chọn active/passive cho DB quan hệ (Goldman Sachs 2021); WarpStream "active-active nhưng một leader" (WarpStream 2025). Cả hai đều né xung đột ghi.

Liên quan

• Failover, replica và dự phòng dữ liệu
• Chọn database theo workload