1、什么是幂等性
API Idempotency就是用户对于同一操作发起的一次请求或者多次请求的结果是一致的，不会因为多次点击而产生了副作用；比如说支付场景，用户购买了商品支付扣款成功，但是返回结果的时候网络异常，此时钱已经扣了，用户再次点击按钮，此时会进行第二次扣款，返回结果成功，用户查询余额返发现多扣钱了，流水记录也变成了两条…，这就没有保证接口的幂等性。
2、哪些情况需要防止
用户多次点击按钮 用户页面回退再次提交 Microservices互相调用，由于网络Problem，导致请求失败。feign触发重试Mechanism其他业务情况
3、什么情况下需要幂等
天然Idempotent的：以SQL为例，有些操作是。
SELECT*FROM table WHERid=？无论Execute多少次都不会改变状态，是天然的Idempotent。
UPDATE tab1 SET col1=1WHERE col2=2 无论Execute成功多少次状态都是一致的，也是Idempotent操作。
delete from user where userid=1多次操作，结果一样，具备Idempotency
insert into user（userid，name）values（1，a）如userid为唯一主键，即重复操作上面的业务，只会插入一条用户Data，具备Idempotency。
不是Idempotent的
UPDATE tab1 SET col1=col1+1WHERE col2=2每次Execute的结果都会发生变化，不是Idempotent的。
insert into user（userid，name）values（1，a）如userid不是主键，可以重复，那上面业务多次操作，Data都会新增多条，不具备Idempotency。
4、幂等解决方案
一、token机制
1、Service端提供了发送token的Interface。我们在分析业务的时候，哪些业务是存在IdempotentProblem的，就必须在Execute业务前，先去Gettoken，Server会把token保存到redis中。
2、然后调用业务Interface请求时，把token携带过去，一般放在Request Header部。 3、Server判断token是否存在redis中，存在表示第一次请求，然后删除token，继续Execute业务。
4、如果判断token不存在redis中，就表示是重复操作，直接Return重复标记给client，这样就保证了业务Code，不被重复Execute。
危险性： 1、先删除token 还是后删除token； （1）先删除可能导致，业务确实没有Execute，重试还带上之前token，由于防重Design导致，请求还是不能Execute。 （2）后删除可能导致，业务处理成功，但是Service闪断，出现超时，没有删除 token，别人继续重试，导致业务被Execute两边 （3）我们最好Design为先删除token，如果业务调用失败，就重新Gettoken 再次请求。 2、TokenGet、比较和删除必须是原子性 （1）redis.get（token）、token.equals、redis.delltoken）如果这两个操作不是原子，可能导致，高Concurrency下，都get 到同样的Data，判断都成功，继续业务ConcurrencyExecute
（2）可以在redis UsageluaScript完成这个操作
if redis. call("get', KEYS[1])==ARGV[1] then return redis. call(' del", KEYS[1]) else return 0 end二、各种锁机制
1、Database悲观Lock
select*from xxxx where id=1 for update；悲观LockUsage时一般伴随Transaction一起Usage，DataLock定时间可能会很长，需要根据实际情况选用。另外要注意的是，id字段一定是主键或者唯一Indexing，不然可能造成Lock表的结果，处理起来会非常麻烦。 2、Database乐观Lock 这种Method适合在更新的场景中
update t_goods set count=count-1，version =version+1 where good_id=2 and version=1根据 versionVersion，也就是在操作Library存前先Get当前商品的 version Version号，然后操作的时候带上此version号。我们梳理下，我们第一次操作Library存时，得到version为1，调用Library存Serviceversion变成了2；但Return给订单Service出现了Problem，订单Service又一次发起调用Library存Service，当订单Service传如的version还是1，再Execute上面的sql语句时，就不会Execute；因为version已经变为2了，where条件就不成立。这样就保证了不管调用几次，只会真正的处理一次。 乐观Lock主要Usage于处理读多写少的Problem。
3、业务层分怖式Lock 如果多个机器可能在同一时间同时处理相同的Data，比如多台机器Scheduled Tasks都拿到了相同Data处理，我们就可以加Distributed Lock，Lock定此Data，处理完成后释放Lock。Get到Lock的必须先判断这个Data是否被处理过。
3、各种唯一约束
1、Database唯一Constraints 插入Data，应该按照唯一Indexing进行插入，比如订单号，相同的订单就不可能有两条记录插入。 我们在Database层面防止重复。 这个Mechanism是利用了Database的主键唯一Constraints的Features，解决了在insert场景时IdempotentProblem。但主键的要求不是自增的主键，这样就需要业务生成全局唯一的主键。 如果是分Library分表场景下，路由规则要保证相同请求下，落地在同一个Database和同一表中，要不然Database主键Constraints就不起效果了，因为是不同的Database和表主键不相关。 2、redis set防重 很多Data需要处理，只能被处理一次，比如我们可以计算Data的MD5将其放入redis的set，每次处理Data，先看这个MD5是否已经存在，存在就不处理。
4、防重表
Usage订单号orderNo做为去重表的唯一Indexing，把唯一Indexing插入去重表，再进行业务操作，且他们在同一个Transaction中。这个保证了重复请求时，因为去重表有唯一Constraints，导致请求失败，避免了IdempotentProblem。这里要注意的是，去重表和业务表应该在同一Library中，这样就保证了在同一个Transaction，即使业务操作失败了，也会把去重表的Data回滚。这个很好的保证了Data Consistency。redis防重也算。
5、全局请求唯一id
调用Interface时，生成一个唯一id，redis 将Data保存到集合中（去重），存在即处理过。 可以UsagenginxSettings每一个请求的唯一id；proxy_set_header X-Request-ld Srequest_id；
