可以用数据库唯一索引处理幂等性吗？
周末来个简单的吧～
有一个小伙伴在面试时遇到这么个问题，面试回来后微信问松哥。
那咱们今天就来捋一捋这事。
一 唯一索引处理幂等
先说结论：不建议。
为啥呢？
大家想想，用数据库唯一索引处理幂等，要求你必须是插入操作，因为只有插入操作，通过唯一索引进行判断的时候，才能把重复插入的数据给拒绝了。所以你的业务必须得是插入这种操作，如果你是更新或者删除操作想要保证幂等，那么用唯一索引显然是有问题的。
当然光这一点还不够。
用唯一索引还有一个问题就是我们怎么发现重复插入了呢？是插入操作抛出了 DuplicateKeyException 异常，这个异常是 Spring 提供的，这里就存在两个问题：
- 第一个问题就是我们一般不建议使用异常来控制业务逻辑，因为这首先带来性能问题。其次用异常，我们可能要捕获异常，进而影响到事务的回滚。退一万步说，Java 之父设计异常也不是用来干这个的呀；
- 第二个问题就是这个异常依赖底层数据库和框架的，如果有一天项目不用 MySQL 或者不用 Spring 框架了，怎么办？
从这个角度来说，也不建议使用唯一索引去处理幂等。
二 推荐方案
在双 11 和双 12 的活动中，对于幂等性问题，支付宝团队总结了一套解决方案：
一锁二判三更新。
这个方案，可以作为一个比较通用的综合性的幂等解决方案。
在任何时刻，只要牢记这个规则，基本上就不会发生重复操作的问题。
那么什么是“一锁二判三更新”呢？
就是说，当一个请求到达之后，具体操作步骤如下：
- 先锁定数据，一般来说我们可以利用 Redis 分布式锁做这个事情，不建议使用并发能力低的 DB 锁，关于 Redis 分布式锁，松哥在【Redis–不止缓存】已经介绍过了，这里不再赘述。
- 然后判断单据状态，是否之前已经更新过了，这个检查可以基于状态机、流水表等，结合自己的业务逻辑进行具体的判断。
- 如果之前并没有更新，则本次请求可以更新，接着完成相关业务逻辑；如果之前已经更新，则本次不能更新，也不能完成业务逻辑。操作完成后记得释放锁。
方案是死的人是活的，在具体的实践中我们可以根据自身的业务需求对方案作出调整。
比如说系统的并发量不大，那么我们就可以省略第一步，不去提前锁定数据，而是在数据更新的时候通过乐观锁去处理幂等问题。
