1、幂等的基本概念
幂等简单点讲，就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会产生任何副作用。幂等分很多种，比如接口的幂等、消息的幂等，它是分布式系统设计时必须要考虑的一个方面。

查询操作(天然幂等)
查询一次和查询多次，在数据不变的情况下，查询结果是一样的。查询是天然的幂等操作删除操作 (天然幂等) 删除操作也是幂等的，删除一次和删除多次都是把数据删除(注意可能返回结果不一样，删除的数据不存在返回 0，删除的数据多条，返回结果多个)。

删除操作 (天然幂等)
删除操作也是幂等的，删除一次和删除多次都是把数据删除(注意可能返回结果不一样，删除的数据不存在, 返回 0，删除的数据多条，返回结果多个).

新增操作
新增操作，这种情况下多次请求，可能会产生重复数据；

修改操作
修改操作，如果只是单纯的更新数据，比如: update account set money=100 where id=1，是没有问题的，如果还有计算，比如: update account set money=money+100 where id=l，这种情况下多次请求，可能会导致数据错误。

总结：当出现消费者对某条消息重复消费的情况时，重复消费的结果与消费一次的结果是相同的，并且多次消费并未对业务系统产生任何负面影响，那么这个消费者的处理过程就是幂等的。例如，在支付场景下，消费者消费扣款消息，对一笔订单执行扣款操作，扣款金额为 100 元。如果因网络不稳定等原因导致扣款消息重复投递，消费者重复消费了该扣款消息，但最终的业务结果是只扣款一次扣费 100 元，且用户的扣款记录中对应的订单只有一条扣款流水，不会多次扣除费用。那么这次扣款操作是符合要求的，整个消费过程实现了消费幂等。

2、产生消息重复的原因
在可联网应用中，尤其在网络不稳定的情况下，消息队列的消息有可能会出现重复，如果消息重复消费会影响您的业务处理，请对消息做幂等处理。消息重复的可能原因如下:

发送时消息重复 当一条消息已被成功发送到服务端并完成持久化，此时出现了网络闪断或者生产者宕机，导致服务端对生产者应答失败。 如果此时生产者 Producer 意识到消息发送失败并尝试再次发送消息，消费者 Consumer 后续会收到两条内容相同的消息。

投递时消息重复 消息消费的场景下，消息已投递到消费者 Consumer 并完成业务处理，当消费者给服务端反馈应答的时候网络闪断，为了保证消息至少被消费一次，消息队列的服务端将在网络恢复后再次尝试投递之前已被处理过的消息，消费者 Consumer 后续会收到两条内容相同的消息；

负载均衡时消息重复 当消息队列的服务端或消费者重启、扩容或缩容时，都有可能会触发 rebalance，此时消费者 Consumer 可能会收到重复消息。

3、解决方案及案例分析
既然消息可能会产生重复，那如何解决消息幂等的问题呢?我们需要从生产者、中间件、消费者这几个不同层面，来保证消息的幂等,[消息的幂等业界有很多种方案，我这里列出常见的几种方案供大家参考

3.1 设置业务唯一 key 方案 (应用最广泛)
业务唯一key 可以是单个字段或者组合字段，这个方案是怎么实现的呢?

生产者消息休构造业务唯一 key，消息端针对这个 key 加分布式锁；

在消费端，创建一个消息防重表，利用插入记录唯一健约束控制， 但是这会与业务有一定的耦合，另外高并发下频繁对消息防重表进行操作，性能比较低，不太建议使用，我们通常是在消费端加一个redis分布式锁，防止短期内消息的重复投递；

数据库业务表加唯一索引 (数据库)

以用户在积分商城下单为例，具体业务流程如下：

1、客户发起支付流程；

2、生产者生产消息构造一个订单号作为消息体幂等的唯一 key；

3、发送消息给 broker，broker 持久化消息到磁盘；

4、消费者开始消费消息，在消费逻辑中加一个分布式锁，key为订单号，防止短时间内消息重复投递；

5、当加锁成功后，执行核心业务逻辑，然后释放分布式锁，当加锁失败，直接结束；

6、最后，为了防止后续生产者重复推送相同唯一key 的消息我们需要在数据库的业务表中给这个订单号加一个唯一索引，通过唯一健约束来保证数据库表不会出现两条相同的记录，从而实现消息幂等

3.2 设置业务唯一id方案
这个其实跟上一个方案类似，只是唯一id是需要我们通过 分布式id服务 生成，其他的处理方法跟上一个方案一样。

3.3 基于业务的状态机方案
在设计单据相关的业务，或者是任务相关的业务，肯定会涉及到状态机(状态变更图)，我们以业务单据为例：在业务单据上面会有个状态，状态在不同的情况下会发生变更，一般情况下存在有限状态机，当消费业务消息的时候，如果状态机已经处于下一个状态，这时候来了一个上一个状态的消息，直接丢弃消息不处理，保证了有限状态机的幂等。

3.4 基于version版本号的乐观锁方案
此方案一般是适用于更新业务的场景，更新表的时候通过版本号对比来保证消息的幂等

具体业务流程
1、客户购买商品，完成后准备发送一条扣减账户200 的消息；

2、生产端开始生产消息，构造消息体{ id=1，money=200，version=1 }；

3、发送消息给 broker，broker 持久化这条消息后，返回确认消息给生产者，此时时出现了网络闪断或者生产者宕机，导致 broker 对生产者响应失败， 如果此时生产者意识到消息发送失败并尝试再次发送消息，消费者后续会收到两条内容相同的消息；

4、消费者收到相同的消息，开始消费第一条消息{id=1，money=200，version=1}，根据 version=1 更新记录更新成功；

5、接着开始消费第二条消息{id=1，money=200，version=l }，根据 version=1更新记录，但是此时 version 已经被更新为 2，条件不满足更新失败；

6、消费者通过基于version的乐观锁保证了消息幂等。

3.5 insert ... on duplicate key update 方案
此方案一般适合一些统计更新类的业务或者定时同步第三方平台数据到自己数据库的场景，例如: 定时同步企业微信的成员数据到自已企微库的成员表，就可以采用这种方案实现。

on dupdate key update 语句基本功能是：当表中没有原来记录时，就插入，有的话就更新。

1. on duplicate key update 语句根据主键id或唯一键来判断当前插入是否已存在。
2. 记录已存在时，只会更新on duplicate key update之后指定的字段。
3. 如果同时传递了主键和唯一键，以主键为判断存在依据，唯一键字段内容可以被修改。

具体业务流程：
1、张三关注某 A 公司企业微信，加人深圳区企微群；
2、管理员在深圳区企微群投放一个活动，张三第一次点击这个活动，这个时候活动模块发送一条 kafka 消息；
3、在数据库创建一张活动效果统计表，act_code 和 usr_id 两个字段作为联合唯一索引；
4、数据处理模块消费这条消息，通过 insert on duplicate key update 插人一条记录；
5、过了几小时，张三第二次点击这个活动，这个时候活动模块再发送一条 kafka 消息，数据处理模块再次消费这条消息，通过 insert...on duplicate key update 更新对应唯一索引的这条记录的更新时间字段；
6、通过 insert...on duplicate key update 命令，可以实现数据库表不会出现重复的记录，还能实现业务的更新逻辑。

补充：

消息消费失败的时候，可以做好监控报警，以便进行人工干预；
消费消息的方法，确保在同一个事务，以便消费失败的时候，可以回滚；