一、分布式服务的接口幂等性设计
(一)概述
所谓幂等:多次调用方法或者接口不会改变业务状态,可以保证重复调用的结果和单次调用的结果一致。
基于RESTful API的角度对部分常见类型请求的幂等性特点进行分析:
请求方式 | 说明 |
---|---|
GET | 查询操作,天然幂等 |
POST | 新增操作,请求一次与请求多次造成的结果不同,不是幂等的 |
PUT | 更新操作,如果是以绝对值更新,则是幂等的。如果是通过增量的方式更新,则不是幂等的 |
DELETE | 根据唯一值删除,则是幂等的;如果是根据条件删除,则不一定幂等。例如每次删除某字段最大的记录 |
(二)需要幂等的场景
- 网络波动:因网络波动,可能会引起重复请求。
- MQ 消息重复:生产者已把消息发送给 MQ,在 MQ 给生产者返回 ack 的时候网络中断,生产者未收到确定消息,认为消息未发送成功。但实际情况是,MQ 已成功接收到消息,在网络重连后,生产者会重新发送刚才的消息,造成 MQ 接收了重复的消息。
- 用户重复点击:用户在使用产品时,可能会误操作而触发多笔交易,或因为长时间没有响应,而有意触发多笔交易。
- 应用使用失败或超时重试机制:为考虑系统业务稳定性,开发人员一般设计系统时,会考虑失败了如何进行下一步操作或等待一定时间继续前端的动作。
(三)后端解决方案
- 方案一:数据库唯一索引
- 使用数据库提供的唯一索引来保证数据重复插入,避免脏数据产生。
- 解决场景:新增。
- 方案二:token + redis
- 第一次请求:在后端生成一个唯一的 token(比如:key:userid, value:UUID),将 token 存储到 redis 中,将 token 返回前端。
- 第二次请求:在真正处理业务的时候需要携带过来之前的 token,到 redis 中查询 token 是否存在。如果存在,则正常处理业务,同时删除 redis 中的 token;如果不存在,则操作失败。
- 解决场景:新增、删除、修改。
- 方案三:分布式锁
- 在分布式锁使用的时候,要注意粒度。在操作数据时,先添加一个分布式锁,当操作完成后再释放掉这把锁。同时在操作过程中,如果有人来抢锁,应当抛出异常,即:
if (!lock) { log.info("操作作者信息获取锁失败,operator: { }",request.getOperator());