（二）如何进行MQ技术选型
常见的MQ有ActiveMQ RabbitMQ RocketMQ Kafka
先来了解各自的特点
特性 | ActiveMQ | RabbitMQ | RocketMQ | Kafka |
单机吞吐量 | 万级 | 万级 | 10万级 | 10万级 |
topic数量对吞吐量的影响 | topic可以达到几百几千个的级别，吞吐量会有较小幅度的下降。这是RocketMQ的一大优势，在同等机器下，可以支撑大量的topic | topic从几十个到几百个的时候，吞吐量会大幅度下降。所以在同等机器下，kafka尽量保证topic数量不要过多。如果要支撑大规模topic，需要增加更多的机器资源 | ||
时效性 | ms级 | 微秒级，延迟是最低的 | ms级 | ms级以内 |
可用性 | 高，基于主从架构实现高可用 | 高，基于主从架构实现高可用 | 非常高，分布式架构 | 非常高，天然分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用 |
消息可靠性 | 有较低概率丢失数据 | 经过参数优化配置可以做到0丢失 | 经过参数优化配置可以做到0丢失 | |
功能支持 | 功能极其完备 | 基于erlang开发，并发能力很强，性能极好，延时很低 | 功能较为完善，并且是分布式的，扩展性好 | 功能较为简单，在大数据领域的实时计算和日志采集被大规模应用，是事实上的标准 |
优劣势总结 | 非常成熟，功能强大，在业内大量的公司以及项目中都有应用偶尔会有较低概率丢失消息而且现在社区以及国内应用都越来越少，官方社区现在对ActiveMQ 5.x维护越来越少，几个月才发布一个版本而且确实主要是基于解耦和异步来用的，较少在大规模吞吐的场景中使用 | erlang语言开发，性能极其好，延时很低；吞吐量到万级，MQ功能比较完备而且开源提供的管理界面非常棒，用起来很好用社区相对比较活跃，几乎每个月都发布几个版本分在国内一些互联网公司近几年用rabbitmq也比较多一些但是问题也是显而易见的，RabbitMQ确实吞吐量会低一些，这是因为他做的实现机制比较重。而且erlang开发，国内有几个公司有实力做erlang源码级别的研究和定制？如果说你没这个实力的话，确实偶尔会有一些问题，你很难去看懂源码，你公司对这个东西的掌控很弱，基本职能依赖于开源社区的快速维护和修复bug。而且rabbitmq集群动态扩展会很麻烦，不过这个我觉得还好。其实主要是erlang语言本身带来的问题。很难读源码，很难定制和掌控。 | 接口简单易用，而且毕竟在阿里大规模应用过，有阿里品牌保障日处理消息上百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是ok的，还可以支撑大规模的topic数量，支持复杂MQ业务场景而且一个很大的优势在于，阿里出品都是java系的，我们可以自己阅读源码，定制自己公司的MQ，可以掌控社区活跃度相对较为一般，不过也还可以，文档相对来说简单一些，然后接口这块不是按照标准JMS规范走的有些系统要迁移需要修改大量代码还有就是阿里出台的技术，你得做好这个技术万一被抛弃，社区黄掉的风险，那如果你们公司有技术实力我觉得用RocketMQ挺好的 | kafka的特点其实很明显，就是仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级的延迟，极高的可用性以及可靠性，而且分布式可以任意扩展同时kafka最好是支撑较少的topic数量即可，保证其超高吞吐量而且kafka唯一的一点劣势是有可能消息重复消费，那么对数据准确性会造成极其轻微的影响，在大数据领域中以及日志采集中，这点轻微影响可以忽略这个特性天然适合大数据实时计算以及日志收集 |
总结一下
ActiveMQ是大家最早使用的，但是现在社区活跃度不高，而且没有经过大规模吞吐量场景的考验，建议新项目中就不要使用了
RabbitMQ可以推荐用一下，唯一的缺点是开发语言是erlang，国内会这个的比较少，缺少定制开发的能力
RocketMQ也可以使用一下，开发语言是java，背景是阿里。正是由于是阿里开源的产品，所以可能有黄掉的风险
Kafka在大数据领域的实时计算、日志采集等场景是业内标准，没有选择其他的理由。但是在普通的业务场景，这个不建议使用
so，对于互联网大多数业务场景最终只能在RabbitMQ和RocketMQ中做个选择了，到时候再根据具体情况和团队成员的掌握程度来决定吧
