Dựa trên những gì tôi đã hiểu về tính nhất quán cuối cùng, tất cả các dịch vụ này (người tiêu dùng) sẽ nhận được sự kiện cùng một lúc và xử lý chúng một cách riêng biệt , trong một kịch bản tốt, sẽ dẫn đến dữ liệu nhất quán.
Không, không nhất thiết. Như tôi đã nhận xét, chúng tôi không thể hoàn tác một email đã gửi, vì vậy chúng tôi vẫn cần một loại "trình tự". IPC về quản lý dữ liệu theo sự kiện không được miễn trừ cho việc trồng cây 1 .
Chẳng hạn, email không nên được gửi trừ khi các giao dịch trước đó kết thúc thành công và dịch vụ email có bằng chứng về nó. 3
Tuy nhiên, nếu một dịch vụ không xử lý sự kiện thì sao? ví dụ ngắt kết nối đột ngột, lỗi cơ sở dữ liệu, v.v ... Mô hình / thực tiễn tốt để xử lý các lỗi giao dịch này là gì?
Nói xin chào với những ngụy biện của máy tính phân tán . Chúng là thứ khiến mọi thứ trở nên phức tạp và như thường lệ, không có viên đạn bạc nào để đối phó với chúng.
Trước khi bắt đầu hành trình tìm kiếm Lost Ark, chúng tôi phải xem xét yêu cầu tổ chức trước. Thông thường, giải pháp là cách tổ chức đối mặt với những vấn đề này trong thế giới thực .
Mọi người (bộ phận) làm gì khi dữ liệu nhất định bị thiếu hoặc không đầy đủ?
Chúng ta sẽ nhận ra rằng các phòng ban khác nhau có các giải pháp khác nhau, những người, hoàn toàn, bao gồm giải pháp được thực hiện.
Dù sao, ở đây một số thực tiễn có thể giúp chúng tôi ra chiến lược để làm theo.
Thay vì đảm bảo rằng hệ thống luôn ở trạng thái nhất quán, thay vào đó chúng ta có thể chấp nhận rằng hệ thống sẽ có được nó vào một lúc nào đó trong tương lai. Cách tiếp cận này đặc biệt hữu ích cho các hoạt động kinh doanh lâu dài.
Cách để hệ thống đạt được sự thống nhất khác nhau tùy theo hệ thống. Nó có thể liên quan từ các quy trình tự động đến một số loại can thiệp của con người. Chẳng hạn, việc thử lại điển hình sau đó hoặc liên hệ với Dịch vụ khách hàng .
Hủy bỏ tất cả các hoạt động
Đặt hệ thống trở lại trạng thái nhất quán thông qua các giao dịch bù . Tuy nhiên, chúng ta phải tính đến việc, các giao dịch này cũng có thể thất bại, điều gì có thể dẫn chúng ta đến một điểm mà sự không nhất quán thậm chí còn khó giải quyết hơn. Và, một lần nữa, chúng tôi không thể hoàn tác một email đã gửi.
Đối với số lượng giao dịch thấp, cách tiếp cận này là khả thi, vì số lượng giao dịch bù cũng quá thấp. Nếu có một số giao dịch kinh doanh liên quan đến IPC, việc xử lý một giao dịch bù cho mỗi giao dịch sẽ là một thách thức.
Nếu chúng ta thực hiện các giao dịch bù , chúng ta sẽ thấy mẫu thiết kế bộ ngắt mạch rất hữu ích - và tôi bắt buộc phải nói -
Giao dịch phân tán
Ý tưởng là mở rộng nhiều giao dịch trong một giao dịch, thông qua quy trình quản lý tổng thể được gọi là Trình quản lý giao dịch . Một thuật toán phổ biến để xử lý các giao dịch phân tán là Cam kết hai pha .
Mối quan tâm chính của các giao dịch phân tán là chúng dựa vào việc khóa tài nguyên trong suốt vòng đời của nó và như chúng ta biết, mọi thứ cũng có thể sai đối với Trình quản lý giao dịch .
Nếu Người quản lý giao dịch bị xâm phạm, chúng ta có thể kết thúc với một số khóa tất cả các bối cảnh bị ràng buộc khác nhau, dẫn đến các hành vi không mong muốn do việc gửi tin nhắn. 2
Hoạt động phân hủy. Tại sao?
Nếu bạn đang phân tách một hệ thống hiện có và tìm thấy một tập hợp các khái niệm thực sự muốn nằm trong một ranh giới giao dịch duy nhất, có lẽ hãy để chúng tồn tại đến cuối cùng.
Sam Newman
Để phù hợp với các lập luận trên, Sam -in trong cuốn sách Building microservice của mình - nói rằng, nếu chúng ta thực sự, thực sự không thể đủ khả năng thống nhất cuối cùng, chúng ta nên tránh chia tách hoạt động ngay bây giờ.
Nếu chúng tôi không đủ khả năng chia một số hoạt động nhất định thành hai hoặc nhiều giao dịch, có thể nói rằng - có thể - các giao dịch này thuộc cùng một bối cảnh bị ràng buộc, hoặc - ít nhất là - trong bối cảnh xuyên suốt vẫn được mô hình hóa.
Ví dụ: trong trường hợp của chúng tôi, chúng tôi nhận ra rằng các giao dịch # 1 và # 2 liên quan chặt chẽ với nhau và có lẽ cả hai có thể thuộc cùng một Tài khoản bối cảnh , Người dùng , Đăng ký , bất cứ điều gì ...
Xem xét đặt cả hai hoạt động trong ranh giới của cùng một giao dịch. Nó sẽ làm cho toàn bộ hoạt động dễ dàng hơn để xử lý. Ngoài ra, mức độ quan trọng của từng giao dịch. Có lẽ, nếu giao dịch số 2 thất bại, nó sẽ không thỏa hiệp toàn bộ hoạt động. Trong trường hợp nghi ngờ yêu cầu tổ chức .
1: Không phải kiểu dàn nhạc mà bạn nghĩ. Tôi không nói về việc trồng cây của ESB. Tôi đang nói về việc làm cho các dịch vụ phản ứng với sự kiện thích hợp.
2: Bạn có thể tìm thấy ý kiến thú vị của Sam Newman về các giao dịch phân tán.
3: Hãy xem câu trả lời của David Parker về chủ đề này.
