Vấn thứ tự messge trong việc xử lý bất đồng bộ dựa trên message queue
Message Queue
6
Distributed System
7
White

Nghia Minh Le viết ngày 26/09/2016

Kiến trúc dựa trên message và các ưu điểm của nó trong việc mở rộng hệ thống thì nhiều người đã rõ. Nhưng việc xây dựng phần mềm dựa trên kiến trúc message gặp nhiều thách thức trong việc monitor để đảm bảo tính ổn định của quá trình xử lý. Một trong các vấn đề đó là về việc đảm bảo thứ tự của message.

1. Vấn đề đảm bảo thứ tự xử lý của message.

Nhiều người dùng message queue, nhưng không nhiều người để ý tới vấn đề này. Vì hiển nhiên queue thì phải FIFO, nên thứ tự được đảm bảo rồi. Cái gì vào trước thì ra trước. Quả đúng là như vậy. Tất cả các message queue đều đảm bảo điều đó. Nhưng thứ tự mà người thiết kế mong muốn không chỉ đơn giản thứ tự vào ra mà còn là thứ tự của các quá trình xử lý nối tiếp nhau.
Trong môi trường phân tán, sẽ có nhiều ứng dụng cùng xử lý song song trên cùng một message queue. Khi đó message vào trước và ra trước nhưng không chắc chắn là sẽ được xử lý xong trước tiên. Vì ngay khi message đó được dequeue ra thì message kế tiếp cũng có thể được dequeue ra ngay lập tức. Nếu quá trình xử lý của message thứ nhất mà lâu hơn message thứ hai, thì thứ tự xử lý sẽ không như mong muốn của việc đưa message vào.
Xét một ví dụ đơn giản, một đơn hàng khi được cập nhật các trạng thái thì sẽ đồng bộ với các quá trình xử lý khác nhau. Mỗi khi các trạng thái thay đổi thì sẽ gửi các message qua message queue để đồng bộ. Giả sử có hai trạng thái tương ứng xảy ra lần lượt là: xác nhận đơn hàng và hủy đơn hàng. Các trạng thái này chuyển thành các message và gửi lần lượt vào queue. Nhưng nếu tại đầu dequeue, message hủy lại được xử lý xong trước, như vậy message xác nhận xử lý sau thì sẽ gây ra lỗi về luồng nghiệp vụ. Hủy rồi còn xác nhận gì nữa!
Đây là một điều rất đau đầu, nếu không để ý và thiết kế hệ thống ngay từ đầu thì khi gặp vấn đề xảy ra sẽ rất khó để giải quyết và làm cho toàn bộ hệ thống mất ổn định.
Các message queue phổ biến: Rabbit MQ, Gearman Queue, Redis Queue... không đảm bảo được điều này. Nó chỉ đảm bảo thứ tự vào ra của message nhưng không đảm bảo việc tuần tự xử lý trong môi trường phân tán.
Kafka queue, Windows Service Bus là hai loại queue hỗ trợ rất mạnh tính năng này với partition (Kafka) và session (Windows Service Bus). Khi đó một các message của cùng một partition hoặc một session sẽ chỉ đổ về một nơi. Đảm bảo cho việc xử lý được tuần tự. Như ví dụ đơn hàng trên thì các message của cùng một đơn hàng sẽ đổ về cùng một nơi nên không bị sai về mặt logic xử lý.

2. Vấn đề đảm bảo xử lý thứ tự của message khi xảy ra sự cố.

