MQ消息中间件选型

我们在做架构的时候经常面临各种技术框架的选型，其中消息队列基本上对于一些高并发的互联网项目是必不可少的，那么话说回来我们在做消息队列选型的时候是否问过如下几个问题呢？

• 为什么使用消息队列啊？

• 消息队列有什么优点和缺点啊？

• kafka、activemq、rabbitmq、rocketmq都有什么区别以及适合哪些场景？

如果你思考过如上几个问题，那么恭喜你，你正在向一个合格的架构师迈进。很多时候不要因为使用而使用，你要清楚的知道为什么要使用，能解决什么样的问题等。 

（1）我之前面试就见过有一部分候选人，说自己项目里用了redis、mq，但是一问其实他都并不知道自己为什么要用这个东西。其实说白了，就是为了用而用，或者是别人设计的架构，他从头到尾没思考过。没有对自己的架构问过为什么的人，一定是平时没有思考的人。（希望你不要成为这种人 haha）

（2）另外就是你要思考系统中引入消息队列之后会不会有什么坏处？你要是没考虑过这个，那你盲目弄个MQ进系统里，后面出了问题你能不能解决，解决花费的代价有多大？你要是没考虑过引入一个技术可能存在的弊端和风险，那就是在给自己和同事挖坑了。

（3）然后就是既然用了MQ，那么具体是哪一种MQ，当时做没做过调研呢？ 

 

千万别傻乎乎的自己拍脑袋看个人喜好就瞎用了一个MQ，比如kafka。甚至都从没调研过业界到底流行的MQ有哪几种？每一个MQ的优点和缺点是什么？每一个MQ没有绝对的好坏，但是就是看用在哪个场景可以扬长避短，利用其优势，规避其劣势。

那么接下来针对以上3个问题做一下简单剖析

 （1）为什么使用消息队列？

先说一下消息队列的常见使用场景，其实场景有很多，但是比较核心的有3个：解耦、异步、削峰

解耦：

未采用MQ时系统间的调用案例：A系统发送个数据到BCD三个系统，接口调用发送，那如果E系统也要这个数据呢？那如果C系统现在不需要了呢？现在A系统又要发送第二种数据了呢？A系统负责人濒临崩溃中。。。再来点更加崩溃的事儿，A系统要时时刻刻考虑BCDE四个系统如果挂了咋办？我要不要重发？我要不要把消息存起来？头发都白了啊。。。

 

采用MQ解耦后的效果图如下：系统A并不在关心谁需要使用它的数据，往MQ中一扔，谁要用自己去取就是了。即通过MQ后系统A与其它各系统之间彻底解耦了。

 

异步：

未采用MQ异步时的调用案例：A系统接收一个请求，需要在自己本地写库，还需要在BCD三个系统写库，自己本地写库要3ms，BCD三个系统分别写库要300ms、450ms、200ms。最终请求总延时是3 + 300 + 450 + 200 = 953ms，接近1s，用户感觉搞个什么东西，慢死了慢死了。

 

采用MQ异步时的效果如下图：系统A将请求发送给MQ，其它个系统通过后台线程各自去执行即可，系统A不用管等待直接返回，给用户的感觉将是瞬间响应，极大的提升了用户体验。

 

削峰：

未采用MQ削峰时的案例：每天0点到11点，A系统风平浪静，每秒并发请求数量就100个。结果每次一到11点~1点，每秒并发请求数量突然会暴增到1万条。但是系统最大的处理能力就只能是每秒钟处理1000个请求啊。。。尴尬了，系统会死。。。

 

采用了MQ削峰时的效果图如下：将高并发下的大量请求压入MQ中，减少了服务器的压力，防止数据库服务器直接被大流量打死，从而造成整个系统宕机。

（2）消息队列有什么优点和缺点啊？

优点上面已经说了，就是在特殊场景下有其对应的好处，解耦、异步、削峰 。

缺点呢？显而易见的有如下几个方面：

 

系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统的接口就好了，人ABCD四个系统好好的，没啥问题，你偏加个MQ进来，万一MQ挂了咋整？MQ挂了，整套系统崩溃了，你不就完了么。 

 

系统复杂性提高：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？头大头大，问题一大堆，痛苦不已。 

 

一致性问题：A系统处理完了直接返回成功了，人都以为你这个请求就成功了；但是问题是，要是BCD三个系统那里，BD两个系统写库成功了，结果C系统写库失败了，咋整？你这数据就不一致了。 

 

tip：对于以上所说的缺点，系统可用性降低、系统复杂性提高、一致性问题将在后续文章中依次解答，持续关注公众号“虾米聊吧”

 

所以消息队列实际是一种非常复杂的架构，你引入它有很多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，可能系统复杂度提升了一个数量级，也许是复杂了10倍。但是关键时刻，用，还是得用的。。。 

 

（3）kafka、activemq、rabbitmq、rocketmq都有什么优点和缺点啊？

常见的MQ其实就这几种，别的还有很多其他MQ，但是比较冷门的，那么就别多说了

作为一个码农，你起码得知道各种mq的优点和缺点吧，咱们来画个表格看看   

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

  综上所述，各种对比之后，我个人倾向于是： 

对于RabbitMQ，由于是erlang语言阻止了大量的java工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实是开源的，比较稳定的支持，活跃度也高。

不过现在确实越来越多的公司，会去用RocketMQ，确实很不错，对自己公司技术实力有绝对自信的，我推荐用RocketMQ，否则就用RabbitMQ吧，毕竟活跃开源社区，也不那么复杂。

所以中小型公司，技术实力较为一般，技术挑战不是特别高，用RabbitMQ是不错的选择；大型公司，基础架构研发实力较强，用RocketMQ是很好的选择。 

如果是大数据领域的实时计算、日志采集等场景，用Kafka是业内标准的，绝对没问题，社区活跃度很高，何况几乎是全世界这个领域的事实性规范。

  参考：石杉笔记

 

关注微信公众号“虾米聊吧”，后续持续放送“技术架构”干货！！！

一个热衷于分享技术和生活的程序猿，让我们一起交流吧~                                                     微信扫描二维码，关注我的公众号