浅谈幂等设计 | 京东云技术团队

1 幂等性

一句话，幂等就是一个执行操作，无论执行多少次，产生的效果和返回的结果都是一样的。

如今随着互联网技术快速发展，业务越来越复杂，系统的高并发和关键数据的场景越来越多。

在分布式系统中，机器宕机和消息丢失也是需要重点关注的问题，其中的一个典型就是幂等性问题。

想想看，一个对外暴露的接口会面领很多次请求，如果不能保证幂等性会带来什么样的后果？

微信进行一次扣款操作，应该只扣用户一次钱，当遇到网络故障或系统 bug，如果没有实现幂等性扣多了你会不会直接“C 语言”投诉？

当然，有些接口是天然保证幂等性的，比如查询操作、删除操作。有些对数据的修改是一个常量，无其他操作，也是具有幂等性的。修改操作可能幂等可能不幂等。

SELECT col1 FROM tab1 WHERE col2 = 2UPDATE tab1 SET col1 = 1 WHERE col2 = 2UPDATE tab1 SET col1 = col1 + 1 WHERE col2 = 2

这三个 sql 只有第三个不是幂等的。

POST 请求天生就不是一个幂等操作，每次调用都会在系统中产生新的资源，想要幂等就必须在业务中实现。

需要避免的是，幂等性和并发安全不是一回事。当同一笔订单即使你不停的提交支付，如果扣了不止一次钱，就说明该操作不幂等。

而有多笔订单同时进行支付，最后扣除的金额不是这么多笔金额的总和，说明该操作有并发安全问题。这是两个维度的问题，应该分开讨论解决。

（1）数据库防重

利用数据表唯一索引的特性，当并发时新增报错时，再查询一次，数据已经存在，就避免了脏数据的新增。但注意，不要将 uuid 作为索引字段，其大小和类型对于索引而言都会导致速度非常慢。

常见的场景，比如博客/微博系统点赞，一个用户对一个微博点赞，就把用户 id 与该博文 id 绑定，后续该用户再对该博文点赞就无法插入。再比如金融账户，可以通过在账户表中增加唯一索引来存储用户 id，即使重复操作一个用户也只能拥有一个账户。

（2）token 令牌机制

token 机制是适用范围最广泛的一种幂等设计。虽然实现方式有很多种，但核心思想就是每次操作都生成一个唯一 token 凭证，服务器通过这个唯一凭证确保同样的操作不会被执行多次。

具体可以分为两个阶段，获取 token 和使用 token。每次接口请求前先获取一个 token，然后在下次请求时在请求的 header 体中加上这个 token，后端进行校验，如果验证通过则删除 token，下次请求再次判断 token。如果在 redis 缓存的帮助下，流程图如下：

（3）分布式锁

数据库防重表可以通过分布式锁代替，相比去重表，将放并发做到了缓存中，效率更高。局限性都是同一时间只能完成一次请求。

比如某些业务处理流程很长，要求不能并发执行，可以在流程执行之前根据某个标志(用户 ID+后缀等)获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁。

优点：

业务需要

缺点：

（1）客户端处理逻辑得以简化，但服务端控制幂等逻辑变得更加复杂；

（2）把并发执行变成改为串行执行，降低了执行效率。

分布式自增 ID 可以借鉴 Snowflake 算法，优点是高性能、低延迟、按时间有序；缺点是需要独立的开发和部署。

其结构如下：

最高位是符号位，始终为 0，不可用。
41 位的时间序列，精确到毫秒级，41 位的长度可以使用 (1L << 41) / (1000L * 60 * 60 * 24 * 365) = 69 年。时间位还有一个很重要的作用是可以根据时间进行排序。注意，41 位时间截不是存储当前时间的时间截，而是存储时间截的差值（当前时间截 - 开始时间截) 后得到的值，这里的的开始时间截，一般是我们的 id 生成器开始使用的时间，由我们程序来指定的。
10 位的机器标识，10 位的长度最多支持部署 1024 个节点。
12 位的计数序列号，序列号即一系列的自增 id，可以支持同一节点同一毫秒生成多个 ID 序号，12 位的计数序列号支持每个节点每毫秒产生 4096 个 ID 序号。

加起来刚好 64 位，为一个 Long 型。这个算法很简洁，但依旧是一个很好的 ID 生成策略。

参考文献：

[1] 分布式系统互斥性与幂等性问题的分析与解决

[2] 高并发下接口幂等性解决方案

[3] 幂等性问题和解决方法

[4] 雪花算法

[5] 聊聊开发中幂等问题