高并发场景的分布式事务，我们采用柔性事务+可靠消息+最终一致性方案（异步确保型），可靠性是最重要的，那么如何保证消息的可靠性呢？
一、消息丢失
1、消息发送出去，由于网络问题没有抵达服务器 做好容错方法(try-catch)，发送消息可能会网络失败，失败后要有容错机制，可记录到数据库，采用定期扫描重发的方式。 做好日志记录，每个消息状态是否都被服务器收到都应该记录 做好定期重发，如果消息没有发送成功，定期去数据库扫描未成功的消息进行重发
2、消息抵达Broker，Broker要将消息写入磁盘（持久化）才算成功。此时Broker尚未持久化完成，宕机。
publisher 也必须加入确认回调机制，确认成功的消息，修改数据库消息状态。 生产者消息确认回调应该增加日志记录，确认回调成功后修改记录日志的状态： 3、自动ACK的状态下。消费者收到消息，但没来得及消费然后宕机。
一定开启手动ACK，消费成功才移除，失败或者还没来得及处理就 noAck并重新入队。 防止消息丢失记住这两条： 1、做好消息确认机制（publisher,consumer【手动ack】】） 2、每一个发送的消息都在数据库做好记录。定期将失败的消息再发送一遍
二、消息重复
出现重复的几种情况# 1、消息消费成功，事务已经提交，ack时，机器宕机，导致没有ack成功。 Broker的消息重新由 unack 变为ready，并发送给其他消费者 2、消息消费失败，由于重试机制，自动又将消息发送出去。 3、成功消费，ack时宕机，消息又unack变为ready,Broker又重新发送 解决方案# 消费者的业务消费接口应该设计为幂等性的。比如扣库存有工作单的状态标识。 使用防重表（redis/mysql）,发送消息每一个都有业务的唯一标识，处理过就不用再处理。 rabbitMQ的每一个消息都有 redilivered字段，可以获取是否被重新投递过来的，而不是第一次被投递过来的。
三、消息积压 消费者宕机 消费者消费能力不足 发送者发送流量太大 上线更多的消费者，进行正常的消费 上线专门的队列消费服务，将消息先批量取出来，记录数据库，离线慢慢处理
标签：积压,宕机,ack,解决方案,Broker,RabbitMQ,成功,发送,消息 From： https://blog.51cto.com/u_15993308/6148315