分布式系统的接口幂等性设计.docxVIP

分布式系统的接口幂等性设计 2021-09-06 概念 幂等性, Idempotence, 这个词来源自数学领域, 百科 上一元运算的幂等性解释如下： 设 f 为一由 {x} 映射至 {x} 的一元运算, 则 f 为幂等的, 当对于全部在 {x} 内的 x: f(f(x)) = f(x) 特殊的是，恒等函数肯定是幂等的，且任一常数函数也都是幂等的。 幂等性衍生到软件工程中, 它的语义是指: 函数/接口可以使用相同的参数反复执行, 不应当影响系统形态, 也不会对系统形成转变 . 一个简答的例子: 查询接口 GetFoo(), 不管调用多少次, 都不会破坏当前的系统/内存, 这就是一个幂等操作. 当然, 系统内部产生的日志这些细节不要在意. 在 HTTP/1.1 规范中, 幂等性有类似的明确定义: Methods can also have the property of “idempotence” in that (aside from error or expiration issues) the side-effects of N 0 identical requests is the same as for a single request. 从语义上不难看出, HTTP GET 是一个清楚的幂等操作, HTTP DELETE/POST 是非幂等的, HTTP PUT 也是幂等的, 由于对同一个 URI 进行多次 PUT 的 side-effetcs 是全都的. 在 分布式系统 中, 由于分布式自然?特性的时序问题, 以及网络的不行靠性(机器、机架、机房毛病, 电缆被挖断等等), 反复恳求很常见, 接口幂等性设计就显得尤为重要 . 案例分析 举一个玩耍领域中的案例: 玩家 Jack 花费点券购买道具, 调用后端 shop_svr 集群的 rpc 接口 buy_commodity(commodity_id) .?由于网络延迟, 或者系统负载比较高, shop_svr 没来得及前往, 总之, 第一次调用超时了没前往.?Jack 见一直木有反映, 又点了一次购买按钮.?网络恢复了, shop_svr 连续收到两次 buy_commodity(commodity_id) 恳求.?好吧, Jack 原来只想花 100 点券买个小喇叭, 系统硬是让他买了俩, 难怪都说 XX 玩耍坑钱了……?上面错误的示例只是扯个蛋, 咳咳…… 从这个问题中可以折射出几点系统设计的问题: buy_commodity() 接口不符合幂等性 , 当反复操作时, 对整个系统产生了影响, 玩家 A 被多扣了点券, 在网游业务中, 一旦涉及到钱这种敏感数据, 往往就不妙了. shop_svr 的消息处理做的不够完善, 当它收到延迟了许久的消息时, 应当及早拒绝, 前往失败, 不只是为了避开反复调用, 更重要的是保证 shop_svr 不会过载而导致整个系统雪崩 (不过这又是另外个话题, 不在此赘述). 那么, 怎样完善 buy_commodity() 接口的幂等性呢？自创银行等金融系统的做法, 引入 票据 (token) 是个不错的办法: Jack 花费点券购买道具, 先到 shop_svr 中去申请买卖票据 token.?shop_svr 生成独一 token, 并记录到 DB.?Jack 拿到 token, 调用接口 buy_commodity(token, commodity_id) 购买.?由于网络延迟, 或者系统负载比较高, shop_svr 没来得及前往, 总之, 第一次调用超时了没前往.?Jack 重试购买, 仍旧调用接口 buy_commodity(token, commodity_id) .?shop_svr 收到第一次 buy_commodity() 恳求, 验证 token 之后完成购买行为, 再将 token 标记为已执行, 这是个 原子行为 .?shop_svr 收到其次次 buy_commodity() 恳求, 验证 token 失败, 丢弃消息.?票据 (token) 机制, 保证了 buy_commodity() 接口的幂等性 , 同样的恳求, 并不会对系统形成额外的 side-effects, 即多次调用预期保持全都, 问题处理! PS: 依据上面的描述, DB 层保证 “验证 token”, “加道具扣点券”, “标记 token” 这三步操作的原子性, 这并不是一个很简约的事情, 所以实际中往往妥协为: 先 “验证并标记 token” , 再 “加道具扣点券” 这两步操作: 第一步操作可以通过 SQL 的条件更新, 或者带版本号写(部分 NoSQL 支持)来实现, 这是幂等性操