AnhDH
Published on
8 mins read-... views

Message Broker

Curiosity is the wick in the candle of learning.” – William Arthur Ward
banner

Hi các bạn 👋. Mình là Hùng Anh.

Trong thời đại mà các ứng dụng phải giao tiếp liên tục và xử lý lượng dữ liệu khổng lồ theo thời gian thực, làm sao để đảm bảo các hệ thống vẫn vận hành mượt mà? Đã bao giờ bạn tự hỏi điều gì đang diễn ra đằng sau những dịch vụ như hệ thống thanh toán, mạng xã hội, hay ứng dụng giao hàng mà chúng ta sử dụng hàng ngày?

Một trong những câu trả lời chính là Message Broker - công cụ ‘kết nối vô hình’ giúp đảm bảo mọi thông tin được truyền tải một cách an toàn, nhanh chóng và đáng tin cậy giữa các hệ thống.

Hôm nay, hãy cùng mình khám phá Message Broker là gì, lý do nó quan trọng, cũng như các ưu điểm, nhược điểm và cách ứng dụng hiệu quả của nó trong phát triển hệ thống phân tán nhé.

Bắt đầu thôi.

Table of Contents

1. Mô hình Request - Response

Đầu tiên, ta hãy cùng xem xét các tính chất của mô hình giao tiếp truyền thống request - response.

Ở đây ta xét ví dụ có một Service A gửi request sang Service B, sau đó đợi Service B xử lý xong và trả response về cho Service A. Kiểu giao tiếp này nó có tính chất đồng bộ (Synchronous). Khi service A phải đợi response của service B để thực hiện các công việc tiếp theo, thì lúc ấy ta gọi Service A phụ thuộc (Coupling) service B.

request-response-model

2. Message broker là gì?

Message Broker mang đến một cách thức giao tiếp mới, khắc phục được hạn chế của mô hình request - response. Nó là một phần mềm trung gian giúp nhận các message từ các service gửi (producer) và chuyển chúng đến các service đích (consumer) phù hợp. Với Message Broker, các service không cần phải giao tiếp trực tiếp với nhau, mà sẽ truyền và nhận message thông qua broker, từ đó giảm thiểu sự phụ thuộc lẫn nhau giữa các service.

Message broker

Ở đây, ta gọi service A là Producer vì nó đóng vài trò là service gửi message tới Message Brocker. Service B, C, D gọi là Cosummer vì nó đóng vai trò là service nhận hoặc lấy các message từ Message Brocker.

Tiếp theo, chúng ta sẽ cùng đi tìm hiểu một số những ưu điểm của Message Brocker thông qua phân tích một số các bài toán cụ thể nhé.

3. Ưu điểm của Message Broker

3.1. Giao tiếp bất đồng bộ (Asynchronous Communication)

Ta xét bài toán sau: Service A cần gửi một message tới service B, C, D.

Với mô hình request - response truyền thống, service A phải gửi 3 gói tin tới các service B, C, D.

request-response-model

Để thực hiện được điều này, chúng ta có hai cách:

  • Gửi đồng bộ.
  • Gửi không đồng bộ.

Với cách gửi đồng bộ thì luồng của chúng ta sẽ trông như sau:

request-response-sync

Service A gửi message tới service B, sau đó thì đợi service B phản hổi. Sau khi nhận được response từ service B, service A mới tiếp tục gửi message sang service C, ...

Từ cách làm này, ta có thể nhìn thấy một vài những ưu, nhược điểm:

  • Ưu điểm: Dễ triển khai, thứ tự nhận phản hồi từ các service được đảm bảo.
  • Nhược điểm: Service A bị “block” chờ phản hồi từ các service khác, không tận dụng tối đa tài nguyên của Service A.

Với cách gửi không đồng bộ thì luồng của chúng ta sẽ trông như sau:

request-response-sync

Service A gửi đồng thời gửi các message tới service B, C và không cần đợi response từ service B, C. Sau khi hai service B và C xử lý xong thì sẽ response về cho service A.

Ta sẽ cùng xem xét các ưu, nhược điểm của phương pháp này

  • Ưu điểm: Service A không phải chờ phản hồi từ các service khác, tận dụng tối đa tài nguyên của Service A.
  • Nhược điểm: Thứ tự phản hồi từ các service nhận có thể không đúng thứ tự gửi (response của Service B có thể đến sau Service C).

Với Message Broker, service A chỉ cần gửi (publish) message 1 lần duy nhất tới Broker, sau đó Broker sẽ đẩy (push) các message này tới các service B, C, D tương ứng, hoặc là service B, C, D sẽ tự lấy (pull) message về khi cần. Nhờ đó, các service A, B, C, D hoàn toàn giao tiếp không đồng bộ với nhau.

Message broker

3.2. Giảm sự phụ phuộc (Decoupling)

Ta vẫn xét bài toán trên: Service A cần gửi một message tới service B, C, D.

