Vì sao dữ liệu giữa nhiều hệ thống có thể không nhất quán?

Vì vậy, tính nhất quán của dữ liệu không đơn giản là “mọi nơi phải có cùng một giá trị”. Cần xét cả trạng thái dữ liệu có tuân thủ quy tắc nghiệp vụ hay không, các thay đổi có được nhìn nhận theo đúng thứ tự hay không và những hệ thống liên quan có đang sử dụng cùng một nguồn sự thật hay không.

Tính nhất quán của dữ liệu là gì?

Ở cấp cơ sở dữ liệu, tính nhất quán có thể hiểu là sau một giao dịch, dữ liệu vẫn phải tuân thủ các quy tắc và ràng buộc đã được xác định. Một giao dịch hợp lệ phải đưa cơ sở dữ liệu từ một trạng thái hợp lệ sang một trạng thái hợp lệ khác.

Ví dụ, nếu quy tắc nghiệp vụ quy định một đơn hàng đã hủy không được tiếp tục ghi nhận là đang giao, thì trạng thái cuối cùng phải phù hợp với quy tắc đó. Đây là khía cạnh consistency trong mô hình giao dịch, khác với việc chỉ kiểm tra hai hệ thống có đang hiển thị cùng một giá trị hay không.

Khi mở rộng sang nhiều hệ thống, khái niệm trở nên phức tạp hơn. Một khách hàng có thể tồn tại đồng thời trong CRM, hệ thống thanh toán và kho dữ liệu. Nếu CRM đã cập nhật địa chỉ mới nhưng kho dữ liệu chưa nhận được thay đổi, hai nguồn có thể tạm thời khác nhau dù mỗi hệ thống vẫn đang hoạt động bình thường.

Do đó, có thể nhìn tính nhất quán theo hai lớp:

·         Nhất quán nội bộ: dữ liệu trong một hệ thống tuân thủ các ràng buộc và quy tắc của hệ thống đó

·         Nhất quán giữa các hệ thống: các hệ thống có cách biểu diễn và cập nhật trạng thái của cùng một đối tượng phù hợp với quy tắc đồng bộ đã thống nhất

Hai lớp này không đồng nghĩa. Một cơ sở dữ liệu có thể nhất quán nội bộ nhưng vẫn khác dữ liệu trong một hệ thống khác.

Vì sao nhiều hệ thống có thể lưu cùng một dữ liệu nhưng cho kết quả khác nhau?

Nguyên nhân cốt lõi là một thay đổi dữ liệu không nhất thiết được thực hiện đồng thời, theo cùng một quy tắc và tại cùng một thời điểm ở tất cả các hệ thống.

Độ trễ đồng bộ tạo ra trạng thái tạm thời khác nhau

Một hệ thống nguồn có thể ghi thay đổi trước, sau đó mới phát sự kiện hoặc gửi dữ liệu sang hệ thống đích. Trong khoảng thời gian đó, hai nguồn có thể nhìn thấy hai phiên bản khác nhau.

Ví dụ:

1.    Hệ thống bán hàng cập nhật trạng thái đơn hàng từ “Đang xử lý” thành “Đã giao”

2.    Sự kiện cập nhật được gửi sang hệ thống phân tích

3.    Hệ thống phân tích chưa xử lý sự kiện

4.    Báo cáo vẫn hiển thị “Đang xử lý”

Đây là dạng eventual consistency: các bản sao có thể chưa giống nhau tại một thời điểm, nhưng thiết kế hệ thống hướng tới việc hội tụ sau khi các thay đổi được truyền và xử lý.

Điểm quan trọng là “khác nhau” không nhất thiết đồng nghĩa với “sai”. Nó có thể là trạng thái được thiết kế và chấp nhận vì hệ thống ưu tiên độ trễ thấp, khả năng mở rộng hoặc tính sẵn sàng.

Hai hệ thống có thể cùng cập nhật một bản ghi

