分布式事务的一种计划：音讯可靠性 + 最终一致性，那么

如何保障音讯的可靠性？

1. 音讯失落(最重要)

音讯失落：如何保障音讯不失落？

1.1. 网络起因发不出 -> 记录日志 + 定时工作解决

比方网络起因公布进来：怎么弄？catch 异样从新 while(true)发几次？NoNoNo! 如果是网络起因，很可能发不进来，

正确做法：

1. 数据库建一个 mq_message 的表，每发一条 mq 音讯都记录到库;
2. 定时工作扫，状态是 “ 未发送胜利 ” 的记录，从新发送；

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 种情景：

比方消费者生产音讯，收到了两遍

1. consumer 生产失败，手动 basicReject 回绝了，这种是容许的；

2. 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 压力