Vấn đề đảm bảo thứ tự của message sẽ phức tạp hơn trong trường hợp xảy ra sự cố với một message. Ví dụ đầu A gửi tới đầu B các message : m1->m2->m3. Khi đó dù được đảm bảo thứ tự như trình bày ở trên rồi, nhưng nếu message thứ nhất bị lỗi trong quá trình xử lý trong khi đã bị loại ra khỏi queue. Như vậy các message m2 và m3 không thể tiếp tục xử lý. Nhưng với m1 thì làm thế nào? Giả sử sau khi khắc phục được sự cố thì làm thế nào để nhét m1 vào cho đúng thứ tự mong muốn.
Có hai nhóm giải pháp cần triển khai cho vấn đề này:

  • Circuit Breaker Pattern: đây là một pattern dùng để ngắt một quá trình xử lý khi hệ thống gặp sự cố, để đảm bảo số lượng message bị lỗi không tăng cao, làm cho việc khắc phục trở nên khó khăn, cũng như có thể làm cho hệ thống bị xụp đổ hàng loạt do ảnh hưởng lẫn nhau. Tư tưởng nó giống cái automat trong mạng điện, khi xảy ra chập điện, thì ngay lập tức automat sẽ ngắt mạch điện, khi nào khắc phúc xong đóng lại thì mạch điện mới thông trở lại. Các bạn có thể search thêm pattern này trên mạng để tìm hiểu chi tiết hơn. Áp dụng nó cho trường hợp message bị lỗi trên, thì ngay khi phát hiện ra sự cố thì ngay lập tức ngắt quá trình nhận message để đảm bảo các message tiếp theo không bị lỗi tiếp.
  • Dead Letter Message: Các message lỗi thì sẽ được đưa vào một queue riêng gọi là dead letter queue. Nếu bạn nào chưa rõ cái này thì có thể tìm lại note trước của mình để đọc thêm. Việc monitor queue này sẽ cho biết các message của một quá trình xử lý nào đó có bị xử lý lỗi hay không. Kết hợp hai giải pháp trên, sau khi khắc phục sự cố, circuit breaker chuyển từ trạng thái ngắt mạch sang trạng thái đóng thì việc đầu tiên là nó sẽ lấy hết các message bị lỗi từ dead letter queue ra để đưa lại vào quá trình xử lý, sau đó mới đưa các message không bị lỗi để xử lý như bình thường. Việc xây dựng dựa trên kiến trúc message đòi hỏi phải monitor rất tốt. Vì các quá trình xử lý là bất đồng bộ. Nên không monitor tốt thì khi gặp sự cố hậu quả sẽ rất tai hại.
Bình luận


White
{{ comment.user.name }}
Bỏ hay Hay
{{comment.like_count}}
Male avatar
{{ comment_error }}
Hủy
   

Hiển thị thử

Chỉnh sửa

White

Nghia Minh Le

10 bài viết.
115 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
30 0
1. Nguyên lý consistency của relational database – SQL Server. SQL Server nói riêng và các database quan hệ nói chung là dạng database có độ nhất...
Nghia Minh Le viết gần 2 năm trước
30 0
White
19 0
Nhân đọc cuốn The Pragmatic Programmer Lập trình viên thực dụng, note lại mấy dòng về tính thực dụng trong thiết kế. Có một câu chuyện vui: có căn...
Nghia Minh Le viết gần 2 năm trước
19 0
White
16 2
Mô hình Event Sourcing là một mô hình thiết kế hệ thống mà theo đó sẽ lưu giữ trạng thái thay đổi của một đối tượng là một chuỗi các thay đổi đã xả...
Nghia Minh Le viết gần 2 năm trước
16 2
Bài viết liên quan
White
5 0
Tranh chấp tài nguyên là vấn đề lớn cần phải giải quyết trong việc xây dựng hệ thống lớn. Việc tranh chấp tài nguyên ảnh hưởng lớn tới hiệu năng và...
Nghia Minh Le viết gần 2 năm trước
5 0
White
10 1
Transaction và Distributed Transaction là các vấn đề phải đối mặt rất nhiều trong xây dựng các hệ thống lớn Enterprise Software. Nó ảnh hưởng rất l...
Nghia Minh Le viết gần 2 năm trước
10 1
{{like_count}}

kipalog

{{ comment_count }}

bình luận

{{liked ? "Đã kipalog" : "Kipalog"}}


White
{{userFollowed ? 'Following' : 'Follow'}}
10 bài viết.
115 người follow

 Đầu mục bài viết

Vẫn còn nữa! x

Kipalog vẫn còn rất nhiều bài viết hay và chủ đề thú vị chờ bạn khám phá!