Kỹ sư QLTT Ghi chú ôn thi
← Về danh sách
Cơ sở dữ liệu
#최종일관성#EventualConsistency#분산시스템#CAP#비동기복제#CRDT#충돌해결#일관성모델
Cập nhật lần cuối · 2026-09-26

Nhất quán cuối cùng (Eventual Consistency) và các mô hình nhất quán trong hệ phân tán

1. Tổng quan

A. Định nghĩa

Nhất quán cuối cùng (Eventual Consistency) là mô hình nhất quán dữ liệu phân tán, theo đó nếu không còn cập nhật mới nào xảy ra và việc lan truyền giữa các bản sao hoàn tất bình thường, thì theo thời gian mọi bản sao sẽ hội tụ về cùng một giá trị.

Nhất quán cuối cùng không phải là lời hứa rằng mọi lần đọc đều trả về ngay giá trị mới nhất. Tại một thời điểm, có thể quan sát thấy các giá trị khác nhau do độ trễ mạng giữa các bản sao ở các vùng, sao chép bất đồng bộ, và khác biệt thứ tự thử lại.

Thay vào đó, hệ thống ưu tiên tính sẵn sàng và độ trễ, đồng thời được thiết kế để khi sự cố được khắc phục và việc lan truyền cập nhật kết thúc, kết quả sẽ hội tụ về một.

Mô hình này thường được dùng trong các dịch vụ phải phản hồi nhanh cho người dùng toàn cầu như kho khóa-giá trị sao chép dữ liệu qua nhiều vùng, DNS, cache CDN, bảng tin mạng xã hội, giỏ hàng, kết quả gợi ý.

B. Bối cảnh ra đời và sự cần thiết

Trong một cơ sở dữ liệu đơn lẻ, có thể định nghĩa trạng thái mới nhất tương đối dễ dàng bằng một nhật ký giao dịch và cơ chế khóa.

Tuy nhiên, trong dịch vụ đa vùng (multi-region), người dùng kết nối tới bản sao ở vùng gần nhất, và việc liên lạc giữa các vùng có thể bị trễ hoặc gián đoạn tạm thời.

Nếu gửi mọi thao tác ghi tới một leader trung tâm và buộc mọi thao tác đọc chờ kết quả đó, ta có được nhất quán mạnh, nhưng sự cố vùng và thời gian khứ hồi dài sẽ trực tiếp dẫn tới độ trễ dịch vụ và suy giảm tính sẵn sàng.

Nhất quán cuối cùng cho phép lựa chọn tại điểm này: “có thể tạm thời hiển thị giá trị khác, nhưng dịch vụ vẫn tiếp tục phản hồi”.

Ví dụ, nếu người dùng đổi tên hồ sơ ở Seoul rồi ngay lập tức xem hồ sơ của mình từ vùng Tokyo, tên cũ có thể tạm thời hiển thị.

Nếu dịch vụ chấp nhận hiện tượng này, có thể thu hẹp phạm vi chờ phản hồi ghi thành công để nâng cao trải nghiệm người dùng và khả năng mở rộng về địa lý.

Ngược lại, trong các lĩnh vực mà chấp nhận giá trị cũ sẽ gây tổn thất trực tiếp hoặc sự cố bảo mật như số dư chuyển tiền, trừ tồn kho, thu hồi quyền, thì nhất quán cuối cùng đơn thuần là không đủ.

Do đó, mô hình nhất quán cần được hiểu không phải là thuộc tính của kho lưu trữ mà là quyết định thiết kế phản ánh ý nghĩa nghiệp vụ, chi phí lỗi và kỳ vọng của người dùng.

C. Quan hệ với CAP và độ trễ

Hệ phân tán, trên tiền đề phân vùng mạng có thể xảy ra, đòi hỏi lựa chọn giữa tính nhất quán (Consistency) và tính sẵn sàng (Availability).

C trong CAP gần với nhất quán theo nghĩa mạnh — mọi nút thấy cùng giá trị mới nhất — còn A là tính chất phản hồi yêu cầu ngay cả khi một số nút bị cô lập.

