如何选择合适的开源消息中间件
如何选择合适的开源消息中间件 Posted on 2015-05-25 09:43 协思 阅读(...) 评论(...) 编辑 收藏原创文章转载请注明出处：@协思,http://zeeman.cnblogs.com我们要引入消息中间件，势必要考虑成本收益问题，怎样达到最高的性价比。很多公司的研发团队还没有专门的资源投入到基础设施的研发中，使用开源产品，扬长避短无疑是最好的方式。业界消息中间件的种类繁多，各有侧重点，看着网上的一些选型推荐，你会觉得无所适从。但我可以告诉你的是，能用的真的不多:)。对于一般的电子商务而言，不会为了性能降低可靠性，因为一个消息的丢失，可能意味着有一笔订单无法及时处理。追求极致性能的ZeroMQ一般用在游戏和工控方面，咱们做电商的还是别添乱了。就规模体量而言，大公司会自研消息队列，像阿里、新浪、亚马逊，京东，携程，据我所知，他们是自己开发维护着一套消息队列，为什么要自己做，说到底是他们使用消息队列的场景模式已经相对固化，需要在这种场景下追求最高的性能。中小公司没有这样的资源去做，采用通用的开源产品是很合适的，当你有那么大的体量时，再自己去发明一套定制轮子。我们能选择的有三种：1. ActiveMQ/ApolloMQ优点：老牌的消息队列，使用java语言编写。对JMS支持最好，采用多线程并发，资源消耗比较大。如果你的主语言是Java，可以重点考虑。缺点：由于历史悠久，历史包袱较多，版本更新很缓慢。集群模式需要依赖Zookeeper实现。最新架构的产品被命名为Apollo，号称下一代ActiveMQ，目前案例较少。2. RocketMQ/Kafka优点：专为海量消息传递打造，主张使用拉模式，天然的集群、HA、负载均衡支持。话说还是那句话，适合不适合看你有没有那么大的量。缺点：所谓鱼和熊掌不可兼得，放弃了一些消息中间件的灵活性，使用的场景较窄，需关注你的业务模式是否契合，否则山寨变相使用很别扭。除此之外，RocketMQ没有.NET下的客户端可用。RocketMQ身出名门，但使用者不多，生态较小，毕竟消息量能达到这种体量的公司不多，你也可以直接去购买阿里云的消息服务。Kafka生态完善，其代码是用Scala语言写成，可靠性比RocketMQ低一些。3. RabbitMQ优点：生态丰富，使用者众，有很多人在前面踩坑。AMQP协议的领导实现，支持多种场景。淘宝的MySQL集群内部有使用它进行通讯，OpenStack开源云平台的通信组件，最先在金融行业得到运用。缺点：Erlang代码你Hold得住不? 虽然Erlang是天然集群化的，但RabbitMQ在高可用方面做起来还不是特别得心应手，别相信广告。如果你不着急使用，也可以观望一下Redis作者的新产品Disque，还有Go语言写的Nsq也有不错的表现。等你每个产品都作了测试就会发现，都有不爽的地方，毕竟不是为你量身打造的，所以我前面说能选择的不多。我建议使用的时候遵守AMTP或者STOMP规范，在规范之下，Client SDK和Service Broker是可替换的，不管你用哪种语言都可以在Github上找到一堆SDK，这两种规范ActiveMQ和RabbitMQ都是支持的，Kafka自成一派，基本上大多数人用不上。ActiveMQ和RabbitMQ之间对于有.NET背景的团队建议使用RabbitMQ，希望本文对你的选择性障碍有所缓解。
