Thực hành tốt nhất để xử lý giao tiếp không đồng bộ?

Gần đây đã hoàn thành một dự án để xử lý xử lý thẻ tín dụng. Một trong những khó khăn tôi gặp phải là xử lý sự chậm trễ / thất bại có thể của tin nhắn thông báo. Ví dụ phức tạp nhất là:

• một hệ thống bên ngoài gửi yêu cầu thanh toán
• hệ thống của tôi biến yêu cầu đó thành yêu cầu đến cổng thanh toán
• gửi người dùng đến cổng
• chờ người dùng thực hiện thanh toán
• người dùng quay trở lại hệ thống của tôi nhưng bị giữ cho đến khi hệ thống nhận được thông báo thành công / thất bại
• Gửi người dùng trở lại hệ thống bên ngoài tùy thuộc vào thất bại

Khó khăn hơn nữa là khi không gửi được thông báo, cổng cố gắng gửi thông báo cứ sau 15 phút trong một số giờ.

Tôi đã giải quyết nó bằng cách sử dụng bản ghi cơ sở dữ liệu về các giao dịch đang chờ xử lý và sau đó phát hiện thành công và thất bại từ việc trả lại cộng với một trình lắng nghe chậm trễ theo thời gian để xử lý thông báo và giao dịch ...

Hợp lý khó khăn!

Nhưng điều này hẳn đã được giải quyết một thời gian trước đây vậy thực hành tốt nhất là gì?

Tôi có thể thấy tương lai của mình sẽ viết ra cách xử lý giữa tất cả các hệ thống này và quản lý sự chậm trễ thời gian và các lỗi mạng có thể xảy ra vì vậy tôi muốn tuân theo các thực tiễn tốt nhất.

Đề xuất sách / bài viết sẽ là tuyệt vời.

Cảm ơn trước!

Khi xây dựng các hệ thống phân tán, sự khác biệt giữa hệ thống 'đồng bộ' và hệ thống 'không đồng bộ' là: Hệ thống đồng bộ có giới hạn trên về thời gian tính toán và thời gian gửi tin nhắn. Vì vậy: bạn có một hệ thống không đồng bộ trong đó các sự kiện nhất định không có các giới hạn trên đã biết. Làm thế nào để bạn xử lý nó?

1. Nếu các quy trình không đồng bộ này có giới hạn trên có xác suất thì bạn có thể sử dụng thời gian chờ để làm cho hệ thống của bạn hoạt động như một hệ thống đồng bộ một phần . Nếu thời gian phản hồi phân vị thứ 98 của cổng thanh toán là 5 giây thì thời gian chờ 5 giây sẽ khiến 98% yêu cầu của bạn thành công và 2% còn lại sẽ thất bại. Điều này có nghĩa là bây giờ bạn có giới hạn trên đã biết về quá trình này sẽ mất bao lâu để thành công hay thất bại. Đây phát hiện thất bại xác suất là một công cụ quan trọng để biến hệ thống không đồng bộ vào hệ thống đồng bộ.

2. Giữ một bản ghi bền của các sự kiện này để bạn có thể khôi phục trạng thái hệ thống của mình trong trường hợp xảy ra lỗi hệ thống. Nếu trình xử lý cổng thanh toán của bạn đang giữ các sự kiện này trong bộ nhớ không ổn định và nó gặp sự cố thì bạn đã bị lừa.

3. Mỗi giao dịch phức tạp về cơ bản là một chuỗi các biến đổi trạng thái dựa trên việc gửi và nhận tin nhắn (sự kiện) trong hệ thống. Nghe có vẻ như bạn đang mô hình hóa một cách không chính thức bằng cách sử dụng "bản ghi các giao dịch đang chờ xử lý" của mình nhưng tôi khuyên bạn nên đi xa hơn: Đối với mỗi giao dịch bạn cần quản lý, hãy tạo một máy trạng thái chính thức mô tả nó và giữ một bản ghi bền vững về trạng thái hiện tại của nó . Bạn sẽ thấy rằng các máy trạng thái này dễ hiểu, dễ kiểm tra và cung cấp khả năng hiển thị rất cần thiết cho các quy trình này cho cả bạn và người dùng của bạn.

Hệ thống của bạn càng không đồng bộ, bạn càng cần phải chính thức và rõ ràng hơn khi quản lý các biến đổi trạng thái phức tạp này. Hết giờ, ghi nhật ký sự kiện lâu bền và máy trạng thái là cách tốt nhất ở đây. Đây là lý do tại sao Erlang OTP dựa trên phần lớn hành vi ứng dụng của nó trên mô hình máy trạng thái.

Để tham khảo, tôi chưa tìm thấy gì tốt hơn Giới thiệu về Lập trình phân tán an toàn và đáng tin cậy . Nó sẽ cung cấp cho bạn một cơ sở thuật toán mạnh mẽ để hiểu cả hệ thống đồng bộ và không đồng bộ từ các nguyên tắc đầu tiên.