Ghi đa vùng: thay đổi thực sự được xác nhận ở đâu?

Hai máy chủ ứng dụng ở hai vùng, một máy khách ghi qua VPN, và một câu hỏi không ai viết ra: thành phần nào quyết định rằng việc ghi đã xảy ra? Định tuyến đưa yêu cầu đến một tiến trình. Ranh giới giao dịch quyết định khi nào thay đổi trở nên bền vững và hiển thị. Đó là những công việc khác nhau do các hệ thống khác nhau thực hiện, và khoảng trống giữa chúng là nơi phần lớn lỗi ghi đa vùng sinh sống.

Bắt đầu từ quy tắc kinh doanh, không phải bản đồ

Hãy bắt đầu bằng một câu về quy tắc kinh doanh thay vì về địa lý: những lần đọc và ghi nào phải thành công cùng nhau, và những thay đổi đồng thời nào phải là bất khả thi trong lúc đó. Với việc giữ chỗ tồn kho, điều đó có nghĩa là kiểm tra tồn kho và giữ chỗ hoặc cả hai đều có hiệu lực hoặc không cái nào, và không đơn hàng thứ hai nào được tiêu thụ cùng đơn vị đó ở giữa.

Chính hàng ở giữa đó là thứ các nhóm bỏ qua. Tính nguyên tử mà không có cách ly đầy đủ cho phép hai giao dịch mỗi cái được xác nhận đúng cách và vẫn tạo ra một trạng thái mà doanh nghiệp coi là bất khả thi, và không lượng logic thử lại nào sửa được điều đó về sau.

Một ranh giới có thẩm quyền thắng hai máy chủ vùng

Các máy chủ ứng dụng theo vùng có thể ở nguyên chỗ, miễn là chúng gửi thao tác đến một dịch vụ thực hiện nó bên trong một ranh giới giao dịch được hỗ trợ duy nhất. Tầng ứng dụng trở thành bộ định tuyến của ý định; tầng dữ liệu sở hữu sự thật.

Giữ ranh giới đó ngắn và gần dữ liệu mà nó chạm vào. Một giao dịch để mở trong khi con người trả lời một lời nhắc, hoặc trong khi một lời gọi băng qua hai vùng, dành thời gian của nó để giữ khóa và làm tăng khả năng một thứ khác hết thời gian ở phía sau. Lỗi đó trông giống vấn đề cơ sở dữ liệu và thực ra là vấn đề thiết kế đang mặc bộ đồ đó. Chuyển quyết định xuống tầng dữ liệu thường loại bỏ nó hoàn toàn.

BEGIN;
UPDATE inventory SET reserved = reserved + 1
 WHERE sku = 'A-100' AND available >= 1;
INSERT INTO reservation (sku, order_id) VALUES ('A-100', 'ord-9f');
COMMIT;

Hãy đọc bản phác thảo đó như một ranh giới, không phải như một khuyến nghị hiệu năng. Điểm mấu chốt là việc kiểm tra và việc chèn chia sẻ một lần xác nhận, nên một đơn hàng đồng thời hoặc thấy tồn kho bị tiêu thụ hoặc không bao giờ thấy.

Cơ sở dữ liệu sao chép cho được gì và không cho được gì

Một cơ sở dữ liệu sao chép có thể cung cấp ranh giới rộng hơn khi mô hình giao dịch của chính nó hỗ trợ điều đó. Spanner ghi nhận các giao dịch đọc-ghi nguyên tử trong một cơ sở dữ liệu duy nhất xuyên các bảng, với cách ly và hành vi thử lại được xác định. Đó là một bảo đảm mà bạn đọc, kiểm thử và dựa vào một cách có chủ đích.

Đó cũng là bảo đảm đến từ sản phẩm, không phải từ tuyến đường. Một VPN giữa các vùng thay đổi cách các gói tin di chuyển và cách lỗi tự thể hiện. Nó không mở rộng ranh giới giao dịch thêm một hàng nào, dù đường hầm trông khỏe đến đâu. Nhầm lẫn hai điều đó tạo ra những kiến trúc mà mọi thành phần đều qua được kiểm tra của riêng nó và dữ liệu vẫn không khớp.

Hai cơ sở dữ liệu không trở thành một hệ thống

Hai cơ sở dữ liệu được quản lý độc lập không có được một trình quản lý giao dịch dùng chung chỉ vì máy khách chạm tới được cả hai. Nếu doanh nghiệp thực sự cần cam kết nguyên tử xuyên cặp đó, cơ chế phối hợp, các bên tham gia và quy trình phục hồi đều phải được chọn và đánh giá thay vì giả định.

Hãy nghĩ đến khoảnh khắc một bên tham gia hoặc một liên kết biến mất sau khi công việc đã được chuẩn bị. Một cam kết phân tán được hỗ trợ có thể để lại trạng thái chưa rõ cần thủ tục phục hồi và quyết định của con người, và nó không đi kèm lời hứa rằng mọi vùng vẫn ghi được qua mọi phân vùng.

Nếu thay vào đó có thể chấp nhận phối hợp bất đồng bộ, hãy nói rõ điều đó và ghi lại các trạng thái kinh doanh trung gian cùng các quy tắc đối soát. Một chuỗi các bước được xác nhận cục bộ với phần bù là một thiết kế hợp lệ; nó chỉ đơn giản không phải một giao dịch nguyên tử dưới tên khác.

Thiết kế việc thử lại trước sự cố đầu tiên

Máy khách có thể mất phản hồi sau khi thao tác đã được xác nhận, nên bên gọi không thể coi thời gian chờ là thất bại. Hãy giữ một danh tính yêu cầu bền vững và dùng kết quả của dịch vụ hoặc cơ chế bất biến trước khi thử lại một thay đổi, nếu không lần thử lại trở thành lần ghi thứ hai.

Các lệnh gọi lại giao dịch tự động cũng có thể chạy nhiều hơn một lần sau một lần hủy có thể thử lại, khiến chúng thành nơi tồi để đặt các hiệu ứng bên ngoài không thể đảo ngược. Hãy giữ những thứ đó bên ngoài lệnh gọi lại trừ khi quy trình công việc định nghĩa một giao thức an toàn rõ ràng cho chúng. Sự thận trọng tương tự áp dụng cho bất cứ thứ gì tốn tiền hoặc gửi một tin nhắn. Một khoản tính tiền trùng là cuộc trò chuyện khó hơn nhiều so với một dòng nhật ký trùng.

Việc nghiệm thu nên phát lại bốn kịch bản: hai máy khách tranh nhau cùng một hàng, một lần hủy mà dịch vụ nói có thể thử lại, một lần xác nhận mà câu trả lời không bao giờ đến, và việc mất một vùng hoặc liên kết giữa chúng. Hãy ghi lại kết quả kinh doanh đã xác nhận và các trạng thái chưa giải quyết bên cạnh thiết kế định tuyến, để không ai nhầm mạng lưới với thành phần cung cấp bảo đảm.