1.概述

作为开发人员，我们每天都要开发大量的接口，其中包括了读接口和写接口，而对于写接口来说，除了要保证他的性能、可用性以外，还需要有一个重要的问题，那就是考虑如何保证接口的幂等性。
“幂等（idempotent、idempotence）是一个数学与计算机学概念，常见于抽象代数中。 在编程中一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。 幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。 这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。”

以上是百度百科中的回答，总结起来就是一句话：一个接口，不管我调多少次，只要参数不变，结果也应该不变。

但是，实际在工作中，谈到幂等性，一般分为两种，即请求幂等和业务幂等

请求幂等：每次请求，如果参数一样，结果也要一样。

业务幂等：同一次业务请求，在拿到最终状态之后的每次请求，结果要保证一样。在没拿到最终状态之前，每一次请求需要正常执行业务逻辑，直到推进到最终状态。

一般来说，我们谈到的幂等性，大部分都是业务幂等。比如，一次支付请求，如果支付返回处理中，或者系统异常等，我们需要重试，继续调用，直到他明确的返回支付成功，或者明确的无法成功的支付失败结果。

2.如何保证幂等

想要保证幂等性，最简单的做法就是：在做业务操作之前，先查一下，判断下本次操作是否有被执行过，如果执行过，则不再执行，否则继续执行。

但是，这个方案存在一个关键性的问题，那就是在高并发场景中，是可能会有幂等击穿的。

所以，想要解决好这个问题，需要做好并发控制，那么，做并发控制，大家首先想到的就是锁，没错。就是要用锁。

那么，解决幂等问题，请记住这个口诀：”一锁、二判、三更新”

3.一锁、二判、三更新

“一锁、二判、三更新”，只要严格遵守这个过程，那么就可以解决并发问题。

一锁：第一步，先加锁。可以加分布式锁、或者悲观锁都可以。但是一定要是一个互斥锁！

二判：第二步，进行幂等性判断。可以基于状态机、流水表、唯一性索引等等进行重复操作的判断。

三更新：第三步，进行数据的更新，将数据进行持久化。

三步需要严格控制顺序，确保加锁成功后进行数据查询和判断，幂等性判断通过后再更新，更新结束后释放锁。

以上操作需要有一个前提，那就是第一步加锁、和第二步判断的时候，需要有一个依据，这个就是幂等号了，通常需要和上游约定一个唯一ID作为幂等号。然后通过对幂等号加锁，再通过幂等号进行幂等判断即可。

一锁这个过程，建议使用Redis实现分布式锁，因为他是非阻塞的高效率的互斥锁。非常适合在幂等控制场景中。

二判这个过程，如果有操作流水，建议基于操作流水做幂等，并将幂等号作为唯一性约束，确保唯一性。如果没有流水，那么基于状态机也是可以的。

但是不管怎么样，数据库的唯一性约束都要加好，这是系统的最后一道防线。万一前面的锁失效了，这里也能控制得住不会产生脏数据。