常見開源訊息系統

發表於2013-08-12

訊息系統的作用：非同步處理、削減峰值、減少元件之間的耦合。

選擇訊息系統根據業務需要需要考慮以下幾個方面：

  1. 是否持久化
  2. 吞吐能力
  3. 高可用
  4. 分散式擴充套件能力
  5. 相容現有協議
  6. 易於維護
  7. 其他，如訊息丟失和重複的處理
  8. 避免單點故障
  9. 負載均衡

常見訊息系統協議:

  1. STOMP
  2. AMQP
  3. 類似 MEMCACHE 的協議
  4. HTTP
  5. 自定格式

1、2 是不錯的可選開源元件：

1. Kafka/MetaQ: 廣泛用於 Linkedin 內部 (類似有 Java 版本的國產 MetaQ)

由於優先考慮吞吐，更加適合大資料量的訊息收集和處理，比如日誌分析、使用者行為資訊實時報表、叢集狀態資訊收集和分析。

  1. 優先考慮持久化的設計,依靠 page cache 管理記憶體
  2. 高吞吐 112MB/s 11K msgs/s (比 beanstalkd >70x 吞吐能力)
  3. 支援非同步複製
  4. 高可用、基於 Zookeeper 的叢集設計、支援消費者失效後重新負載均衡
  5. Kafka 提供 PHP 類庫
  6. 支援 ganglia JMX 監控
  7. 需要策略避免重複訊息, 消費者更新 Zookeeper 的 offset 的方式 (MetaQ 已經提供了幾種方式避免訊息重複)
  8. MetaQ 提供 HTTP 介面

http://www.mail-archive.com/kafka-users@incubator.apache.org/msg02082.html
https://github.com/neophenix/StateOfTheMQ/blob/master/state_of_the_mq.pdf?raw=true
http://s.urge.omniti.net/i/content/slides/Surge2012-ErikOnen_Kafka_Messaging-Paradigms.pdf
http://research.microsoft.com/en-us/um/people/srikanth/netdb11/netdb11papers/netdb11-final12.pdf
http://dirlt.com/kafka.html
http://dirlt.com/index.html
http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes

2. NSQ – Golang

無中心設計、節點自動註冊和發現。可以考慮作為內部通訊框架的基礎。

https://github.com/bitly/nsq
* 追求簡單部署
* 追求高可用、避免單點故障、無中心設計
* 確保訊息送達
* 生產者消費者自動發現、消費者連線所有生產者、向消費者推的模式
* 提供 HTTP 介面

https://speakerdeck.com/snakes/nsq-nyc-golang-meetup
https://github.com/davegardnerisme/nsqphp

http://www.davegardner.me.uk/blog/tag/nsq/

3. Beanstalkd

  1. 支援持久化 binlog 設計，重啟訊息不丟失
  2. 一般
  3. 無高可用設計
  4. 和 memcached 一樣的分散式擴充套件方式
  5. 各種類庫
  6. 有 Web 管理工具
  7. 支援同步呼叫，等待返回
  8. 只有類似 Memcache TCP ASCII 協議, 單檔案部署
  9. 支援訊息優先順序
  10. 9K jobs/s 入佇列 5K jobs/s 出佇列
  11. 單點故障
  12. 無主從同步複製機制
  13. 最好單機多例項部署

https://github.com/kr/beanstalkd/wiki/Tools
https://github.com/pda/pheanstalk

4. Redis

需要自己封裝 Pub/Sub

  • 基於 Redis 的複製高可用

其他常見開源訊息系統：

ZeroMQ: 輕量級基礎訊息庫

只適合不需要持久化的場景、需要自己封裝

  1. 不支援持久化，只提供訊息分發, 效能最好
  2. 無 Broker 設計, 無中心故障

RabbitMQ

  • 2500 job/s 入佇列 1300 job/s 出佇列
  • 適合小訊息
  • 分散式無單點設計
  • 底層為 Erlang 實現
    有評論: RabbitMQ could not enqueue/dequeue fast enough.

https://blogs.vmware.com/vfabric/2013/04/how-fast-is-a-rabbit-basic-rabbitmq-performance-benchmarks.html

RESTMQ

http://restmq.com/

MemcacheQ

http://memcachedb.org/memcacheq/

HTTPSQS

https://code.google.com/p/httpsqs/

Gearman

http://gearman.org/presentations
https://code.google.com/p/shard-query/

Kestrel

http://robey.github.io/kestrel/
http://robey.github.io/kestrel/docs/guide.html

HornetQ

效能差不考慮[3]

Resque

3800 jobs/s 入佇列 300 jobs/s 出佇列
https://github.com/blog/542-introducing-resque
基於 Redis 的訊息佇列

Starling

https://github.com/starling/starling

SquirrelMQ

https://code.google.com/p/squirrel-message-queue/

Sparrow – Ruby

https://code.google.com/p/sparrow/

Apache ActiveMQ

ActiveMQ crashed constantly under load.

STOMP HTTP 協議

http://stomp.github.io/stomp-specification-1.2.html

參考:

http://hiramchirino.com/stomp-benchmark/ec2-c1.xlarge/index.html
https://blog.serverdensity.com/queueing-mongodb-using-mongodb/
[3] http://x-aeon.com/wp/2013/04/10/a-quick-message-queue-benchmark-activemq-rabbitmq-hornetq-qpid-apollo/
https://news.ycombinator.com/item?id=5531192
http://www.javaplex.com/blog/high-performance-message-queues-get-reviewed/
http://adam.heroku.com/past/2010/4/24/beanstalkasimpleandfastqueueingbackend/

相關文章