消息队列-解耦、异步、削锋

解耦

不使用MQ时

A系统发送数据到B、C、D系统，但没有使用消息队列时候的耦合场景

当后面系统不断增加，比如 E，F系统的加入，以及D系统的移除

因为A系统和其它各种系统耦合起来，那么需要处理的事情会给出多

使用MQ后

系统A发送一条消息，到消息队列中，哪个系统需要获取到哪里，那么从MQ中消费数据，如果新系统E加入的话，那么只需要编写代码，然后也直接从MQ中消费即可，当系统D不需要这个数据时，那么只需要不对该消息进行消费即可。系统A不需要考虑给谁发送数据，也不需要维护这个代码，不需要考虑人家是否调用成功、失败、超时等等情况

总结：通过一个MQ，发布和订阅模型（Pub/Sub模型），系统A就和其它系统彻底解耦。

需要考虑一下负责的系统中，是否有类似的场景，就是一个系统或者一个模块，调用了多个系统，互相之间的调用很复杂，维护起来很麻烦。但是其实这个调用是不需要同步调用接口的，如果用MQ给他异步化解耦，也是可以的，这个时候可以考虑在自己的项目中，是不是可以运用这个MQ来进行系统的解耦。

异步

不用MQ的同步高延时请求场景

下面的一个场景就是系统A，调用了其它三个系统的服务，我们发现用户在执行一个请求后，需要花费很长的时间

我们发现，用户执行一个接口，就需要花费350毫秒，假设我们将每个接口的耗时增加，可能会将近花费1秒，这个时候一般用户几乎不能接受，因为一般互联网类的企业，对用户的直接操作，一般要求是每个请求都必须在200ms以内完成，因为这个是对用户是无感知的

使用MQ进行异步化

系统A只需要发送消息到MQ中就直接返回了，然后其它系统各自在MQ中进行消费。用户在执行系统A的时候，就会感觉非常快就得到响应了。

削峰

没有用MQ的削峰

一般的MySQL，抗到QPS=2000的时候就已经达到了瓶颈，如果每秒请求达到了5000的话，可能直接就把MySQL打死了。如果MySQL被打死，然后整个系统就崩溃，然后系统就没法使用。

但是中午的高峰期过了之后，到下午的时候，就成了低峰期，可能也就一万用户同时在网站上操作，每秒的请求数量可能就50个请求，对整个系统几乎没有任何压力。

使用MQ来进行削峰

削峰就是大量的请求过来，然后MQ将其消化掉了，然后通过其它系统从MQ中取消息，在逐步进行消费，保证系统的有序运行。一般高峰期不会持续太长，在一段时间后，就会被下游系统消化掉。

 

上面已经说了：解耦、异步、削峰，缺点呢？显而易见的

• 系统可用性降低：系统引入的外部依赖越多，越容易挂掉，本来你就是A系统调用BCD三个系统接口就好了，人家ABCD四个系统好好的，没啥问题，这个时候却加入了MQ进来，万一MQ挂了怎么办？MQ挂了整套系统也会崩溃了。
• 系统复杂性提高：硬生生加个MQ进来，你怎么保证消息没有重复消费？怎么处理消息丢失的情况？怎么保证消息传递的顺序性？
• 一致性问题：A系统处理完了直接返回成功了，人都以为你的请求成功了，但是问题是，要在BCD三个系统中，BD两个系统写库成功了，结果C系统写库失败了，这样就会存在数据不一致的问题。
• 所以说消息队列实际上是一种复杂的架构，你引入它有好多好处，但是也得针对它带来的坏处做各种额外的技术方案和架构来规避掉，最后发现系统复杂性提升了一个数量级，也许是复杂10倍，但是关键时刻，用还是得用。

 

主流MQ包括：kafka、ActiveMQ、RabbitMQ和RocketMQ

常见的MQ其实就上面的四种

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，吞吐量比RocketMQ和Kafka要低一个数量级	万级，吞吐量比RocketMQ和Kafka要低一个数量级	10万级，RocketMQ也是可以支撑高吞吐的一种MQ	10万级1这是kafka最大的优点，就是吞吐量高。一般配置和数据类的系统进行实时数据计算、日志采集等场景
时效性	ms级	微妙级，这是RabbitMQ的一大特点，就是延迟最低	ms级	延迟在ms级内
可用性	基于主从架构实现高可用	高，基于主从架构实现高可用	非常高，分布式架构	非常高，kafka是分布式的，一个数据多个副本，少数机器宕机后，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	消息不丢失	经过参数优化配置，可以做到0丢失	经过参数优化配置可以做到0丢失
核心特点	MQ领域的功能及其完备	基于Erlang开发，所以并发能力强，性能及其好，延时很低	MQ功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，是实时上的标准。
	非常成熟，功能强大，在业内大量公司以及项目都有应用。 但是偶尔消息丢失的概率，并且现在社区以及国内应用都越来越少，官方社区对ActiveMQ5.X维护越来越少，而且确实主要是基于解耦和异步来用的，较少在大规模吞吐场景中使用	erlang语言开发的，性能及其好，延时很低。而且开源的版本，就提供的管理界面非常棒，在国内一些互联网公司近几年用RabbitMQ也是比较多一些，特别适用于中小型的公司 缺点显而易见，就是吞吐量会低一些，这是因为它做的实现机制比较中，因为使用erlang开发，目前没有多少公司使用其开发。所以针对源码界别的定制，非常困难，因此公司的掌控非常弱，只能依赖于开源社区的维护。	接口简单易用，毕竟在阿里大规模应用过，有阿里平台保障，日处理消息上 百亿之多，可以做到大规模吞吐，性能也非常好，分布式扩展也很方便，社区维护还可以，可靠性和可用性都是OK的，还可以支撑大规模的topic数量，支持复杂MQ业务场景。	仅仅提供较少的核心功能，但是提供超高的吞吐量，ms级别的延迟，极高的可用性以及可靠性，分布式可以任意扩展。 同时kafka最好是支撑较少的topic数量即可，保证其超高的吞吐量。

综上所述：

• 一般的业务要引入MQ，最早大家都是用ACviceMQ，但是现在大家用的不多了，没有经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了，不太图鉴使用
• RabbitMQ后面被大量的中小型公司所使用，但是erlang语言阻碍了大量的Java工程师深入研究和掌握它，对公司而言，几乎处于不可控的状态，但是RabbitMQ目前开源稳定，活跃度也表较高。
• RocketMQ是阿里开源的一套消息中间件，目前也已经经历了天猫双十一，同时底层使用Java进行开发

如果中小型企业技术实力一般，技术挑战不是很高，可以推荐，RabbitMQ。

如果公司的基础研发能力很强，想精确到源码级别的掌握，那么推荐使用RocketMQ。

同时如果项目是聚焦于大数据领域的实时计算，日志采集等场景，那么Kafka是业内标准