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

• 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 said:

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.

yeuemdeokinh12 said:

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

• 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 said:

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.

slayer2k9 said:

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

• Storage performance
• IOPS throughput latency

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

the_ruler said:

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

slayer2k9 said:

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

yeuemdeokinh12 said:

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

• 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.