分布式事务的一种计划：音讯可靠性 + 最终一致性， 那么
如何保障音讯的可靠性？
1. 音讯失落(最重要)
音讯失落：如何保障音讯不失落？
1.1. 网络起因发不出-> 记录日志+定时工作解决
比方网络起因公布进来：怎么弄？ catch异样从新while(true)发几次？NoNoNo! 如果是网络起因， 很可能发不进来，
正确做法：
- 数据库建一个mq_message的表， 每发一条mq音讯都记录到库;
- 定时工作扫， 状态是 “未发送胜利” 的记录， 从新发送；
1.2 Broker长久化失败->生产者发送确认+失败重发
咱们的音讯都要设置长久化保留， 咱们胜利将音讯发送到mq的Broker，然而broker须要将音讯长久化， 而后能力进入到queue里， 这个两头mq挂了， 怎么保障音讯不失落？
Producer–>（Broker(Exchange)–>(Queue)）–>Consumer
咱们应用生产者发送者的确认机制： 只有发送到broker， broker长久化实现音讯到达送给队列当前， broker才会给发送者确认；这样就能保障发送胜利
1.3 Consumer生产失落->敞开主动确认, 应用手动ACK
MQ生产时宕机或生产失败？敞开生产时主动确认， 应用 手动manual ACK， 生产完确认！
2. 音讯反复
2.1 音讯反复的2种情景：
比方消费者生产音讯， 收到了两遍
- consumer生产失败， 手动basicReject回绝了， 这种是容许的；
-
consumer生产实现，手动ACK之前忽然宕机， 此时没给broker确认音讯生产实现；这样, 就有可能会再发给其余的消费者，造成音讯反复；
生产胜利，ack宕机，音讯由 unack变为ready, 而后broker会从新发送
主旨： 设计生产时， 做到 幂等生产
2.2 幂等生产
2.2.1 生产做状态判断
业务设置状态， 生产时做状态判断， 解决过就疏忽
2.2.2 防重表：惟一标识
防重表：发送的每一个音讯都有惟一标识， 解决过就疏忽
3. 音讯积压
音讯积压会带来MQ性能的降落， 所以肯定要解决音讯积压的问题
3.1 音讯积压的3种起因
3.1.1 消费者宕机
3.1.2 消费者自身生产能力有余
3.1.3 发送者流量太大
3.2 解决音讯积压的计划
3.2.1 限度业务流量+限度发送流量（上策）
3.2.2 上线更多的消费者， 加大生产规模
3.2.2.3 若生产逻辑简单，能够设置:先纯生产-记录数据库-离线解决
能够解决mq压力， 转移mq压力
发表回复