消息队列如何保证消息不被重复消费（如何保证消费时的幂等性）？

关于消息的重复执行

首先我们可以确认的是，触发消息重复执行的条件会是很苛刻的， 也就说 在大多数场景下不会触发该条件。 一般出在消费者任务超时，或者没有及时返回状态（如任务耗时过长导致ACK超时），还有就是消费者还没来得及ACK就突然宕机或者异常消息导致循环消费等等，引起任务重新入队列，重新消费！  所以消费任务类型最好要支持幂等性，这样的好处是 任务执行多少次都没关系，顶多消耗一些性能！ 

如何避免重复消费呢(或者说怎么保证消息队列消费的幂等性)

这点我们需结合实际业务场景来说：

• 如果消费者只是拿个数据要写库，可以先根据主键查一下，如果这数据都有了，就不做插入了
• 如果是写 Redis，那没问题了，反正每次都是 set，天然幂等性。
• 如果业务复杂的，可以引入Redis，让生产者发送每条数据的时候，消息中加一个全局唯一的 id，将消费者已经消费完成了的消息id扔进redis中。消费者的逻辑是拿到消息开始消费之前，先根据这个 id 去Redis 里查一下，如果没有消费过，消费者就开始处理，待消费处理完成后返回ACK，如果有记录则表示该条消息已经被消费过了直接返回ACK，保证别重复处理相同的消息即可。
• 还有一种情况就是异常消息或消息处理耗时过长致使消息TTL过期，导致consumer没有及时返回ACK造成死循环。这里我们可能就需要用到死信队列，而这条消息就是死信。将产生的死信通过程序的配置路由到指定的死信队列，然后应用监听死信队列，对接收到的死信做后续的处理避免死信被重复消费。

关于死信消息队列的解释以及具体实现，请参考另一篇文章 RabbitMQ之死信队列