Gần hai năm trước, trong bài Dual write, mình có giới thiệu một vài pattern để xử lý dual write và nói rằng có thể sẽ viết kỹ hơn về chúng sau. Hơi lâu một chút, nhưng cuối cùng cũng tới lúc rồi. Nếu chưa đọc bài đó, bạn có thể xem lại để hiểu vấn đề và lý do chỉ đổi thứ tự ghi hay retry trong bộ nhớ vẫn chưa giải quyết được.
Khi học hoặc làm việc với database, bạn có từng gặp các chữ viết tắt ACID, BASE, CAP rồi tự hỏi chúng có nghĩa là gì không? Mình đã từng như vậy, và bài này là kết quả tìm hiểu của mình về chủ đề đó.
CAP là viết tắt của Consistency, Availability, Partition-tolerance, được Eric Brewer giới thiệu trong một buổi diễn thuyết vào năm 2000. Theo Brewer, khi xảy ra partition trong một hệ thống phân tán, tức là kết nối mạng hoặc liên lạc giữa các node bị chia cắt, hệ thống chỉ có thể chọn consistency hoặc availability. Nó không thể đảm bảo cả hai cùng lúc. Vậy những tính chất này là gì, và tại sao chúng ta không thể chọn cả hai?
Khi làm backend, chúng ta thường gặp một cách xử lý dữ liệu như sau: server nhận dữ liệu từ message broker hoặc API, xử lý theo quy tắc nghiệp vụ rồi thêm hoặc cập nhật dữ liệu vào database. Sau đó, server tiếp tục gửi dữ liệu đến server kế tiếp qua message broker hoặc API. Cách xử lý này được gọi là dual write, đôi khi còn gọi là multi-write hoặc sync-write.