Multi-leader — ghi ở nhiều nơi và bài toán xung đột

TL;DR: Multi-leader cho phép nhiều node cùng nhận ghi, mỗi leader vừa nhận ghi cục bộ vừa replicate cho các leader khác. Lợi: ghi có độ trễ thấp (ghi vào leader gần nhất), chịu được một datacenter chết, và hoạt động cả khi tạm mất kết nối (client offline, cộng tác thời gian thực). Giá phải trả — và là lý do multi-leader khó — là write conflict: hai leader chấp nhận hai ghi mâu thuẫn lên cùng một dữ liệu trước khi biết về nhau. Xung đột phải được phát hiện rồi giải quyết: last-write-wins (đơn giản nhưng mất dữ liệu), theo dõi nhân quả bằng vector clock, gộp giá trị, hoặc để ứng dụng/người dùng quyết. Không có cách giải quyết nào miễn phí — chọn cách nào là quyết định theo bản chất dữ liệu.

Single-leader tránh xung đột bằng cách ép mọi ghi qua một điểm. Multi-leader gỡ ràng buộc đó để lấy độ trễ và khả dụng — và ngay lập tức phải đối mặt câu hỏi cốt lõi của dữ liệu phân tán: khi hai nơi thay đổi cùng một thứ độc lập, sự thật là gì? Bài này phân tích xung đột sinh ra thế nào và các cách sống với nó.

1. Analogy — hai chi nhánh cùng sửa một hồ sơ

Một công ty có hai chi nhánh, mỗi nơi giữ bản hồ sơ khách và đều được sửa. Sáng nay, chi nhánh Hà Nội đổi số điện thoại khách thành A; cùng lúc, chi nhánh Sài Gòn đổi thành B. Mỗi bên ghi vào bản của mình rồi tối gửi bản cập nhật cho bên kia. Đến tối, hai bản mâu thuẫn: một bên nói A, một bên nói B — và không có "sổ gốc" nào để phân xử.

Ai đúng? Không có câu trả lời tự nhiên. Phải có quy tắc: lấy cái ghi sau (theo đồng hồ — nhưng đồng hồ hai chi nhánh có thể lệch), hay giữ cả hai để người phụ trách chọn, hay gộp (nếu là danh sách thì union). Mọi quy tắc đều có cái giá — LWW thì mất một số, giữ cả hai thì phải có ai đó quyết.

2. Vì sao (và khi nào) cần multi-leader?

Single-leader ổn cho phần lớn trường hợp; multi-leader chỉ đáng cái phức tạp thêm khi:

• Nhiều datacenter: mỗi datacenter có leader riêng → ghi vào leader gần (độ trễ thấp), và một datacenter chết không chặn ghi ở nơi khác. Với single-leader xuyên lục địa, mọi ghi phải bay tới một datacenter — chậm và mong manh.
• Client hoạt động offline: ứng dụng lịch/ghi chú trên điện thoại vẫn cho sửa khi mất mạng — mỗi thiết bị như một "leader" nhỏ, đồng bộ lại khi có mạng.
• Cộng tác thời gian thực: nhiều người sửa cùng tài liệu; mỗi client ghi ngay (không chờ round-trip tới server) rồi hoà.

Điểm chung: các tình huống mà ép mọi ghi qua một điểm là không chấp nhận được (quá chậm, hoặc bất khả khi offline). Đổi lại, ta nhận về write conflict.

3. Write conflict sinh ra thế nào?

flowchart TB
  UA["User A"] -->|"ghi X = 1"| L1["Leader DC1"]
  UB["User B"] -->|"ghi X = 2"| L2["Leader DC2"]
  L1 -->|"replicate (tre)"| L2
  L2 -->|"replicate (tre)"| L1
  L1 --> C["Xung dot: X = 1 hay 2?"]
  L2 --> C

Hai leader nhận hai ghi lên cùng một khoá trong khoảng chúng chưa biết về nhau (do replication bất đồng bộ, nhớ lag ở bài 02). Khi hai ghi cuối cùng gặp nhau, mỗi leader thấy một giá trị khác — đó là write conflict. Với single-leader điều này không thể xảy ra vì một nơi quyết thứ tự; multi-leader mở ra đúng khả năng đó.

Lần theo cơ chế: kịch bản (a) là xung đột thật — hai ghi song song (concurrent), không cái nào "biết" cái kia, nên khi gặp nhau mỗi leader thấy một giá trị và không có cơ sở tự nhiên để chọn. Kịch bản (b) không phải xung đột: ghi X=2 xảy ra sau khi đã thấy X=1 (quan hệ nhân quả), nên nó đơn giản đè X=1 — thứ tự đã rõ ràng. Điểm tinh tế nằm đúng ở đây: xung đột chỉ tính khi hai ghi song song; phân biệt "song song" với "nhân quả" chính là việc của vector clock.

4. Giải quyết xung đột — không có cách nào miễn phí

