MQ消息队列的应用场景、特点及选型

消息队列基础知识

消息队列场景

异步

下单系统付了钱后，搞了个扣减优惠券、又搞了个增减积分、再来个发短信，这样子搞下来流程RT(ResponseTime)响应就慢了，怎么办呢？

大概是这样的

异步，在下单支付成功后，发消息，让其它系统去处理，整个链路是这样的。

解耦

订单流程，扣积分，扣优惠券，发短信，去库存。。。每次加一个你就要调用一个接口然后还要重新发布系统，耦合性太差了。所以通过MQ解耦，各系统做系统的事。

削峰

比方说秒杀，平时流量很低，做秒杀活动时，流量很大，突然怼进来了，服务器，Redis,Mysql各自承受能力不一样，如果全部流量照单全收，必然会挂。

所以呢，把请求放在MQ队列里面，至于每秒消费多少，取决于服务器处理能力。比方说能处理5000QPS,那就每秒消费这么多，稍微比正常的慢一点，不至于打挂服务器，等流量高峰下去了，服务也就没压力。

事务消息

下单了，支付成功的消息通过事务消息告诉周边系统，各自去处理，要是下单挂了，周边系统也就不会收到下单成功的消息。如果是周边系统异常了，那也不影响下单程序嘛，让其它系统的开发去负责排查了。各自管各自的系统嘛。

消息队列的三个特点

系统复杂性

怎么讲呢，就是说一个简单的系统，你引入消息中间件，就得考虑消息的重复消费、消息丢失、消息的顺序消息等情况。

数据一致性

分布式服务本身存在一个问题，不仅仅是消息队列的问题。只是说数据一致性这个问题比较严重。

怎么严重呢？比方说，你下单的服务保证自己成功了，成功发了消息，其它系统成功还是失败，你就不管了吗？

显然这样不好，所以呢，这里要提下分布式事务，把下单、优惠券、库存、积分系统都放在一个事务里，要成功都成功，要失败都失败。

可用性

消息集群多Master多Slave,同步刷盘

消息组件那么多，如何选呢？

比较主流的消息中间件有Kafa、ActiveMQ、RabbitMQ、RocketMQ等。。。

Kafa、RocketMQ在国内挺火的，很多大公司都在用。

下面再从网上找的图对比下四大消息中间件的区别：

延伸阅读

对RocketMQ感兴趣的同学，点击下方链接延伸阅读：

RocketMQ事务消息原理解析：https://blog.csdn.net/Bao_jingyu/article/details/104726534

基于Docker部署RocketMQ双主双从异步集群搭建：https://blog.csdn.net/Bao_jingyu/article/details/105359418