Hiện nay, trong lĩnh vực phần mềm, việc phát triển các ứng dụng phức tạp và được phân tán đã trở thành một xu hướng thịnh hành. Điều này tạo ra những thách thức không nhỏ trong việc điều phối giao tiếp và chia sẻ dữ liệu giữa các bộ phận của hệ thống.
Để giải quyết thách thức trên, người ta đã sáng tạo ra nhiều công nghệ, trong đó có message broker. Bài viết này sẽ giúp bạn có cái nhìn tổng quan về message broker và cách ứng dụng nó trong thực tế.
1. Message broker là gì?
Message broker là một ứng dụng phần mềm đóng vai trò là trung gian trong việc truyền đạt thông điệp giữa các ứng dụng, hệ thống, hoặc thành phần. Nó cho phép các ứng dụng gửi và nhận thông điệp mà không cần biết về sự tồn tại lẫn nhau, từ đó giảm thiểu sự phụ thuộc và tăng cường khả năng mở rộng và linh hoạt của hệ thống.
2. Các loại mô hình Message broker
Có nhiều loại mô hình Message Broker, mỗi loại phục vụ cho các mục đích giao tiếp khác nhau.
Dưới đây là 3 mô hình Message broker phổ biến:
Mô hình Point-to-Point (P2P)
Mô hình Publish/Subscribe (Pub/Sub)
Mô hình Hybrid giữa Pub/Sub và P2P
2.1. Mô hình Point-to-Point (P2P)
Trong mô hình điểm-điểm (point-to-point), tin nhắn được gửi từ người gửi tin nhắn đến chỉ một người nhận ngay cả khi nhiều người nhận tin nhắn đang lắng nghe trong cùng một hàng đợi tin nhắn. Trong mô hình điểm-điểm, các thuật ngữ message sender và message receiver thường được áp dụng thay vì message publisher và message consumer.
Có hai loại tin nhắn điểm-điểm, tin nhắn fire-and-forget (một chiều) và tin nhắn request/reply (yêu cầu-phản hồi). Sự khác biệt giữa fire-and-forget và request/reply là cách người gửi tin nhắn quan tâm đến trạng thái của tin nhắn đang gửi.
Fire-and-forget
Trong fire-and-forget, người gửi tin nhắn không chờ đợi bất kỳ phản hồi nào từ hàng đợi tin nhắn. Nó không quan tâm hàng đợi tin nhắn có nhận được tin nhắn hay không. Trong mô hình này, Originator and the Recipient sẽ không có tương tác nào cả.
The request/reply messaging model
Khác với fire-and-forget, trong mô hình nhắn tin request/reply, người gửi tin nhắn gửi tin nhắn trên một hàng đợi và sau đó nó chờ phản hồi từ người nhận. Với mô hình này, Send quan tâm đến trạng thái tin nhắn đã nhận được hay chưa.
2.2. Mô hình Publish/Subscribe (Pub/Sub)
Publish/Subscribe Messaging hay thường gọi là pub/sub messaging là một dạng tin nhắn không đồng bộ. Trong mô hình này, message producers được gọi là publisher và message consumers được gọi là subscriber. Publisher tạo tin nhắn cho một topic, sau đó tất cả những subscribed topic đó sẽ nhận được tin nhắn gửi đi và sử dụng chúng. Sự khác biệt giữa mô hình tin nhắn point-to-point và publish/subscribe là có bao nhiêu người nhận cho một tin nhắn. Một sự khác biệt nữa là trong mô hình point-to-point, người gửi tin nhắn phải biết người nhận nhưng trong publish/subscribe, publisher không cần biết tin nhắn sẽ được sử dụng ở đâu. Đặc điểm này cung cấp khả năng tách rời cao cho ứng dụng khi áp dụng mô hình tin nhắn publish/subscribe.
Pub/Sub được dùng trong trường hợp mất tin nhắn là không đáng kể. Ví dụ, máy cảm biến nhiệt có thể gửi rất nhiều chỉ số nhiệt tới topic mỗi giây, việc topic bỏ sót một vài chỉ số nhiệt sẽ ảnh hưởng không đáng kể tới hệ thống.
2.3. Mô hình Hybrid giữa Pub/Sub và P2P
Một trang web bán hàng format order thành message và gửi vào một queue. Consumer chính của các message kia là hệ thống thực hiện đơn hàng. Bên cạnh đó, hệ thống kiểm toán cần có bản sao của các order để theo dõi sau này. Cả hai hệ thống đều không thể bỏ lỡ bất kỳ order nào, ngay cả khi hệ thống gặp lỗi. Trang web hoạt động bình thường mà không cần biết về các hệ thống khác hoạt động như nào.
Đây là ví dụ điển hình của mô hình hybrid giữa Pub/Sub và P2P. Hybrid tận dụng ưu điểm và khắc phục nhược điểm của cả 2 mô hình. Ví dụ, khi consumer ngắt kết nối, message sẽ được giữ trong queue và sẽ được gửi khi consumer kết nối lại.
Vì những ưu điểm trên nên mô hình Hybrid được tận dụng trong các công nghệ nổi tiếng như ActiveMQ và Kafka.
3. Ưu điểm của message broker
Giảm sự phụ thuộc: Message broker giúp tách biệt giữa người gửi và người nhận, giảm sự phụ thuộc trực tiếp giữa các thành phần hệ thống.
Đảm bảo tính tin cậy: Nó có thể lưu trữ thông điệp tạm thời nếu người nhận không sẵn sàng, đảm bảo thông điệp không bị mất.
Tăng khả năng mở rộng: Hệ thống có thể dễ dàng mở rộng bằng cách thêm các thành phần mới mà không ảnh hưởng đến các thành phần hiện tại.
Đơn giản hóa giao tiếp: Cung cấp một giao diện giao tiếp đơn giản, giúp dễ dàng tích hợp các ứng dụng khác nhau.
4. Nhược điểm của message broker
Tăng độ trễ: Do có một trung gian, thời gian để thông điệp được chuyển từ nguồn đến đích có thể lâu hơn so với giao tiếp trực tiếp. Điều này có thể không phù hợp với các ứng dụng cần xử lý thời gian thực hoặc yêu cầu độ trễ thấp.
Tăng độ phức tạp của hệ thống: Việc triển khai và quản lý một Message Broker có thể làm tăng độ phức tạp của hệ thống, đòi hỏi kỹ thuật và kiến thức chuyên môn cao để đảm bảo hệ thống hoạt động ổn định và hiệu quả.
Chi phí cơ sở hạ tầng: Việc duy trì Message Broker có thể yêu cầu thêm cơ sở hạ tầng và tài nguyên, từ đó tăng chi phí cho dự án, đặc biệt là đối với các dự án lớn hoặc các hệ thống phân tán rộng rãi.
Rủi ro nút thắc cổ chai: Trong một số trường hợp, Message Broker có thể trở thành điểm nghẽn của hệ thống nếu không được thiết kế hoặc cấu hình đúng cách, đặc biệt khi xử lý lượng lớn thông điệp hoặc trong các tình huống giao tiếp cần độ tin cậy cao.
5. Sử dụng Message broker trong thực tế
Một số công nghệ phổ biến sử dụng message broker bao gồm:
RabbitMQ: Một message broker mã nguồn mở rất phổ biến, hỗ trợ nhiều giao thức giao tiếp.
Apache Kafka: Được thiết kế cho việc xử lý dữ liệu dòng với khả năng mở rộng và độ tin cậy cao.
AWS SNS/SQS: Dịch vụ message của Amazon Web Services, hỗ trợ việc giao tiếp linh hoạt trong hệ thống đám mây.