1 什么是幂等
幂等的概念来自数学和计算机科学
数学概念：幂等函数 f(x) = f (f(x)) ，如绝对值函数abs(-5) = abs(abs(-5))
计算机科学：多次请求同同一资源与一次请求的影响是一致的
2 为什么要幂等设计
为什么要幂等设计呢？
我们举个例子：
除了转账的例子，我们日常开发中还会遇到许多其他考虑幂等的例子
A.MQ下游消费系统重复消费的问题
B.前端form表单重复提交的问题
3 接口超时了如何设计
我们在调用下游接口超时的时候该如何处理呢？一般来讲有两种方案：方案一：下游系统提供一个查询接口，上游调用超时，调用查询接口，根据查询接口返回的结果做相应的处理
方案二：下游支付中心支持幂等，超时之后，发起重试
4 如何设计幂等
这么多场景需要考虑幂等，那如何设计幂等呢幂等的核心问题是保持请求的唯一性，那首先要解决的问题是全局唯一性ID
如果使用唯一索引控制幂等，那么唯一索引就是唯一的；
如果使用数据库主键控制幂等，那么主键就是唯一的；
如果使用悲观锁控制幂等，那么底层标志还是全局唯一ID
4.1 全局唯一ID
如UUID、雪花算法（snowflake IDs），UUID的方式简单，但是可读性差，
雪花算法是一种生成分布式全局唯一ID的算法，生成的ID称为Snowflake IDs。这种算法由Twitter创建，并用于推文的ID。
一个snowflake是64位
第一位代表正负，1代表负数、0代表整数，一般ID都是整数，所以默认是0；
接下来的41位是时间戳，自选定日期以来的毫秒数；
接下来的10位代表计算机ID；
最后12位代表这个机器生成的ID序列码，允许在同一毫秒内创建多少个snowflake ID
当然，全局唯一ID还可以使用美团的Leaf，百度的Uidgenerator.
4.2 幂等设计的基本流程
幂等设计归根结底是过滤一下请求，要过滤请求，必须满足两个条件，全局唯一ID，请求记录被保存，当收到请求时，优先查询请求记录，记录存在则返回结果，不存在则处理请求并记录，然后返回结果。
5 实现幂等设计的8中方案幂等设计的基本流程都一致，简单概括起来有8中实现方案
5.1 select + Insert + 主键/唯一索引冲突当请求过来，根据唯一流水号查询请求记录记录存在直接返回结果记录不存在，插入记录，记录插入成功，返回结果，插入报主键冲突，根据已经插入的记录返回结果。
伪代码如下：
/**
* 幂等处理
*/
Rsp idempotent（Request req）{
Object requestRecord =selectByBizSeq（bizSeq）;
if(requestRecord !=null){
//拦截是重复请求
log.info("重复请求，直接返回成功，流水号：{}",bizSeq);
return rsp;
}
try{
insert(req);
}catch(DuplicateKeyException e){
//拦截是重复请求，直接返回成功
log.info("主键冲突，是重复请求，直接返回成功，流水号：{}",bizSeq);
return rsp;
}
//正常处理请求
dealRequest(req);
return rsp;
}
5.2 直接Insert + 主键/唯一索引冲突
5.1 的方案中先判断了请求是否存在，如果并发度不是很高的时候，可以跳过查询，根据主键冲突判重。
伪代码如下：
/**幂等处理 */*/Rsp idempotent（Request req）{ try{ insert(req); }catch(DuplicateKeyException e){ //拦截是重复请求，直接返回成功 log.info("主键冲突，是重复请求，直接返回成功，流水号：{}",bizSeq); return rsp; } //正常处理请求 dealRequest(req); return rsp;}
5.3 状态机
很多业务表都是有状态，如转账流水表，状态一般有0：待处理；1：处理中；2：成功；3：失败，转账流水的更新一般都会有状态的变更，即状态机（状态变更图）。比如转账成功后，把处理中的转账流水更新为成功状态，SQL这么写：
update transfr_flow set status=2 where biz_seq=‘666’ and status=1;
伪代码如下：
Rsp idempotentTransfer（Request req）{String bizSeq = req.getBizSeq();int rows= "update transfr_flow set status=2 where biz_seq=#{bizSeq} and status=1;"
if(rows==1){ log.info(“更新成功,可以处理该请求”); //其他业务逻辑处理 return rsp;}else if(rows==0){ log.info(“更新不成功，不处理该请求”); //不处理，直接返回 return rsp;} log.warn("数据异常") return rsp：
}
5.4 抽取防重表
5.1和5.2的方案，都是建立在业务流水表上bizSeq的唯一性上。很多时候，我们业务表唯一流水号希望后端系统生成，又或者我们希望防重功能与业务表分隔开来，这时候我们可以单独搞个防重表。当然防重表也是利用主键/索引的唯一性，如果插入防重表冲突即直接返回成功，如果插入成功，即去处理请求。
5.5 token令牌
为每个请求生成一个唯一的Token，并在服务端进行校验，一旦处理了对应的请求，就丢弃该Token，避免重复处理。具体步骤：
1、服务端提供了发送 token 的接口。我们在分析业务的时候，哪些业务是存在幂等问题的， 就必须在执行业务前，先去获取 token，服务器会把 token 保存到 redis 中。
2、然后调用业务接口请求时，把 token 携带过去，一般放在请求头部。
3、服务器判断 token 是否存在 redis 中，存在表示第一次请求，然后删除 token,继续执行业务。
4、如果判断token不存在redis中，就表示是重复操作，直接返回重复标记给 client，这样就保证了业务代码，不被重复执行。
核心逻辑：
// 服务端接口，接收请求并处理token
void do(String token) {
if (Redis.exists(token)) {
// 删除token，确保不会重复处理
Redis.del(token);
// 执行具体的业务操作
doSometing();
} else {
log.info(token);
}
}
注意：最好设计为先删除 token，如果业务调用失败，就重新获取 token 再次请求。可以在 redis 使用 lua 脚本完成这个操作
if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end
5.6 悲观锁
通俗点讲就是很悲观，每次去操作数据时，都觉得别人中途会修改，所以每次在拿数据的时候都会上锁。官方点讲就是，共享资源每次只给一个线程使用，其它线程阻塞，用完后再把资源转让给其它线程。
悲观锁如何控制幂等的呢？就是加锁呀，一般配合事务来实现。
伪代码如下：
begin; # 1.开始事务select * from order where order_id='666' # 查询订单，判断状态if（status !=处理中）{//非处理中状态，直接返回；return ;}## 处理业务逻辑update order set status='完成' where order_id='666' # 更新完成commit; # 5.提交事务
这里面order_id需要是索引或主键哈，要锁住这条记录就好，如果不是索引或者主键，会锁表的！
悲观锁在同一事务操作过程中，锁住了一行数据。别的请求过来只能等待，如果当前事务耗时比较长，就很影响接口性能。所以一般不建议用悲观锁做这个事情。
5.7 乐观锁
通过记录数据的版本号或时间戳，仅当数据未被其他事务修改时，才允许更新操作执行。每次更新数据时，版本号都会递增。
UPDATE orders
SET
quantity = 1,
order_status = 1,
pay_time = '2024-04-30 10:20:00',
version = version + 1
WHERE
order_id = 'ORD-20231023-0001' AND
version = 1;
效果演示：
如果 Session-01 已经提交了事务，Session-02 的更新操作将不会影响任何行，因为 version 已经从 1 增加到了 2。
5.8 分布式锁
分布式锁实现幂等性的逻辑就是，请求过来时，先去尝试获得分布式锁，如果获得成功，就执行业务逻辑，反之获取失败的话，就舍弃请求直接返回成功。执行流程如下图所示：
分布式锁可以使用Redis，也可以使用ZooKeeper，不过还是Redis相对好点，因为较轻量级。
Redis分布式锁，可以使用命令SET EX PX NX + 唯一流水号实现，分布式锁的key必须为业务的唯一标识哈
Redis执行设置key的动作时，要设置过期时间哈，这个过期时间不能太短，太短拦截不了重复请求，也不能设置太长，会占存储空间，处理完成，要在finally中删除锁。
