1.背景

有的公司本身的业务体量很小，所以直接单机一把梭啥都能搞定了，但是后面业务体量不断扩大，采用微服务的设计思想，分布式的部署方式，所以拆分了很多的服务，随着体量的增加以及业务场景越来越复杂，很多场景单机的技术栈和中间件已经不能胜任越来越繁重的业务量，而且对系统的友好性也下降了，最后做了很多技术选型的工作，决定引入消息队列中间件。

2.使用场景

说道使用场景我们要立刻它最主要的几个作用：异步、解耦、削峰。

1. 异步
   就举例我们生活中经常用到的下单操作，最原始的是不是下单然后支付流程就完毕。但是后面来了些产品需求经理什么的今天加个优惠券、明天加个积分、后天加个发送短信等等流程，告诉别人兄弟你下单成功，成功优化了多少钱，你本次加了多少积分等等。
   

如图随着业务的添加，我们的单次调用时长也是越来越长，系统响应速度变得越来越慢，用户的体验也会越来越差，就像两个轮的自行车能有四个轮的小汽车跑得快吗？？？如果当前用户为淘宝用户，会不会转向拼夕夕，我们这个系统有丢失客户的可能。

那怎么做才能若只如初见，复现出我们最开始的100ms，其实按照实际的用户体验我们知道，支付、优惠券、积分、消息发送都是并行的不存在先后关系，我们可以让其并行，提高响应速度。

2. 解耦
   我们引入中间件以后就可以达到真正的解耦，支付成功以后，我不用关心优惠券扣减成功没有，积分叠加没有，短信发送没有。我只用关注我的下单支付功能，但是实际的情况可能会有区别，我们操作数据就要保证数据的一致性，不能出现A扣完款成功，B加款失败；支付成功优惠券使用了，但是没有过期的情；这些都是在实际的下单支付过程中是不能出现的，所以这里就涉及到了分布式事务，只有当A生产的消息发送成功的情况我们才能通过事务管理机制告知A commit。
   

3. 削峰
   
   我们都知道秒杀活动吧，例如：我们正在进行一场秒杀活动，00 ：00的时候流量疯狂怼进来，你的服务器，Redis，MySQL各自的承受能力都不一样，你直接全部流量照单全收肯定有问题啊，你的服务器能不能支持太高的并发，如何保证你的机器处理数据的响应速度以及准确性，可能并发量太高机器处理不过来就直接挂掉了都有可能。那怎么办？
   简单，把请求放到队列里面，然后至于每秒消费多少请求，就看自己的服务器处理能力，你能处理10000QPS你就消费这么多，可能会比正常的慢一点，但是不至于压垮服务器，等流量高峰下去了，你的服务也就没压力了。
   你看阿里双十一12：00的时候这么多流量瞬间涌进去，他有时候是不是会慢一点，但是人家没挂啊，或者降级给你个友好的提示页面，等高峰过去了又是一条好汉了。

3.消息生产消费流程

1. A服务先发送个Half Message给Brock端，消息中携带 B服务 即将要+100元的信息。
2. 当A服务知道Half Message发送成功后，那么开始第3步执行本地事务。
3. 执行本地事务(会有三种情况1、执行成功。2、执行失败。3、网络等原因导致没有响应)
4. 如果本地事务成功，那么Product像Brock服务器发送Commit,这样B服务就可以消费该message。
5. 如果本地事务失败，那么Product像Brock服务器发送Rollback,那么就会直接删除上面这条半消息。
6. 如果因为网络等原因迟迟没有返回失败还是成功，那么会执行RocketMQ的回调接口,来进行事务的回查。