自定义注解，基于Redis实现接口幂等性

一、幂等性概念

幂等(idempotent、idempotence)是一个数学与计算机学概念，常见于抽象代数中。

在编程中，一个幂等操作的特点是其任意多次执行所产生的影响均与一次执行的影响相同。幂等函数，或幂等方法，是指可以使用相同参数重复执行，并能获得相同结果的函数。这些函数不会影响系统状态，也不用担心重复执行会对系统造成改变。

幂等就是一个操作，不论执行多少次，产生的效果和返回的结果都是一样的。

二、技术方案

1.数据库唯一索引

对于插入类的操作，一般都是建议要在数据库表中设计一些唯一索引或唯一组合索引来防止新增数据存在脏数据。

2. 悲观锁

获取数据的时候加锁获取

select * from table_xxx where id='xxx' for update;

注意：id字段一定是主键或者唯一索引

悲观锁使用时一般伴随事务一起使用，数据锁定时间可能会很长，根据实际情况选用。

3. 乐观锁

乐观锁只是在更新数据那一刻锁表，其他时间不锁表，所以相对于悲观锁，效率更高。

乐观锁可以通过version或者其他状态条件实现：

(1)通过版本号实现

update table_xxx set name=#name#,version=version+1 where version=#version#

(2)通过条件限制

update tablexxx set avaiamount=avaiamount-#subAmount# where avaiamount-#subAmount# >= 0

要求：quality-#subQuality# >= ，这个情景适合不用版本号，只更新是做数据安全校验，适合库存模型，扣份额和回滚份额，性能更高。

注意：乐观锁的更新操作，最好用主键或者唯一索引来更新,这样是行锁，否则更新时会锁表，上面两个sql改成下面的两个更好

update tablexxx set name=#name#,version=version+1 where id=#id# and version=#version#

update tablexxx set avaiamount=avaiamount-#subAmount# where id=#id# and avai_amount-#subAmount# >= 0

4. 基于Redis实现防重

(1)背景

电商系统中，订单创建后，一般会去调用库存服务去扣减库存。

订单服务调用库存服务的时候，因为网络抖动，请求超时了，超过了秒钟，此时订单服务会重试，再次调用一下库存服务，发送一模一样的请求过去。

比如说，订单服务第一次请求库存服务，库存服务其实是把扣减库存的业务逻辑执行成功了，只不过网络问题，导致响应迟迟没有返回给订单服务，可能在1.2s之后返回了响应给订单服务。订单服务就认为请求超时了，他就再次发送了一个一模一样的请求给库存服务，库存服务可能会再次对库存进行扣减。

(2)实现思路

定制化的去针对接口开发幂等性的机制，比如说一旦库存扣减成功之后，就立马要写一条数据到redis里去，如：order_id_11356_stock_deduct，写入redis中，如果写入成功，就说明之前这个订单的库存扣减，没人执行过。但是如果此时有一些重试的请求过来了，调用了你的库存扣减接口，他同时也进行了库存的扣减，但是他用同样的一个key，order_id_11356_stock_deduct，写入redis中，此时会发现已经有人写过key，key已经存在了。此时你就应该直接对刚才的库存扣减逻辑做一个反向的回滚逻辑，将之前扣减的库存加回来。update product_stock set stock = stock + 100，反向逻辑，回滚掉，这样就可以解决重复扣减库存的问题。

(3)具体代码实现