java幂等性处理

这两天在对接别人接口的时候发现了一个问题。别人通过调我接口给我传消息，当然不是通过mq，而是直接调。然后发现，他一条消息调我好几次接口，导致产生许多的脏数据。后来我们老大说用幂等处理下，当时我是懵的，没用过。然后我就上网查了下，原来是这样。。。。现在遇到了这个问题，所以现在就总结下

什么是幂等？
一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。
简单来说就是一个操作无论整多少次，产生的效果和返回的结果都是一样的。

幂等场景
查询操作
查询一次和查询多次，在数据不变的情况下，查询结果是一样的。select是天然的幂等操作。

表单提交类
按钮在没有新的编辑情况下置灰，不允许重复点击，数据库UK（唯一索引）限制。Token令牌的方式,取得令牌则操作实际业务,否则返回。或者搞个请求定时器限制。

订单支付
支付相关业务幂等的处理十分重要，比如重复的下单，三方接口的回调这些都会造成幂等问题。
订单生成采用全局唯一ID方案，然后结合数据库唯一索引保证订单的唯一性，并且后续所有业务都需要此订单号做逻辑处理。唯一索引可以防止新增脏数据。（当表存在唯一索引，并发时新增报错时，可以先查询一次，如果数据应该已经存在了，返回结果即可）；

MQ消息幂等
MQ作为异步解耦的中间件，我们业务开发经常使用，比如用它来处理异步逻辑。但是MQ的生产者和消费者同样存在幂等问题，即重复消息，重复消费等问题。
重复消费的处理可能还好说点，消费一般是新增或者修改之类，订单一般都是唯一的，你可以先查询一下，如果这数据都有了，你就别插入了，更新一下好吧。
那重复发消息呢？RocketMQ不保证消息不重复，如果你的业务需要保证严格的不重复消息，需要你自己在业务端去重。

悲观锁
获取数据的时候加锁获取。select * from xxx where id=‘xxx’ for update; 注意：id字段一定是主键或者唯一索引，不然是锁表，会死人的；悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用；一般使用场景用于写的场景多点。

乐观锁
乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。乐观锁的实现方式多种多样可以通过version或者其他状态条件：

1. 通过版本号实现update table_xxx set name=#name#,version=version+1 where version=#version#；
2. 通过条件限制 update table_xxx set avai_amount=avai_amount-#subAmount# where avai_amount-#subAmount# >= 0要求：quality-#subQuality# >= ，这个情景适合不用版本号，只更新是做数据安全校验，适合库存模型，扣份额和回滚份额，性能更高；一般使用场景用于读的场景多点。注意：乐观锁的更新操作，最好用主键或者唯一索引来更新,这样是行锁，否则更新时会锁表，。

分布式锁

如果是分布式系统，构建全局唯一索引比较困难，例如唯一性的字段没法确定，这时候可以引入分布式锁，通过第三方的系统(redis或zookeeper)，在业务系统插入数据或者更新数据，获取分布式锁，然后做操作，之后释放锁，这样其实是把多线程并发的锁的思路，引入多多个系统，也就是分布式系统中得解决思路。要点：某个长流程处理过程要求不能并发执行，可以在流程执行之前根据某个标志(用户ID+后缀等)获取分布式锁，其他流程执行时获取锁就会失败，也就是同一时间该流程只能有一个能执行成功，执行完成后，释放分布式锁(分布式锁要第三方系统提供)；

select + insert
并发不高的后台系统，或者一些任务JOB，为了支持幂等，支持重复执行，简单的处理方法是，先查询下一些关键数据，判断是否已经执行过，在进行业务处理，就可以了。注意：核心高并发流程不要用这种方法；

对外提供接口的api如何保证幂
如银联提供的付款接口：需要接入商户提交付款请求时附带：source来源，seq序列号；source+seq在数据库里面做唯一索引，防止多次付款(并发时，只能处理一个请求) 。
重点：对外提供接口为了支持幂等调用，接口有两个字段必须传，一个是来源source，一个是来源方序列号seq，这个两个字段在提供方系统里面做联合唯一索引，这样当第三方调用时，先在本方系统里面查询一下，是否已经处理过，返回相应处理结果；没有处理过，进行相应处理，返回结果。注意，为了幂等友好，一定要先查询一下，是否处理过该笔业务，不查询直接插入业务系统，会报错，但实际已经处理了。