Hệ thống nhất quán cuối cùng có thể mang tính chất AP — mỗi bản sao vẫn phản hồi đọc hoặc ghi trong lúc phân vùng mạng — nhưng điều đó không có nghĩa là luôn chấp nhận kết quả vô điều kiện.

Các sản phẩm thực tế kết hợp ghi có điều kiện theo khóa, đọc theo túc số (quorum), bảo đảm phiên, chính sách giải quyết xung đột để tạo điểm thỏa hiệp theo từng nghiệp vụ.

CAP là khung lý thuyết giải thích lựa chọn trong tình huống sự cố, và không tự động quyết định độ trễ·thông lượng·chi phí·độ phức tạp vận hành lúc bình thường.

2. Ý nghĩa và các tầng của tính nhất quán

A. Nhất quán mạnh và nhất quán yếu

Nhất quán mạnh yêu cầu sau khi ghi thành công, đọc từ bất kỳ nút nào cũng phải trả về giá trị mới nhất hoặc giá trị sau đó.

Khả tuyến tính (Linearizability) khiến mỗi thao tác trông như xảy ra nguyên tử tại một thời điểm giữa lời gọi và phản hồi, đồng thời bảo toàn cả thứ tự thời gian thực.

Tính chất này phù hợp với các tác vụ mà thứ tự và độ mới là cốt lõi như số dư tài khoản hay khóa phân tán, nhưng vì phải chờ đồng thuận giữa nhiều vùng nên chi phí độ trễ và lan truyền sự cố tăng lên.

Nhất quán yếu không bảo đảm giá trị mới nhất tại thời điểm đọc. Tuy nhiên, tùy theo “phải hội tụ trước khi nào” và “bảo đảm thứ tự nào cho các yêu cầu liên tiếp của một người dùng” mà chia thành nhiều mô hình con.

Nhất quán cuối cùng là mô hình trong nhóm nhất quán yếu có nêu rõ điều kiện hội tụ, và không có nghĩa là được phép cung cấp các giá trị khác nhau mãi mãi.

B. Các mô hình nhất quán chính

Mô hình Bảo đảm cốt lõi Ứng dụng tiêu biểu Chi phí chính
Khả tuyến tính Mọi thao tác trông như theo một thứ tự toàn cục duy nhất Số dư, bầu leader, khóa Trễ đồng thuận, giảm tính sẵn sàng
Nhất quán tuần tự Một thứ tự duy nhất bảo toàn thứ tự theo từng tiến trình Trừu tượng bộ nhớ chia sẻ Điều phối thứ tự toàn cục
Nhất quán nhân quả Mọi nút bảo toàn quan hệ nguyên nhân-kết quả Bình luận và trả lời, tin nhắn Quản lý siêu dữ liệu nhân quả
Nhất quán phiên Bảo đảm thứ tự đọc·ghi trong một phiên Hồ sơ người dùng, giỏ hàng Cố định phiên hoặc token
Nhất quán cuối cùng Các bản sao hội tụ khi cập nhật dừng DNS, bảng tin, cache Giá trị cũ tạm thời, xung đột
Đọc-được-ghi-của-mình Giá trị mình đã ghi sẽ thấy ở các lần đọc sau Thay đổi cài đặt người dùng Định tuyến phiên·truyền phiên bản
Đọc đơn điệu Các lần đọc của cùng người dùng không lùi về quá khứ Màn hình tra cứu trạng thái Kiểm soát chọn bản sao

Các mô hình trong bảng này không phải là phân loại sản phẩm loại trừ lẫn nhau, mà là tổ hợp các khả năng quan sát mà hệ thống cung cấp cho người dùng.

Ví dụ, toàn hệ thống là nhất quán cuối cùng, nhưng có thể áp dụng đọc-được-ghi-của-mình và đọc đơn điệu cho phiên người dùng.

