Hoạt động nguyên tử trên một số hệ thống bên ngoài không giao dịch

Question

Giả sử bạn có một ứng dụng kết nối với 3 hệ thống bên ngoài khác nhau. Bạn cần phải cập nhật một cái gì đó trong tất cả 3. Trong trường hợp thất bại, bạn cần phải quay trở lại các hoạt động. Đây không phải là một điều khó khăn để thực hiện, nhưng nói rằng hoạt động 3 thất bại, và khi quay trở lại, rollback cho hoạt động 1 không thành công! Bây giờ hệ thống bên ngoài đầu tiên đang ở trạng thái không hợp lệ ...

Tôi đang nghĩ giải pháp có thể là tắt ứng dụng và buộc khắc phục thủ công hệ thống bên ngoài, nhưng sau đó lại ... Có thể đã có sử dụng thông tin này (và có lẽ đó là lý do tại sao nó không thành công), hoặc chúng tôi có thể không có đủ quyền truy cập. Hoặc nó thậm chí có thể không phải là một cách hay để khôi phục lại hành động!

Có một số cách hay để xử lý các trường hợp như vậy không?

EDIT: Một số chi tiết ứng dụng ..

Đó là ứng dụng web đa người dùng. Hầu hết các công việc được thực hiện với các công việc theo lịch trình (thông qua Quartz.Net), vì vậy hầu hết các hoạt động được chạy trong chủ đề riêng của nó. Một số hành động của người dùng sẽ kích hoạt các công việc cập nhật một số hệ thống. Các hệ thống bên ngoài có phần không ổn định.

Tôi đã nghĩ đến việc thay đổi các ứng dụng để sử dụng Bộ chỉ huy và đơn vị của mô hình làm việc

Answer 1

Cam kết hai pha (2PC) có thể phù hợp tại đây.

Giai đoạn đầu tiên là nhận được nhiều cơ sở dữ liệu khác nhau để đồng ý rằng họ sẵn sàng tiếp tục với cam kết. Trong ví dụ của bạn, cơ sở dữ liệu 1 sẽ không tiến hành viết cho đến khi nó chắc chắn rằng cả ba cơ sở dữ liệu đã báo cáo rằng giao dịch sẽ có thể thực hiện được.

Điều này so sánh với quy trình mà bạn mô tả đó là cách tiếp cận "lạc quan" - Cơ sở dữ liệu 1 sẽ cho rằng giao dịch sẽ được thực hiện cho đến khi nó biết cách khác và buộc phải quay lại.

Answer 2

Tùy thuộc vào kích thước của ứng dụng (dùng duy nhất so với doanh nghiệp), tắt ứng dụng có thể là một ý tưởng tồi.

Trước hết, tôi khuyên bạn nên lưu trạng thái ban đầu của thông tin đang được thay đổi trong 3 ứng dụng bên ngoài để lưu trữ cục bộ vào ứng dụng của riêng bạn. Điều đó có nghĩa là bạn ít nhất cũng có thể xác định trạng thái rollback được cho là ứng dụng của bạn bị lỗi/rollback fail/etc. Sau khi giao dịch thành công, bạn có thể xóa dữ liệu này.

Việc cần làm khi một trong các thao tác không phụ thuộc vào chức năng của 3 hệ thống bên ngoài. Giả sử rằng một trong những hệ thống này chứa dữ liệu của nhân viên. Tắt ứng dụng đơn giản chỉ vì địa chỉ của một nhân viên là sai do giao dịch thất bại là quá mức cần thiết. Tốt hơn hết là chỉ cần kiểm tra nhật ký giao dịch không thành công (ví dụ: bộ nhớ cục bộ mà bạn đã lưu trạng thái ban đầu của 3 ứng dụng bên ngoài) bất cứ khi nào dữ liệu của nhân viên được truy cập. Nếu dữ liệu nhân viên đó được gắn cờ là không hợp lệ, hãy ném một lỗi cho biết rằng bản ghi ở trạng thái không hợp lệ và không thể truy xuất được.

Tuy nhiên, nếu toàn bộ hệ thống bên ngoài sẽ bị ném vào tình trạng lộn xộn bởi giao dịch không thành công, thì có - bạn không thể làm gì ở đây nhưng tắt ứng dụng của mình cho đến khi sự cố được khắc phục.

Answer 3

Bạn có muốn giải thích thêm về cách khôi phục hoạt động 1 có thể không thành công không?

Trạng thái mà nó đang nhắm đến là trạng thái đã có trước đây, vì vậy nó phải phù hợp về mặt logic.Có thể có các vấn đề thoáng qua như lỗi mạng, nhưng có thể là cách tốt nhất để giải quyết vấn đề đó là thử lại cho đến khi vấn đề biến mất.

Nếu vấn đề là các giao dịch tiếp theo đã bị khóa hoặc thay đổi dữ liệu trong thời gian chờ đợi, thì bạn có vấn đề lớn hơn nhiều - giao dịch của bạn không nguyên tử và việc chuyển chúng trở lại có thể khiến đầu ra của các giao dịch khác không hợp lệ.

Answer 4

Câu trả lời của câu hỏi bổ sung là một câu trả lời hay nhưng bị giới hạn bởi vì rất khó để thực sự là đáng tin cậy thực hiện 2PC. Điều này đã được biết đến trong cộng đồng máy tính phân tán trong một thời gian dài, mặc dù rất nhiều người cố hết sức để bỏ qua nó.

Nếu bạn quan tâm đến việc tìm hiểu kỹ hơn về khu vực này, thì Paxos consensus algorithm là một nơi tốt để bắt đầu. Và lưu ý rằng đây là một vấn đề khó khăn đáng ngạc nhiên, chính xác là do cả hai vấn đề mà bạn ám chỉ và thực tế là không thể xây dựng một hệ thống nhắn tin thực sự đáng tin cậy có thể truyền tải thông điệp trong một khoảng thời gian giới hạn. (Để hiểu tại sao đó là sự thật, hãy xem xét rằng someone with a backhoe có thể xóa sạch tất cả các liên kết mạng giữa các bên giao tiếp khác nhau…)

Tôi nghi ngờ bản sửa lỗi thực là thiết kế kiến ​​trúc của toàn bộ hệ thống và cách bạn triển khai các thay đổi trên đó rằng mất liên lạc trong một khu vực không phải là thảm họa. Điều này có thể hoặc có thể không dễ dàng, tùy thuộc vào chi tiết chính xác.