Sự Nhất Quán Cuối Cùng (Eventual Consistency): Giá Phải Trả Khi Chuyển Sang Microservices

Tôi đã chán ngấy cảnh các lập trình viên mù quáng chạy theo các xu hướng kiến trúc mà không hiểu rõ cái giá phải trả. Việc chia nhỏ một monolith nhàm chán nhưng gọn gàng thành một mạng lưới dịch vụ phân tán cảm thấy rất tuyệt vời trong một dự án mới (greenfield), cho đến khi các giao dịch cơ sở dữ liệu đột nhiên biến mất. Việc dựa vào sự nhất quán cuối cùng (eventual consistency) là cái giá chúng ta phải trả cho tính sẵn sàng cao (high availability), nhưng quá nhiều đội nhóm lại phớt lờ chi phí kỹ thuật khổng lồ mà nó mang lại. Để tôi nói thẳng: Định lý CAP không quan tâm đến kiến trúc sạch sẽ hay bộ công nghệ (tech stack) hào nhoáng của bạn. Nếu bạn phân tán dữ liệu để sống sót qua sự phân mảnh mạng (network partitions), bạn sẽ mất tính nhất quán. Đơn giản vậy thôi.

Hình minh họa về kiến trúc hệ thống

Đừng Tưởng Giá Trị P99 trên Bảng Điều Khiển Là Mọi Thứ

Trong nhiều năm dọn dẹp những mớ hỗn độn trong môi trường sản xuất (production), tôi đã học được rằng các chỉ số giám sát có thể là những lời nói dối hoàn toàn. Các bản sao cơ sở dữ liệu (replicas) của bạn có thể tự hào về thời gian đồng bộ hóa dưới mili-giây trên một bảng điều khiển sạch đẹp, trong khi người dùng thực tế đang phải chịu độ trễ khổng lồ. Khi một người dùng tạo một tài nguyên, kích hoạt làm mới trang, và không thấy gì cả vì yêu cầu đọc trúng vào một node đang bị chậm, bạn đã thất bại họ. Không quan trọng truy vấn của bạn nhanh thế nào nếu dữ liệu chúng phục vụ về cơ bản là không chính xác.

Chúng ta cần ngừng nhìn vào hệ thống phân tán qua lăng kính hiệu suất thuần túy và bắt đầu nhìn qua lăng kính của tính chính xác nghiêm ngặt. Nếu bạn không có một chiến lược riêng cho tính nhất quán "đọc những gì bạn viết" (read-your-writes consistency) tại tầng gateway hoặc ứng dụng, kiến trúc của bạn chỉ là một sự cố đang chờ xảy ra.

Cơn Ác Mộng Tuyệt Đối Của Trạng Thái Phân Tán

Điều tồi tệ nhất bạn có thể làm khi xử lý sự không nhất quán dữ liệu trong microservices là tin vào đồng hồ hệ thống (wall-clock timestamps) để giải quyết xung đột. Tôi đã từng nhìn thấy toàn bộ dữ liệu bị âm thầm hỏng hóc chỉ vì một đội ngũ tin một cách mù quáng vào chiến lược "Ghi Cuối Cùng Thắng" (Last Write Wins) trên các triển khai đa khu vực (multi-region). Một độ trễ đồng hồ 50 mili-giây giữa các máy chủ của bạn là đủ để ghi đè dữ liệu người dùng mới và hợp lệ bằng một trạng thái cũ, lỗi thời.

Nếu doanh nghiệp của bạn không thể chấp nhận mất dữ liệu, bạn cần từ bỏ các phương pháp heuristic đơn giản và bắt đầu triển khai giải quyết xung đột xác định (deterministic conflict resolution). Chúng ta cần bình thường hóa việc đưa các khái niệm nâng cao như Loại Dữ Liệu Nhân Bản Không Xung Đột (CRDTs) và đồng hồ vector (vector clocks) ra khỏi các bài viết nghiên cứu và đưa vào cơ sở mã sản xuất hàng ngày. Có, việc mô hình hóa dữ liệu sẽ khó hơn, nhưng đó là cách duy nhất để ngăn cơ sở dữ liệu của bạn "nuốt chửng" các lệnh ghi trong sự kiện chia cắt não bộ (split-brain).

Quy Tắc Thực Tế Thay Vì "Cảm Hứng" Kiến Trúc

Tôi vừa xuất bản một bản phân tích sâu sắc, thực tế về cách thực sự thuần hóa những "quái vật" này mà không khiến bạn phát điên. Trong đó, tôi vén màn về lý do tại sao Cam kết Hai Giai Đoạn (Two-Phase Commits) cổ điển là một bẫy deadlock và tại sao mô hình Saga là người cứu tinh thực sự duy nhất cho các hoạt động đa dịch vụ. Tôi cũng đã tổng hợp một danh sách kiểm tra kiến trúc nghiêm ngặt mà bạn có thể sử dụng để kiểm toán hệ thống hiện tại của mình trước khi người dùng nhận ra những vết nứt.

Đừng để những "cảm hứng" kiến trúc chi phối lựa chọn cơ sở dữ liệu của bạn. Hãy xem bản phân tích đầy đủ và hãy cùng thảo luận trong phần bình luận về cách bạn giữ cho dữ liệu phân tán của mình không bị sụp đổ.

Tác giả: Krun Dev Sys