重复提交-系统幂等性设计

幂等性

• 什么是幂等性

HTTP/1.1中对幂等性的定义是：一次和多次请求某一个资源对于资源本身应该具有同样的结果（网络超时等问题除外）。也就是说，其任意多次执行对资源本身所产生的影响均与一次执行的影响相同。

简单来说，是指无论调用多少次都不会有不同结果的 HTTP 方法。

• 什么情况下需要幂等

业务开发中，经常会遇到重复提交的情况，无论是由于网络问题无法收到请求结果而重新发起请求，或是前端的操作抖动而造成重复提交情况。 在交易系统，支付系统这种重复提交造成的问题有尤其明显，比如：

1. 用户在APP上连续点击了多次提交订单，后台应该只产生一个订单；
2. 向支付宝发起支付请求，由于网络问题或系统BUG重发，支付宝应该只扣一次钱。 很显然，声明幂等的服务认为，外部调用者会存在多次调用的情况，为了防止外部多次调用对系统数据状态的发生多次改变，将服务设计成幂等。

解决方案

1. 乐观锁：基于版本号version实现, 在更新数据那一刻校验数据（会出现ABA问题）

2. 布式锁：redis 或 zookeeper 实现

3. version令牌： 防止页面重复提交

4. 防重表：防止新增脏数据

5. 消息队列：把请求快速缓冲起来，然后异步任务处理，优点：提高吞吐量，不足：不能及时响应返回对应结果，需要后续接口监听异步接口

实现幂等性
本次采用version令牌的方式实现幂等性，即采用 redis + version机制拦截器实现接口幂等性校验；

实现思路：

• 首先网关是全部请求的入口点，为了保证幂等性，即需要全局统一的version机制，先获取version，并且把version放入到redis中，然后请求业务接口时候，将上一步获取的version，放到header中（或者参数中）进行请求
• 服务端接收到对应的请求，首先采用拦截器的方式拦截对应参数，去redis中查找是否有存在该version
• 如果存在，执行业务逻辑之前在删除version，那么如果重复提交，由于version被删除，则返回给客户端提示 参数异常
• 如果本身就不存在，直接说明参数不合法