Làm như vậy, mọi người dùng không phải chờ giá trị mới nhất toàn cục, nhưng vẫn giảm được sự bối rối khi thay đổi mình vừa thực hiện biến mất khỏi màn hình.

C. Phân biệt tính nhất quán với tính bền vững·tính đúng đắn

Tính nhất quán nói về việc giá trị được quan sát theo thứ tự và thời điểm nào giữa các bản sao.

Tính bền vững (durability) là tính chất về việc thao tác ghi thành công có bị mất sau sự cố hay không, còn tính toàn vẹn nói về việc giá trị có vi phạm quy tắc nghiệp vụ hay không.

Chọn nhất quán cuối cùng không có nghĩa là được phép làm mất dữ liệu.

Ví dụ, sự kiện đặt hàng được lưu bền vững, còn chỉ mục tìm kiếm và kết quả gợi ý được cập nhật bất đồng bộ và cung cấp theo nhất quán cuối cùng.

Nếu không phân biệt điều này, sẽ nảy sinh thiết kế sai lầm kiểu “vì là sao chép bất đồng bộ nên dữ liệu mất cũng không sao”.

3. Nguyên lý hoạt động và các thành phần

A. Cấu trúc sao chép bất đồng bộ

flowchart LR
    U[Yêu cầu người dùng] --> G[API gateway]
    G --> R1[Bản sao vùng A]
    R1 --> L[Nhật ký thay đổi hoặc luồng sự kiện]
    L --> P[Worker lan truyền sao chép]
    P --> R2[Bản sao vùng B]
    P --> R3[Bản sao vùng C]
    R2 --> Q[Đọc tại vùng B]
    R3 --> S[Đọc tại vùng C]
    R1 -. Thông tin phiên bản·xung đột .-> P
    P -. Thử lại·loại trùng lặp .-> L

Khi ghi thành công ở vùng A, cơ sở dữ liệu trước tiên hoàn tất lưu cục bộ và ghi nhật ký, sau đó worker sao chép gửi thay đổi tới vùng B và C.

Lúc này, nếu tách phản hồi cho client khỏi việc hoàn tất sao chép từ xa, có thể giảm độ trễ khứ hồi, nhưng trong khoảng sự cố trước khi sao chép từ xa xong, giá trị giữa các vùng sẽ khác nhau.

Do đó, nhật ký không phải là bộ đệm thông điệp mạng đơn thuần mà phải là bản ghi bền vững các sự kiện, cần cho khởi động lại·gửi lại·truy vết thứ tự·kiểm toán.

Worker sao chép dùng timeout và backoff lũy thừa để chịu được sự cố tạm thời, và phải bảo đảm tính lũy đẳng (idempotency) để dù cùng một sự kiện được chuyển nhiều lần thì kết quả chỉ được áp dụng một lần.

B. Truy vết phiên bản và thứ tự

Cách giải quyết xung đột đơn giản nhất là ưu tiên dấu thời gian mới nhất (LWW). Đây là cách gắn thời điểm logic hoặc vật lý cho mỗi cập nhật và giữ lại giá trị lớn hơn.

Nhưng nếu đồng hồ của các nút khác nhau bị lệch, thay đổi thực sự mới hơn có thể bị loại bỏ, và cũng khó phân biệt các thao tác ghi đồng thời cùng thời điểm.

Đồng hồ logic (Logical Clock) truy vết thứ tự nhân quả của thông điệp thay cho đồng hồ vật lý. Đồng hồ Lamport biểu diễn thứ tự “A xảy ra trước B”, nhưng không phân biệt được cả các sự kiện đồng thời độc lập với nhau.

Đồng hồ vectơ (Vector Clock) duy trì bộ đếm cho từng nút để so sánh quan hệ giữa hai phiên bản. Nếu mọi phần tử của một vectơ nhỏ hơn hoặc bằng vectơ kia thì là quan hệ đi trước, còn nếu không bên nào bao hàm bên nào thì có thể phán định là cập nhật đồng thời.

