分布式系统接口幂等实现

1.背景

最近的系统中使用了springCloud微服务框架，这种分布式框架的确提供了非常多便利的地方，不过随之也出现了很多的问题，特别是在实际开发中，接口的幂等性。

而所谓的幂等，通俗点说就是一个操作不管请求多少次返回的结果都是一样的，比如支付、扣除库存、扣除积分等等，如果因为网络问题而出现多扣、多加、多新增数据的问题，

不仅会影响用户体验，数据的维护也非常的困难。

2.概念

幂等：在编程中一个幂等操作中任意多次执行产生的影响均与一次执行的影响相同。幂等函数或者方法，是指可以使用相参数重复执行，并能获取相同结果的函数。这些函数不会影响系统状态。

3.具体实现

a)、增加唯一索引

就比如一个用户签到赠送积分的场景，用户进入程序的首页就触发签到程序，主动给用户签到，并且赠送积分。但是由于网络的问题，前端同一个用户的签到触发了两次请求，积分也赠送了两次。

程序的初始也做了一些基本的重复签到处理，如select + insert，查询某用户是否签到过，然后再进行签到。虽然能简单有效的控制重复签到的问题，但是高并发的情况下，而且是在分布式框架中，select + insert 就显得非常的无力。那么唯一索引就非常好的解决了这个问题。设计签到表时，把用户的ID和签到日期作为表的联合唯一主键，这样签到表中无论什么情况下只可能存在一条签到数据，积分也可能赠送一次。

b)、乐观锁和悲观锁

乐观锁和悲观锁通常也用于数据重复多次提交、并发删除更新等问题。

详情可看文章：http://blog.csdn.net/zhangwj0101/article/details/50946054

c)、token机制，前端防止重复提交

数据提交前向服务器申请token，token放到redis中，提交后后台校验token，同时删除tonken，保证了每个请求只有一个tonken。

不过要注意的点是，这种方式通过删除token结果来校验token的正确性。

如果删除前加了查询（select）再删除来校验token，那么又会引发并发问题，存在隐患。

d)、分布式锁

目前分布式锁的实现可以借助第三方的工具实现，缓存（redis）、zookeeper，也可以基于数据库实现分布式锁。

那么分布式锁会加入考虑中，必然要保证在项目集群中，获取锁和释放锁的性能要好，而且要避免死锁。

参考文章：http://blog.csdn.net/zxp_cpinfo/article/details/53692922

更多的方法的实现欢迎大家指导交流。