【分布式】: 幂等性和实现方式
编程世界
所谓的幂等性，是分布式环境下的一个常见问题，一般是指我们在进行多次操作时，所得到的结果是一样的，即多次运算结果是一致的。
幂等：任意多次执行所产生的影响均与一次执行的影响相同，这是幂等性的核心特点。
也就是说，用户对于同一操作，无论是发起一次请求还是多次请求，最终的执行结果是一致的，不会因为多次点击而产生副作用。
什么是接口幂等性？
在HTTP/1.1中，对幂等性进行了定义。它描述了一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外），即第一次请求的时候对资源产生了副作用，但是以后的多次请求都不会再对资源产生副作用。
这里的副作用是不会对结果产生破坏或者产生不可预料的结果。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。
什么情况下会产生重复提交( 非幂等性 ）
以下几种情况会导致非幂等性的结果出现：
- 连续点击提交两次按钮；
- 点击刷新按钮；
- 使用浏览器后退按钮重复之前的操作，导致重复提交表单；
- 使用浏览器历史记录重复提交表单；
- 浏览器重复地HTTP请求等
为什么需要实现幂等性
在接口调用时一般情况下都能正常返回信息不会重复提交，不过在遇见以下情况时可以就会出现问题，如：
-
前端重复提交表单：在填写一些表格时候，用户填写完成提交，很多时候会因网络波动没有及时对用户做出提交成功响应，致使用户认为没有成功提交，然后一直点提交按钮，这时就会发生重复提交表单请求。
-
用户恶意进行刷单：例如在实现用户投票这种功能时，如果用户针对一个用户进行重复提交投票，这样会导致接口接收到用户重复提交的投票信息，这样会使投票结果与事实严重不符。
-
接口超时重复提交：很多时候 HTTP 客户端工具都默认开启超时重试的机制，尤其是第三方调用接口时候，为了防止网络波动超时等造成的请求失败，都会添加重试机制，导致一个请求提交多次。
-
消息进行重复消费：当使用 MQ 消息中间件时候，如果发生消息中间件出现错误未及时提交消费信息，导致发生重复消费。
幂等也有不好的地方
幂等性是为了简化客户端逻辑处理，能放置重复提交等操作，但却增加了服务端的逻辑复杂性和成本，其主要是：
-
把并行执行的功能改为串行执行，降低了执行效率。
-
增加了额外控制幂等的业务逻辑，复杂化了业务功能；
所以在使用时候需要考虑是否引入幂等性的必要性，根据实际业务场景具体分析，除了业务上的特殊要求外，一般情况下不需要引入的接口幂等性。
Restful API 接口幂等性如何？
| http method | 幂等 | 说明 |
|---|---|---|
| GET | ✔️ | 查询读读操作，不修改数据，一般都是幂等 |
| POST | ❌ | 新增资源，每次都是新增。 |
| PUT | - | 1. 根据某个值更新，是幂等。 2. 做累加操作更新等，非幂等 |
| DELETE | - | 1. 根据唯一值删除，是幂等 2. 根据条件删除，非幂等 |
实现幂等的方案
| 方案 | 适用方法 | 实现复杂度 | 缺点 |
|---|---|---|---|
| 数据库唯一主键 | 插入操作删除操作 | 简单 | - 只能用于插入操作 - 只能用于存在唯一主键场景 |
| 数据库乐观锁 | 更新操作 | 简单 | - 只能更新操作 - 表中新增字段 |
| 请求序列号 | 插入操作删除操作更新操作 | 简单 | - 需要保证下游生成唯一序号 - 需要redi第三方存储生成token |
| 防重Token令牌 | 插入操作删除操作更新操作 | 适中 | 需要redi第三方存储生成token |
方案原理讲解
数据库唯一主键实现幂等性
关键步骤：需要生成全局唯一主键 ID
主要流程如下：
-
客户端执行创建请求，调用服务端接口。
-
服务端执行业务逻辑，生成一个分布式
ID，将该 ID 充当待插入数据的主键，然 后执数据插入操作，运行对应的SQL语句。 -
服务端将该条数据插入数据库中，如果插入成功则表示没有重复调用接口。如果抛出主键重复异常，则表示数据库中已经存在该条记录，返回错误信息到客户端。
数据库乐观锁实现幂等性
关键步骤： 需要数据库对应业务表中添加额外字段
为了每次执行更新时防止重复更新，确定更新的一定是要更新的内容，我们通常都会添加一个 version 字段记录当前的记录版本，这样在更新时候将该值带上，那么只要执行更新操作就能确定一定更新的是某个对应版本下的信息。
这样每次执行更新时候，都要指定要更新的版本号，如下操作就能准确更新 version=5 的信息：
UPDATE my_table SET price=price+50,version=version+1 WHERE id=1 AND version=5
上面 WHERE 后面跟着条件 id=1 AND version=5 被执行后，id=1 的 version 被更新为 6，所以如果重复执行该条 SQL 语句将不生效，因为 id=1 AND version=5 的数据已经不存在，这样就能保住更新的幂等，多次更新对结果不会产生影响。
防重 Token 令牌实现幂等性
NOTE ： 获取Token只做一次，而非每次调用资源请求时都获取。
获取一次TOKEN可以随页面加载的时候去获取，或调用资源接口前获取一次。
在资源接口一次或多次请求时，使用的token是一样的。如果刷新界面或切换资源id，可以重新获取token
关键步骤：
-
服务端提供获取 Token 的接口，该 Token 可以是一个序列号，也可以是一个分布式
ID或者UUID串。 -
客户端调用接口获取 Token，这时候服务端会生成一个 Token 串。
-
然后将该串存入 Redis 数据库中，以该 Token 作为 Redis 的键（注意设置过期时间）。
-
将 Token 返回到客户端，客户端拿到后应存到表单隐藏域中。
-
客户端在执行提交表单时，把 Token 存入到
Headers中，执行业务请求带上该Headers。 -
服务端接收到请求后从
Headers中拿到 Token，然后根据 Token 到 Redis 中查找该key是否存在。 -
服务端根据 Redis 中是否存该
key进行判断，如果存在就将该key删除，然后正常执行业务逻辑。如果不存在就抛异常，返回重复提交的错误信息。
下游传递唯一序列号实现幂等性
关键步骤：
-
要求第三方传递唯一序列号；
-
需要使用第三方组件 Redis 进行数据效验；
- 下游服务生成分布式
ID作为序列号，然后执行请求调用上游接口，并附带唯一序列号与请求的认证凭据ID。 - 上游服务进行安全效验，检测下游传递的参数中是否存在序列号和凭据ID。
- 上游服务到 Redis 中检测是否存在对应的序列号与认证ID组成的
Key，如果存在就抛出重复执行的异常信息，然后响应下游对应的错误信息。如果不存在就以该序列号和认证ID组合作为Key，以下游关键信息作为Value，进而存储到 Redis 中，然后正常执行接来来的业务逻辑。
实现
基于 防重Token令牌方案 实现
代码仓库：
无难事者若执 / Spring Utils · GitCode
