RabbitMQ 也進來搶 Streaming Engine 這塊市場了

RabbitMQ 要在 3.9 版推出 Streams (目前 3.9 還在 RC):「RabbitMQ Streams Overview」,在 Hacker News 上有一些討論可以看:「RabbitMQ Streams Overview (rabbitmq.com)」。

這樣 RabbitMQ 可以同時有 queue 與 stream 的能力,對於一些小專案應該會方便不少,算是打隔壁棚 Kafka 的痛點之一,弄一組 HA cluster 至少要三台 ZooKeeper 加上兩台 Broker,基礎建設還要有對應的 HA load balancer 機制,在 AWS 上可以拿 ELB 偷懶,如果是實體機房的話也許用 F5 擋,或是用 open source 的 Keepalived (或是老一點的 Heartbeat) + nginx

目前還不知道 scalability 的能耐,不過印象中在 queue 的單台 throughput 不差,如果沒有意外的話,streaming 的部份對小型專案應該夠用。

Amazon MQ 支援 RabbitMQ

Amazon MQ 本來只支援 ActiveMQ,剛剛看到消息支援 RabbitMQ 了:「Announcing Amazon MQ for RabbitMQ」。

用的版本還算可以,查了一下 3.8.6 是今年八月出的:

Amazon MQ currently supports RabbitMQ version 3.8.6 and has support for version upgrades.

基本上 ActiveMQ 版本與 RabbitMQ 版本的價錢相同,不過 RabbitMQ 看起來就只支援比較新的機器了,像是 t2 系列的機器基本上就不支援了。

然後費用相當貴,差不多是機器本身三倍左右的價錢,看起來能自己架還是可以考慮自己架...

對各類 Message Queue 的效能測試

在「Benchmarking Message Queue Latency」這篇看到作者測了一輪 Message Queue 軟體:

RabbitMQ (3.6.0), Kafka (0.8.2.2 and 0.9.0.0), Redis (2.8.4) pub/sub, and NATS (0.7.3)

測試包括了從一個 9 到六個 9 的 latency (i.e. 90%、99%、99.9%、99.99%、99.999%、99.9999%),另外也測了 message 大小帶來的效能差異。

99.9% 表示 1/1000,而 99.99% 表示 1/10000,如果差距跟 90% 很大,表示系統反應時間會很不一致。另外有些 Message Queue 軟體有 disk persistence 的功能,也因為寫入資料,會看到更大的差距。

善用或是避開這些特性去規劃才能減少問題,像是關掉 disk persistence 之類的方法。