Quorum Read/Write cho Database phân tán: Cân bằng nhất quán, độ trễ và tính sẵn sàng

Sao chép dữ liệu sang nhiều node giúp hệ thống chịu được lỗi máy, nhưng đồng thời tạo ra một câu hỏi khó: cần bao nhiêu replica xác nhận thì một lần đọc hoặc ghi được coi là thành công? Trả lời quá thận trọng làm tăng độ trễ và giảm khả năng phục vụ khi có sự cố; trả lời quá dễ dãi làm ứng dụng đọc phải dữ liệu cũ hoặc ghi đè lên thay đổi mới hơn. Quorum read/write là cách mô hình hóa quyết định đó bằng ba tham số N, R và W.

Bài viết này tập trung vào quorum trong hệ thống sao chép kiểu leaderless hoặc cho phép điều chỉnh consistency level theo request. Mục tiêu không phải biến công thức R + W > N thành một khẩu hiệu, mà là hiểu điều kiện khiến giao nhau giữa tập đọc và tập ghi thực sự có ý nghĩa. Ta sẽ đi từ mô hình cơ bản đến failure mode, read repair, hinted handoff, conflict resolution, observability và quy trình rollout. Các ví dụ dùng số nhỏ để minh họa, không phải cấu hình mặc định cho mọi database.

1. N, R và W đại diện cho điều gì?

N là replication factor: số replica logic giữ một bản của cùng key hoặc partition. W là số replica phải xác nhận một lần ghi trước khi coordinator trả thành công. R là số replica cần tham gia hoặc phản hồi cho một lần đọc. Với N = 3, cấu hình W = 2 yêu cầu hai bản sao chấp nhận ghi; R = 2 thu thập hai phản hồi để chọn phiên bản phù hợp.

Quorum không có nghĩa mọi request luôn liên hệ đúng cùng một tập node cố định. Coordinator chọn replica theo topology, health và consistency level. Vì vậy cần phân biệt replication factor với số phản hồi thực tế, đồng thời hiểu database xử lý replica tạm thời, node thay thế và topology thay đổi như thế nào.

2. Vì sao R + W > N tạo ra giao nhau?

Nếu một bản ghi đã được xác nhận bởi W trong tổng số N replica và lần đọc lấy ít nhất R replica, điều kiện R + W > N buộc hai tập có ít nhất một phần tử chung. Ví dụ, với ba replica, không thể chọn hai node để ghi và hai node để đọc mà hai tập hoàn toàn tách rời. Replica giao nhau có thể mang phiên bản đã được ghi.

N = 3
write acknowledgements = {A, B}  // W = 2
read responses         = {B, C}  // R = 2
intersection           = {B}

Tuy nhiên, “có một replica nhìn thấy bản mới” chưa tự động đồng nghĩa với linearizability. Coordinator còn phải xác định bản nào mới hơn; write cạnh tranh có thể xảy ra; clock có thể lệch; một lần ghi timeout có thể đã được áp dụng ở vài node; topology có thể đổi trong lúc request chạy. Công thức chỉ mô tả giao nhau về số lượng trong một mô hình nhất định. Semantics cuối cùng phụ thuộc vào thuật toán phiên bản, conflict resolution và contract cụ thể của database.

Quorum là một thành phần của consistency protocol, không phải bằng chứng độc lập rằng mọi lần đọc đều trả về “giá trị mới nhất” theo thời gian thực.

3. Ghi thành công, ghi timeout và trạng thái “không biết”

Khi coordinator nhận đủ W xác nhận, nó có thể trả thành công dù các replica còn lại chưa cập nhật. Những bản chậm sẽ hội tụ qua cơ chế của hệ thống. Khi không đủ xác nhận trước deadline, client nhận timeout hoặc unavailable. Điều quan trọng là timeout không chứng minh lần ghi chưa xảy ra: một hoặc nhiều replica có thể đã lưu dữ liệu, thậm chí coordinator có thể mất kết nối ngay trước khi nhận acknowledgement.

