Amazon Aurora MySQL Bài 11: Cơ chế Quorum Read/Write trong tầng lưu trữ phân tán của Aurora

Khi tìm hiểu về các hệ thống cơ sở dữ liệu phân tán (Distributed Databases), Quorum (Biểu quyết/Hạn ngạch) là thuật toán toán học cốt lõi quyết định tính nhất quán dữ liệu (Consistency) và độ sẵn sàng (Availability). Trong Amazon Aurora MySQL, tầng lưu trữ (Storage Layer) sử dụng mô hình Quorum cực kỳ tinh vi để thay thế cho các cơ chế khóa ổ đĩa cứng hoặc đồng bộ truyền thống.

Bài viết này sẽ mổ xẻ chi tiết cách Quorum Read/Write hoạt động bên dưới mui xe của Aurora.

1. Bản chất của mô hình Quorum trong hệ thống phân tán

Ở các cơ sở dữ liệu đơn khối (Monolithic), việc ghi dữ liệu chỉ diễn ra trên một ổ cứng cục bộ. Nhưng trong một hệ thống phân tán nơi dữ liệu được nhân bản ra nhiều nơi, câu hỏi đặt ra là: Làm sao để hệ thống biết một transaction ghi đã thực sự hoàn thành an toàn khi một vài bản sao có thể bị chậm trễ hoặc mất kết nối mạng?

Mô hình Quorum giải quyết bài toán này dựa trên nguyên lý tập hợp giao (Overlapping Sets). Thay vì bắt buộc tất cả các bản sao phải đồng bộ xong mới báo thành công (gây chậm hệ thống), Aurora chỉ yêu cầu một số lượng tối thiểu (quốc hội/hạn ngạch) các bản sao xác nhận thành công.

2. Cấu trúc Quorum 6 bản sao của Aurora (The Math Behind It)

Như chúng ta đã bàn ở các bài trước, mỗi khối dữ liệu 10GB của Aurora Storage Volume được nhân bản thành 6 bản sao ($N = 6$) và rải đều trên 3 Availability Zones (AZs).

Để vận hành hệ thống đọc/ghi mà không có độ trễ lớn nhưng vẫn đảm bảo không bao giờ mất dữ liệu hoặc đọc phải dữ liệu cũ, Aurora áp dụng công thức Quorum tiêu chuẩn:

• Write Quorum ($W$): Số lượng bản sao tối thiểu phải xác nhận đã ghi thành công trước khi hệ thống coi như transaction hoàn tất.

  • Trong Aurora, $W = 4$ trên tổng số 6 bản sao.

• Read Quorum ($R$): Số lượng bản sao tối thiểu cần truy vấn khi đọc dữ liệu để chắc chắn lấy được phiên bản mới nhất.

  • Trong Aurora, $R = 3$ trên tổng số 6 bản sao.

Kiểm chứng nguyên lý Quorum: Ta luôn có $W + R = 4 + 3 = 7$, lớn hơn tổng số bản sao $N = 6$ ($W + R > N$). Điều này đảm bảo rằng tập hợp các bản sao đọc luôn có ít nhất một bản sao giao nhau với tập hợp các bản sao ghi gần nhất, triệt để loại bỏ hiện tượng đọc nhầm dữ liệu cũ (Stale Read).

3. Q trình Quorum Write và Quorum Read hoạt động ra sao?

a. Q trình Ghi (Write Path)

1. Writer Instance đẩy các Log Record xuống tầng lưu trữ phân tán.

2. Các Storage Nodes nhận log record và tiến hành ghi vào bộ nhớ đệm/đĩa của chúng.

3. Ngay khi nhận được phản hồi xác nhận (ACK) từ 4 trên 6 node lưu trữ, tầng storage báo về cho Writer rằng transaction đã ghi thành công.

4. Hai node còn lại có thể phản hồi chậm hơn một chút, hệ thống sẽ tự động đồng bộ ngầm ở tầng nền (background sync) mà không làm gián đoạn tiến trình của ứng dụng.

b. Q trình Đọc (Read Path)

1. Khi ứng dụng yêu cầu đọc dữ liệu, Aurora không bắt buộc phải hỏi tất cả 6 node.

2. Nó chỉ cần lấy phản hồi từ 3 node có chứa số hiệu version (LSA - Log Sequence Number) mới nhất.

3. Nhờ cơ chế này, tốc độ đọc và ghi luôn được tối ưu hóa ở mức cao nhất, tránh việc bị nghẽn do một vài node phần cứng ở tầng dưới gặp sự cố hoặc bận xử lý tác vụ khác.

4. Khả năng chống chịu lỗi tuyệt vời (Fault Tolerance)

Nhờ cơ chế Quorum kết hợp 6 bản sao phân tán trên 3 AZs, cụm Aurora có sức chống chịu phần cứng cực kỳ ấn tượng:

• Chịu mất toàn bộ 1 AZ: Giả sử một AZ chứa 2 bản sao bị sập hoàn toàn do mất điện trung tâm dữ liệu, hệ thống vẫn còn lại 4 bản sao ở 2 AZ còn lại. Vẫn đủ điều kiện thỏa mãn $W = 4$ và $R = 3$, ứng dụng tiếp tục đọc/ghi bình thường mà không hề gián đoạn.

• Chịu lỗi đồng thời các node lẻ: Ngay cả khi mất 1 AZ và hỏng thêm 1 bản sao đơn lẻ ở AZ khác (tổng cộng mất 3 bản sao), hệ thống vẫn có thể đọc (vì cần ít nhất 3 node) dù lúc này việc ghi có thể bị hạn chế cho đến khi tiến trình tự phục hồi (self-healing) tạo lại bản sao mới.

5. Góc nhìn vận hành cho Backend Engineer

• Tính nhất quán mạnh (Strong Consistency): Mặc dù phân tán trên nhiều thiết bị phần cứng, cơ chế Quorum của Aurora đảm bảo dữ liệu sau khi được câu lệnh COMMIT trả về thành công là hoàn toàn nhất quán. Bạn không phải lo lắng về bài toán "eventual consistency" (nhất quán cuối cùng) phức tạp như trên các NoSQL databases thông thường.

• Tách biệt áp lực I/O: Toàn bộ toán tử Quorum phức tạp này được xử lý hoàn toàn bởi các bộ vi xử lý thông minh nằm ở tầng storage phân tán, giải phóng hoàn toàn CPU và RAM của các Aurora Instance (Writer/Reader) để tập trung xử lý logic truy vấn SQL từ ứng dụng backend.