Chuyện là tôi đang làm một cái side project nho nhỏ, một công cụ thu thập metrics từ các thiết bị IoT. Yêu cầu cũng không có gì quá phức tạp, chỉ cần một cái message queue đã được battle-tested có độ trễ thấp, và có thể chịu được tải tăng đột biến. Mục tiêu là chịu được khoảng 10,000 message/s mà không toang.
Dĩ nhiên, cái tên đầu tiên bật ra trong đầu tôi là Kafka.
Nên tôi đã quyết định nghỉ buổi câu cá cuối tuần để test thử =)), đem nó ra benchmark cùng với RabbitMQ và Redis Streams.
Kết quả cũng khá bất ngờ. Nó khiến tôi phải đặt lại câu hỏi về cách mà chúng ta thường mặc định lựa chọn message system cho dự án của mình.
Setup môi trường Benchmark
Để đảm bảo bài test này fair play, tôi cũng cố gắng mô phỏng một môi trường thực tế nhất có thể.
Đây là setup môi trường tôi sử dụng:
- Máy ảo: VM Ubuntu 4 vCPU, 16 GB RAM (dùng Ec2).
- Producer/Consumer: Viết bằng Golang (anh em dev Go thì cũng biết, goroutines xử lý concurrency ngon thế nào).
- Message size: 512 bytes (mô phỏng payload nhỏ, ví dụ dữ liệu từ sensor).
- Message rate: Tăng dần lên 10,000 msg/s.
- Thời gian test: Duy trì tải trong 10 phút cho mỗi tools.
- Bật Persistence: Vì benchmark mà không bật durability thì kết quả chỉ để ngắm, chẳng có giá trị gì.
Mỗi bài test sử dụng một topic/stream/queue duy nhất với 3 producer và 3 consumer.
Đây là kiến trúc siêu cơ bản của cái tool benchmark mà tôi setup:
+-----------------+
| Producer |
+-----------------+
|
v
+-------------------------------------+
| Messaging System |
| (Kafka / RabbitMQ / Redis) |
+-------------------------------------+
|
v
+-----------------+
| Consumer |
+-----------------+Các Chỉ Số Quan Trọng
Tôi đo 3 chỉ số metric chính:
- End-to-End Latency (P95): Thời gian từ lúc producer gửi message đến khi consumer xử lý xong.
- Throughput: số msg/s deliver thành công.
- CPU + Memory Usage: để đo lượng tài nguyên tiêu thụ.
Bài test 1: Kafka
Apache Kafka gần như là lựa chọn mặc định cho các hệ thống throughput cao. Nó scale ngang tốt.
Tôi sử dụng kafka-go cho bài test này.
Điểm mạnh của Kafka:
- Throughput cực “khủng”: Kafka dễ dàng đạt ngưỡng 11,000 msg/s.
- Durability ngon: Mọi message đều được ghi xuống disk và replica.
- Hệ sinh thái tốt: Giám sát với JMX + Prometheus rất mượt mà.
Điểm yếu của Kafka:
- P95 Latency cao (140ms): Chủ yếu do cơ chế batching và overhead của
fsync. - Ngốn CPU: Tải tăng một phát là CPU nhảy vọt lên 80% khi ghi liên tục.
- Setup hơi “lằng nhằng”: Dù không còn Zookeeper nữa, nhưng Kafka vẫn không phải kiểu ‘spin up một phát là chạy’.
Thông số benchmark của Kafka:
- Throughput: 11,000 msg/s
- P95 Latency: 140ms
- CPU trung bình: 82%
- RAM sử dụng: 2.1 GB
Kết luận: Throughput của Kafka thì khỏi chê, nhưng để chạy mấy cái workload vừa và nhỏ thì có vẻ hơi “quá thừa”, không đáng.
Bài test 2: RabbitMQ
RabbitMQ là message broker quốc dân mà có thể mọi người đang dùng mà không hề hay biết. Nó sinh ra để dành cho các task mang tính transactional.
Tôi dùng Go client qua github.com/streadway/amqp.
Điểm mạnh của RabbitMQ:
- Latency thấp (P95: 45ms): Thấp hơn Kafka khá nhiều.
- Setup đơn giản: chạy Docker container cái là xong.
- Xử lý workload burst đỉnh: Nó xử lý các đợt message tăng vọt rất mượt mà.
Điểm yếu của RabbitMQ:
- Throughput có phần limit: Chỉ đạt khoảng 7,000 msg/s.
- Chế độ persistence làm giảm performance: Không bật thì nhanh, bật lên thì latency tăng gấp đôi.
- UI dễ dùng, nhưng thao tác còn hơi thủ công.
Thông số benchmark của RabbitMQ:
- Throughput: 7,000 msgs/giây
- P95 Latency: 45ms
- CPU trung bình: 60%
- RAM sử dụng: 1.4 GB
Kết luận: RabbitMQ là lựa chọn vừa vặn, đủ tốt cho phần lớn use case, nhất là các hệ thống giao dịch cần độ tin cậy cao.
Bài test 3: Redis Streams
Redis Streams? Anh em nghe hơi lạ phải không =))?. Trước giờ ít ai để ý Redis như một message queue. Nhưng từ Redis 5 đã giới thiệu streams, một dạng append-only log có persistence, hoạt động giống Kafka một cách đáng kinh ngạc.
Tôi sử dụng github.com/go-redis/redis/v8.
Điểm mạnh của Redis Streams:
- Latency nhanh như chớp (P95: 18ms): Dẫn đầu cuộc đua luôn.
- Setup và triển khai dễ dàng
- Cực kỳ nhẹ, tốn ít tài nguyên
Điều ấn tượng nhất là dù bật persistence, Redis vẫn giữ latency thấp nhất.
Điểm yếu của Redis Streams:
- Throughput chỉ dừng ở mức ~9,000 msg/s
- TThiếu cơ chế scale consumer “native” Phải tự gán consumer group bằng tay, hơi mất công.
- Tool còn hạn chế: Không có dashboard hay broker “xịn sò” như Kafka.
Thông số benchmark của Redis Streams:
- Throughput: 9,000 msgs/giây
- P95 Latency: 18ms
- CPU trung bình: 40%
- RAM sử dụng: 980 MB
Kết luận: Redis Streams cho tôi cảm giác như dùng cheat code vậy: tốc độ siêu nhanh, cấu hình đơn giản, cực kỳ hợp với workload real-time.
Bảng So Sánh Tổng Hợp
| Chỉ số | Kafka | RabbitMQ | Redis Streams |
|---|---|---|---|
| Throughput (msg/s) | 11,000 | 7,000 | 9,000 |
| P95 Latency | 140ms | 45ms | 18ms |
| CPU Usage | 82% | 60% | 40% |
| Memory Usage | 2.1 GB | 1.4 GB | 980 MB |
| Persistence | Tốt | Chậm | Tốt |
| Dễ setup | Khá | Tốt | Tốt |
| Hệ sinh thái | Tốt | Tốt | Khá |
Vậy Nên Dùng Cái Nào?
Đây là góc nhìn cá nhân của tôi sau bài test này:
- Dùng Kafka nếu mọi người có một pipeline dữ liệu khổng lồ và cần scale ngang trên hàng chục, hàng trăm microservice. Nó sinh ra để dành cho analytics, xử lý log và kiến trúc decoupled. Chỉ cần chuẩn bị tinh thần chăm sóc nó thật cẩn thận:))
- Dùng RabbitMQ nếu use case của mọi người mang tính transactional: chạy background job, các task cần đảm bảo delivery, hay các hệ thống cần cơ chế retry mạnh mẽ.
- Dùng Redis Streams nếu mọi người cần latency cực thấp và đã có sẵn Redis trong hệ thống. Đối với những thứ như live chat, thu thập dữ liệu IoT, hay đồng bộ trạng thái game, Redis Streams là một lựa chọn tối ưu nhất.
Vài điều rút ra sau khi benchmark
- Đừng chạy theo số đông. Đa phần nhiều team chọn Kafka chỉ vì nó phổ biến, chứ chẳng mấy khi tự benchmark để xem nó có thực sự hợp với mình không. Tự kiểm tra hiệu năng trên workload của mình sẽ giúp mọi người có cái nhìn chính xác hơn.
- Hãy quan tâm đến hiệu quả tài nguyên. Bài test cho thấy Redis Streams mang lại độ trễ cực thấp trong khi tiêu thụ ít CPU và RAM hơn hẳn. Chi phí vận hành là một yếu tố quan trọng cần cân nhắc.
- Mỗi công cụ có một vai trò riêng. Kafka mạnh nhất về throughput, RabbitMQ ổn định cho các workload transactional, còn Redis Streams nổi bật ở latency thấp. Điều quan trọng nhất là mọi người phải hiểu rõ bài toán của mình cần gì để chọn đúng công cụ.
Một ví dụ thực tế
Giả sử mọi người đang xây một hệ thống messaging cho app gọi xe:
- Kafka sẽ là pipeline xử lý analytics và log sự kiện chuyến đi (nặng đô, scale tốt).
- RabbitMQ sẽ dùng cho các update giao dịch (thanh toán, xác nhận đơn, retry).
- Redis Streams sẽ cấp nguồn cho tính năng cập nhật vị trí tài xế-khách hàng trực tiếp (latency thấp, gần như real-time).
Mỗi công cụ có một vai trò riêng.
Lời cuối
Sau bài test này, điều làm tôi bất ngờ nhất không chỉ là hiệu năng, mà là việc Redis Streams lại ít được nhắc đến trong các hệ thống production.
Kafka nổi bật về throughput, RabbitMQ đáng tin cậy với các tác vụ transactional. Trong khi đó, Redis Streams là một giải pháp hiệu quả về mặt chi phí và hiệu năng nhưng thường không được ưu tiên lựa chọn.
Trước khi chọn Kafka cho dự án tiếp theo, bạn có thể tự hỏi: Liệu mình có thực sự cần một hệ thống phân tán phức tạp, hay chỉ đơn giản là cần truyền message thật nhanh? Nếu câu trả lời là vế sau, hãy thử cân nhắc Redis Streams. Có thể nó sẽ là lựa chọn tối ưu mà bạn đang tìm kiếm.
Website không chứa bất kỳ quảng cáo nào, mọi đóng góp để duy trì phát triển cho website (donation) xin vui lòng gửi về STK 90.2142.8888 - Ngân hàng Vietcombank Thăng Long - TRAN VAN BINH
=============================
Nếu bạn không muốn bị AI thay thế và tiết kiệm 3-5 NĂM trên con đường trở thành DBA chuyên nghiệp hay làm chủ Database thì hãy đăng ký ngay KHOÁ HỌC ORACLE DATABASE A-Z ENTERPRISE, được Coaching trực tiếp từ tôi với toàn bộ bí kíp thực chiến, thủ tục, quy trình của gần 20 năm kinh nghiệm (mà bạn sẽ KHÔNG THỂ tìm kiếm trên Internet/Google) từ đó giúp bạn dễ dàng quản trị mọi hệ thống Core tại Việt Nam và trên thế giới, đỗ OCP.
- CÁCH ĐĂNG KÝ: Gõ (.) hoặc để lại số điện thoại hoặc inbox https://m.me/tranvanbinh.vn hoặc Hotline/Zalo 090.29.12.888
- Chi tiết tham khảo:
https://bit.ly/oaz_w
=============================
2 khóa học online qua video giúp bạn nhanh chóng có những kiến thức nền tảng về Linux, Oracle, học mọi nơi, chỉ cần có Internet/4G:
- Oracle cơ bản: https://bit.ly/admin_1200
- Linux: https://bit.ly/linux_1200
=============================
KẾT NỐI VỚI CHUYÊN GIA TRẦN VĂN BÌNH:
📧 Mail: binhoracle@gmail.com
☎️ Mobile/Zalo: 0902912888
👨 Facebook: https://www.facebook.com/BinhOracleMaster
👨 Inbox Messenger: https://m.me/101036604657441 (profile)
👨 Fanpage: https://www.facebook.com/tranvanbinh.vn
👨 Inbox Fanpage: https://m.me/tranvanbinh.vn
👨👩 Group FB: https://www.facebook.com/groups/DBAVietNam
👨 Website: https://www.tranvanbinh.vn
👨 Blogger: https://tranvanbinhmaster.blogspot.com
🎬 Youtube: https://www.youtube.com/@binhguru
👨 Tiktok: https://www.tiktok.com/@binhguru
👨 Linkin: https://www.linkedin.com/in/binhoracle
👨 Twitter: https://twitter.com/binhguru
👨 Podcast: https://www.podbean.com/pu/pbblog-eskre-5f82d6
👨 Địa chỉ: Tòa nhà Sun Square - 21 Lê Đức Thọ - Phường Mỹ Đình 1 - Quận Nam Từ Liêm - TP.Hà Nội
=============================
cơ sở dữ liệu, cơ sở dữ liệu quốc gia, database, AI, trí tuệ nhân tạo, artificial intelligence, machine learning, deep learning, LLM, ChatGPT, DeepSeek, Grok, oracle tutorial, học oracle database, Tự học Oracle, Tài liệu Oracle 12c tiếng Việt, Hướng dẫn sử dụng Oracle Database, Oracle SQL cơ bản, Oracle SQL là gì, Khóa học Oracle Hà Nội, Học chứng chỉ Oracle ở đầu, Khóa học Oracle online,sql tutorial, khóa học pl/sql tutorial, học dba, học dba ở việt nam, khóa học dba, khóa học dba sql, tài liệu học dba oracle, Khóa học Oracle online, học oracle sql, học oracle ở đâu tphcm, học oracle bắt đầu từ đâu, học oracle ở hà nội, oracle database tutorial, oracle database 12c, oracle database là gì, oracle database 11g, oracle download, oracle database 19c/21c/23c/23ai, oracle dba tutorial, oracle tunning, sql tunning , oracle 12c, oracle multitenant, Container Databases (CDB), Pluggable Databases (PDB), oracle cloud, oracle security, oracle fga, audit_trail,oracle RAC, ASM, oracle dataguard, oracle goldengate, mview, oracle exadata, oracle oca, oracle ocp, oracle ocm , oracle weblogic, postgresql tutorial, mysql tutorial, mariadb tutorial, ms sql server tutorial, nosql, mongodb tutorial, oci, cloud, middleware tutorial, docker, k8s, micro service, hoc solaris tutorial, hoc linux tutorial, hoc aix tutorial, unix tutorial, securecrt, xshell, mobaxterm, putty
