幂等:
- 落表状态
- Redis设置key,setnx也能,但都不能设置过期时间或需要设置较长时间
======================== 一致性 =============================
一. MQ消息生产端: 本地业务与消息生产者
- 本地业务与发送MQ同一个事务(生产者发送重试(rocketMQ默认2次),一般处理方式,杜绝不了会出现不一致的情况)
目前生产环境处理方式,兼有业务重试机制 - 事务消息(rocketMQ)
- 独立消息服务
二. MQ消息生产端与消费端:
一般依靠MQ重试机制,从而保证最终一致性
三. 重试:
四. rocketMQ消息丢失:
首先在如下三个部分都可能会出现丢失消息的情况：
Producer端
Broker端
Consumer端
- 生产端: 重试(默认2次)
producer.setRetryTimesWhenSendFailed(10);//重试10次
- broker: 通过同步刷盘防止
## 默认情况为 ASYNC_FLUSH，修改为同步刷盘：SYNC_FLUSH，实际场景看业务，同步刷盘效率肯定不如异步刷盘高。
flushDiskType = SYNC_FLUSH
Consumer端: 完全消费正常后在进行手动ack确认
五. rocketMQ的消息堆积如何处理
下游消费系统如果宕机了，导致几百万条消息在消息中间件里积压，此时怎么处理?
你们线上是否遇到过消息积压的生产故障?如果没遇到过，你考虑一下如何应对?
首先要找到是什么原因导致的消息堆积，是Producer太多了，Consumer太少了导致的还是说其他情况, 总之先定位问题。然后看下消息消费速度是否正常，正常的话，可以通过上线更多consumer临时解决消息堆 积问题
追问：如果Consumer和Queue不对等，上线了多台也在短时间内无法消费完堆积的消息怎么
办？
1. 准备一个临时的topic
2. queue的数量是堆积的几倍
3. queue分布到多Broker中
4. 上线一台Consumer做消息的搬运工，把原来Topic中的消息挪到新的Topic里，不做业务逻辑处理，只是
挪过去
5. 上线N台Consumer同时消费临时Topic中的数据
6. 修复原来的Consumer，继续消费之前的Topic
追问：堆积时间过长消息超时了？
RocketMQ中的消息只会在commitLog被删除的时候才会消失，不会超时。也就是说未被消费的消息不会存在
超时删除这情况。
追问：堆积的消息会不会进死信队列？
不会，消息在消费失败后会进入重试队列（%RETRY%+ConsumerGroup），16次（默认16次，messageDelayLevel 没有1,2级别直接从第3级别开始重试,延时消息级别才是18个）才会进入死信队列
（%DLQ%+ConsumerGroup）。
1）死信消息具有以下特性：
- 不会再被消费者正常消费。
- 有效期与正常消息相同，均为 3 天，3 天后会被自动删除。因此，请在死信消息产生后的 3 天内及时处理。
文献:
https://blog.csdn.net/qingwufeiyang_530/article/details/110563298
