实现幂等性：策略与方法解析,-优快云博客

1、出现需要实现幂等性的场景

1.1、前端重复提交

用户注册，用户创建商品等操作，前端都会提交一些数据给后台服务，后台需要根据用户提交的数据在数据库中创建记录。如果用户不小心多点了几次，后端收到了好几次提交，这时就会在数据库中重复创建了多条记录。这就是接口没有幂等性带来的 bug。

1.2、接口超时重试

对于给第三方调用的接口，有可能会因为网络原因而调用失败，这时，一般在设计的时候会对接口调用加上失败重试的机制。如果第一次调用已经执行了一半时，发生了网络异常。这时再次调用时就会因为脏数据的存在而出现调用异常。

1.3、消息重复消费

在使用消息中间件来处理消息队列，且手动 ack 确认消息被正常消费时。如果消费者突然断开连接，那么已经执行了一半的消息会重新放回队列。

当消息被其他消费者重新消费时，如果没有幂等性，就会导致消息重复消费时结果异常，如数据库重复数据，数据库数据冲突，资源重复等。

2、实现幂等性的方案

2.1、使用token机制实现

具体流程步骤：

客户端会先发送一个请求去获取 token，服务端会生成一个全局唯一的 ID 作为 token 保存在 redis 中，同时把这个 ID 返回给客户端
客户端第二次调用业务请求的时候必须携带这个 token
服务端会校验这个 token，如果校验成功，则执行业务，并删除 redis 中的 token
如果校验失败，说明 redis 中已经没有对应的 token，则表示重复操作，直接返回指定的结果给客户端

注意：

对 redis 中是否存在 token 以及删除的代码逻辑建议用 Lua 脚本实现，保证原子性
全局唯一 ID 可以用百度的 uid-generator、美团的 Leaf 去生成

2.2、基于 mysql 实现

建立一张去重表，其中某个字段需要建立唯一索引
客户端去请求服务端，服务端会将这次请求的一些信息插入这张去重表中
因为表中某个字段带有唯一索引，如果插入成功，证明表中没有这次请求的信息，则执行后续的业务逻辑
如果插入失败，则代表已经执行过当前请求，直接返回

2.3、基于 redis 实现

这种实现方式是基于 SETNX 命令实现的

SETNX key value：将 key 的值设为 value ，当且仅当 key 不存在。若给定的 key 已经存在，则 SETNX 不做任何动作。

该命令在设置成功时返回 1，设置失败时返回 0。

具体流程步骤：

客户端先请求服务端，会拿到一个能代表这次请求业务的唯一字段
将该字段以 SETNX 的方式存入 redis 中，并根据业务设置相应的超时时间
如果设置成功，证明这是第一次请求，则执行后续的业务逻辑
如果设置失败，则代表已经执行过当前请求，直接返回

2.4、悲观锁

获取数据的时候加锁获取
select * from table_xxx where id='xxx' for update;
注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的
悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用

2.5、乐观锁

乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。

乐观锁的实现方式多种多样可以通过version或者其他状态条件：
1. 通过版本号实现
update table_xxx set name=#name#,version=version+1 where version=#version#
如下图(来自网上)：

2. 通过条件限制
update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount# >= 0
要求：quality-#subQuality# >= ，这个情景适合不用版本号，只更新是做数据安全校验，适合库存模型，扣份额和回滚份额，性能更高

注意：乐观锁的更新操作，最好用主键或者唯一索引来更新,这样是行锁，否则更新时会锁表，上面两个sql改成下面的两个更好
update table_xxx set name=#name#,version=version+1 where id=#id# and version=#version#
update table_xxx set avai_amount=avai_amount-#subAmount# where id=#id# and avai_amount-#subAmount# >= 0

2.6、分布式锁

还是拿插入数据的例子，如果是分布是系统，构建全局唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统(redis或zookeeper)，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。

要点：某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁(分布式锁要第三方系统提供)