中国建设工程造价信息网站,网站网站做代理赚钱吗,做网站头视频,网站建设项目计划书1.1 概述
所谓幂等: 多次调用方法或者接口不会改变业务状态#xff0c;可以保证重复调用的结果和单次调用的结果一致。 基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析
举个例子:
假如你有个某多多 有个服务 服务提供一个接口#xff0c;结果这个服务部署在…
1.1 概述
所谓幂等: 多次调用方法或者接口不会改变业务状态可以保证重复调用的结果和单次调用的结果一致。 基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析
举个例子:
假如你有个某多多 有个服务 服务提供一个接口结果这个服务部署在了5台机器上接着有个接口就是砍一刀的接口。 然后用户在前端上操作的时候不知道为啥总之就是一个砍一个订单 不小心发起了两次砍一刀请求然后这俩请求分散在了这个服务部署的不同的机器上结果造成一个用户被砍了扣两次。
所谓幂等性就是说一个接口多次发起同一个请求你这个接口得保证结果是准确的比如不能多扣款不能多插入一条数据不能将统计值多加了1。。 1.2 需要幂等的场景
1.2.1 网络波动
因网络波动可能会引起重复请求
1.2.2 MQ消息重复
生产者已把消息发送给MQ在MQ给生产者返回ack的时候网络中断故生产者未收到确定消息生产者认为消息未发送成功。但实际情况是MQ已成功接收到了消息在网络重连后生产者会重新发送刚才的消息造成MQ接收了重复的消息。
1.2.3 用户重复点击
用户在使用产品时可能会误操作而触发多笔交易或因为长时间没有响应而有意触发多笔交易。
1.2.4 应用使用失败或超时重试机制; 为了考虑系统业务稳定性开发人员一般设计系统时会考虑失败了如何进行下一步操作或等待一定时间继续前端的动作的。
1.3 后端解决方案
数据库唯一索引
使用数据库提供的唯一索引来保证数据重复插入避免脏数据产生 解决场景新增
tokenredis
● 第一次请求 ○ 在后端生成一个唯一的token(比如key:userid,value:UUID) ○ 将token存储到redis中 ○ 将token返回前端
● 第二次请求 ○ 在真正处理业务的时候需要携带过来之前的token ○ 到redis中查询token是否存在 ○ 如果存在则正常处理业务同时删除redis中的token ○ 如果不存在则操作失败 解决场景新增、删除、修改
分布式锁
在分布式锁使用的时候要注意粒度 在操作数据时先添加一个分布式锁当操作完成后再释放掉这把锁同时在操作过程中如果有人来抢锁应当抛出异常即
if (!lock) {log.info(操作作者信息获取锁失败operator:{},request.getOperator());throw new BaseBizException(新增/修改失败);
}操作完成后释放掉锁因为幂等问题通常是一个请求快速过来两次或者多次所以在释放锁之前让后来的同一个用户的请求直接失败即可保证当前方法在短时间之内只能被执行一次切记控制锁的粒度。 public SaveOrUpdateUserDTO saveOrUpdateUser(SaveOrUpdateUserRequest request) {// 加入用户要先取得一把分布式锁针对的是操作人// 同一个操作人同时间只能新增用户避免说重复请求短时间内发生数据重复灌入// 加分布式锁String userUpdateLockKey RedisKeyConstants.USER_UPDATE_LOCK_PREFIX request.getOperator();boolean lock redisLock.lock(userUpdateLockKey);if (!lock) {log.info(操作作者信息获取锁失败operator:{}, request.getOperator());throw new BaseBizException(新增/修改失败);}//忽略代码} finally {redisLock.unlock(userUpdateLockKey);}}