Số nút càng nhiều thì siêu dữ liệu vectơ càng lớn, nên trong thực tế người ta chọn phiên bản theo phân vùng, đồng hồ logic lai (hybrid logical clock), số thứ tự do máy chủ tạo, v.v. theo yêu cầu.

C. Giải quyết xung đột

sequenceDiagram
    participant A as Vùng A
    participant B as Vùng B
    participant M as Quy tắc hợp nhất
    A->>A: Lưu giá trị X, phiên bản a
    B->>B: Lưu giá trị Y, phiên bản b
    A-->>B: Gửi lại thay đổi X
    B-->>A: Gửi lại thay đổi Y
    A->>M: So sánh X và Y
    B->>M: So sánh X và Y
    M-->>A: Bên thắng hoặc kết quả hợp nhất
    M-->>B: Lan truyền cùng kết quả
    Note over A,B: Cùng trạng thái sau khi hội tụ

Xung đột xảy ra khi hai bản sao cập nhật cùng một khóa bằng các giá trị khác nhau rồi trao đổi thay đổi.

LWW dễ triển khai và tốn ít dung lượng, nhưng ý nghĩa của giá trị thua bị mất đi nên có thể đánh mất thông tin quan trọng với người dùng.

Hợp nhất theo trường có thể bảo toàn các trường được sửa độc lập như tên và địa chỉ, nhưng có thể phá vỡ quy tắc nghiệp vụ giữa các trường.

Thanh ghi đa giá trị (multi-value register) giữ lại mọi giá trị xung đột và để ứng dụng hoặc người dùng lựa chọn về sau.

CRDT — hợp nhất bản thân thao tác như bộ đếm·tập hợp·bản đồ — được thiết kế dùng tính giao hoán·kết hợp·lũy đẳng để hội tụ về cùng kết quả dù thứ tự thông điệp khác nhau.

Tuy nhiên, không phải mọi trạng thái miền nghiệp vụ đều biểu diễn được bằng CRDT. Các ràng buộc như tồn kho không được nhỏ hơn 0 hay bất biến toàn cục như “chỉ trúng thưởng một lần” cần thủ tục đặt trước·đồng thuận·bù trừ riêng.

D. Thử lại và tính lũy đẳng

Thông điệp sao chép có thể bị bên gửi gửi lại cùng một sự kiện do mất phản hồi.

Nếu bên nhận chỉ đơn giản cộng dồn sự kiện, bộ đếm sẽ tăng hai lần và cùng một đơn hàng bị tạo hai lần.

Để ngăn điều này, dùng ID sự kiện, phân vùng nguồn và offset, khóa nghiệp vụ để phát hiện trùng lặp và ghi lại kết quả xử lý.

Phép gán lũy đẳng cho cùng kết quả dù áp dụng cùng giá trị nhiều lần, nhưng các phép tăng dần như “tăng số dư thêm 100” phải ghi lại ID sự kiện hoặc bọc trong thao tác nguyên tử chỉ áp dụng một lần.

Chính sách thử lại phải bao gồm số lần thử lại tối đa và hàng đợi tạm giữ, cô lập thông điệp độc (poison message), thủ tục tái xử lý của người vận hành.

4. Thiết kế mức nhất quán và quy trình triển khai

A. Phân tích yêu cầu

Bước đầu tiên không phải là yêu cầu “giá trị mới nhất” một cách trừu tượng, mà là định nghĩa phạm vi giá trị cũ mà người dùng và nghiệp vụ có thể chịu đựng.

Việc kết quả tìm kiếm sản phẩm phản ánh chậm vài giây là chấp nhận được, nhưng giá và tồn kho ngay trước thanh toán có thể cần kiểm tra riêng.

Về tiêu chí định lượng, định nghĩa phân vị mục tiêu của độ trễ hội tụ, thời gian tối đa cho phép của đọc cũ, tỷ lệ xung đột, tỷ lệ tái xử lý.

Nếu không định nghĩa các chỉ số này, ta chỉ xác nhận được việc sao chép đang chạy, chứ không thể kiểm chứng đến khi nào phải hiển thị đúng cho người dùng.

