什么是幂等性？
参考地址：解决幂等问题
概念：
一个接口，不管我调多少次，只要参数不变，结果也应该不变。
但是在实际工作中，幂等性一般分为两种：
- 请求幂等：每次请求，如果参数一样，结果也应该一样。
- 业务幂等：同一次业务请求，在拿到最终状态之后的每次请求，结果要保证一样。在没拿到状态之前，每一次请求需要正常执行业务逻辑，直到推进到最终状态。
一般来说，我们谈到的幂等性，大部分都是业务幂等。
比如：一次支付请求，如果支付返回处理中，或者系统异常等，我们需要重试，继续调用，直到他明确的返回支付成功，或者明确的无法支付失败结果。
如何保证幂等性？
想要保证幂等性，最简单的做法就是：在做业务操作之前，先查一下，判断下本次操作是否有被执行过，如果执行过，则不再执行，否则继续执行。
但是，这个方案存在一个关键性的问题：就是在高并发场景中，可能会有幂等击穿的。
所以，想要解决好这个问题，需要做好并发控制。
解决幂等问题口诀：一锁、二判、三更新。
一锁、二判、三更新
一锁：第一步，先加锁。可以加分布式锁，或者悲观锁。但是一定要是一个互斥锁。
二判：第二步，进行幂等性判断。可以基于状态机、流水表、唯一性索引等进行重复操作判断。
三更新：第三步，进行数据的更新，将数据进行持久化。
三步需要严格控制顺序，确保加锁成功后进行数据查询和判断，幂等性判断通过后再更新，更新结束后释放锁。
以上操作需要有一个前提，那就是第一步加锁、和第二步判断的时候，需要有一个依据，这个就是幂等号了，通常需要和上游约定一个唯一ID作为幂等号。然后通过对幂等号加锁，再通过幂等号进行幂等判断即可。
一锁这个过程，建议使用Redis实现分布式锁，因为他是非阻塞的高效率的互斥锁。非常适合在幂等控制场景中。
二判这个过程，如果有操作流水，建议基于操作流水做幂等，并将幂等号作为唯一性约束，确保唯一性。如果没有流水，那么基于状态机也是可以的。
但是不管怎么样，数据库的唯一性约束都要加好，这是系统的最后一道防线。万一前面的锁失效了，这里也能控制得住不会产生脏数据。
