消息中间件(一)——MQ的优缺点及各个消息中间件的比较

1、什么是MQ

       消息队列（MQ）是一种应用程序对应用程序的通信方法。应用程序通过写和检索出入列队的针对应用程序的数据（消息）来通信，而无需专用连接来链接它们。

       上面的这个是百度百科对MQ的定义，简单来说MQ就是用来系统之间进行数据传递的。比如：A系统和B系统之间要进行消息传递，我们常用的方式可能是某一个系统提供一个接口，另一个系统调用该接口来传递数据，从而满足业务需求。但是，更好的方式是使用消息队列来实现。假设A系统需要向B系统传递消息，那么A系统可以向消息队列中写入一条消息，而B系统则可以监听消息队列，当有消息的时候，B系统可以从消息队列中取出该消息进行消费。

2、MQ的优点

       可能你会问：明明通过调用接口就可以进行系统之间的交流了，为什么还要用MQ呢？使用MQ当然有他的好处的，主要的好处是三点：解耦、异步和削峰。

2.1、解耦

我们通过使用MQ可以进行系统之间的解耦，使得系统之间的耦合度比较低。这也符合高内聚，低耦合的原则。不过首先我们可以先讲下通过接口调用有什么样的坏处。

2.1.1 接口调用的耦合度高

从这个图可以看出，系统之间的依赖度高，每多一个系统或者少一个系统，系统A都需要做修改。对于系统A的人员来说，工作量大，难以维护。

2.1.2 MQ解耦的原理

       从图中可以看出，在系统中引入了MQ之后，各个系统之间的耦合度降低了。系统之间不再通过接口之间调用，系统A只负责生成消息，把消息保存到MQ，不用管谁来消费消息。而其他系统如果需要系统A的消息，只要监听到响应的队列，就能从对列中取出消息。

 

2.2 异步

2.2.1 接口调用情况

从上可以看出，如果是接口调用的情况，每次请求都需要A调用完成BCD系统之后，用户才能收到回应，而且时间比较久。这对于用户来说，比较难以接受的。

2.2.2 MQ的异步作用

上图，当用户向系统A发起一次请求，系统A处理完成之后，就会向用户响应结果。后续的处理由BCD系统去MQ中拉取消息并消费。这样，用户的体验很好，不需要等待BCD系统的处理逻辑了，起到了异步的效果。

 

2.3 削峰

       我们都知道，系统不是每时每刻都是并发量很大的，但是，系统又必须要能扛住某个时候的峰值。比如很多电商网站，平时的请求量并不多，但是到了晚上下班了，客户访问量就会增多，特别是在双十一的时候，客户访问量暴增，此时如果系统不能扛住的话，那就麻烦了，老板肯定会损失不少。所以，面对这种峰值，是对系统的考验。如果不使用MQ，那么系统可能就崩了，下面我们就以单机服务器（tomcat）来分析：

2.3.1 不使用MQ的情况

在不使用MQ的时候，如果系统不能抗住峰值请求，那么系统就会瘫痪掉了。当然我们也可以增加服务器的数量，搭集群，这样肯定满足需求，但是这样就增加了成本。而且也是资源的浪费，因为这种峰值时候是相当少的。所以这种方式不太可取。

2.3.2 MQ处理峰值

在电商系统中，MQ用来处理峰值请求很常见，现时秒杀也用到了MQ。

 

3、MQ的缺点

1、系统可用性降低。比如在系统中引入MQ，那么万一MQ挂了怎么办呢？一旦MQ挂了，那么系统之间的通信就完全断开了，导致了系统不可用。这在实际情况中，是有这种情况发生的。一般而言，引入的外部依赖越多，系统越脆弱，每一个依赖出问题都会导致整个系统的崩溃。
2、系统复杂度提高。本来系统直接通过接口调用就可以了的，如果引入了MQ之后，就需要考虑MQ的各种情况，比如：消息的重复消费、消息丢失、保证消费顺序等等......，使得系统越来越复杂。
3、数据一致性问题。比如A系统已经给客户返回操作成功，这时候操作BC都成功了，操作D却失败了，导致数据不一致。

       所以在软件的正常功能开发中，并不需要去刻意的寻找消息队列的使用场景，而是当出现性能瓶颈时，去查看业务逻辑是否存在可以异步处理的耗时操作，如果存在的话便可以引入消息队列来解决。否则盲目的使用消息队列可能会增加维护和开发的成本却无法得到可观的性能提升，那就得不偿失了。

4、ActiveMQ、RabbitMQ、RocketMQ和Kafka比较

特性	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功能
优势	非常成熟，功能强大，在业内大量公司和项目中都有应用	erlang语言开发，性能极好、延时很低，吞吐量万级、MQ功能完备，管理界面非常好，社区活跃；互联网公司使用较多	接口简单易用，阿里出品有保障，吞吐量大，分布式扩展方便、社区比较活跃，支持大规模的topic、支持复杂的业务场景，可以基于源码进行定制开发	超高吞吐量，ms级的时延，极高的可用性和可靠性，分布式扩展方便
劣势	偶尔有较低概率丢失消息，社区活跃度不高	吞吐量较低，erlang语言开发不容易进行定制开发，集群动态扩展麻烦	接口不是按照标准JMS规范走的，有的系统迁移要修改大量的代码，技术有被抛弃的风险	有可能进行消息的重复消费
应用	主要用于解耦和异步，较少用在大规模吞吐的场景中	都有使用	用于大规模吞吐、复杂业务中	在大数据的实时计算和日志采集中被大规模使用，是业界的标准

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

开发中，该选择哪种消息中间件，下面给出几点小建议：

1、ActiveMQ已经不推荐使用了，因为社区活跃度很低，没什么人再去维护了。一旦使用过程中出现了问题，比较难以找到解决办法；

2、RabbitMQ现在是使用的比较多的，吞吐量也达到了万级，而且延时低，最好的一个优点就是它提供了一个后台管理系统，对于中小型公司来说很有用的；同时目前来看，社区活跃度也比较高。缺点就是开发语言使用的是erlang语言，对于Java开发者来说，erlang语言比较难以看懂，不能去深入的研究，只能简单的使用。

3、RocketMQ的阿里开源的，现在社区也比较活跃，并且是用Java语言开发的，支持分布式集群。但是有被弃用的风险，一旦阿里什么时候不维护了，那么就有可能被废弃掉。如果是有能力大公司还好，可以自己去钻研源码，自己维护，如果是小公司的话，那么就被坑了。

4、Kafka主要用在大数据领域。它的主要优点就是吞吐量大，同时也是分布式的。