Do đó write timeout tạo ra kết quả bất định ở phía client. Retry một thao tác có side effect với payload mới hoặc operation ID mới có thể tạo trùng. API phía trên nên dùng idempotency key ổn định, version dự kiến hoặc business key duy nhất. Nếu thao tác là “đặt số dư thành 100”, retry có semantics khác “cộng thêm 100”; đội phát triển phải định nghĩa rõ trước khi chọn chiến lược retry.

• Giữ cùng request ID hoặc idempotency key cho mọi attempt của một logical operation.
• Không diễn giải timeout thành thất bại tuyệt đối nếu storage contract nói kết quả có thể chưa xác định.
• Đọc đối chiếu chỉ hữu ích khi consistency level và conflict resolution của lần đọc đủ mạnh.
• Đối với nghiệp vụ tiền, tồn kho hoặc quota, đặt invariant trong transaction/conditional write thay vì dựa vào read-then-write.

4. Lần đọc quorum chọn phiên bản nào?

Coordinator có thể nhận nhiều phiên bản của cùng key. Nó cần metadata để so sánh: version number, timestamp, logical clock, vector clock, causal metadata hoặc quy tắc do ứng dụng cung cấp. Last-write-wins dựa trên timestamp đơn giản nhưng có thể làm mất dữ liệu nếu clock lệch hoặc hai writer cập nhật đồng thời. Một giá trị có timestamp lớn không nhất thiết phản ánh quan hệ nhân quả mới hơn.

Hệ thống hỗ trợ sibling hoặc version vector có thể giữ nhiều phiên bản cạnh tranh để ứng dụng hòa giải. Cách này tránh âm thầm xóa một nhánh nhưng đẩy độ phức tạp lên domain: giỏ hàng có thể hợp nhất tập sản phẩm, trong khi hai trạng thái thanh toán xung đột không thể chỉ union. Với conditional write, compare-and-set hoặc lightweight transaction, database có thể cung cấp semantics mạnh hơn nhưng chi phí round trip và contention thường cao hơn đường ghi thông thường.

5. Read repair và anti-entropy không nằm trên cùng một đường thời gian

Khi một lần đọc thấy các replica trả phiên bản khác nhau, hệ thống có thể gửi bản được chọn về replica cũ; đó là read repair. Nó giúp key được đọc thường xuyên hội tụ nhanh hơn, nhưng không sửa những key lâu không được truy cập. Anti-entropy chạy nền, so sánh dữ liệu theo range hoặc cấu trúc tóm tắt rồi đồng bộ khác biệt, giúp bao phủ phần dữ liệu “lạnh”.

Không nên coi repair là miễn phí. Read repair đồng bộ trên critical path có thể tăng tail latency; repair bất đồng bộ giảm tác động tới response nhưng kéo dài cửa sổ không nhất quán. Anti-entropy dùng network, disk I/O và compaction. Nếu backlog repair tăng vô hạn, hệ thống có thể báo request vẫn thành công trong khi durability thực tế suy giảm vì các bản sao chưa hội tụ.

• Theo dõi tuổi và kích thước repair backlog theo node, shard hoặc token range.
• Giới hạn băng thông repair để không đẩy foreground traffic vào timeout.
• Không xóa tombstone trước khi chắc chắn replica vắng mặt đã có cơ hội nhận deletion.
• Kiểm thử bootstrap, replace node và restore backup cùng với lịch repair thực tế.

6. Hinted handoff và sloppy quorum thay đổi giả định ra sao?

Khi replica đích tạm thời không truy cập được, một hệ thống có thể giữ “hint” ở node khác và chuyển lại sau. Sloppy quorum có thể ghi lên các node khỏe ngoài tập replica ưu tiên để đạt số xác nhận trong lúc partition. Hai kỹ thuật này tăng khả năng nhận ghi, nhưng một quorum xác nhận bởi node thay thế không nhất thiết giao với lần đọc chỉ hỏi tập replica gốc.

Đây là khác biệt giữa quorum số học và quorum nghiêm ngặt trên cùng membership. Nếu ứng dụng yêu cầu strong consistency, cần kiểm tra consistency level có giới hạn theo datacenter, topology và replica tự nhiên hay không; không suy luận chỉ từ con số W và R. Hint cũng là dữ liệu cần durability, expiry và monitoring. Nếu hint hết hạn trước khi replay hoặc node giữ hint hỏng, bản ghi có thể không đến được replica dự kiến.

