初识消息队列

一. Why MQ？

    消息队列是软件开发中常见的技术，那么何时应该使用消息队列？或者说消息队列有哪些好处呢?

    1. 异步处理

    ​    ​你做过的服务有没有遇到过这种情况？只是简单的一个post请求添加一条数据，却不得不增加统计分析、短息提醒、微信提醒等等其他对用户来说不必要的处理？这个时候整个流程都是同步的，大大的增加了接口返回的时间，使得用户交互的体验感变差！这种情况下可以考虑使用MQ，让接口只做两件事：（1）添加一条数据；（2）将数据写入MQ等待其他服务拉取。这样一来，我们的接口就变成了异步处理，避免了在主要业务（添加数据）中混入了大量的不必要业务（统计分析等）。

    ​2. 流量控制

    ​    ​当做一个类似于秒杀系统的服务时，流量短时间内蜂拥而至，这时候如果服务的自我保护机制不够健壮，很可能会拖垮服务器。因此，我们可以使用MQ连接网关和后台服务将后端的服务保护起来。网关接受到请求以后，将请求写入MQ，后端服务在根据其最大处理能力从MQ中获取请求 然后再将返回值返回给客户端。对于那些超时的操作可以当作秒杀失败来处理即可。

    ​    ​不过这样做也是有一些代价的：（1）增加了系统的调用链环节；（2）上下游都需要将同步操作变成异步操作

    ​3. 服务解耦

    ​    ​还是用第一个例子，如果采用统计分析、短息提醒等服务在post主服务中异步调用的方式好不好呢？它也可以实现异步调用的目的。答案是：不够好！为什么呢？随着业务增长，下游服务不断增加、修改，这时任何一个服务的变更都要整个服务模块重新上线 维护起来非常麻烦。引入消息队列后，所有的下游服务都订阅一个主题，上下游服务之间不需要知道彼此的存在，无论是删除一个下游服务还是增加一个下游服务都是极其容易的。

 

二. How to choice MQ?

    ​现在我们知道了使用消息队列的好处：异步处理、流量控制、服务解耦。然后我们谈谈如何选择一个消息队列组件。  

    ​选择消息队列组件的基本标准：（1）开源（2）社区活跃度（3）消息传输可靠性（4）cluser集群（5）性能

    ​接下来我们一起看一下有哪些符合上面这些条件，可供选择的开源消息队列：

    ​1. RabbitMQ

    ​    ​RabbitMQ的特点是轻量级、迅捷，它的口号是开箱即用，非常容易部署和使用。另一个特色是，RabbitMQ支持非常灵活的路由配置，与其他消息队列不同的是，它在生产者和队列中间加了一个Exchange模块（类似交换机）。

    ​    ​Exchange模块会根据配置的路由规则将生产者发出的消息分发给不同的队列。路由规则非常灵活，甚至可以自己来实现路由规则。

    ​    ​RabbitMQ的客户端支持的编程语言也十分多，如果后端是用比较冷门的语言开发的话，那么多半可以找到对应的RabbitMQ客户端。

    ​    ​RabbitMQ的设计理念里，消息队列是一个管道，大量的堆积消息是一种不正常的情况，所以它对消息堆积的支持并不好，会引发性能的急剧下降。

    ​    ​RabbitMQ的性能也比较差，大概每秒钟可以处理几万到十几万条消息。

    ​    ​最后一个问题是RabbitMQ使用的语言是Erlang，是十分小众的，很难基于RabbitMQ做扩展和二次开发。

    ​2. RocketMQ

    ​    ​RocketMQ是阿里在2012年开源的产品，RocketMQ是一个比较全面的消息队列，有着不错的性能、可靠性、稳定性。

    ​    ​RocketMQ有强大的中文社区支持。

    ​    ​RocketMQ在线上业务做了极致的优化，大多数情况下可以做到毫秒级的响应。

    ​    ​RocketMQ每秒钟可以处理几十万条消息。

    ​    ​RocketMQ作为一个国产应用，与周边生态系统的集成和兼容程度要略逊一筹。

    ​3. kafka

    ​    ​早期的kafka为了获得极致的性能，在设计方面做了很多牺牲，比如不支持消息的可靠传输，也不支持集群，功能上也比较简陋。这些对于其诞生的初衷--处理海量日志这个特定场景是可以接受的。但是，随后几年，kafka不断完善，逐渐补全了这些短板，现在的kafka已经是比较成熟的消息队列，在性能、可靠性、稳定性上都有着不错的表现。

    ​    ​kafka是与周边生态环境最好的，尤其是在大数据和流处理上，几乎所有开源软件系统都会优先支持kafka。

    ​    ​kafka使用scala和java开发，设计上大量的使用了批量和异步的思想。这种设计使得kafka有超高的性能，它的性能尤其是异步收发的性能是三款应用中最好的。但和RocektMQ没有量级上的差距，也是一秒钟处理几十万条消息。

    ​    ​kafka由于使用了批量处理的机制，可以得到更好的性能，但是也会增加同步收发消息的延时。因为当客户端发出一条消息后，kafka不会马上处理，而是积攒到一定数据量时再处理。在业务场景中，每秒钟的消息没那么多的时候，采用kafka反而会增加延时，所以kafka不适用于线上业务场景。

    ​4. 其他

    ​    ​ActiveMQ：最早的消息队列，已经进入老年期，社区不活跃，功能和性能较其他消息队列有很大差距，新项目并不会采用ActiveMQ，其存在的意义仅是维护那些老产品。

    ​    ​ZeroMQ：基于消息队列的多线程网络库，如果你的需求是将消息队列集成到你的系统进程中，那么可以试试它。

    ​    ​Pulsar：一个新兴的消息队列产品，目前还处于成长期，成熟度、流行度还不高。Pulsar采用的是存储和计算分离的设计模式，它很可能会引导未来消息队列的发展方向。

 

​