本文详细探讨了消息中间件在保证消息不丢失、处理重复消费问题以及实现高可用机制等方面的方法。针对RabbitMQ，提出了开启生产者确认、消息持久化和消费者确认机制来防止消息丢失，利用死信交换机实现延迟队列，并讨论了应对消息堆积和数据丢失的策略。对于Kafka，介绍了其通过生产者回调、副本复制和消费者手动提交offset确保消息不丢失，以及保证消费顺序性和集群高可用的机制。
RabbitMQ-如何保证消息不丢失？
我们当时MySQL和Redis的数据双写一致性就是采用RabbitMQ实现同步的，这里面就要求了消息的高可用性，我们要保证消息的不丢失。主要从三个层面考虑
第一：开启生产者确认机制，确保生产者的消息能到达队列，如果报错可以先记录到日志中，再去修复数据
第二：开启持久化功能，确保消息未消费前在队列中不会丢失，其中的交换机、队列、和消息都要做持久化
第三：开启消费者确认机制为auto，由spring确认消息处理成功后完成ack，当然也需要设置一定的重试次数，我们当时设置了3次，如果重试3次还没有收到消息，就将失败后的消息投递到异常交换机，交由人工处理
RabbitMQ消息的重复消费问题如何解决的？
这个我们还真遇到过，是这样的，我们当时消费者是设置了自动确认机制，当服务还没来得及给MQ确认的时候，服务宕机了，导致服务重启之后，又消费了一次消息。这样就重复消费了
因为我们当时处理的支付(订单|业务唯一标识)，它有一个业务的唯一标识，我们再处理消息时，先到数据库查询一下，这个数据是否存在，如果不存在，说明没有处理过，这个时候就可以正常处理这个消息了。如果已经存在这个数据了，就说明消息重复消费了，我们就不需要再消费了
最低0.47元/天 解锁文章
521
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