Thực tế hơn là tách tổ hợp đọc và ghi theo từng nghiệp vụ và pha trộn “nhất quán mạnh toàn cục”, “nhất quán cuối cùng cục bộ theo vùng”, “bảo đảm phiên”.

B. Phân loại dữ liệu

Loại dữ liệu Mô hình cho phép Ví dụ thiết kế
Tài khoản·phê duyệt thanh toán Nhất quán mạnh hoặc một nguồn có thẩm quyền duy nhất Dịch vụ sổ cái và cập nhật có điều kiện
Chỉ mục tìm kiếm sản phẩm Nhất quán cuối cùng DB gốc và lập chỉ mục bất đồng bộ
Giỏ hàng Phiên·đọc-được-ghi-của-mình Phân vùng theo người dùng và hợp nhất
Lượt thích·lượt xem Nhất quán cuối cùng có thể hợp nhất Bộ đếm CRDT hoặc tổng hợp sự kiện
Thu hồi quyền·token Lan truyền nhanh hơn TTL ngắn Chính sách tập trung và vô hiệu hóa cache
Đặc trưng phân tích·gợi ý Nhất quán cuối cùng cho phép trễ Xử lý luồng và tính toán lại

Cốt lõi của phân loại là đánh giá thiệt hại khi dùng sai, hơn là bản thân dữ liệu.

Ví dụ, mô tả sản phẩm có thể xem muộn, nhưng không được thanh toán chỉ dựa vào tồn kho có thể bán trong chỉ mục tìm kiếm.

Dịch vụ thanh toán dù tham khảo kết quả tìm kiếm nhất quán cuối cùng vẫn đặt kiểm tra kép, truy vấn lại hệ thống tồn kho·thanh toán có thẩm quyền tại thời điểm phê duyệt cuối.

C. Lựa chọn giao thức sao chép

Sao chép đồng bộ nhận xác nhận ghi từ nhiều nút nên cung cấp tính nhất quán cao, nhưng sự cố ở vùng xa có thể lan thành độ trễ ghi.

Sao chép bất đồng bộ cung cấp phản hồi cục bộ nhanh nhưng phải vận hành khả năng trễ sao chép, xung đột, mất dữ liệu tại điểm phục hồi.

Sao chép dựa trên leader làm thứ tự đơn giản, nhưng khi leader gặp sự cố thì việc bầu chọn và dồn lưu lượng về vùng của leader trở thành vấn đề.

Cấu trúc đa leader giảm độ trễ ghi theo vùng nhưng ứng dụng phải chịu trách nhiệm về xung đột đồng thời và chính sách hợp nhất.

Trong cấu trúc điều chỉnh túc số đọc và túc số ghi, đặt tổng số bản sao là N, túc số đọc là R, túc số ghi là W và có thể tận dụng quan hệ R+W>N.

Quan hệ này nâng cao khả năng đọc được thao tác ghi mới nhất nhờ các bản sao chồng lấn, nhưng không tự động giải quyết sự cố·trễ·ghi đồng thời·chính sách chọn phiên bản.

D. Bổ trợ ở tầng ứng dụng

Nếu client nhận token phiên bản trong phản hồi ghi và chuyển nó vào lần đọc tiếp theo, máy chủ có thể định tuyến tới bản sao có phiên bản đó trở lên.

Cách này tạo được tính chất đọc-được-ghi-của-mình mà không cần cố định phiên, nhưng phải định nghĩa việc chờ·phản hồi thay thế khi token hết hạn hoặc phiên bản chưa tới vùng đó.

Trên màn hình người dùng có thể hiển thị “đang xử lý”, “đang đồng bộ”, “cần xác nhận trạng thái mới nhất” để truyền đạt có ý nghĩa sự không nhất quán tạm thời thay vì che giấu.

Nếu ghi lệnh nghiệp vụ dưới dạng sự kiện thay vì ghi đè trạng thái, và khi xung đột thì chuyển sang giao dịch bù trừ hoặc hàng đợi rà soát thủ công, việc truy vết nguyên nhân và phục hồi sẽ dễ dàng hơn.

