幂等性的方案

定义：任意多次的请求对于资源的影响与一次请求的影响相同

重点：

第一次请求对资源产生了影响（查询操作除外），后边的请求对资源就没有影响了

幂等关注的是对于资源是否有影响，而不关注结果（影响是否成功，比如因为网络超时，操作失败等等）

需要幂等的业务场景：

前端操作抖动导致重复提交，因为网络问题导致的重试（例如dubbo服务超时重试），特别是在交易的业务场景中，不能因为多次提交出现多次扣款的情景，要将提供的服务保证幂等性

防重与幂等的区别：

在第一次请求成功的前提，人为多次操作，导致不满足幂等的服务的状态多次改变

幂等是在第一次请求不知道结果或者请求异常的情况下发起多次请求，目的是多次确认第一次的请求是否成功，而不会造成状态的变化

幂等的策略：

需要唯一的单号来保证业务的唯一性（例外：查询，删除具有天然的幂等性），不考虑并发的情况，实现并发一般分成两步：

1. 查询状态，如果已经产生影响，返回结果
2. 如果状态未变，修改状态，返回结果

思路就是保证1,2两步的原子性就可以保证幂等

幂等的方案：

• 乐观锁  例如： UPDATE tab1 SET col1=1,version=version+1 WHERE version=#version#
• 防重表  唯一单号作为去重表的唯一索引
• 分布式锁  流程类似于jvm中的锁的加锁和释放过程 
• 队列 原理同步变异步 将请求放入到队列中，后续使用异步任务处理请求，要异步通知结果

总结：幂等性非功能性的需求保证了接口的健壮