ActiveMQ Failover Transport
activemq
1
Java
164
spring boot
76
White

Tất Huân viết ngày 14/03/2020

ActiveMQ Failover Transport

Trong mô hình Asynchronous Processing, Message queue đóng vai trò vô cùng quan trọng trong việc trung chuyển message tạo lên mô hình xử lý bất đồng bộ các request từ phía Client. Giả sử chúng ta đang xây dựng một hệ thống ghi nhận clicks để tính tiền cho các chiến dịch quảng cáo. Với mô hình này, khi có một request về thông tin Click, service sẽ không xử lý luôn mà đẩy thông tin về Click đó vào Message Queue và responds lại ngay lập tức cho Client rằng nó đã tiếp nhận. Mô hình này giúp cho Client không cần đợi cho tới khi service xử lý xong cả quá trình mới nhận được response.

Tuy nhiên, mô hình này sẽ gặp vấn đề trong trường hợp Message Queue server down hoặc network giữa service và Message Queue gặp sự cố. Tất nhiên chúng ta có thể xử lý exception, lưu tạm Message vào file hoặc In Memory Queue sau đó gửi lại tới Queue Server khi xử lý được vấn đề. Tuy nhiên ActiveMQ cung cấp cách đơn giản hơn giúp chúng ta xử lý vấn đề này mà không cần thêm logic code thông qua URI configurations--- The Failover Transport.

Trong trường hợp chúng ta chỉ có một Queue Server

Khi chỉ có một queue server, không có cách nào khác ngoài việc chúng ta phải retry --- thử kết nối lại sau một khoảng thời gian. Một URI thông thường sẽ có dạng tcp://remotehost:61616để cấu hình retry với Active MQ, chúng ta chỉ cần chỉnh sửa URI với cấu trúc như sau:

failover:(tcp://remotehost:61616)?initialReconnectDelay=2&other_options

Các option được truyền vào dưới dạng query parameter, chúng ta có một số options thường sử dụng như sau:

  • initialReconnectDelay: Khoảng thời gian delay (ms) sau lần đầu tiên service thử kết nối lại tới Queue Server.
  • reconnectDelayExponent: Số nhân trong phép toán tăng thời gian delay thử lại theo cấp số nhân. Giá trị mặc định là 2
  • maxReconnectDelay: Thời gian delay tối đa (ms) giữa các lần thử kết nối lại với Queue Server sau lần thứ 2. Giá trị mặc định là 30000ms
  • maxReconnectAttempts: Số lần tối đa thử kết nối lại trước khi throw exception. -1: retry forever, 0: disable retry (Chỉ thử kết nối lại 1 lần duy nhất). Từ ActiveMQ 5.6 trở đi, giá trị mặc định là -1 (retry forever)
  • useExponentialBackOff: Giá trị true/false tương ứng với việc enable/disable tăng thời gian delay theo cấp số nhân. Giá trị mặc định là true
  • startupMaxReconnectAttempts: Số lần tối đa thử kết nối lại trong lần đầu kết nối tới Queue Server. Một khi đã kết nối thành công, nếu mất kết nối, giá trị maxReconnectAttempts sẽ được sử dụng. Giá trị mặc định là -1 (retry forever)
  • warnAfterReconnectAttempts: Số lần thử lại tối đa trước khi log warning về việc reconnect này. Giá trị mặc định là 10

Tuy nhiên nhược điểm của mô hình này là client phải đợi cho tới khi việc retry thành công --- đôi khi là timeout.

Trong trường hợp chúng ta có nhiều queue server

Trong trường hợp có nhiều queue server, chúng ta sẽ có 2 kịch bản chính:

  • Random queue server: với option randomize=true. Option này cũng có ý nghĩa cân bằng tải cho các queue server với mô hình bên dưới.
  • Chỉ định một queue server làm Primary, chỉ connect tới các queue còn lại khi queue Primary không thể conenct được: với option ramdomize=false. Để service luôn cố gắng re-connect lại primary queue, chúng ta cần sử dụng thêm option priorityBackup=true

Ngoài ra, các options khác vẫn sử dụng tương tự các options đề cập tới ở trường hợp phía trên.

Best pratices

Nhằm giảm thiểu tối đa rủi ro về vấn đề network, tốt nhất chúng ta nên có primary queue nên nằm cùng server với service và một secondary queue. Để có mô hình bên dưới, chúng ta sẽ sử dụng một số option như sau:

  • randomize=false. Để service luôn thử kết nối tới primary queue trước, chỉ khi không kết nối được thì mới chuyển sang secondary
  • priorityBackup=true. Service luôn thử kết nối lại primary queue

Khi đó, service sẽ luôn ưu tiên kết nối tới primary queue, trong trường hợp queue này down nó sẽ chuyển qua secondary. Ở lần tiếp theo, service vẫn sẽ lặp lại việc thử kết nối tới primary queue trước. Ở Secondary queue, chúng ta nên cắm monitor và có alert ngay khi queue này có message để kiểm tra vấn đề ở Primary queue.

--- Tất Huân from Pushtimize ---

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

Tất Huân

10 bài viết.
2 người follow
Kipalog
{{userFollowed ? 'Following' : 'Follow'}}
Cùng một tác giả
White
7 0
Sử dụng Jacksondatabind mapping Object Json và ứng dụng load file config 1. Mapping Object Json Jacksondatabind Maven: com.fasterxml.jackson.c...
Tất Huân viết hơn 2 năm trước
7 0
White
5 2
Một số hàm giúp mapping data đơn giản với Groovy Ví dụ với list data như sau: def student1 = name: "Huan", age: 22, gender: "male"] def student...
Tất Huân viết hơn 2 năm trước
5 2
White
5 0
Trước tiên mình muốn làm rõ khái niệm Vertical và Horizontal scaling: (Ảnh) Nguồn ảnh: Internet Ví dụ liên tưởng: ================= Giả sử bạn...
Tất Huân viết 1 năm trước
5 0
Bài viết liên quan
White
0 0
Trong bài viết này, một số hình ảnh hoặc nọi dung có thể bị thiếu do quá trình chế bản. Vui lòng xem nội dung ở blog gốc sau: (Link) (Link), chúng...
programmerit viết 5 năm trước
0 0
White
4 0
I used Spring boot, Hibernate few times back then at University, I'v started using it again recently. In this (Link), I want to check how Spring J...
Rey viết hơn 1 năm trước
4 0
{{like_count}}

kipalog

{{ comment_count }}

bình luận

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


White
{{userFollowed ? 'Following' : 'Follow'}}
10 bài viết.
2 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á!