幂等相关(一)
日常开发中，有很多例子需要考虑幂等
比如提交form表单时，如果快速点击提交按钮，可能产生了两条一样的数据（前端重复提交，下单，用户注册等）
MQ（消息中间件）消费者读取消息时，有可能会读取到重复消息。（重复消费）
幂等意味着一条请求的唯一性。不管是你哪个方案去设计幂等，都需要一个全局唯一的ID，去标记这个请求是独一无二的。
- 如果你是利用唯一索引控制幂等，那唯一索引是唯一的
- 如果你是利用数据库主键控制幂等，那主键是唯一的
- 如果你是悲观锁的方式，底层标记还是全局唯一的ID
幂等设计的基本流程
幂等处理的过程，说到底其实就是过滤一下已经收到的请求，当然，请求一定要有一个全局唯一的ID标记哈。然后，怎么判断请求是否之前收到过呢？把请求储存起来，收到请求时，先查下存储记录，记录存在就返回上次的结果，不存在就处理请求。
实现幂等的8种方案
1. select+insert+主键/唯一索引冲突
日常开发中，为了实现交易接口幂等，我是这样实现的：
交易请求过来，我会先根据请求的唯一流水号 bizSeq字段，先select一下数据库的流水表
- 如果数据已经存在，就拦截是重复请求，直接返回成功；
- 如果数据不存在，就执行
insert插入，如果insert成功，则直接返回成功，如果insert产生主键冲突异常，则捕获异常，接着直接返回成功
2.直接insert + 主键/唯一索引冲突
在1方案中，都会先查一下流水表的交易请求，判断是否存在，然后不存在再插入请求记录。如果重复请求的概率比较低的话，我们可以直接插入请求，利用主键/唯一索引冲突，去判断是重复请求。
3.状态机幂等
很多业务表，都是有状态的，比如转账流水表，就会有0-待处理，1-处理中、2-成功、3-失败状态。转账流水更新的时候，都会涉及流水状态更新，即涉及状态机 (即状态变更图)。我们可以利用状态机实现幂等，一起来看下它是怎么实现的。
比如转账成功后，把处理中的转账流水更新为成功状态，SQL这么写：
1 | update transfr_flow set status=2 where biz_seq=‘666’ and status=1; |
4.抽取防重表
1和2的方案，都是建立在业务流水表上的唯一性上。很多时候，我们业务表唯一流水号希望后端系统生成，又或者我们希望防重功能与业务表分隔开来，这时候我们可以单独搞个防重表。当然防重表也是利用主键/索引的唯一性，如果插入防重表冲突即直接返回成功，如果插入成功，即去处理请求。
5.token令牌
token 令牌方案一般包括两个请求阶段：
客户端请求申请获取token，服务端生成token返回
客户端带着token请求，服务端校验token
流程如下：
客户端发起请求，申请获取token。
服务端生成全局唯一的token，保存到redis中（一般会设置一个过期时间），然后返回给客户端。
客户端带着token，发起请求。
服务端去redis确认token是否存在，一般用 redis.del(token)的方式，如果存在会删除成功，即处理业务逻辑，如果删除失败不处理业务逻辑，直接返回结果。
6.悲观锁
一般配合事务来实现，查询的时候加锁(如select for update)
7.乐观锁
给表的加多一列version版本号，每次更新记录version都升级一下（version=version+1）。具体流程就是先查出当前的版本号version，然后去更新修改数据时，确认下是不是刚刚查出的版本号，如果是才执行更新
8.分布式锁
分布式锁实现幂等性的逻辑就是，请求过来时，先去尝试获得分布式锁，如果获得成功，就执行业务逻辑，反之获取失败的话，就舍弃请求直接返回成功。
