1. Message Broker là gì?
Message Broker là một thành phần trung gian giúp các ứng dụng hoặc service gửi và nhận message mà không cần giao tiếp trực tiếp với nhau trong mọi trường hợp.
Thay vì service A gọi trực tiếp service B, service A có thể gửi message đến broker. Broker tiếp nhận message và định tuyến nó đến queue, topic hoặc subscriber phù hợp.
Ví dụ, khi khách hàng đặt hàng, hệ thống có thể cần:
- Tạo đơn hàng.
- Trừ tồn kho.
- Xử lý thanh toán.
- Gửi email xác nhận.
- Cập nhật hệ thống phân tích dữ liệu.
Nếu Order Service phải gọi trực tiếp tất cả các service trên, nó sẽ phụ thuộc vào địa chỉ, API, thời gian phản hồi và tình trạng hoạt động của từng service.
2. Vì sao cần Message Broker?
Giảm coupling giữa các service
Giả sử hệ thống có ba service:
- Order Service quản lý đơn hàng.
- Notification Service gửi thông báo.
- Analytics Service ghi nhận dữ liệu phân tích.
Nếu Order Service gọi trực tiếp cả hai service còn lại, nó cần biết cách giao tiếp với từng service và xử lý lỗi riêng cho từng lời gọi.
Order Service không cần biết cụ thể Notification Service đang chạy ở máy nào hoặc có bao nhiêu instance.
Tuy nhiên, các service vẫn phụ thuộc vào định nghĩa sự kiện và ý nghĩa nghiệp vụ của nó. Message broker giúp giảm coupling về giao tiếp và thời điểm thực thi, chứ không loại bỏ mọi sự phụ thuộc.
Tách biệt thời gian hoạt động
Trong giao tiếp đồng bộ, service gọi thường phải chờ service được gọi phản hồi.
Trong giao tiếp bất đồng bộ, producer có thể phát message rồi tiếp tục công việc của mình sau khi hoàn thành bước gửi message theo cơ chế xác nhận được yêu cầu.
Consumer xử lý message sau đó, miễn là broker và cơ chế lưu trữ đáp ứng các điều kiện cần thiết.
Điều này đặc biệt hữu ích khi công việc mất nhiều thời gian hoặc phụ thuộc vào dịch vụ bên ngoài.
Hấp thụ tải tăng đột biến
Broker có thể đóng vai trò bộ đệm giữa tốc độ phát sinh message và tốc độ xử lý của consumer.
Ví dụ, hệ thống nhận 5.000 sự kiện đơn hàng trong một đợt cao điểm, nhưng các worker xử lý thanh toán chỉ có thể tiếp nhận một tốc độ thấp hơn.
Message có thể được xếp hàng để xử lý dần. Tuy nhiên, nếu tốc độ tạo message liên tục lớn hơn năng lực xử lý, backlog vẫn tăng. Broker không tự động giải quyết được giới hạn tài nguyên.
Một sự kiện có thể phục vụ nhiều hệ thống
Một sự kiện order.created có thể được sử dụng bởi nhiều thành phần:
- Notification Service gửi email.
- Analytics Service cập nhật số liệu.
- Loyalty Service cộng điểm.
- Search Service cập nhật dữ liệu tìm kiếm.
Nhờ vậy, có thể thêm consumer mới mà không nhất thiết phải sửa logic gửi sự kiện trong Order Service, miễn là contract và chính sách routing đã phù hợp.
3. Phân biệt Message, Command và Event
Message
Message là đơn vị dữ liệu được gửi từ một thành phần đến một thành phần khác.
Một message có thể mang dữ liệu nghiệp vụ, metadata, ID, thời điểm tạo và phiên bản schema.
Command
Command thể hiện yêu cầu một thành phần thực hiện một hành động.
Ví dụ:
CreateInvoice
SendWelcomeEmail
ReserveInventoryCommand thường hướng đến một consumer có trách nhiệm thực hiện hành động đó.
Command có thể thất bại vì điều kiện nghiệp vụ không thỏa mãn. Ví dụ, ReserveInventory có thể bị từ chối vì không đủ hàng.
Event
Event thể hiện một sự việc đã xảy ra.
Ví dụ:
OrderCreated
PaymentSucceeded
InventoryReservedEvent thường được đặt tên ở thì quá khứ vì nó mô tả sự thật đã xảy ra.
Một event có thể được nhiều consumer quan tâm. Producer phát ra event mà không nhất thiết biết tất cả consumer sẽ làm gì với nó.
4. Queue và Pub/Sub
Hai mô hình messaging phổ biến là queue-based messaging và publish-subscribe.
Queue-based messaging
rong mô hình queue truyền thống, nhiều consumer có thể cùng lấy message từ một queue để chia tải. Thông thường, mỗi message được giao cho một consumer xử lý trong nhóm consumer đó, tùy cơ chế của broker. Mục tiêu chính là phân phối công việc và tăng khả năng xử lý song song.
Publish-subscribe (Pub/Sub)
Trong mô hình Pub/Sub, publisher phát message hoặc event đến một topic, subject hoặc cơ chế phân phối tương ứng. Nhiều subscriber có thể cùng nhận bản sao của message nếu họ đăng ký phù hợp. Mục tiêu chính là cho phép nhiều thành phần phản ứng độc lập với cùng một sự kiện.
5. Các loại Message Broker phổ biến
RabbitMQ
RabbitMQ là message broker phù hợp với các hệ thống cần queue, routing message linh hoạt và cơ chế acknowledgement.
Các khái niệm quan trọng:
- Exchange: nhận message từ producer.
- Queue: lưu message chờ xử lý.
- Binding: quy tắc kết nối exchange với queue.
- Routing key: dữ liệu dùng để định tuyến.
- Consumer acknowledgement: consumer xác nhận việc xử lý.
- Publisher confirms: broker xác nhận việc tiếp nhận message từ publisher.
RabbitMQ phù hợp với:
- Background jobs.
- Giao tiếp bất đồng bộ giữa microservices.
- Routing theo loại sự kiện.
- Hệ thống cần kiểm soát việc giao và xác nhận message.
Apache Kafka
Kafka tập trung vào việc lưu trữ và phân phối event theo mô hình log phân vùng.
Các khái niệm quan trọng:
- Topic: nhóm các event cùng loại.
- Partition: phân chia topic để tăng khả năng mở rộng.
- Offset: vị trí của record trong partition.
- Producer: ghi event vào topic.
- Consumer group: nhóm consumer cùng chia nhau đọc dữ liệu.
- Retention: thời gian hoặc chính sách lưu trữ event.
Một điểm khác biệt quan trọng: trong Kafka, event không mặc định bị xóa ngay sau khi consumer xử lý. Event thường được giữ lại theo chính sách retention; consumer có thể đọc lại dữ liệu trong phạm vi còn được lưu.
Kafka phù hợp với:
- Event streaming.
- Data pipelines.
- Thu thập log và sự kiện ở quy mô lớn.
- Đồng bộ dữ liệu giữa hệ thống.
- Xây dựng nhiều consumer độc lập từ cùng một nguồn event.
6. Message Ordering và xử lý đồng thời
Khi có nhiều consumer, message có thể được xử lý song song. Điều này tăng throughput nhưng cũng làm phát sinh vấn đề thứ tự.
Ví dụ, một đơn hàng phát ra hai event:
OrderCreated
OrderCancelledNếu hai event được xử lý song song, OrderCancelled có thể hoàn tất trước OrderCreated, dù event được phát theo thứ tự ngược lại.
Nếu nghiệp vụ yêu cầu thứ tự, cần thiết kế cơ chế tương ứng:
- Định tuyến các message cùng aggregate hoặc entity đến cùng một partition/queue khi phù hợp.
- Sử dụng sequence number hoặc version để phát hiện event đến sai thứ tự.
- Áp dụng cập nhật có điều kiện trong database.
- Xử lý event đến muộn hoặc bị trùng.
- Giới hạn concurrency trong những trường hợp cần thiết.
Kafka đảm bảo thứ tự trong một partition. Điều này không đồng nghĩa toàn bộ consumer xử lý xong theo cùng thứ tự, nhất là khi ứng dụng thực thi các thao tác bất đồng bộ song song.
7. Kết luận
Message Broker là một thành phần quan trọng trong backend hiện đại, đặc biệt khi hệ thống có nhiều service, xử lý bất đồng bộ hoặc cần phân phối sự kiện đến nhiều consumer. Nhưng broker không tự động làm hệ thống đáng tin cậy. Độ tin cậy phụ thuộc vào cách producer xác nhận publish, cách consumer ACK, chính sách retry, idempotency, quản lý schema, lưu trữ message và khả năng giám sát.
Bài viết khác
Logging – Monitoring – CI/CD
Logging, Monitoring và CI/CD là gì? Vai trò trong phát triển Backend 1. Tổng quan Khi xây dựng một ứng dụng Backend, viết code và chạy được chương trình mới chỉ là bước đầu. Khi ứng dụng được đưa vào sử dụng, lập trình viên còn cần biết ứng dụng đang hoạt động như thế […]
Docker là gì?
Docker là gì? Hướng dẫn sử dụng Docker trong Backend với Go 1. Docker là gì? Docker là nền tảng hỗ trợ đóng gói và chạy ứng dụng trong các môi trường độc lập gọi là container. Thay vì chỉ chia sẻ mã nguồn, lập trình viên có thể mô tả môi trường chạy ứng […]
Logging / Monitoring / CI/CD
1. Tổng quan: Ba thành phần giải quyết ba vấn đề khác nhau Khi một Backend chạy trên production, việc code hoạt động đúng trên máy local chưa đủ. Hệ thống cần có khả năng ghi nhận sự kiện, phát hiện sự cố và triển khai phiên bản mới một cách an toàn. Ba thành […]
Unit & Integration Testing
1. Unit Testing và Integration Testing là gì? Trong quá trình phát triển phần mềm, viết code để triển khai chức năng mới chỉ là một phần của công việc. Lập trình viên còn cần kiểm tra xem chương trình có hoạt động đúng theo yêu cầu hay không, đồng thời bảo đảm những thay […]
Docker
1. Docker là gì? Docker là nền tảng giúp đóng gói và chạy ứng dụng trong các môi trường được gọi là container. Một ứng dụng Backend thường phụ thuộc vào nhiều thành phần: Ngôn ngữ lập trình và runtime như Go, PHP hoặc Node.js. Thư viện và package. Database như PostgreSQL hoặc MySQL. Cache […]
Message Broker
Message Broker là gì? Vai trò của Message Broker trong Backend 1. Message Broker là gì? Message Broker là phần mềm trung gian cho phép các thành phần trong hệ thống trao đổi thông điệp với nhau mà không cần giao tiếp trực tiếp. Nó tiếp nhận thông điệp từ bên gửi, sau đó định […]
Khoá học lập trình game con rắn cho trẻ em 