5. So sánh với nhất quán mạnh

A. Lý do tạo nên khác biệt

Nhất quán mạnh làm đơn giản suy luận của người dùng về kết quả đọc. Có thể đặt giả định trong mã rằng nếu ghi thành công thì sau đó đọc ở bất kỳ vị trí nào cũng ra cùng kết quả.

Tuy nhiên, bảo đảm này làm trễ yêu cầu cho đến khi việc liên lạc và điều phối giữa các bản sao hoàn tất, và trong lúc phân vùng mạng có thể dẫn đến lựa chọn từ chối phản hồi.

Nhất quán cuối cùng có thể xử lý cục bộ mà không chờ liên lạc nên có lợi về độ trễ và tính sẵn sàng theo vùng.

Đổi lại, ứng dụng phải xử lý tường minh dữ liệu cũ, sự kiện trùng lặp, xung đột, đảo ngược thứ tự, tái xử lý.

Hạng mục so sánh Nhất quán mạnh Nhất quán cuối cùng
Ý nghĩa đọc Gần với trạng thái toàn cục mới nhất Có thể tạm thời là trạng thái trước
Độ trễ ghi Tăng tỷ lệ với phạm vi điều phối Có thể giảm nhờ phản hồi cục bộ
Lựa chọn khi sự cố Tăng khả năng lỗi·chặn Có thể duy trì dịch vụ theo vùng
Xử lý xung đột Giao thức giảm bớt Cần quy tắc miền nghiệp vụ
Độ khó vận hành Quản lý đồng thuận·sự cố leader Quản lý trễ sao chép·tái xử lý
Nghiệp vụ phù hợp Sổ cái·quyền·chốt tồn kho Bảng tin·tìm kiếm·phân tích·cache

B. Ý nghĩa thực tiễn của mô hình hỗn hợp

Không cần quyết định toàn bộ một hệ thống là nhất quán mạnh hoặc toàn bộ là nhất quán cuối cùng.

Có thể dùng cấu trúc CQRS, giữ sổ cái và trạng thái đơn hàng ở mức mạnh, còn tìm kiếm đơn hàng·thông báo·dashboard nhận sự kiện và cập nhật muộn.

Chẳng hạn, việc người dùng xem dashboard ngay sau khi đặt hàng mà vẫn thấy “đang xử lý” là chấp nhận được, còn màn hình chi tiết thì xác nhận trực tiếp với dịch vụ sổ cái.

Tách dữ liệu có thẩm quyền khỏi dữ liệu phái sinh như vậy cho phép chỉ trả chi phí nhất quán cao ở những ranh giới thực sự cần thiết.

6. Tình huống ứng dụng trong công nghiệp

A. Bảng tin mạng xã hội toàn cầu

Việc đăng bài có thể lưu trước ở vùng gần tác giả, còn dòng thời gian cho người theo dõi được tạo bằng fan-out bất đồng bộ.

Trong lúc lan truyền bị trễ, việc một số người theo dõi thấy bài mới muộn nhìn chung là chấp nhận được.

Nhưng yêu cầu xóa hoặc xử lý chặn phải áp dụng lan truyền nhanh hơn bài đăng thông thường và vô hiệu hóa cache, đồng thời cần tác vụ thu hồi để không còn bản sao đã lan truyền.

B. Tồn kho thương mại điện tử

Chi tiết sản phẩm·chỉ mục tìm kiếm có thể vận hành theo nhất quán cuối cùng để phân tán tải đọc.

Nhưng ở bước thanh toán, không dùng số lượng tồn kho trong chỉ mục tìm kiếm làm giá trị chốt mà gửi lệnh đặt trước tới dịch vụ có thẩm quyền về tồn kho.

Lệnh đặt trước chứa ID đơn hàng làm khóa lũy đẳng, và có cơ chế hết hạn đặt trước cũng như hoàn trả bù trừ khi thanh toán thất bại.

