消息队列基础知识
消息队列场景
异步
下单系统付了钱后,搞了个扣减优惠券、又搞了个增减积分、再来个发短信,这样子搞下来流程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