什么是幂等性
-
幂等性定义:
- 一次和屡次申请某一个资源对于资源自身应该具备同样的后果
- 任意屡次执行对资源自身所产生的影响均与一次执行的影响雷同
-
幂等性定义的几个重点:
-
幂等不仅仅只是一次或者屡次申请对资源没有副作用
- 比方, 查询数据库操作, 没有增删改, 无论多少次操作对数据库都没有任何影响
- 幂等还包含第一次申请的时候对资源产生了副作用, 然而当前的屡次申请都不会再对资源产生副作用
- 幂等关注的是当前屡次申请是否对资源产生副作用, 并不关注后果
- 网络超时等问题, 不是幂等的探讨范畴
-
- 幂等性是零碎服务对外一种承诺, 而不是实现
- 承诺只有调用接口胜利, 内部屡次调用对系统的影响是统一的
-
申明为幂等的服务会认为内部调用失败是常态, 并且失败后必然会有重试
幂等性的应用场景
-
业务开发中, 常常遇到反复提交的状况:
- 因为网络问题无奈收到申请后果而从新发动申请
- 前端的操作抖动而造成的反复提交的状况
-
在交易系统中, 领取零碎这种反复提交造成的问题尤为显著:
- 用户在 APP 上间断点击屡次提交订单, 后盾应该只产生一个订单
- 向领取零碎发动申请, 因为网络问题或者零碎 Bug 问题导致重发, 领取零碎应该只做一次扣除操作
-
申明幂等的服务认为, 内部调用者会存在屡次调用的状况, 为了避免内部屡次调用对系统的数据状态产生屡次扭转, 须要将服务设计为幂等
幂等和防重
-
反复提交的状况和服务幂等的初衷是不同的
- 反复提交是在第一次申请曾经胜利的状况下 , 人为地进行屡次操作, 导致不满足幂等要求的服务屡次扭转状态
- 幂等更多应用的状况是第一次申请因为某些状况, 不如超时, 而导致不晓得后果或者申请失败的 异常情况下, 发动屡次申请
-
幂等的目标是申请屡次确认第一次申请胜利, 不会因为屡次申请而呈现屡次的状态变动
保障幂等性的状况
-
在 SQL 中, 有以下三种场景, 只有第三种场景须要保障幂等性:
- SELECT col1 FROM tab1 WHERE col2=2 : 无论执行多少次都不会扭转状态, 是人造的幂等
- UPDATE tab1 SET col1=1 WHERE col2=2 : 无论执行胜利多少次状态都是统一的, 也是幂等操作
-
UPDATE tab1 SET col1=col1+1 WHERE col2=2: 每次执行的后果都会发生变化, 这种不是幂等的, 要采取策略保障幂等性
设计幂等性服务
- 幂等使得客户端逻辑解决很简略, 然而服务端逻辑会很简单
-
满足幂等性服务须要蕴含两点逻辑:
- 首先去查问上一次的执行状态, 如果没有则认为是第一次申请
-
在服务扭转状态的业务逻辑前保障防反复提交的逻辑
保障幂等策略
-
幂等须要通过 惟一的业务单号 来保障:
- 雷同的业务单号, 认为是同一业务
- 应用惟一的业务单号确保: 前面屡次雷同业务单号的解决逻辑和执行成果是统一的
-
幂等实现示例 - 领取:
- 先查问订单是否领取过
- 如果曾经领取过, 返回领取胜利
-
如果没有领取, 则进行领取流程, 批改订单的状态为已领取
防反复提交策略
- 在保障幂等的策略中, 执行是分两步执行的, 前面一步依赖下面一步的查问后果, 这样就无奈保障原子性
-
无奈保障原子性在高并发的状况下会存在问题:
- 第二次申请在第一次申请的下一步订单状态没有批改为 ” 已领取状态 ” 时进行
-
为了解决这个问题 : 将查问和变更状态操作加锁, 并将并行操作改为串行执行
乐观锁
- 如果只是更新已有的数据, 没有必要对业务进行加锁
-
设计表构造时应用乐观锁, 个别通过 version 来实现乐观锁:
- 保障执行效率
-
保障幂等
UPDATE tab1 SET col1=1,version=version+1 WHERE version=#version#因为 ABA 问题会导致乐观锁存在生效的状况, 只有保障 version 值自增就不会呈现 ABA 的问题
防重表
-
应用 orderNo 作为去重表中的惟一索引, 每次申请都依据订单号 orderNo 向去重表中插入一条数据:
-
第一次申请查问订单领取状态:
- 订单没有领取
- 进行领取操作
- 无论胜利与否, 执行实现之后更新订单的状态为胜利或失败, 删除去重表中的数据
- 后续订单因为表中的惟一索引插入失败, 返回操作失败, 直到第一次申请实现(胜利或者失败)
-
-
防重表的作用是实现加锁的性能
分布式锁
- 能够应用 Redis 分布式锁代替防重表的性能
-
示例:
- 订单发动领取申请
- 领取零碎会去 Redis 缓存中查问是否存在该订单Key
- 如果不存在, 向 Redis 中减少 Key 为订单号
- 查问订单领取是否曾经领取
- 如果没有则进行领取, 领取实现后删除该订单的Key
- 通过 Redis 实现分布式锁, 只有这次订单申请实现, 下次申请才会进来
- 比照去重表,Redis 分布式锁将放并发做在缓存中, 效率更高
-
同一时间只能实现一次领取申请
token 令牌
-
token 令牌分为两个阶段:
-
申请 token 阶段:
- 在进入到提交订单页面之前, 须要订单零碎依据用户信息向领取零碎发动一次申请 token 的申请
- 领取零碎将 token 保留到 Redis 缓存中, 给领取阶段应用
-
领取阶段:
- 订单零碎获取到申请的token, 发动领取申请,
-
领取零碎查看 Redis 是否存在该token
- 如果存在, 示意第一次发动领取申请, 删除缓存中的 token 开始领取逻辑解决
-
如果缓存中不存在, 示意非法申请
领取缓冲区
-
-
领取缓冲区:
- 将订单的领取申请都疾速地接管下来, 是一个疾速接管申请的缓冲管道
- 应用 异步 工作解决管道中的数据, 过滤调掉反复的待领取的数据
- 长处: 同步转异步, 高吞吐
-
毛病: 无奈及时返回领取后果, 须要后续监听领取后果的异步返回
- 幂等是为了简化客户端逻辑, 然而减少了服务提供者的逻辑和老本
- 幂等的应用须要依据具体场景具体分析
- 减少了额定管制幂等的业务逻辑, 简单了业务性能
-
将并行的性能转化为串行, 升高了执行效率