【IT老齐020】接口幂等性
传统方案
业务代码增加前置判断
if(数据未更新){ 更新数据 }
缺点
- 判断因素过多
- 技术问题干扰业务代码
通用方案
幂等表
架构方案 nginx+lua+redis
- 请求经过nginx转发到redis，redis查找幂等表是否存在请求id（uuid或请求hash）对应的key
- 幂等表不存在请求id
- lua脚本保存到幂等表并设置请求状态（PROC）及存活时间
- 处理请求，处理结束后更新幂等表请求状态（OK）（无论请求结果如何）并返回结果
- 幂等表存在请求id
- 直接返回201，前台自动排除
使用自定义注解，利用@AOP After通知，更新Redis状态
过期时间作用
- redis占用内存，幂等表数据过多，会导致系统响应变慢。设置过期时间使数据总量处于低水位
- 服务处理未即使更新redis幂等表。设置过期时间使请求重新可用
优点
- 后台服务无代码侵入，无需修改业务逻辑
缺点
- 前台应用要针对幂等进行改造
- 架构复杂度增加，需要额外部署Nginx、Redis
拓展
- 数据量大的接口保证幂等？
- 首先大多数幂等有效期不需要很长时间，在业务允许的前提下可以考虑缩短过期时间，其次数据量大是不怕的，怕是在数据间的耦合太大导致服务无法水平扩展，只要能保证扩展，qps就能打下来
- 如果应用系统发出一个新请求，应用网关成功将requestId存入redis，而此时网关向数据服务转发请求时失败。在key失效前应用系统的重试机制是不是不管用了？网关转发请求到数据服务，网关自身有重试吗？
- 网关不做重试否则幂等就被破坏了。 由网关转发失败导致的情况确实有，极少数不考虑
- 区分那些url请求是要幂等处理呢？
- 查询的接口可以在请求的时候不带requestId，网关判断没有id就不存redis，切面判断没有id就不去该redis
- 加在nginx去处理会增加复杂度，直接用redis分布式锁不是也可以实现么？为什么不用redis分布式锁呢？这里nginx去redis进行nx操作，实际上也是分布式锁的一种实现
- 降低服务端的负荷，让无效的请求不要穿透到服务端处理。
- 后端发生错误时，redis一直会保持proc，retry的请求进不来，而redis的过期又必须覆盖retry的最大尝试时间，不然在极端情况下最后的retry还是会被错误的处理。如何解决？
- 在后端程序发生了非逻辑错误的时候，比如依赖的其他组件或服务发生错误时，必须去处理redis中数据的状态或删除，以保证后续的retry请求能进来。