mq选择

基本标准

1. 开源: 遇到有问题的bug可以通过修改源码的方式来修复或者规避、而不是只能等待下一个官方版本发版来修复
2. 产品社区有一定活跃度: 遇到问题的时候、可以快速找到类似场景、快速修复, 相比于每一个bug都需要自己通过阅读源码来解决、毕竟线上问题挂着的的成本很高
   社区活跃度较高的产品、与周边应用的兼容性也会比较好、省去很多造轮子的时间
3. 性能要求:
   1. 确保消息可靠传递、不丢失消息
   2. 支持集群、确保某个节点宕掉不会影响整个服务
   3. 性能、能满足大部分实际需求场景的需要

目前可选方案

RabbitMQ

源码实现 : Erlang
特点: 轻量级、性能好、方便部署和使用、维护简单
         支持灵活的路由配置、相对其它MQ、在Producer和Queue之间增加Exchange模块、可根据配置规则将生产者发出的Msg发送到不同队列
         Client支持多种语言

短处: 
1. 消息堆积处理支持不好、消息大量堆积时会导致MQ的性能急速下降
2. 处理消息的性能比较一般、根据硬件配置不同、每秒大概可以处理的消息数量为: 几w ~ 十几w
3. 源码语言为Erlang、比较小众、扩展开发成本增加

RocketMQ

2012年阿里开源出来的产品、17年交给apache维护
源码: Java
性能: 稳定性、可靠性和性能都不错、对响应延迟也做了优化、大多数情况可以做到ms级的响应、每秒可处理消息 几十万(性能比RabbitMQ高一个数量级)

短处: 相比国外同类产品、与周边生态系统的集成度和兼容性稍低

Kafka

最初设计是为了处理海量日志、早期版本不保证消息可靠性、也不支持集群、但对于处理海量日志这个诉求是比较好的选择

近期版本、在数据可靠性、稳定性和功能特性上都可以满足大多数的场景需求

源码实现: Java + Scala
优势:
1. 与周边生态系统的兼容性最好、尤其是大数据和流计算领域、几乎所有相关开源软件都优先支持Kafka
2.  异步收发性能最好、在服务器配置高时、极限情况每秒可处理2000w消息

短处:
异步批量处理带来的问题是: 同步收发响应延时较高、它是攒一批然后批量发送、每秒消息数没那么高的时候、kafka的延时反而会高、

不适合在线业务场景

第二梯队mq

ZeroMQ

严格来说不能算是消息队列、而是一个基于消息队列的多线程网络库
如果需求是将消息队列的功能集成到系统进程中、可以考虑ZeroMQ

ActiveMQ

社区已经不活跃、进入了老年期