Tản mạn về hệ thống messaging: Kafka & RabbitMQ

Chắc hẳn các bạn đã quá quen thuộc với những hệ thống messaging khi bạn là một backend-developer. Mình có thể liệt kê một loạt các hệ thống messaging mình biết như:

• RabbitMQ

• Kafka

• ZeroMQ

• ActiveMQ

• IronMQ

• RocketMQ

Tuy nhiên, ở bài viết này mình sẽ chỉ đề cập đến hai loại là RabbitMQ & Kafka. Vì đây là hai loại phổ biến nhất mà các công ty cũng như các bạn backend-developer đang sử dụng. Thế thì, câu hỏi mình đặt ra là các bạn có bao giờ nghĩ rằng khi nhận một project và yêu cầu đặt ra là tích hợp pub/sub systems thì bạn sẽ phải lựa chọn hệ thống nào cho team mình hay không? Kafka hay RabbitMQ? Nếu không nắm rõ về chúng, có thể bạn sẽ dẫn đến lạc lối cho con đường mình chọn.

Okay! Let's do it :)

Để trả lời câu hỏi đó, trước hết mình sẽ đi sơ lược kiến trúc từng loại.

RabbitMQ

RabbitMQ là một message broker ( message-oriented middleware) hỗ trợ các protocols như MQTT, AMQP (Advanced Message Queue Protocol - giao thức phổ biến được sử dụng), và STOMP.

Flow cơ bản: Producer -> Exchange -> Binding -> Queues -> Consumer.

Producer đẩy message vào exchange. Sau khi exchange nhận message, exchange (4 loại: direct, topic, fanout, headers ) là một lớp middleware nên nó giúp điều hướng binding message (dựa trên thuộc tính của message - routing key) đến hàng đợi (queue). Các message tại queue sẽ được xử lý bới consumer, một khi được xử lý xong sẽ đánh dấu status của consumer và message được xóa khỏi queue.

Kafka

Kafka là một nền tảng truyền dữ liệu phân tán (distributed messaging system). Kafka sử dụng mô hình truyền thông public-subscribe, bên public dữ liệu được gọi là producer bên subscribe nhận dữ liệu theo topic được gọi là consumer. Kafka có khả năng truyền một lượng lớn dữ liệu trong thời gian thực, trong trường hợp bên nhận chưa nhận dữ liệu vẫn được lưu trữ lại để bảo đảm an toàn về mặt dữ liệu.

Flow kiến trúc cơ bản:

Producer gửi một message đến một topic (topic là một chủ đề bao gồm các message - hiểu đơn giản là ngôn ngữ giao tiếp giữa producer vs consumer). Các consumer theo dõi (subscribe) một topic và bắt đầu nhận message từ nó. Khi một topic được phân vùng thì mỗi vùng sẽ có một thể hiện consumer riêng. Các thể hiện trên cùng một consumer được gọi là một consumer group.

Mỗi partition là một chuỗi log, có thứ tự và không thể thay đổi (immutable).

Mỗi message trong partition đều có id tăng dần, gọi là offset. Tại offset này, consumer có thể lựa chọn để đọc.

Kafka cluster sẽ lưu lại mọi message đã được published, cho dù message đó đã consume hay chưa.

Qua sơ lược, chắc các bạn thấy chúng đã có sự khác nhau thế nào rồi, bây giờ mình sẽ chi tiết sự phân biệt ấy.

So sánh và phân biệt

Như vậy, mình sẽ tóm lại như thế này từ bảng so sánh trên:

• Nếu hệ thống của bạn không cần lưu trữ message, ưu tiên cho việc đòi hỏi sự đảm bảo rằng các consumer đều nhận được message và duy nhất bên cạnh độ ưu tiên của từng message thì dạng messaging truyền thống như RabbitMQ sẽ thực sự hữu dụng.

• Nếu hệ thống của bạn đòi hỏi về mặt lưu trữ và tốc độ truyền tải message. Consumer muốn lựa chọn số lượng message mình cần, có thể lấy theo thứ tự hoặc muốn lấy từ lúc bắt đầu, một consumer có thể nhận đi nhận lại nhiều lần message đấy. Lúc này đây, hệ thông messaging dạng pipeline như Kafka sẽ được tin dùng. Có thể kể đến một số user cases như: Stream Processing, Event sourcing,..

✧ ✧ ✧

Tổng kết, chúng ta nên lựa chọn hệ thống messaging phù hợp với nhu cầu và mục đích của hệ thống mình mong muốn. Đôi khi chúng ta cũng sẽ sử dụng cả hai loại trên để tận dụng tối đa các ưu điểm của từng loại.

Cuối cùng, hi vọng bài viết của mình giúp các bạn giảm bớt được thời gian tìm hiểu cũng như chọn lọc được hệ thống messaging mình cần trong tương lai.

Thank you!! :)