目录儿
- 常见MQ
- RocketMQ
- 2、`RocketMQ`测试可用
- MQ常见问题
- 1、幂等性问题
- 2、如何保证消息不丢失
- 3、消息积压问题
- 4、事务消息设计分析
常见MQ
RocketMQ
RocketMQ又四部分组成
- NameServer 同步Broker服务信息，给消费者和生产者提供可用Broker的服务信息。
- Broker 消息存储业务核心
- Producer 消息生产者
- Consumer 消息消费者
先启动
NameServer作为注册中心，然后再启动Broker服务。
2、RocketMQ测试可用
在RocketMQ的安装包中，提供了一个tools.sh工具可以用来在命令行快速验证RocketMQ服务。进入RocketMQ的安装目录：
① 首先需要配置一个环境变量NAMESRV_ADDR指向我们启动的NameServer服务。
export NAMESRV_ADDR='localhost:9876'
② 然后执行工具脚本，启动消息生产者发送消息：默认会发1000条消息
bin/tools.sh org.apache.rocketmg.example.quickstart.Producer
③ 然后执行工具脚本，然后启动消息消费者接收消息
bin/tools.sh org.apache.rocketmg.example.quickstart.Consumer
成功了表单机服务就搭建好了
MQ常见问题
1、幂等性问题
通常。客户端调用服务端接口是通过http协议来调取的，不安全且整个调用过程是一个同步过程。服务端处理业务逻辑比较耗时没有及时响应的情况下，于服务端而言产生了请求堆积，可能会造成 服务雪崩。于客户端会造成阻塞等待、超时断开 自动重试，这样服务器端接口就在一段时间内接收到了n个相同的请求，产生了 幂等性问题
如何防止幂等性问题，通用做法：
- 如表单重复提交、add表数据，可以用全局id做唯一约束
- 如重复update表数据，可以用版本号防止重复修改，每次修改都基于版本号
- 幂等性：
所谓的幂等性，是分布式环境下的一个常见问题，一般是指我们在进行多次操作时，所得到的结果是一样的，即多次运算结果是一致的(同一个业务逻辑重复执行多次最终只算一次)。
也就是说，用户对于同一操作，无论是发起一次请求还是多次请求，最终的执行结果是一致的，不会因为多次点击而产生副作用。- 常见幂等性操作：
- select查询天然幂等；
- delete删除也是幂等，删除同一个数据多次其效果一样;
- update直接更新某个值时，幂等；
- update更新累加操作的的结果，非幂等；
- insert操作会每次都新增一条，非幂等；
- 什么情况下会产生重复提交(非幂等性)：
- 连续点击提交两次按钮；
- 点击刷新按钮；
- 使用浏览器后退按钮重复之前的操作，导致重复提交表单；
- 使用浏览器历史记录重复提交表单；
- 浏览器重复地HTTP请求等。
2、如何保证消息不丢失
引入MQ消息中间件最直接的目的是：做系统解耦合流量控制，追其根源还是为了解决互联网系统的高可用和高性能问题
引入MQ虽然实现了系统解耦合流量控制，也会带来其他问题
其中保证数据传输的一致性就是保证消息不丢失的关键
消息从生产到消费不同环节发生消息丢失对应的原因不同，解决方案也不同，所以要分开来说
上面三个环节的解决方案看似完美，但在分布式系统中，常常出现各种故障，且不可避免，所以还是需要一种机制，来检查消息是否丢失
总体方案思路：
在消息生产端，给每个发出的消息都指定一个全局唯一D或者附加一个连续递增的版本号，然后在消费端做对应的版本校验
具体实现思路1：
可以利用拦截器机制，在生产端发送消息之前，通过拦截器将消息版本号注入消息中，然后在消费端收到消息后，再通过拦截器检测版本号的连续性或消费状态，这样实现的好处是消息检测的代码不会侵入到业务代码中，可以通过单独的任务来定位丢失的消息，做进一步的排查
不同的唯一ID生成方案也会有不同的问题存在，没有完美的方案。
3、消息积压问题
如果出现积压，那一定是性能问题，想要解决消息从生产到消费上的性能问题就首先要知道哪些环节可能出现消息积压，然后在考虑如何解决。
因为消息在生产并发送到Broker之后才会出现积压问题，所以问题不在生产端，而又因为在绝大部分消息队列单节点性能都能达到几万/s的处理能力，所以问题大概率也不在存储端上。所以性能问题绝大多数出现在消费端。
应急处理方案：
如果是线上突发问题，就要临时扩容，增加消费端的数量(水平扩容)，与此同时，还可以降级一些非核心的业务，通过扩容和降级抗住流量。
扩容的同时要增加分区，防止扩容失效。
逻辑优化方案：
排查解决异常问题，比如通过查看监控，日志等手段分析是否消费端的业务逻辑代码出现了问题，进而优化消费端的业务处理逻辑，提升消费能力。
4、事务消息设计分析
如下场景：用户操作下单，我们首先需要生成一条订单信息，然后库存系统需要针对订单中的商品进行库存扣减的操作。这两步操作必须保证数据的一致性，否则会出现库存超扣等情况。
第一种情况如图所示，在本地事务提交前发送事务消息。若在创建订单信息时发生了异常，而此时事务消息已经成功发送，库存系统消费事务消息就会导致订单并没有创建成功，而库存却被扣减。
进而有了第二种情况，如图所示，在本地事务提交完成后再发送事务消息。若在发送事务消息的过程发生了异常，如网络波动等等，将会出现订单已创建完成，而库存系统永远也监听不到消息，导致库存无法正常扣减。
综合第一和第二种情况，汇总成第三种方案如图所示。在本地事务执行前，先向MQ发送前置的Prepared消息，在本地事务执行完毕后，再发送确认的消息，告知MQ当前事务消息需提交/回滚。如果事务正常则提交消息，那么这条消息将会被消息消费方监听到；如果事务回滚，MQ会丢弃这条消息，消息消费方无法监听到这条消息。以上情况对应 事务消息生产者的设计思路 图中的 1、2、3、4步骤。
继续分析，如果上图的第二步中，发送确认消息的过程中，出现异常，没有发送成功怎么办？RocketMQ会定期（默认60s）扫描Prepared消息，如果迟迟没有收到确认消息，将会执行事务回查的逻辑，主动去消息生产方确认事务状态。对应 事务消息生产者的设计思路 图中的 5、6、7步骤。综上，是事务消息中生产者的设计思路，保证本地事务和事务消息一致性。
如上图中，在事务消息者中，如果步骤4返回了消费失败或者超时未响应的情况，怎么办？RocketMQ对待事务消息的处理和普通消息一样。如果消费失败或超时，将会把这条消息加入到重试队列中，不断是重复执行步骤3、4，如果重复的次数达到阈值，那么可能需要人工介入处理。
如果消费方本地事务执行成功，仅仅是在确认消息时失败呢？ 那么这里又会出现另一个问题 重复消费？ 这里就需要具体的业务模块去处理消息的幂等性。如接住Redis来处理。如在本地事务执行前先去查询redis中当前消息是否已经消费，执行成功后再向redis写入一条成功消费的记录，这样就能保证消费不会被重复消费了。
参考资料：
- 哔哩哔哩 余胜军 BAT大厂消息中间件MQ，常见面试题及答案，你能搞懂有哪些？
https://www.bilibili.com/video/BV1zK4y1e7kS?share_source=copy_web- 如何解决幂等性问题？ - Java马剑威的回答 - 知乎
https://www.zhihu.com/question/534651475/answer/2542377973- 哔哩哔哩 so贝塔 MQ：如何回答消息队列的丢失、重复与积压问题
https://www.bilibili.com/video/BV1F8411g7LF?share_source=copy_web- 哔哩哔哩 图灵教育-诸葛 这可能是B站讲的最好的RocketMQ实战教程全套完整版（2023年最新版）
https://www.bilibili.com/video/BV1DY41127Be?p=2&share_source=copy_web
5.CSDN Rooibos gron RocketMQ事务消息
https://blog.csdn.net/qq_42877546/article/details/125404307
