消息队列 MQ

介绍

消息队列可以看作是一个消息容器，将消息缓存至这个容器再进行处理；可以对系统进行解耦、异步以及削峰。目前使用较多的消息队列有ActiveMQ，RabbitMQ，Kafka，RocketMQ。
解耦：例如有A系统，同时需要向BCD系统发送消息。一方面会增加系统复杂度，如果新增一个系统E需要A系统的信息，并且C系统希望取消A系统发送的消息，那么就会增加A系统的复杂度。因此提供一个MQ，利用其提供的发布订阅消息功能，A将信息直接发送给MQ，BCDE系统根据需要直接从MQ中取得数据即可，解放了A系统，不需要再考虑消息的发送。
异步：例如A系统接受请求，需要对请求进行处理10ms，同时还需要将这个信息发送给BCD系统再处理，同时可能BCD系统忙碌，处理时间花费300ms，A系统等待BCD处理完再反馈给用用户，那么等待时间将会很长，达到300*3+10=910ms。如果A系统接受消息请求后，自行处理10ms，再花费10ms将消息发送给MQ，不需要实时等待BCD系统响应，而BCD通过MQ取得信息，后台异步处理。那么用户接收到A系统的响应仅需要10+10=20ms。大大提升了响应速度。
削峰：主要体现在MQ极大的缓存能力上。比如某网站在某一段时间内有很大的请求量，比如达到5w条，而网站后台系统处理极限仅有2w，那么如果不对请求进行缓存处理，系统将会有崩溃的风险。采用MQ，将请求缓存至消息队列中，后台系统按照2w的速度从MQ中取出数据进行处理，缓解后台压力。

优缺点

优点：解耦、异步、削峰；
缺点：

• 系统可靠性降低：MQ有崩溃出错的可能性，比如MQ数据一致性、重复问题；
• 系统复杂度增加：增加了一个中间件，相应的配套设计也会有所增加，同时需要对MQ进行维护；
• 可用性降低：如何保证消息队列的高可用，可以点击这里查看

特性	Topic	Queue
概要	Publish Subscribe messaging 发布订阅消息	Point-to-Point 点对点
有无状态	topic数据默认不落地，是无状态的。	Queue数据默认会在mq服务器上以文件形式保存，比如Active MQ一般保存在$AMQ_HOME\data\kr-store\data下面。也可以配置成DB存储。
完整性保障	并不保证publisher发布的每条数据，Subscriber都能接受到。	Queue保证每条数据都能被receiver接收。
消息是否会丢失	一般来说publisher发布消息到某一个topic时，只有正在监听该topic地址的sub能够接收到消息；如果没有sub在监听，该topic就丢失了。	Sender发送消息到目标Queue，receiver可以异步接收这个Queue上的消息。Queue上的消息如果暂时没有receiver来取，也不会丢失。
消息发布接收策略	一对多的消息发布接收策略，监听同一个topic地址的多个sub都能收到publisher发送的消息。Sub接收完通知mq服务器	一对一的消息发布接收策略，一个sender发送的消息，只能有一个receiver接收。receiver接收完后，通知mq服务器已接收，mq服务器对queue里的消息采取删除或其他操作。

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级，比 RocketMQ、Kafka 低一个数量级	同 ActiveMQ	10 万级，支撑高吞吐	10 万级，高吞吐，一般配合大数据类的系统来进行实时数据计算、日志采集等场景
topic 数量对吞吐量的影响			topic 可以达到几百/几千的级别，吞吐量会有较小幅度的下降，这是 RocketMQ 的一大优势，在同等机器下，可以支撑大量的 topic	topic 从几十到几百个时候，吞吐量会大幅度下降，在同等机器下，Kafka 尽量保证 topic 数量不要过多，如果要支撑大规模的 topic，需要增加更多的机器资源
可用性	高，基于主从架构实现高可用	同 ActiveMQ	非常高，分布式架构	非常高，分布式，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
消息可靠性	有较低的概率丢失数据	基本不丢	经过参数优化配置，可以做到 0 丢失	同 RocketMQ
功能支持	MQ 领域的功能极其完备	基于 erlang 开发，并发能力很强，性能极好，延时很低	MQ 功能较为完善，还是分布式的，扩展性好	功能较为简单，主要支持简单的 MQ 功能，在大数据领域的实时计算以及日志采集被大规模使用

一般的业务系统要引入 MQ，最早大家都用 ActiveMQ，但是现在确实大家用的不多了，没经过大规模吞吐量场景的验证，社区也不是很活跃，所以大家还是算了吧，我个人不推荐用这个了；
后来大家开始用 RabbitMQ，但是确实 erlang 语言阻止了大量的 Java 工程师去深入研究和掌控它，对公司而言，几乎处于不可控的状态，但是确实人家是开源的，比较稳定的支持，活跃度也高；
不过现在确实越来越多的公司会去用 RocketMQ，确实很不错，毕竟是阿里出品，但社区可能有突然黄掉的风险（目前 RocketMQ 已捐给 Apache，但 GitHub 上的活跃度其实不算高）对自己公司技术实力有绝对自信的，推荐用 RocketMQ，否则回去老老实实用 RabbitMQ 吧，人家有活跃的开源社区，绝对不会黄。
所以中小型公司，技术实力较为一般，技术挑战不是特别高，用 RabbitMQ 是不错的选择；大型公司，基础架构研发实力较强，用 RocketMQ 是很好的选择。
如果是大数据领域的实时计算、日志采集等场景，用 Kafka 是业内标准的，绝对没问题，社区活跃度很高，绝对不会黄，何况几乎是全世界这个领域的事实性规范。