解决方案.gif
典型幂等策略
幂等处理的一般流程.png
唯一索引策略（极少使用）
1.select+insert+唯一索引冲突
//1.根据幂等号查询幂等记录
Record record = dao.select(param);
if (record != null){
//2.幂等记录存在，直接返回幂等结果或根据记录状态（如失败可重试）进一步处理
}else{
try{
//3.幂等记录不存在，插入幂等记录
dao.insert(entity);
//4.插入成功，执行业务逻辑
}catch(DuplicateKeyException e){
//5/插入失败，若为重复异常，直接返回幂等结果或进一步处理
record = dao.select(param);
//6.处理逻辑
}catch(Throwable tr){
//7.其他异常处理逻辑
}
}
2.insert+唯一索引冲突
//1.插入幂等记录
try{
//2.插入成功，执行业务逻辑
dao.insert(entity);
}catch(DuplicateKeyException e){
//3.插入失败且为重复异常，直接返回幂等结果或进一步处理
dao.select(param);
//4.处理逻辑
}catch(Throwable tr){
//5.其他异常处理逻辑
}
数据库开销大，如果重复请求发生的概率较小，可优先选择2.insert+唯一索引冲突。
唯一索引需结合幂等记录状态变更管控+事务机制（数据库事务/分布式事务）+锁机制。
悲观锁策略（金融账务清算域常用方式）
//1.开启事务
begin;
//2.基于幂等号 biz_no 锁行查询
record = select * from table_name where biz_no='xxxx' for update
//3.没有相关幂等记录，说明是首次请求
if (record == null){
//4.初始化并插入幂等记录
insert(init(param))
//5.再次基于幂等号biz_no锁行查询
record = select * from table_name where biz_no='xxxx' for update
}
//6.锁行查询成功，根据记录判断决策处理方式
if (record.getStatus() != 预期状态){
//7.非预期状态，结束处理
return;
}
//8.预期状态，执行业务逻辑，如查询，更新流水等
//9.更新记录
update table_name set status ='目标状态' where biz_no='xxx';
//10.提交事务
commit
通过串性化实现幂等，资源占用较多
依靠数据库自身的特性来实现，实现成本低，结合了事务机制保障了较强的数据一致性，解决了请求并发、乱序等的问题
1.查询幂等数据的状态，如果是不可重试终态，直接返回；
2.如果是可重试终态，则进行重试（同一幂等号），涉及到下游则需要结合分布式事务
3.插入幂等记录TransactionTemplate REQUIRED_NEW
4.下游处理成功，则变更幂等记录状态
5.下游也必须是幂等的。
分布式锁
分布式幂等.png
SETNX keyName value,若keyName已存在于Redis中，则返回0；
若不存在，则返回1.
//1.尝试将keyName写入缓存
if(redis.setNx(keyName, 1) == 1){
//2.写入成功，即获取锁成功，继续执行业务逻辑
//3.执行完成，释放锁（为了防止误释放，可采用LUA脚本）
}else{
//4.写入失败，即获取锁失败，要么直接返回，要么等待、重试
}
需结合事务机制和重试机制形成完整方案。
事务机制用于保证业务逻辑的数据一致性；重试机制是基于持久化的幂等记录进行失败重试，保证最终一致性。
还存在释放锁操作可能失败的情况。一旦释放锁操作失败，就会导致一段时间内记录一直在缓冲中，其他线程无法获得锁。
即使设置了失效时间，在有效期内仍会存在问题。失效时间过短，业务逻辑执行完前释放锁，失效时间过长，其他尝试获取锁的过程就需要等待，甚至可能超时。
解决幂等问题的关键
- 1.唯一性约束
- 2.执行唯一性检查
解决幂等问题的实现方式
唯一索引：数据库唯一索引，唯一索引可以基于业务流水建立，也可以单独建表实现；
唯一数据：悲观锁、乐观锁、分布式锁等锁机制；
状态机约束：对于存在状态流转的业务，通过状态机的流转约束，可以实现有限状态机的幂等。
