系统幂等性设计与实践

幂等性

什么是幂等性

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被删除,则返回给客户端提示 参数异常
- 如果本身就不存在,直接说明参数不合法

发布了11 篇原创文章 · 获赞 0 · 访问量 166

猜你喜欢

转载自blog.csdn.net/sdjxgd/article/details/105200696