“接口幂等性”的版本间的差异
		
		
		
		
		
		跳到导航
		跳到搜索
		
				
		
		
	
Jihongchang(讨论 | 贡献)  (→引出问题)  | 
				Jihongchang(讨论 | 贡献)   (→引出问题)  | 
				||
| 第33行: | 第33行: | ||
=== 引出问题 ===  | === 引出问题 ===  | ||
如果真的像上面代码中那样的简单实现,前端调用系统每重发一次请求,1号员工的工资就会上调500,这种情况就是一般说的幂等性被破坏了。  | 如果真的像上面代码中那样的简单实现,前端调用系统每重发一次请求,1号员工的工资就会上调500,这种情况就是一般说的幂等性被破坏了。  | ||
| + | |||
| + | |||
| + | === 解决方案 ===  | ||
| + | 传统办法是代码增加前置判断<syntaxhighlight lang="java">  | ||
| + |         if (!员工已调薪) {  | ||
| + |             进行调薪  | ||
| + |         }  | ||
| + | </syntaxhighlight>  | ||
2023年3月5日 (日) 10:12的版本
https://www.bilibili.com/video/BV1J44y1k7Se
什么是幂等性
发一次接口调用与发多次相同的接口消息都能得到与预期相符的结果
作为前端的应用,应用系统往往需要和后台的数据服务进行交互,在这个交互的过程中通常会选择 RESTful 或者 RPC 的方式进行调用。
在这个过程中,以目前主流的 RESTful 为例:
在实际的开发过程中会遇到这样的情况——系统和系统之间(这里指的就是应用系统和数据服务)是通过网络来进行数据传输的,只要是网络就可能出现网络抖动的情况,那么为了保证系统的高可靠性,作为前端的调用系统,可能会增加像 Spring Retryable 这样的组件,通过不断重试发送相同的调用来尽可能地提高系统的可靠性,这是日常开发中非常常见的一种使用方式。
但是这种使用方式会带来一种附加的问题:作为后台服务,必须要考虑幂等性。
具体案例
PUT https://xxxxx.com/employee/salary {"id":"1","incr_salary":500}
这是一个 RESTful 接口,接口的作用是对 id=1 的员工工资上调 500
        //查询1号员工数据
        Employee employee = employeeService.selectById(1);
        //更新工资
        employee.setSalary(employee.getSalary() + incrSalary);
        //执行更新语句
        employeeService.update(employee);
这样实现看上去没有问题,但如果放在前面描述过的应用 Spring Retryable 这样的组件的系统和系统之间进行调用的环境中就没有考虑到幂等性的处理。
引出问题
如果真的像上面代码中那样的简单实现,前端调用系统每重发一次请求,1号员工的工资就会上调500,这种情况就是一般说的幂等性被破坏了。
解决方案
传统办法是代码增加前置判断
        if (!员工已调薪) {
            进行调薪
        }
