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