Xung đột rõ ràng hơn xảy ra khi nhiều hệ thống đều có quyền ghi.

Giả sử thông tin hạn mức tín dụng của một khách hàng ban đầu là 100 triệu đồng:

·         Hệ thống A đọc giá trị 100 triệu và cập nhật thành 120 triệu

·         Hệ thống B cũng đọc giá trị cũ 100 triệu và cập nhật thành 110 triệu

·         Hai thay đổi được xử lý gần như đồng thời

Nếu không có cơ chế kiểm soát phiên bản hoặc giải quyết xung đột, giá trị cuối cùng có thể phụ thuộc vào thứ tự ghi thay vì phản ánh đúng ý định nghiệp vụ.

Trong các hệ thống giao dịch, các cơ chế kiểm soát đồng thời như serializable isolation được dùng để hạn chế những bất thường kiểu này. Chẳng hạn, các giao dịch có thể được xử lý đồng thời về mặt vật lý nhưng phải cho kết quả tương đương với một thứ tự thực thi tuần tự.

Mỗi hệ thống có thể dùng một mô hình dữ liệu khác

Cùng một đối tượng nhưng các hệ thống có thể định nghĩa khác nhau.

Ví dụ, một hệ thống coi:

·         “Khách hàng hoạt động” = có giao dịch trong 12 tháng gần nhất

Trong khi hệ thống khác coi:

·         “Khách hàng hoạt động” = tài khoản chưa bị khóa

Hai hệ thống có thể cùng lưu trạng thái “active” nhưng thực tế đang trả lời hai câu hỏi nghiệp vụ khác nhau.

Đây không chỉ là vấn đề đồng bộ dữ liệu. Nó là khác biệt về ngữ nghĩa và quy tắc nghiệp vụ.

Thứ tự các sự kiện có thể bị thay đổi

Giả sử:

·         Sự kiện A: đơn hàng được tạo

·         Sự kiện B: đơn hàng được thanh toán

Nếu hệ thống đích xử lý B trước A, nó có thể tạm thời gặp trạng thái không hợp lệ hoặc không thể liên kết B với đơn hàng tương ứng.

Trong hệ thống phân tán, việc bảo toàn quan hệ nhân quả và thứ tự quan sát của các giao dịch là một vấn đề kỹ thuật quan trọng. Các hệ thống có cơ chế nhất quán mạnh phải giải quyết cả thứ tự giao dịch, timestamp và đồng thời giữa nhiều máy chủ.

Một nguồn có thể đang đọc phiên bản cũ

Không phải mọi lần đọc dữ liệu đều yêu cầu giá trị mới nhất.

Một hệ thống có thể chủ động cho phép đọc dữ liệu cũ trong một khoảng thời gian để đổi lấy hiệu năng hoặc giảm độ trễ. Khi đó, hai truy vấn ở các thời điểm hoặc replica khác nhau có thể quan sát các phiên bản khác nhau.

Điều này khác với việc dữ liệu bị ghi sai. Vấn đề nằm ở consistency guarantee mà hệ thống cung cấp cho thao tác đọc.

Những loại xung đột dữ liệu thường gặp giữa các hệ thống

Có thể phân biệt xung đột theo nguyên nhân thay vì chỉ nhìn vào việc “hai giá trị khác nhau”.

Như vậy, không nên xử lý mọi trường hợp bằng cách đơn giản là “copy giá trị từ hệ thống A sang hệ thống B”. Nếu nguyên nhân là khác biệt về quy tắc hoặc quyền sở hữu dữ liệu, việc sao chép có thể chỉ che giấu xung đột chứ không giải quyết nó.

Khi nào sự không nhất quán là vấn đề nghiêm trọng?

Mức độ nghiêm trọng phụ thuộc vào yêu cầu nghiệp vụ đối với dữ liệu, không chỉ vào việc các nguồn có khác nhau hay không.