Cấu trúc này chấp nhận vấn đề số lượng trên màn hình hiển thị hơi chậm, nhưng chặn bán vượt tồn kho tại ranh giới quan trọng.

C. Cache DNS và CDN

DNS và CDN sao chép giá trị tới các điểm biên (edge) trên toàn thế giới để phản hồi nhanh, và lan truyền thay đổi bằng TTL và yêu cầu vô hiệu hóa.

Việc một số người dùng nhận IP cũ hoặc nội dung cũ trong lúc TTL còn hiệu lực là ví dụ điển hình của nhất quán cuối cùng.

Với bản vá bảo mật hay chuyển đổi khi sự cố, không thể chỉ chờ TTL, nên phải thiết kế đồng thời TTL ngắn, vô hiệu hóa chủ động, health check, nguồn gốc thay thế.

7. Kiểm chứng·quan sát·ứng phó sự cố

A. Chỉ số quan sát cốt lõi

Độ trễ sao chép được đo bằng chênh lệch giữa thời điểm sự kiện gốc và thời điểm áp dụng tại bản sao đích, và xem cả p95·p99 thay vì chỉ trung bình.

Tỷ lệ xung đột phải được tổng hợp theo khóa hoặc loại nghiệp vụ thì mới tìm ra hiện tượng chỉ xảy ra ở một nhóm khách hàng hay một vùng cụ thể.

Ghi lại đồng thời tỷ lệ đọc cũ, tỷ lệ thử lại, tỷ lệ loại trùng lặp, độ dài hàng đợi tạm giữ, thời gian tái hội tụ sau phục hồi.

Cần gắn thẻ tenant·vùng·mức quan trọng dữ liệu vào chỉ số để trung bình tổng thể không che khuất những khoảng nguy hiểm.

B. Chiến lược kiểm thử

Cần kiểm thử tiêm lỗi (fault injection) đưa vào độ trễ mạng, mất gói, đảo thứ tự, chuyển trùng lặp, lệch đồng hồ, đứt kết nối vùng.

Trong kiểm thử cập nhật đồng thời cùng một khóa, kiểm chứng rõ kết quả mong đợi là “giá trị cuối” đơn thuần, hợp nhất theo trường, hay xác nhận của người dùng.

Khi tiếp tục sau khi sao chép bị gián đoạn, tìm các sự kiện bị thiếu và xác nhận trạng thái cuối vẫn giống nhau dù phát lại sự kiện nhiều lần.

Các bảo đảm phiên như đọc-được-ghi-của-mình và đọc đơn điệu phải được kiểm thử bằng cách di chuyển người dùng qua nhiều vùng.

C. Ứng phó sự cố

Khi độ trễ sao chép vượt ngưỡng, có thể giảm lưu lượng của các tác vụ phái sinh ít quan trọng và tạm thời tăng đường đọc tới hệ thống có thẩm quyền.

Khi xung đột tăng đột biến, cần chế độ an toàn dừng hợp nhất tự động và yêu cầu phê duyệt của người phụ trách nghiệp vụ tại hàng đợi tạm giữ.

Tái đồng bộ dùng checkpoint và nhật ký thay đổi để thu hẹp khoảng bị thiếu thay vì sao chép toàn bộ, và trong lúc tái đồng bộ dùng kiểm tra phiên bản để dữ liệu cũ không ghi đè dữ liệu mới.

8. Chuyên sâu: CRDT và kiến trúc hướng sự kiện

CRDT (Conflict-free Replicated Data Type) thiết kế cấu trúc dữ liệu và thao tác sao cho kết quả hợp nhất hội tụ dù thứ tự thao tác và thời điểm đến ở các bản sao phân tán khác nhau.

Có thể kết hợp thêm·xóa tập hợp, tăng bộ đếm, thanh ghi và bản đồ, và nhờ tính kết hợp toán học và tính lũy đẳng mà đơn giản hóa việc gửi lại qua mạng.