Trong sự cố mạng dài, ưu tiên availability có thể chấp nhận divergent versions. Khi mạng hồi phục, hệ thống phải phát hiện và hòa giải. Đây là quyết định nghiệp vụ: danh mục sản phẩm có thể chấp nhận stale ngắn; xác nhận thanh toán hoặc cấp một tài nguyên duy nhất thường cần đường coordination mạnh hơn.

7. Network partition buộc hệ thống chọn hành vi cụ thể

Partition không chỉ là “mất mạng hoàn toàn”. Packet loss, latency tăng, DNS lỗi, connection pool cạn hoặc một chiều truyền bị hỏng đều có thể làm một nhóm node bị xem là không phản hồi. Nếu phía thiểu số vẫn nhận ghi với consistency thấp, hai phía có thể tiến triển độc lập. Nếu yêu cầu majority quorum trên membership ổn định, phía không đủ đa số sẽ từ chối để tránh phân nhánh, đổi availability lấy consistency.

Cần định nghĩa hành vi theo từng operation thay vì gắn một nhãn CAP cho toàn sản phẩm. Trang đọc profile có thể fallback sang stale cache; cập nhật email đăng nhập cần conditional write; ghi telemetry có thể chấp nhận consistency thấp và xử lý trùng; đặt hàng cần idempotency cùng invariant tồn kho. Một database duy nhất có thể được gọi bằng nhiều consistency level, nên contract phải nằm trong code và tài liệu của từng repository/service.

operation policy:
  product_catalog_read: local quorum, bounded stale cache fallback
  account_email_change: conditional write, no weak fallback
  telemetry_append: low consistency, stable event id
  inventory_reservation: atomic condition + idempotency key

8. Quorum theo datacenter và chi phí xuyên vùng

Với cụm nhiều datacenter, quorum toàn cục có thể kéo latency của mỗi request theo đường mạng xa. Local quorum chỉ chờ đa số replica trong vùng hiện tại, giúp latency thấp và cô lập một số sự cố WAN, nhưng consistency giữa vùng phụ thuộc replication và conflict model. Một global write rồi local read ở vùng khác có thể chưa thấy dữ liệu nếu contract không đảm bảo.

Thiết kế cần trả lời: ai là owner của key, người dùng có “home region” không, write có được phép ở nhiều vùng, yêu cầu read-your-writes được truyền khi chuyển vùng ra sao, và RPO/RTO khi failover là gì. Sticky routing hoặc session token đôi khi cung cấp read-your-writes mà không buộc mọi read thành quorum toàn cầu. Ngược lại, invariant toàn cục như username duy nhất có thể cần consensus, partitioned ownership hoặc bước xác nhận trung tâm.

Không tối ưu bằng cách hạ consistency level khi chưa đo replication lag. Độ trễ đẹp trên dashboard không bù được việc người dùng vừa cập nhật nhưng màn hình kế tiếp hiển thị trạng thái cũ. SLO nên có cả latency lẫn correctness signal như stale-read rate, conflict rate và thời gian hội tụ.

9. Chọn R và W theo workload, không theo công thức duy nhất

Workload đọc nhiều thường muốn R nhỏ để giảm fan-out, nhưng tăng W có thể làm write nhạy với replica chậm. Workload ghi nhiều có thể chọn W nhỏ và R lớn, song mọi lần đọc phải trả chi phí. Nếu request đọc/ghi có SLO khác nhau, hãy mô phỏng percentile latency: quorum hoàn thành khi phản hồi nhanh thứ R hoặc W đến, không phải khi replica trung bình trả lời.

1. Phân loại operation theo hậu quả của stale read, lost update và unavailable.
2. Đo latency distribution của replica theo zone, không chỉ trung bình toàn cụm.
3. Kiểm tra khả năng chịu lỗi: với N=3, W=3 không thể ghi khi một replica vắng.
4. Xác minh semantics chính xác trong tài liệu phiên bản database đang vận hành.
5. Load test cùng repair, compaction, backup và node replacement.
6. Đặt deadline và retry budget ở client để tránh request treo hoặc bão retry.