Lần theo cơ chế: với LWW, hai thao tác "thêm sản phẩm" chạm cùng bản ghi giỏ hàng thì chỉ ghi có timestamp lớn hơn sống sót — sản phẩm mà thao tác kia vừa thêm biến mất khỏi giỏ, không lỗi, không cảnh báo. Với giỏ hàng, kết quả đó rõ ràng không chấp nhận được (khách mất món hàng vừa thêm); cách đúng hơn là gộp hai giỏ theo sản phẩm (hợp nhất kiểu CRDT tập hợp) thay vì để một thao tác thắng và xoá thao tác kia.

Tránh xung đột (tốt nhất nếu được): định tuyến mọi ghi của một bản ghi cụ thể về cùng một leader (ví dụ theo user-id). Không có hai nơi ghi cùng khoá thì không có xung đột. Nhiều hệ multi-leader thực chất chỉ tránh xung đột bằng cách này; chỉ khi không thể (offline, cộng tác) mới phải giải quyết thật.

Khi buộc phải giải quyết:

• Last-write-wins (LWW): gán mỗi ghi một timestamp, giữ ghi có timestamp lớn nhất, vứt phần còn lại. Đơn giản nhưng mất dữ liệu (một ghi hợp lệ bị âm thầm loại) và phụ thuộc đồng hồ (đồng hồ lệch → "sau" sai). Chấp nhận được khi mất một ghi là ổn (ví dụ ghi trạng thái tạm), tệ hại cho dữ liệu quan trọng.
• Theo dõi nhân quả (vector clock): phân biệt ghi song song (cần gộp) với ghi nhân quả (đè thẳng). Không mất dữ liệu oan, nhưng cần cơ chế gộp cho các ghi song song.
• Gộp giá trị (merge / CRDT — Conflict-free Replicated Data Types, cấu trúc dữ liệu tự hoà không cần khoá): với cấu trúc phù hợp, gộp tự động đúng ngữ nghĩa — like thì union, bộ đếm thì cộng, giỏ hàng thì hợp nhất item. Đây là cách "đúng" cho nhiều dữ liệu cộng tác.
• Để ứng dụng / người dùng quyết: lưu cả hai bản, lần đọc/ghi sau đưa ra để giải (như Git conflict).

5. Thiết kế — chọn chiến lược giải xung đột

Bạn đã có đủ bốn lựa chọn (LWW, vector clock, gộp/CRDT, để người dùng quyết) và một nguyên tắc: chọn theo bản chất dữ liệu. Giờ tự áp. Với ba loại dữ liệu dưới, hãy tự quyết chiến lược nào hợp nhất và biện minh bằng cái giá của từng cách — viết ra (trong đầu hoặc ra giấy) trước khi mở đáp án.

6. Pitfall — chọn LWW vì "đơn giản" cho dữ liệu không được mất

❌ Hai ghi song song X=1 (t=10), X=2 (t=11) -> LWW giu X=2, VUT X=1
   -> khong log, khong bao -> ghi X=1 bien mat im lang
   -> te hon: dong ho 2 node lech -> "t=11" that ra xay ra TRUOC -> giu nham

❌ Dung LWW cho gio hang / danh sach -> mot lan them item bi nuot

7. 📚 Deep Dive

8. Liên hệ các bài khác

• Bài 01 — Single-leader: single-leader không có xung đột (một nơi quyết thứ tự) — multi-leader gỡ ràng buộc đó để lấy độ trễ/khả dụng, đổi bằng xung đột.
• Bài 02 — Replication lag: consistent prefix reads (bài 02) và vector clock ở đây cùng bàn về giữ đúng thứ tự nhân quả.
• Bài 04 — Leaderless: leaderless cũng đối mặt ghi song song và dùng chính vector clock + read repair để hoà — cùng công cụ, kiến trúc khác.
• Module 5 — Đồng hồ không tin cậy: vì sao LWW dựa trên timestamp mong manh — clock skew làm "cái sau" sai.

9. Tóm tắt

• Multi-leader: nhiều node nhận ghi + replicate cho nhau. Đáng dùng khi ép mọi ghi qua một điểm là không chấp nhận được (đa datacenter, offline, cộng tác).
• Giá là write conflict: hai leader chấp nhận hai ghi mâu thuẫn trên cùng khoá khi chưa biết về nhau (do replication async).
• Xung đột chỉ tính khi hai ghi song song (không cái nào thấy cái kia); ghi nhân quả thì đè thẳng — phân biệt bằng vector clock.
• Tránh xung đột (ghim mỗi bản ghi về một leader) tốt hơn giải quyết.
• Resolution: LWW (đơn giản, mất dữ liệu, phụ thuộc đồng hồ), vector clock (gộp đúng song song/nhân quả), CRDT/merge (tự hoà đúng ngữ nghĩa), để người dùng quyết.
• Anti-pattern: LWW mặc định cho dữ liệu không được mất → mất dữ liệu im lặng + phụ thuộc clock skew.

10. Tự kiểm tra

Bài tiếp theo: Leaderless — mọi bản bình đẳng, dùng quorum