Tuy nhiên, phải xử lý riêng ý nghĩa của xóa và thêm lại, sự gia tăng siêu dữ liệu, thu gom rác, sự thao túng của client độc hại.

Trong kiến trúc hướng sự kiện, sự kiện gốc được bảo toàn và nhiều bên tiêu thụ cập nhật độc lập chỉ mục tìm kiếm·thông báo·mô hình phân tích.

Khi đó, khả năng tương thích ngược của lược đồ sự kiện, phạm vi bảo đảm thứ tự, phát lại sự kiện, cô lập độ trễ của bên tiêu thụ, chính sách lan truyền xóa thông tin cá nhân đều nằm trong thiết kế tính nhất quán.

Sự kiện cuối cùng sẽ đến không có nghĩa là màn hình của bên tiêu thụ luôn mới nhất, nên việc cung cấp cho người dùng trạng thái xử lý và thời điểm chuẩn là quan trọng.

9. Các điểm cần cân nhắc và hàm ý

A. Ưu tiên bất biến nghiệp vụ

Không quyết định mô hình nhất quán theo xu hướng công nghệ hay giá trị mặc định của cơ sở dữ liệu, mà trước tiên phải nhận diện các bất biến có thiệt hại lớn về tài chính·pháp lý·an toàn khi bị vi phạm.

Tài nguyên chỉ được tồn tại duy nhất trên toàn cục thì đặt ranh giới mạnh như quyền đặt trước·leader·dịch vụ đồng thuận, còn các mô hình truy vấn còn lại mở rộng bất đồng bộ.

B. Trải nghiệm người dùng và hợp đồng

Nếu giá trị cũ có thể hiển thị, phải nêu rõ thời điểm chuẩn, trạng thái xử lý, cách truy vấn lại trên màn hình·tài liệu API.

Cần phân biệt trong hợp đồng với bên tiêu thụ API rằng “ghi thành công” là hoàn tất lưu bản gốc hay hoàn tất phản ánh vào mọi hệ thống phái sinh.

C. Lan truyền bảo mật·thông tin cá nhân

Thu hồi quyền và xóa thông tin cá nhân phải có mục tiêu lan truyền nghiêm ngặt hơn nội dung thông thường.

Truy vết xem yêu cầu xóa có tới được cache·chỉ mục tìm kiếm·bản sao lưu·kho phân tích hay không, và vận hành log kiểm toán cho phép xác nhận các bản sao còn sót.

D. Chi phí và độ phức tạp vận hành

Nhất quán cuối cùng có thể giảm chi phí mạng và độ trễ người dùng, nhưng lại tạo ra chi phí mới cho nền tảng lưu sự kiện·tái xử lý·rà soát xung đột·quan sát.

Do đó, phải đưa ngân sách độ trễ hội tụ, nhân lực xử lý xung đột, chi phí vận hành hàng đợi tạm giữ vào tổng chi phí sở hữu.

E. Lộ trình dưới góc nhìn Kỹ sư chuyên nghiệp

Ban đầu, xác định phân loại dữ liệu và chỉ số hội tụ, sau đó bổ trợ trải nghiệm phiên bằng token phiên bản và sự kiện lũy đẳng.

Khi quy mô dịch vụ tăng lên, chuẩn hóa thành chức năng nền tảng các nội dung: diễn tập sự cố theo vùng, tái đồng bộ tự động, kiểm toán xung đột, dòng dõi dữ liệu.

Cuối cùng, phải kết nối dữ liệu có thẩm quyền, dữ liệu phái sinh, bảo đảm trải nghiệm người dùng, thủ tục phục hồi thành một hệ thống quản trị dữ liệu thống nhất.

Tài liệu tham khảo

Tóm tắt một câu: Nhất quán cuối cùng dùng sao chép bất đồng bộ để nâng cao độ trễ và tính sẵn sàng nhưng phải chấp nhận đọc cũ·xung đột·tái xử lý, vì vậy cần thiết kế đồng thời mức bảo đảm theo mức quan trọng của dữ liệu cùng việc vận hành hội tụ·phục hồi.