一、消息队列简介
1、消息队列：是在消息的传输过程中保存消息的容器
2、当前使用较多的消息队列有：RabbitMQ、RocketMQ、ActiveMQ、ZeroMQ、MetaMQ、Kafka
二、消息队列的作用
1、异步处理
2、流量控制
3、服务解耦
三、消息队列的问题
1、系统复杂性
接口幂等（强校验、弱校验）
(2)消息丢失：请求确认机制
(3)消息的顺序消费
生产者：发送时要求用户在同一线程中采用同步的方式发送
消息队列：存储保持和发送的顺序一致，一般是在同一个分区中保持顺序性
消费者：一个分区的消息由一个线程来处理消费信息
2、数据一致性
解决：分布式事务：所有的服务都成功才能算这一次下单是成功的
例如：把下单，优惠券，积分。。。都放在一个事务里面一样，要成功一起成功，要失败一起失败。
分布式事务模型：
（1）2pc（两段式提交）
2pc（两段式提交）可以说是分布式事务的最开始的样子了，像极了媒婆，就是通过消息中间件协调多个系统，在两个系统操作事务的时候都锁定资源但是不提交事务，等两者都准备好了，告诉消息中间件，然后再分别提交事务。
如果A系统事务提交成功了，但是B系统在提交的时候网络波动或者各种原因提交失败了，其实还是会失败的。
3pc（三段式提交）
CC（Try、Confirm、Cancel）
例子：张三给李四转账100块钱
第一阶段就是try阶段，张三余额减100，然后张三有一个冻结字段，冻结字段加100，然后李四也有一个冻结字段，李四的冻结字段里加100，就是李四的余额，不是真正的加100
接下来如果是confirm，就把张三的冻结字段减掉100，这样的话数据就抹平了，余额少了100，然后李四的冻结字段减去100把冻结的这100加到李四的余额里，这就是confirm要做的事情。
如果说第一段有问题，那么，Cancel把try阶段做的那些事做一个逆操作。刚才不是让我余额减100吗？现在Cancel后余额加100，刚才冻结字段加了100？现在在冻结字段上减去100。那么李四的Cancel呢？刚才冻结字段加了100，现在让李四的冻结字段减了100 。
半消息/最终一致性（RocketMQ）
3、可用性
mq挂了，会影响到整个系统
四、消息队列的测试点
1、生产端：
MQ发送的时序问题：多个MQ发送时的先后顺序问题
MQ重复发送：同一个MQ是否在不同的地方多次；多次发送是否会有什么问题
MQ发送的消息体：消息体的内容是否发送完整；消息体的内容是否真正的满足所需条件
MQ发送的节点：MQ在什么时候发送；发送的时候前置条件是什么状态；具体有哪些状态可以做一个梳理
2、消费端
MQ消费的时间节点：MQ在什么时候进行消费；消费前的前置条件是什么
MQ消费的内部逻辑处理：MQ内部逻辑处理是否独立完整；消息处理在整个流程中的位置；消息处理的结果表现
