thảo luận Nên chọn message queue nào

• Redis thì nhanh gọn nhẹ, nhưng dễ mất dữ liệu nên hệ thống nào ko cần đảm bảo 100% messages đều cần được xử lý thì dùng.
• RabbitMQ có mô hình pub/sub đơn giản và phù hợp với các tác vụ xử lý lâu hoặc background jobs.
• Kafka phức tạp hơn, to hơn phù hợp trong trường hợp cần xử lý high-throughput data streams.

kaitoubg đã nói:

Chắc câu hỏi của mấy chú Junior mới tìm hiểu về Micro services rồi Tuỳ vào từng trường hợp chứ chả có thằng nào tốt hơn thằng nào cả.
Mỗi 1 thằng có 1 ưu điểm riêng.

• Redis thì nhanh gọn nhẹ, nhưng dễ mất dữ liệu nên hệ thống nào ko cần đảm bảo 100% messages đều cần được xử lý thì dùng.
• RabbitMQ có mô hình pub/sub đơn giản và phù hợp với các tác vụ xử lý lâu hoặc background jobs.
• Kafka phức tạp hơn, to hơn phù hợp trong trường hợp cần xử lý high-throughput data streams.

Đấy là tôi nói phét thế thôi chứ tôi cũng chả dùng hết cái lũ này nên chả hiểu cái mẹ gì đâu.

Nhấp để mở rộng...

yeuemdeokinh12 đã nói:

thím có thể nói rõ hơn về thằng kafka dc ko ạ? e ngồi học hỏi có case study để so sánh với thằng rmq thì tuyệt

via theNEXTvoz for iPhone

Nhấp để mở rộng...

• Grab: https://engineering.grab.com/optimally-scaling-kafka-consumer-applications
• Gojek: https://blog.gojekengineering.com/tagged/kafka
• Uber: https://eng.uber.com/kafka/
• Kafka-summit: https://kafka-summit.org/

kaitoubg đã nói:

Chắc câu hỏi của mấy chú Junior mới tìm hiểu về Micro services rồi Tuỳ vào từng trường hợp chứ chả có thằng nào tốt hơn thằng nào cả.
Mỗi 1 thằng có 1 ưu điểm riêng.

• Redis thì nhanh gọn nhẹ, nhưng dễ mất dữ liệu nên hệ thống nào ko cần đảm bảo 100% messages đều cần được xử lý thì dùng.
• RabbitMQ có mô hình pub/sub đơn giản và phù hợp với các tác vụ xử lý lâu hoặc background jobs.
• Kafka phức tạp hơn, to hơn phù hợp trong trường hợp cần xử lý high-throughput data streams.

Đấy là tôi nói phét thế thôi chứ tôi cũng chả dùng hết cái lũ này nên chả hiểu cái mẹ gì đâu.

Nhấp để mở rộng...

slayer2k9 đã nói:

High throughput là sao bác, cho em ví dụ với

Nhấp để mở rộng...

• Storage performance
• IOPS throughput latency

• Nhận 1M requests per second
• Avg size per request: 1kB
• Thoughput = 1kB x 1M = 1GB/s

the_ruler đã nói:

Use-case thì bạn có thể đọc engineering blog của các công ty event-drive như Grab, Gojek, User, Lift, AirBnB, Netflix ... hoặc nhảy thẳng vào kafka-summit mà xem nha
Vài ví dụ:

• Grab: https://engineering.grab.com/optimally-scaling-kafka-consumer-applications
• Gojek: https://blog.gojekengineering.com/tagged/kafka
• Uber: https://eng.uber.com/kafka/
• Kafka-summit: https://kafka-summit.org/

....
Book thì có thể bắt đầu với cuốn Kafka: The Definitive Guide của Confluent, mình thấy khá dễ hiểu và gần gũi với thực tế.

Edit: Ở VN thì mình biết có mấy bên cũng chơi hệ thống có Kafka ở core, tiếc là mấy cái slide trong mấy cái conference không thấy share

Nhấp để mở rộng...

slayer2k9 đã nói:

High throughput là sao bác, cho em ví dụ với

Nhấp để mở rộng...

yeuemdeokinh12 đã nói:

thím có thể nói rõ hơn về thằng kafka dc ko ạ? e ngồi học hỏi có case study để so sánh với thằng rmq thì tuyệt

via theNEXTvoz for iPhone

Nhấp để mở rộng...

• Việc render file hay thanh toán thì xong xuôi mới cần có response, nếu lượng request không phải quá lớn (vài chục nghìn rq/s+) thì RabbitMQ đáp ứng thoải mái. Thì cứ xài nó vì dễ dùng, dễ hiểu hơn Kafka nhiều - dĩ nhiên team có nhiều kinh nghiệm với kafka thì cũng ko cần thiết dùng rabbitmq.
• Việc stream đòi hỏi phản hồi liên tục, hay đối với các hệ thống cần xử lý quá nhiều request thì Kafka là lựa chọn tốt hơn.

• push (RabbitMQ): Provider push message vào queue cho Consumer -> nếu consumer ko xử lý kịp thì có thể tràn queue.
• pull(Kafka): Kafka dùng topic chứ không phải queue. Các messages trong topic được lưu trữ dạng log và được xoá đi sau 1 thời gian (nếu nhớ ko nhầm default là 7 ngày). Trong khi đó các consumer theo dõi 1 offset trong log này để lấy dữ liệu. Ưu điểm là bạn có thể tua lại thời điểm xảy ra lỗi: VD hệ thống payment xử lý lỗi trong 24h bạn chỉ cần dịch chuyển offset về trước đó 24h. Trong khi đó với RabbitMQ bạn chỉ có cách republish lại các request, vì các message đã được lấy ra khỏi queue -> Khả năng xử lý lỗi của Kafka tốt hơn.

karenshii đã nói:

kafka sinh ra để stream, vì nó đảm bảo được thứ tự của các message, dựa vào key trong mỗi partition. Không ai dùng kafka để làm queue chạy background job cả, vì khi số consumer > số partion, thì việc scale là vô nghĩa.

rabbitmq sinh ra để làm queue chạy background job, rabbitmq không mạnh trong việc đảm bảo thứ tự của msg, có thể cố đấm ăn xôi bằng cách set header priority, nhưng không linh hoạt được.

kafka persistance data tốt hơn, có thể cấu hình thời gian msg có thể được lưu lại disk. Có thể đọc lại bất kỳ msg cũ từ cách khai báo offset. Nên consumer có thể "đọc lại" msg bất cứ khi nào muốn.

Rabbitmq không làm được điều này, từ version 3.8 có hỗ trợ Quorum Queue để HA message, còn các queue khác, thì khi msg đã được subscriber báo ACK đọc msg rồi, thì nó sẽ bị xóa khỏi queue.

...
còn nhiều nữa lắm, mà lười gõ quá

Nhấp để mở rộng...

gaveezy đã nói:

Apache Pulsar nhé, hiện tại thua Kafka mỗi mặt ecosystem do ra đời sau thôi chứ còn lại ăn tất

Nhấp để mở rộng...

mistake37 đã nói:

Có ae nào dùng Nats chưa nhỉ, so với Kafka thì có hơn gì ko?

Sent from Soupie using vozFApp

Nhấp để mở rộng...

mistake37 đã nói:

Có ae nào dùng Nats chưa nhỉ, so với Kafka thì có hơn gì ko?

Sent from Soupie using vozFApp

Nhấp để mở rộng...