每个工程师都应该了解的:聊聊幂等

作者:朱赟

什么是幂等(Idempotency)呢?简单来说,一个操作如果多次任意执行所产生的影响,均与一次执行的影响相同,我们就称其为幂等。

这样说来,似乎很容易理解;但要知道这样的定义,其实是一个语义范畴对行为结果的定义。

如何用语法和规则去确保行为能达到这个结果,往往需要很谨慎地设计和实现。实际系统中,幂等是一个极为重要的概念,无论是在大型互联网应用还是企业级架构中,都能见到 REST API 被越来越多地采用,而正确实现幂等,往往是 API 中最难的技术点之一。

先说说为什么重要,我来举一个简单易懂的例子。

比如,你要处理一次电商网站收款或者付款的交易。当你给微信支付发送这个付款请求后,一个顺利的场景是不会有任何错误发生的,微信支付收到你的付款请求,处理所有转账,然后返回一个 HTTP 200 消息表示交易完成。

那如果发出请求后,有个请求超时,你再也没有收到关于这个请求是成功还是失败的回执,又该如何呢?

这里就有很多种可能的情况。

这个请求在到达微信支付端前就已经发生超时,微信支付从来没有收到这样的请求。

这个请求到达微信支付端,但是支付交易失败,这时发生超时,微信支付收到这样的请求,但没有处理成功。

这个请求到达微信支付端,并且支付交易成功,这时发生超时,微信支付收到这样的请求,处理成功,但是没有回执。

这个请求到达微信支付端,并且支付交易成功,并且发回回执,然而因为网络原因回执丢失,客户端超时,微信支付收到这样的请求,处理成功,发出回执,但是客户没有收到。

人们很直观的想法,也是现实中开发者最常见的做法就是:重新提交一次支付请求。但是这样做有一个潜在的问题:请求超时是上面的哪一种情况,会不会引发多次支付的可能性?

这就涉及系统中的幂等是如何实现的了。

那么幂等又该如何实现呢?

首先来看一下幂等的定义:多次执行所产生的影响均与一次执行的影响相同。简言之,你需要一个去重的机制。这往往有很多不同的实现方法,但是有两个很关键的因素。

第一个因素是幂等令牌(Idempotency Key)。客户端和服务器端通过什么方式来识别,这实际上是同一个请求或是同一个请求的多次尝试。这往往需要双方有一个既定的协议,比如账单号或者交易令牌,这种在同一个请求上具备唯一标识的元素,这种元素通常由客户端生成。

第二个因素是确保唯一性(Uniqueness Guarantee)。服务器端用什么机制去确保同一个请求一定不会被处理两次,也就是微信支付如何确保,同一笔交易不会因为客户端发送两次请求就被处理多次。

最常用的做法是利用数据库。比如把幂等令牌所在的数据库表的列作为唯一性索引。这样,当你试图存储两个含有同样令牌的请求时,必定有一个会报错。注意,简单的读检查并不一定成功,因为读与读之间会有竞争条件(Race Condition),因此还是有可能出错。

一个系统能正确处理和实现上面的两个要素,基本就达到了幂等的需求。那么,现实系统中常见的问题都出在哪里呢?

一是幂等令牌什么时候产生,怎样产生。这一点很重要。拿上面的例子来说,就算微信支付可以保证,每一个请求对应的支付交易一定只会被处理一次,但是这个请求的多次重复,一定要共有微信可以识别的某个标识。

假如客户端对同一笔交易多次请求,产生的幂等令牌并不相同,那么无论你其余的地方多么完美,都不可能保证 “一个操作如果具有任意多次执行,所产生的影响均与一次执行的影响相同”。

二是令牌有没有被误删的可能。这是上面问题的一个特殊情况。幂等令牌是由客户端生成的,那如果生成的令牌在被使用后(一次微信支付请求中使用了),不小心因为数据库回滚(DB Rollback) 等原因被删除了,那么客户端就不知道自己其实已经发过一次请求。这就有可能生成一个新的账单,并产生全新的令牌,而服务端对此则一无所知。

三是各种竞争条件。我在前面讲过,用数据库的读检查来确保唯一性经常因为竞争而不生效,其实一个需要幂等的系统中,保证唯一性的各个环节和实现,都要考虑竞争条件(Race Condition)。

四是对请求重试的处理。这大部分是服务器端要做的工作。一个常见的方法是:区分正在处理的请求、处理成功和处理失败的请求。这样当客户端重试的时候,根据情况或者直接返回,或者再次处理。这就好像之前提到的微信支付的例子,微信支付服务需要知道每一笔交易的处理情况,只有这样,当面对再次转账请求时,才能知道应该用什么方式去处理相应的请求。

五是一个系统中需要多层幂等。这是什么意思呢?A 发送请求给 B,B 处理的一部分是要发送请求给另一个系统 C,C 在处理的过程中还可能需要发请求给另一个系统 D …… D 处理完了返回给 C,C 返回给 B,B 返回给 A。在这个链条中,如果 A、B、C、D 中任何一个系统没有正确实现幂等,也就是出现了 “幂等漏洞”,那么一次请求还是有可能被多次执行,产生区别于一次执行的影响。

今天我和你讨论了架构设计中的幂等概念。我们聊了什么是幂等,幂等的应用场景,如何实现一个幂等功能,以及幂等系统中容易出现的问题。

现在回到文章的开头,什么是幂等?一个操作如果任意多次执行所产生的影响均与一次执行的影响相同,我们就称为幂等。这是一个语义范畴上对行为结果的定义,只有当你把实现中所有的细节都做对了,你才能得到想要的效果。任何一个地方设计有漏洞,或是实现上有 Bug,系统都会出现这样或那样的问题。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 217,542评论 6 504
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 92,822评论 3 394
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 163,912评论 0 354
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,449评论 1 293
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,500评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,370评论 1 302
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,193评论 3 418
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,074评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,505评论 1 314
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,722评论 3 335
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,841评论 1 348
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,569评论 5 345
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,168评论 3 328
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,783评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,918评论 1 269
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,962评论 2 370
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,781评论 2 354