如何选择合适的开源消息中间件

原创文章转载请注明出处：@协思, 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，希望本文对你的选择性障碍有所缓解。