阿里二面：使用消息队列怎样防止消息重复？

主要观点总结

本文讨论了在使用消息队列时可能遇到的重复消息问题，并介绍了如何应对这种情况的几种方法。文章详细解释了消息重复的成因，以及生产者、Broker和消费者在消息防重方面的作用。

关键观点总结

关键观点1: 消息重复的问题及影响

在使用消息队列时，可能会遇到消息重复的问题，这对订单、扣款、对账等需要幂等的场景会产生影响。

关键观点2: 三种语义的解释

文章介绍了消息队列中的三种语义：At Least Once、Exactly Once和At Most Once，并解释了它们的特点和适用场景。

关键观点3: 消息重复的原因

生产者发送消息后，如果Broker保存成功但没有成功返回ACK，或者消费者消费消息后ACK失败，都可能导致消息重复。

关键观点4: 生产者和Broker的防重机制

部分消息中间件支持生产者的幂等性，如Kafka从0.11.0版本开始引入了幂等Producer。Broker的防重机制则通过参数开启，并对重复消息进行响应和处理。

关键观点5: 消费者防重的重要性及实现方式

仅靠生产者和Broker的防重机制只能在Topic/Partition级别生效，为了满足需求，消费端的防重是必要的。消费者可以根据消息体的全局唯一ID进行防重，如使用数据库唯一索引或Redis的setNx操作。

文章预览

来源丨经授 权转自 君哥聊技术 作者丨 朱晋君 使用消息队列时，我们经常会遇到一个可能对业务产生影响的问题，消息重复。在订单、扣款、对账等对幂等有要求的场景，消息重复的问题必须解决。 那怎样应对重复消息呢？今天来聊一聊这个话题。 1.三个语义 正确使用消息队列，我们会考虑到消息防丢失、防重复，我们介绍 3 个语义： At Least Once： 在消息队列中，指消息不丢失，一条消息最少被消费一次，但是可能会有重复消费 。 Exactly Once： 在消息队列中，消息被精准消费一次，不丢失，也不会重复 ； At Most Once： 在消息队列中，消息不会被重复消费，但是可能会有消息丢失 不同的消息场景，需要的语义不同。比如  Exactly Once  最难实现，一般需要引入事务消息。 不同使用场景，对语义的要求也不一样。比如日志收集类的场景 ，At Most Once  ………………………………