Không tăng N chỉ để “an toàn hơn” mà không tính disk, network, repair time và xác suất đạt quorum. Thêm replica có thể tăng durability và placement options, nhưng cũng tăng lượng dữ liệu phải đồng bộ và số node có khả năng tụt hậu.

10. Observability cần nhìn được cả request lẫn độ hội tụ

Metric request thành công chưa đủ. Cần tách latency coordinator, số replica phản hồi, timeout theo consistency level và lý do unavailable. Đồng thời theo dõi replica lag, dropped mutation, hint backlog, repair backlog, conflict, tombstone pressure và node membership. Dashboard phải cho biết hệ thống đang khỏe thật hay chỉ đang phục vụ bằng ít bản sao hơn dự kiến.

• Read/write latency p50, p95, p99 theo operation và consistency level.
• Tỷ lệ request không đạt đủ response, timeout nhưng có partial acknowledgement.
• Số replica lệch phiên bản được phát hiện và sửa qua read repair.
• Tuổi hint lâu nhất, tốc độ replay và lượng hint bị drop/expire.
• Repair throughput, backlog, streaming traffic và compaction debt.
• Conflict rate, conditional-write failure và stale-read signal từ ứng dụng.

Trace nên ghi logical operation ID, coordinator, consistency level, replica được chọn, response time và version metadata ở mức không lộ dữ liệu nhạy cảm. Không gắn giá trị key có cardinality cao vào metric label; dùng trace/log có sampling và hash khi cần điều tra.

11. Kiểm thử failure mode trước khi production tự dạy bài học

Unit test không tái hiện được quorum. Môi trường staging cần topology đủ giống production để thử node chậm, node chết, partition giữa zone, clock lệch trong phạm vi giả định, coordinator restart và repair chạy đồng thời. Mỗi test phải kiểm tra state cuối trên mọi replica, không chỉ HTTP status trả về client.

1. Ghi với một replica chậm và xác nhận request đạt W đúng deadline.
2. Buộc write timeout sau partial acknowledgement rồi retry cùng operation ID.
3. Đọc từ tập replica chứa cả bản cũ và mới, kiểm tra winner cùng repair.
4. Tạo hai write cạnh tranh để xác minh conflict resolution đúng domain.
5. Cô lập một zone đủ lâu để hint và repair backlog tăng, sau đó nối lại.
6. Replace một node và đo thời gian phục hồi đủ replication factor.
7. Kiểm tra ứng dụng degrade hoặc từ chối đúng loại operation khi mất quorum.

Chaos test phải có giới hạn blast radius, abort condition và quan sát capacity. Mục tiêu là chứng minh contract trong failure mode đã dự kiến, không phải tạo sự cố ngẫu nhiên rồi hy vọng tìm được điều thú vị.

12. Checklist triển khai quorum an toàn

• Ghi rõ N, R, W hoặc consistency level cho từng operation quan trọng.
• Phân biệt quorum nghiêm ngặt, local quorum và sloppy quorum của sản phẩm đang dùng.
• Định nghĩa semantics cho timeout, retry, conflict và stale read ở API layer.
• Dùng idempotency/conditional write cho thao tác không được phép lặp hoặc mất cập nhật.
• Lập lịch repair, theo dõi hint và kiểm chứng tombstone retention.
• Đo cả latency, availability, replication health và correctness signal.
• Rollout theo canary; giữ cấu hình rollback và runbook khi mất quorum.

Quorum tốt không phải là chọn con số lớn nhất. Đó là việc biến yêu cầu nghiệp vụ thành một consistency contract có thể đo, kiểm thử và vận hành. R + W > N là điểm bắt đầu để hiểu giao nhau; độ đúng cuối cùng còn phụ thuộc membership, versioning, repair, retry và cách ứng dụng bảo vệ invariant. Khi những phần này được thiết kế cùng nhau, replication mới thực sự mang lại khả năng chịu lỗi thay vì chỉ nhân bản sự mơ hồ.

Tài liệu tham khảo

• Amazon Science: Dynamo - Amazon's Highly Available Key-value Store
• Apache Cassandra Documentation: Dynamo architecture
• Apache Cassandra Documentation: Read repair
• DataStax Cassandra Documentation: Consistency levels