Trong bài viết này, chúng ta sẽ thảo luận về một hình mẫu thiết kế cơ sở dữ liệu được sử dụng rộng rãi, được gọi là Read Replica Pattern (bản sao chỉ có quyền đọc). Thiết lập này liên quan đến việc gửi tất cả các hoạt động sửa đổi dữ liệu như chèn, xóa và cập nhật tới cơ sở dữ liệu chính, trong khi các truy vấn đọc được gửi tới các read replicas (bản sao chỉ có quyền đọc).
Để bạn dễ hiểu cách hoạt động của nó, sau đây là sơ đồ:
Ví dụ: Khi người dùng có tên Alice đặt hàng trên MFast.vn, yêu cầu sẽ được gửi đến Dịch vụ đặt hàng (order service). Dịch vụ đặt hàng tạo một bản ghi của đơn đặt hàng trong cơ sở dữ liệu chính(Primary DB) (ghi). Dữ liệu sau đó được sao chép thành hai bản sao chỉ có quyền đọc (Secondary DB).
Giờ đây, khi Alice muốn xem chi tiết đơn đặt hàng của mình hoặc lịch sử đặt hàng gần đây, dữ liệu được lấy ra từ một bản sao chỉ có quyền đọc (read).
Tuy nhiên, có một vấn đề lớn với thiết lập này, được gọi là độ trễ sao chép (replication lag).
Trong một số trường hợp, chẳng hạn như mạng bị chậm hoặc máy chủ quá tải, dữ liệu trong các bản sao có thể sẽ chậm hơn vài giây hoặc thậm chí vài phút so với cơ sở dữ liệu chính. Trong trường hợp này, nếu Alice ngay lập tức kiểm tra trạng thái đơn hàng sau khi đặt và truy vấn được thực hiện bởi một bản sao, thì cô ấy có thể hoàn toàn không nhìn thấy đơn hàng, dẫn đến nhầm lẫn. Để khắc phục điều này, chúng ta cần một khái niệm gọi là tính nhất quán "đọc-sau-ghi" (read-after-write).
Để giải quyết vấn đề này, có một số giải pháp khả thi, bao gồm:
Gửi tất cả các lần đọc dữ liệu có nguy cơ trễ đến cơ sở dữ liệu chính.
Trỏ tất cả các câu truy vấn đọc sau khi vừa được ghi đến cơ sở dữ liệu chính
Trong một cơ sở dữ liệu quan hệ, kiểm tra xem một bản sao có bắt kịp với bản chính hay không. Nếu dữ liệu đã được đồng bộ, truy vấn có thể được cung cấp bởi bản sao. Nếu không, yêu cầu đọc có thể sẽ không thành công hoặc được cung cấp dữ liệu từ cơ sở dữ liệu chính.
Hữu ích quá!