消息队列各种比较.docx
《消息队列各种比较.docx》由会员分享，可在线阅读，更多相关《消息队列各种比较.docx（7页珍藏版）》请在冰点文库上搜索。
消息队列各种比较
消息队列各种比较
最近的工作需要用到MessageQueue来做“任务分发”，自己写了一个简单的，但是感觉不够满意。
主要还是感觉消息队列持久化要做的好很难，还有各种异常情况等等，短时间开发一个，挑战很大，还是找一个开源的实现吧。
先是找到了RabbitMQ，是erlang写的，而我们的系统是用Go写的，目前它还没有Go的绑定，部署系统的时候也要装erlang虚拟机。
考察了之后决定放弃。
然后是最近大名鼎鼎的ZeroMQ，第一次听说是在云风大哥的博客上（
分析代码的时候就知道它没有分发任务、执行任务时候的各种确认，任务的持久化以防止任务丢失。
不过ZeroMQ可以把内存中放不下的消息先写到磁盘上去，然后再读进内存（见swap_t类）。
这次再大致看了下它的文档，可以确认它的名字虽然是MQ，但是它提倡的是“结构化网络编程”，它建立了非常灵活的编写网络程序的基础设施，可以用在各种场合，不过这些场合都需要你自己利用它提供的基础设施来定制（比如我现在急切需要的各种任务分发相关的特性）。
目前知道的是它可以创建一个queue的device。
不过这个目前和我的“任务分发”需求相差很远。
以后有空再研究这个精彩的、雄心勃勃的项目吧。
然后是Gearman（http:
//gearman.org/），它是专门做任务分发的。
任务可以分为前台任务（同步任务）和后台任务（异步任务），而且提供了任务的持久化机制（配置一个数据库就行了，支持MySQL，Sqlite3等），非常符合我的胃口。
:
）而且mikespook大侠已经提供好了Gearman协议的Golang实现（
我个人觉得Gearman的文档最值得看的就是它的协议交互了（http:
//gearman.org/index.php?
id=protocol），另外就是它的C接口使用（http:
//gearman.org/docs/dev/），分为Client和Worker两部分。
不过在下载安装Gearman的时候，发现竟然要先装Boost，唉。
。
。
另外如果Gearman仍然是C开发的就好了，为什么要转向C++呢。
。
。
搞不懂，不明白。
。
最后以查找资料的时候，国外牛人对各种“MQ”的总结结束。
RabbitMQ、ZeroMq和ActiveMQ的比较：
RabbitMQisoneoftheleadingimplementationoftheAMQPprotocol（alongwithApacheQpid）.Therefore,itimplementsabrokerarchitecture,meaningthatmessagesarequeuedonacentralnodebeforebeingsenttoclients.ThisapproachmakesRabbitMQveryeasytouseanddeploy,becauseadvancedscenarioslikerouting,loadbalancingorpersistentmessagequeuingaresupportedinjustafewlinesofcode.However,italsomakesitlessscalableand“slower”becausethecentralnodeaddslatencyandmessageenvelopesarequitebig.
ZeroMqisaverylightweightmessagingsystemspeciallydesignedforhighthroughput/lowlatencyscenariosliketheoneyoucanfindinthefinancialworld.ZmqsupportsmanyadvancedmessagingscenariosbutcontrarytoRabbitMQ,you’llhavetoimplementmostofthemyourselfbycombiningvariouspiecesoftheframework（e.g:
socketsanddevices）.Zmqisveryflexiblebutyou’llhavetostudythe80pagesorsooftheguide（whichIrecommendreadingforanybodywritingdistributedsystem,evenifyoudon’tuseZmq）beforebeingabletodoanythingmorecomplicatedthatsendingmessagesbetween2peers.
ActiveMQisinthemiddleground.LikeZmq,itcanbedeployedwithbothbrokerandP2Ptopologies.LikeRabbitMQ,it’seasiertoimplementadvancedscenariosbutusuallyatthecostofrawperformance.It’stheSwissarmyknifeofmessaging:
-）.Finally,all3products:
（1）haveclientapisforthemostcommonlanguages（C++,Java,.Net,Python,Php,Ruby,…）
（2）havestrongdocumentation
（3）areactivelysupportedGearman与RabbitMQ的比较：
IwouldsaythatGearmanisbetterforqueuing"jobs"andRabbitMQisbetterforqueuing"data".Ofcourse,theyarebothreallythesamething,butthewayitworksoutformeisthatifyouaretryingto"fanout"worktobedone,andtheworkerscanworkindependently,Gearmanisthebetterwaytodoit.Butifyouaretryingtofeeddatafromalotofsourcesdownintofewerdataconsumers,RabbitMQisthebettersolution.
ThehistoryofRabbitMQ,assomethingthatallowedTwittertotakeburstyloadsofmessages,andfeedthemintocrustyoldSMSgatewaysthatcouldkeeponlyoneconnectionopen,wereratelimited,anddidnthaveretries,isillustrativeofthekindofproblemsthatRabbitMQisgoodatsolving.
一篇文章：
常见的开源消息系统——网站公告、通知、消息的实现方式
消息系统的作用：
异步处理、削减峰值、减少组件之间的耦合。
选择消息系统根据业务需要需要考虑以下几个方面：
是否持久化
吞吐能力
高可用
分布式扩展能力
兼容现有协议
易于维护
其他，如消息丢失和重复的处理
避免单点故障
负载均衡
常见消息系统协议:
STOMP
AMQP
类似MEMCACHE的协议
HTTP
自定格式
下述1、2是不错的可选开源组件：
1.Kafka/MetaQ:
广泛用于Linkedin内部（类似有Java版本的国产MetaQ）
由于优先考虑吞吐，更加适合大数据量的消息收集和处理，比如日志分析、用户行为信息实时报表、集群状态信息收集和分析。
优先考虑持久化的设计,依靠pagecache管理内存
高吞吐112MB/s11Kmsgs/s（比beanstalkd>70x吞吐能力）
支持异步复制
高可用、基于Zookeeper的集群设计、支持消费者失效后重新负载均衡
Kafka提供PHP类库
支持gangliaJMX监控
需要策略避免重复消息,消费者更新Zookeeper的offset的方式（MetaQ已经提供了几种方式避免消息重复）
MetaQ提供HTTP接口
https:
//kafka.apache.org/2.NSQ–Golang
无中心设计、节点自动注册和发现。
可以考虑作为内部通讯框架的基础。
*追求简单部署
*追求高可用、避免单点故障、无中心设计
*确保消息送达
*生产者消费者自动发现、消费者连接所有生产者、向消费者推的模式
*提供HTTP接口
3.Beanstalkd
支持持久化binlog设计，重启消息不丢失
一般
无高可用设计
和memcached一样的分布式扩展方式
各种类库
有Web管理工具
支持同步调用，等待返回
只有类似MemcacheTCPASCII协议,单文件部署
支持消息优先级
9Kjobs/s入队列5Kjobs/s出队列
单点故障
无主从同步复制机制
最好单机多实例部署
http:
//kr.github.io/beanstalkd/
4.Redis
需要自己封装Pub/Sub
基于Redis的复制高可用
其他常见开源消息系统：
ZeroMQ:
轻量级基础消息库
只适合不需要持久化的场景、需要自己封装
不支持持久化，只提供消息分发,性能最好
无Broker设计,无中心故障
RabbitMQ
2500job/s入队列1300job/s出队列
适合小消息
分布式无单点设计
底层为Erlang实现
有评论:
RabbitMQcouldnotenqueue/dequeuefastenough.
RESTMQ
MemcacheQ
http:
//memcachedb.org/memcacheq/
HTTPSQS
Gearman
http:
//gearman.org/presentations
Kestrel
http:
//robey.github.io/kestrel/
http:
//robey.github.io/kestrel/docs/guide.html
HornetQ
性能差不考虑
Resque
3800jobs/s入队列300jobs/s出队列
基于Redis的消息队列
Starling
SquirrelMQ
Sparrow–Ruby
ApacheActiveMQ
ActiveMQcrashedconstantlyunderload.
STOMPHTTP协议
http:
//stomp.github.io/stomp-specification-1.2.html
升级会员 