在实际的项目中我们有很多操作，如api请求，订单付款，发送消息，防重复提交等。不管我们做了多少次，其实应该产生一样的效果或返回一样的结果。这些就需要使用幂等的特性来支持。
什么是幂等？幂等我自己理解为系统统一规则设计，承诺只要调接口成功，多次调用的结果保持一致。声明为幂等的服务会认为外部调用失败是常态，并且失败之后必然会有重试。
如何保证幂等：
1、token机制
业务场景：页面数据只能被点击一次。
发生原因：由于重复点击或者网络重发，或者nginx重发等情况会导致数据被重复提交
解决方式：采用token加redis（redis单线程的，处理需要排队）
基本的处理就是提交后台校验token，同时删除token，生成新的token返回
关键点：先删除token,还是后删除token
后删除token：如果进行业务处理成功后，删除redis中的token失败了，这样就导致了有可能会发生重复请求，因为token没有被删除。这个问题其实是数据库和缓存redis数据不一致问题，后续会写文章进行讲解。
先删除token：如果系统出现问题导致业务处理出现异常，业务处理没有成功，接口调用方也没有获取到明确的结果，然后进行重试，但token已经删除掉了，服务端判断token不存在，认为是重复请求，就直接返回了，无法进行业务处理了。
先删除token可以保证不会因为重复请求，业务数据出现问题。出现业务异常，可以让调用方配合处理一下，重新获取新的token，再次由业务调用方发起重试请求就ok了。
token优缺点：
不足之处：就是要申请，一次有效性，额外的请求（一次获取token请求、判断token是否存在的业务）。其实真实的生产环境中，1万请求也许只会存在10个左右的请求会发生重试，为了这10个请求，我们让9990个请求都发生了额外的请求
优点：可以限流
2、 悲观锁
获取数据的时候加锁获取
select * from table_xxx where id='xxx' for update;
注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的
悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用
3、乐观锁
乐观锁适合在更新的场景中，update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 1
根据version版本，也就是在操作库存前先获取当前商品的version版本号，然后操作的时候带上此version号。流程为第一次操作库存时，得到version为1，调用库存服务version变成了2；但返回给订单服务出现了问题，订单服务又一次发起调用库存服务，当订单服务传如的version还是1，再执行上面的sql语句时，就不会执行；因为version已经变为2了，where条件就不成立。这样就保证了不管调用几次，只会真正的处理一次。乐观锁主要使用于处理读多写少的问题
4、防重表
适用于在业务中有唯一标的插入场景中，比如在以上的支付场景中，如果一个订单只会支付一次，所以订单ID或者订单编号，支付标号等可以作为唯一标识。这时，我们就可以建一张去重表，并且把唯一标识作为唯一索引，在我们实现时，把创建支付单据和写入去去重表，放在一个事务中，如果重复创建，数据库会抛出唯一约束异常，操作就会回滚。
5、唯一主键
这是利用了数据库的主键唯一约束的特性，解决了在insert场景时幂等问题。但主键的要求不是自增的主键，这样就需要业务生成全局唯一的主键。
如果是分库分表场景下，路由规则要保证相同请求下，落地在同一个数据库和同一表中，要不然数据库主键约束就不起效果了，因为是不同的数据库和表主键不相关。
