分布式事务的一种计划:音讯可靠性 + 最终一致性,那么
如何保障音讯的可靠性?
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 压力