Với mô hình request - response, service A cần phải biết địa chỉ chính xác của các Service B, C, D để gửi message. Nếu quá trình gửi message bị lỗi thì có thể sẽ làm ảnh hưởng đến các logic khác có trong Serice A.

request-response-coupling

Với Message Broker, lúc này Service A (đóng vai trò là producer) chỉ cần biết địa chỉ của Message Broker và các service B, C, D (đóng vai trò là Consumer) cũng chỉ cần biết địa chỉ của Message Broker.

message-broker-decoupling

Producer và Comsumer không cần biết đến sự tồn tại của nhau, và nếu như một consumer bị chết thì cũng không làm ảnh hưởng đến producer và các consumer khác. Hay nói cách khác Service A, B, C, D không phụ thuộc vào nhau.

3.3. Dễ dàng mở rộng (Scalability)

Ta vẫn xét bài toán trên trong trường hợp giả sử Service A cần gửi message tới thêm một service E nữa để phục vụ cho một số tính năng mới.

Với mô hình request - response, lúc này service A sẽ cần phải tạo thêm một kết nối mới tới service E. Điều này có thể làm gián đoạn dịch vụ (downtime) Service A.

request-response-scalability

Với Message Broker, ta có thể thêm dễ dang một Consumer E để nhận các message từ Producer A mà không làm ảnh hưởng đến các service khác. Hay nói cách khác việc mở rộng thêm bớt các service trong hệ thống trở lên vô cùng dễ dàng.

message-broker-scalability

3.4. Ổn định hệ thống (Reliability)

Ta xét bài toán: Giả sử ta cần thu thập các event hành vi của người dùng tương tác với các thiết bị IOT và lưu trữ ở trong database. Nhưng lượng event của người dùng rất nhiều, dẫn đến traffic đổ vào database rất lớn, điều này có thể làm chết DB.

message-broker-reliability

Giải pháp: Ở đây ta có thể dùng thêm một Message Broker có tác dụng như là một Message Queue để thu nhỏ lượng traffic đổ xuống DB. Message Queue giống như là một hàng đợi của các request, các request sẽ được lưu trữ ở trong hàng đợi và dần dần được lấy ra để xử lý lưu xuống DB. Nhờ vậy mà hệ thống sẽ trở lên ổn định và an toàn hơn.

message-broker-reliability

4. Tổng kết

Message Broker là một phần mềm trung gian giúp nhận các message từ các service gửi (producer) và chuyển chúng đến các service đích (consumer) phù hợp. Message Broker có nhiều ưu điểm mạnh, nhưng bên cạnh đó nó cũng tồn tại một vài nhược điểm mà chúng ta cần phải lưu ý:

  • Ưu điểm:
    • Giao tiếp bất đồng bộ (Asynchronous Communication)
    • Giảm sự phụ phuộc (Decoupling)
    • Dễ dàng mở rộng (Scalability)
    • Ổn định hệ thống (Reliability)
    • ...
  • Nhược điểm
    • Phức tạp
    • Chi phí lớn
    • Tăng độ trễ do message phải đi qua thêm một thành phần trung gian khác

Cảm ơn bạn đã đồng hành cùng mình đến cuối bài viết này! Hy vọng qua bài chia sẻ, bạn có thể hiểu hơn về Message Broker và những ưu nhược điểm của nó để có thể áp dụng vào trong các dự án thực tế. Nếu bạn có bất kỳ câu hỏi, ý kiến, hay những điều muốn chia sẻ, hãy để lại bình luận bên dưới nhé.

Chúc bạn có những trải nghiệm học tập thú vị và hẹn gặp bạn ở những bài viết sắp tới, nơi chúng ta sẽ tiếp tục khám phá thêm nhiều chủ đề thú vị khác.

Happy reading! 🍻

Tham khảo

  1. Message Broker - Xương Sống Của Hệ Thống Lớn | Ronin Engineer
Authors
  • Previous Article

    Published on
    Sự khác biệt giữa count(*) và count(1) và cái nào hiệu quả hơn?
    Khi chúng ta đếm các bản ghi trong bảng dữ liệu, chúng ta đã quen với việc sử dụng hàm count để đếm, nhưng có nhiều loại tham số có thể được truyền trong hàm count, chẳng hạn như count(1), count(*), count(field), ... Vậy hàm count nào sẽ đem lại hiệu suất tốt nhất?
  • Next Article

    Published on
    CronJob & Cron Expressions
    CronJob là một công cụ quan trọng giúp lập trình viên tự động hóa các tác vụ theo lịch trình định kỳ. Tuy nhiên, để thiết lập CronJob một cách chính xác, bạn cần nắm vững Cron Expression – biểu thức giúp xác định lịch trình cho các công việc tự động. Bài viết này sẽ giới thiệu về CronJob, cách xây dựng Cron Expression, và các công cụ hữu ích để tạo biểu thức cron một cách dễ dàng.
Subscribe to the newsletter