一、何为幂等性？

其任意多次执行所产生的影响均与一次执行的影响相同

从对系统的影响结果来说：At least once + 幂等消费 = Exactly once。

那么如何实现幂等操作呢？最好的方式就是，从业务逻辑设计上入手，将消费的业务逻辑设

计成具备幂等性的操作。但是，不是所有的业务都能设计成天然幂等的，这里就需要一些方

如果一个函数 f(x) 满足：f(f(x)) = f(x)，则函数 f(x) 满足幂等性。

法和技巧来实现幂等。

二、常见幂等性实现实现方式

1.利用数据库的唯一约束实现幂等

发起请求前，预先生成id

正常执行业务逻辑，如果已经消费过，报违反唯一性约束。未消费过，正常执行成功。

2.为更新的数据设置前置条件

(1)业务性条件

给数据变更设置一个前置条件，如果满足条件就更新数据，否则拒绝更新数据，在更新数据的时候，同时变更前置条件中需要判断的数据。这样，重复执行这个操作时，由于第一次更新数据的时候已经变更了前置条件中需要判断的数据，不满足前置条件，则不会重复执行更新数据操作。

比如，刚刚我们说过，“将账户 X 的余额增加 100 元”这个操作并不满足幂等性，我们可

以把这个操作加上一个前置条件，变为：“如果账户 X 当前的余额为 500 元，将余额加

100 元”，这个操作就具备了幂等性。对应到消息队列中的使用时，可以在发消息时在消

息体中带上当前的余额，在消费的时候进行判断数据库中，当前余额是否与消息中的余额相

等，只有相等才执行变更操作。

基于这个思路，不光是可以使用关系型数据库，只要是支持类似“INSERT IF NOT

EXIST”语义的存储类系统都可以用于实现幂等，比如，你可以用 Redis 的 SETNX 命令来

替代数据库中的唯一约束，来实现幂等消费。

(2)类似数据库乐观锁--增加一个version字段

借鉴数据库的乐观锁机制，如：

update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 1

根据version版本，也就是在操作库存前先获取当前商品的version版本号，然后操作的时候带上此version号。我们梳理下，我们第一次操作库存时，得到version为1，调用库存服务version变成了2；但返回给订单服务出现了问题，订单服务又一次发起调用库存服务，当订单服务传如的version还是1，再执行上面的sql语句时，就不会执行；因为version已经变为2了，where条件就不成立。这样就保证了不管调用几次，只会真正的处理一次。

3.记录并检查操作

如果上面提到的两种实现幂等方法都不能适用于你的场景，我们还有一种通用性最强，适用

范围最广的实现幂等性方法：记录并检查操作，也称为“Token 机制或者 GUID(全局唯

一 ID)机制”，实现的思路特别简单：在执行数据更新操作之前，先检查一下是否执行过

这个更新操作。

具体的实现方法是，在发送消息时，给每条消息指定一个全局唯一的 ID，消费时，先根据

这个 ID 检查这条消息是否有被消费过，如果没有消费过，才更新数据，然后将消费状态置

为已消费。

原理和实现是不是很简单？其实一点儿都不简单，在分布式系统中，这个方法其实是非常难

实现的。首先，给每个消息指定一个全局唯一的 ID 就是一件不那么简单的事儿，方法有很

多，但都不太好同时满足简单、高可用和高性能，或多或少都要有些牺牲。更加麻烦的是，

在“检查消费状态，然后更新数据并且设置消费状态”中，三个操作必须作为一组操作保证

原子性，才能真正实现幂等，否则就会出现 Bug。

比如说，对于同一条消息：“全局 ID 为 8，操作为：给 ID 为 666 账户增加 100 元”，有

可能出现这样的情况：

这样就会导致账户被错误地增加了两次 100 元，这是一个在分布式系统中非常容易犯的错

误，一定要引以为戒。

t0 时刻：Consumer A 收到条消息，检查消息执行状态，发现消息未处理过，开始执

行“账户增加 100 元”；

t1 时刻：Consumer B 收到条消息，检查消息执行状态，发现消息未处理过，因为这个

时刻，Consumer A 还未来得及更新消息执行状态。

对于这个问题，当然我们可以用事务来实现，也可以用锁来实现，但是在分布式系统中，无

论是分布式事务还是分布式锁都是比较难解决问题。

参考