Nếu dữ liệu dùng cho một báo cáo có thể chấp nhận độ trễ vài phút, eventual consistency có thể là lựa chọn hợp lý. Ngược lại, với các giao dịch cần bảo đảm trạng thái chính xác tại thời điểm xử lý, việc cho phép các hệ thống nhìn thấy những trạng thái mâu thuẫn có thể gây hậu quả lớn.

Một cách đánh giá là đặt ba câu hỏi:

1.    Dữ liệu nào là nguồn sự thật?

2.    Bao lâu thì các hệ thống phải hội tụ về cùng trạng thái?

3.    Trong thời gian chưa hội tụ, trạng thái nào được phép xuất hiện?

Nếu không trả lời được ba câu hỏi này, tổ chức rất dễ nhầm giữa “độ trễ đồng bộ được chấp nhận” và “lỗi dữ liệu”.

Các hệ thống phân tán có thể cung cấp những mức bảo đảm khác nhau. Chẳng hạn, Google Cloud Spanner cung cấp external consistency, trong đó thứ tự giao dịch được bảo đảm phù hợp với thứ tự commit quan sát được trong thời gian thực; đây là mức bảo đảm mạnh hơn eventual consistency.

Làm thế nào để giảm xung đột dữ liệu giữa nhiều hệ thống?

Giải pháp hiệu quả không chỉ là tăng tốc độ đồng bộ. Cần kiểm soát cả nguồn dữ liệu, quyền ghi, thứ tự thay đổi và quy tắc giải quyết xung đột.

Trước hết, mỗi loại dữ liệu quan trọng nên có một nguồn sự thật được xác định rõ. Các hệ thống khác có thể lưu bản sao để phục vụ nghiệp vụ riêng nhưng cần biết bản sao đó có vai trò gì và khi nào phải quay về nguồn chính để xác thực.

Tiếp theo, cần xác định rõ hệ thống nào có quyền cập nhật từng trường dữ liệu. Nếu nhiều hệ thống đều có quyền ghi nhưng không có quy tắc ưu tiên, xung đột gần như không thể tránh khỏi.

Với kiến trúc đồng bộ qua sự kiện, cần quan tâm đến:

·         Thứ tự sự kiện

·         Mã phiên bản hoặc thời điểm cập nhật

·         Khả năng xử lý lại sự kiện

·         Phát hiện sự kiện trùng lặp

·         Xử lý sự kiện đến muộn

·         Cơ chế phát hiện và giải quyết xung đột

Ở cấp giao dịch, các cơ chế kiểm soát đồng thời phù hợp có thể ngăn nhiều kiểu xung đột giữa các thao tác đọc và ghi. Ví dụ, serializable isolation được thiết kế để các giao dịch đồng thời cho kết quả tương đương với một thứ tự tuần tự, trong khi repeatable read cung cấp một snapshot nhất quán trong phạm vi giao dịch.

Cuối cùng, cần phân biệt tính nhất quán kỹ thuật với tính đúng đắn nghiệp vụ. Một hệ thống có thể đồng bộ rất nhanh nhưng vẫn tạo dữ liệu sai nếu các hệ thống đang áp dụng những định nghĩa hoặc quy tắc nghiệp vụ khác nhau.

Tóm lại, dữ liệu từ nhiều hệ thống không nhất quán vì các nguồn có thể cập nhật ở những thời điểm khác nhau, sử dụng phiên bản khác nhau, xử lý sự kiện theo thứ tự khác nhau, cùng ghi lên một đối tượng hoặc hiểu cùng một trường dữ liệu theo những quy tắc khác nhau. Muốn giảm xung đột, cần thiết kế rõ nguồn sự thật, quyền sở hữu dữ liệu, mức consistency cần thiết và cơ chế kiểm soát phiên bản, đồng bộ và xử lý xung đột ngay từ kiến trúc hệ thống.