用version字段解决并发重复更新：乐观锁原理与实战

并发场景下的重复更新问题几乎是每个做业务系统的开发者迟早要撞上的一堵墙。定时任务跑重了、消息队列投递了两次、用户手抖连点了两下提交按钮、前端重试机制把同一个请求又发了一遍——这些情况单独拎出来都不算大问题但它们共同指向同一个后果同一条行数据被反复更新金额被加了两次、库存被扣了两遍、状态被来回覆盖。很多人第一反应是加锁分布式锁、数据库行锁、悲观锁轮番上阵结果系统复杂度飙升性能还掉了下去。其实有个成本极低、侵入性很小的办法经常被忽略在行数据上加一个 version 版本字段用乐观并发控制的思想把重复更新挡在门外。这篇内容就围绕这个思路展开把原理、落地方式、边界条件和踩过的坑一次讲清楚适合正在做业务系统、对并发一致性有实际诉求的开发者参考。1. 重复更新到底是怎么发生的1.1 先分清重复请求和重复更新很多人把这两个概念混为一谈导致方案选错。重复请求指的是同一个业务动作被提交了多次比如用户连点、网关重试、消息重投重复更新指的是数据库里同一行数据的某个字段被多次写入最终结果和预期不符。这两者有关联但不是一回事重复请求是诱因重复更新是后果。真正要防的是后者因为有些重复请求本身是无害的比如幂等的查询而有些看起来只发了一次的请求也可能因为代码逻辑问题导致多次更新。我在实际项目里见过一个典型场景一个订单状态流转的服务收到支付成功回调后把订单状态从待支付改成已支付同时给用户账户加积分。回调方因为网络抖动重试了三次服务端没有做任何防护结果积分加了三倍。这里的问题不是请求重复本身而是更新动作没有只允许生效一次的约束。version 字段解决的正是这个问题——它让第二次及以后的更新在数据库层面直接失效。1.2 三种最常见的重复更新来源把来源梳理清楚才能判断 version 字段能不能覆盖你的场景。根据我的经验重复更新主要来自三个方向上游重试调用方超时后重发请求服务端两次都执行成功。这是最普遍的来源尤其在跨服务调用、消息队列消费、第三方回调里高频出现。并发写入两个请求几乎同时到达都读到了旧值都基于旧值做计算再写回后写的覆盖先写的造成更新丢失。这就是经典的读-改-写竞态。任务重复调度定时任务在多实例部署下没有做分布式协调同一时刻多个节点都在跑同一批数据。这三种来源的共同点是更新操作本身没有校验我读到的数据是不是还是最新的。version 字段的核心作用就是在写入时校验这个前提一旦发现数据已经被别人改过就拒绝本次更新。1.3 为什么加锁不是唯一答案遇到并发问题加锁是最直觉的反应。数据库行锁SELECT ... FOR UPDATE确实能解决问题但它把并发变成了串行热点行上的吞吐会明显下降分布式锁要引入额外组件还要处理锁超时、锁续期、锁误删这些麻烦事。更关键的是很多重复更新场景根本不需要互斥只需要检测冲突——两个请求同时来让其中一个成功、另一个失败重试或直接丢弃即可没必要让它们排队。乐观并发控制就是这个思路不加锁写入时检查版本冲突就失败。它的假设是冲突不频繁所以用检测代替预防开销小、实现简单。version 字段就是这套机制在数据库层的具体载体。当然它也不是万能的冲突率极高的场景下大量更新会失败重试反而更慢这时候才需要考虑悲观锁。选型的关键在于判断你的业务是读多写少、冲突偶发还是写多且必然冲突。2. version 字段的工作机制拆解2.1 一次带版本校验的更新长什么样原理其实一句话就能说清更新时把 version 作为条件带上更新成功则 version 自增失败说明数据已被改动。落到 SQL 上大概是这样UPDATE orders SET status PAID, points_added 1, version version 1 WHERE id 1001 AND version 3;这条语句执行后数据库会返回受影响的行数。如果返回 1说明版本匹配、更新成功如果返回 0说明这行数据的 version 已经不是 3 了要么被别人改过要么根本不存在。业务代码拿到 0 就应该知道这次更新没生效进而决定是重试、报错还是直接忽略。关键在于WHERE id 1001 AND version 3这个条件。它把这行数据还是我读到的那个版本这个前提变成了数据库层面的原子判断。数据库在执行 UPDATE 时会对目标行加写锁条件判断和写入在同一个原子操作里完成所以不存在判断通过后又被别人插一脚的窗口。这一点非常重要——它意味着你不需要在应用层再做任何额外的同步。2.2 为什么 version 自增能形成闭环单看一次更新version 只是个条件。但把它放到多次更新的序列里闭环就形成了。假设初始 version 是 3时刻操作读取到的 version更新条件结果更新后 versionT1请求A3version 3成功4T2请求B3version 3失败受影响0行仍为4T3请求B重试4version 4成功5请求B第一次拿着过期的 version3 去更新被数据库拒绝它重新读取拿到 version4 后再更新才成功。整个过程没有任何锁但同一版本只能被成功更新一次这个约束被严格保证了。这就是 version 字段防重复更新的本质用版本号给每次更新打上序号序号对不上就不让写。这里有个容易被忽略的细节version 的自增必须和业务字段的更新在同一条 SQL里完成。如果你先更新业务字段、再单独更新 version中间就有了窗口两个请求可能都通过了业务字段的更新version 才后知后觉地自增防护就失效了。所以永远把version version 1写进同一条 UPDATE 语句。2.3 乐观锁与检测冲突的取舍逻辑为什么这套机制叫乐观锁因为它假设冲突不会经常发生所以不去提前加锁而是在提交时才检查。这个假设决定了它的适用边界。冲突率低的时候绝大多数更新一次就成功几乎没有额外开销性能接近裸更新冲突率高的时候大量更新失败重试重试又带来新的读操作整体吞吐反而下降。我一般用这个经验值来判断如果同一行数据在短时间内被并发更新的概率低于 5%乐观锁非常合适如果超过 20%就要认真评估是不是该换悲观锁或者做请求合并。当然这个数字不是绝对的还要看单次重试的成本。对于更新失败直接丢弃、不重试的场景比如防重复提交冲突率高也无所谓因为失败本来就是期望结果。3. 落地时的字段设计与代码写法3.1 version 字段的类型和初始值怎么定字段类型上INT或BIGINT都行绝大多数业务用INT足够。按每次更新自增 1 算INT有约 21 亿的正数空间就算一行数据每秒被更新一次也要几十年才耗尽实际业务里根本到不了。如果确实有极端高频更新的行用BIGINT更稳妥。字段建议设为NOT NULL初始值给 0 或 1并且给个默认值避免历史数据迁移时出现 NULL 导致条件判断异常。ALTER TABLE orders ADD COLUMN version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号;这里有个实操建议加字段的时候顺手把默认值设好老数据会自动填上默认值不需要单独跑一次全表 UPDATE。如果表很大全表 UPDATE 会锁表、产生大量 binlog能省则省。另外version 字段不要暴露给前端随意传值它应该是服务端从数据库读出来、原样带回更新条件的内部字段让客户端参与版本管理只会引入新的不一致。3.2 应用层代码的标准骨架以常见的 ORM 场景为例核心逻辑分三步读、改、带版本更新。下面用伪代码展示这个骨架语言无关重点是结构def pay_order(order_id): # 第一步读出当前数据和版本 order db.query(SELECT id, status, version FROM orders WHERE id ?, order_id) if order is None: raise NotFound() if order.status PAID: return # 已经是已支付直接返回天然幂等 # 第二步基于读到的版本执行带条件的更新 affected db.execute( UPDATE orders SET status PAID, version version 1 WHERE id ? AND version ?, order_id, order.version ) # 第三步根据受影响行数判断结果 if affected 0: # 版本冲突说明被别人改过按业务决定重试或放弃 raise ConcurrentModification() return这段代码里有两个值得说的点。第一if order.status PAID这个前置判断是业务幂等和版本控制的配合——已经处理过的直接返回连更新都不用发能挡掉大部分重复请求。第二affected 0的处理策略要结合业务对于支付回调这种冲突时可以选择重新读取再判断一次状态如果已经是目标状态就当作成功对于积分累加这种冲突时应该重试因为每次更新都有实际业务含义。3.3 重试策略什么时候重试、重试几次版本冲突后要不要重试是落地时最容易拍脑袋决定的地方。我的判断标准是看这次更新是否可重放如果重放一次不会产生副作用比如把状态从 A 改成 B重复执行结果一样那就重试如果每次执行都有累加效果比如扣库存、加积分重试前必须重新读取最新状态确认业务前提仍然成立。重试次数上我一般设 2 到 3 次上限并且加一点随机退避。原因很实际如果冲突是偶发的一两次重试基本能成功如果连续多次都冲突说明这行数据正处于高并发热点继续重试只会加剧竞争不如快速失败、把问题暴露出来。下面是个带退避的重试骨架for attempt in range(3): order read_order(order_id) affected update_with_version(order_id, order.version) if affected 1: return Success() sleep(random.uniform(0.01, 0.05) * (attempt 1)) raise ConcurrentModification()注意重试循环里每次都必须重新读取 version绝不能拿第一次读到的旧版本反复重试那样永远不可能成功。4. 那些让 version 失效的坑4.1 批量更新和 IN 条件里的版本陷阱单行更新用 version 很直观但一到批量场景就容易翻车。比如把一批订单状态统一改成已关闭如果写成UPDATE orders SET statusCLOSED, versionversion1 WHERE id IN (...)这条语句对每一行都自增了 version但它没有校验任何版本条件——它防不住重复执行因为第二次执行照样能匹配到 id。批量更新要真正防重复得逐行带版本或者换用别的幂等设计比如加一个已关闭的状态判断作为前置条件。还有一种隐蔽的坑用WHERE id ? AND version ?而不是version ?。有人觉得用大于等于更宽松、不容易失败但这恰恰破坏了防护——如果数据已经被更新到 version5你拿着 version3 用去更新条件成立重复更新就漏过去了。版本校验必须是精确相等这是原则问题。4.2 读和写不在同一个事务里的时序问题乐观锁不要求读写在同一事务但要求读到的版本和用于更新的版本是同一个。如果代码里读了一次数据中间又调了别的服务、做了耗时计算最后才更新这期间数据可能已经被改过你的更新会失败——这是正常的、期望的行为。真正的问题在于有些人为了避免失败在更新前又偷偷重新读一次版本把最新版本塞进更新条件这就等于绕过了校验重复更新照样发生。我的做法是把读版本和用版本更新放在尽量短的代码路径里中间不做远程调用、不做复杂计算。如果业务确实需要先做一堆处理再更新那就接受处理完可能冲突的事实冲突了重新走一遍流程而不是想办法让更新条件永远成立。4.3 消息重复消费场景下的特殊处理消息队列的至少一次投递语义意味着同一条消息可能被消费多次这是 version 字段的典型用武之地但用法有讲究。消费逻辑里如果只是根据消息内容更新某行数据带版本更新能挡住重复消费但如果消费逻辑是累加型操作比如统计计数version 只能保证同一版本不被重复更新挡不住两条不同消息各自合法地累加一次。这种场景我通常会在业务表之外再加一张消费记录表用消息唯一 ID 做去重version 作为第二道防线。两道防线各管各的去重表管这条消息处理过没有version 管这行数据有没有被并发改乱。只靠 version 去重是不够的因为它防的是并发冲突不是消息级幂等这两个概念一定要分清。4.4 历史数据迁移时的版本初始化给已有表加 version 字段老数据的 version 都是默认值 0。这本身没问题但要注意迁移期间如果有服务还在跑旧代码不带 version 条件更新就会出现旧代码更新了数据但没动 version的情况导致新代码的版本校验形同虚设。稳妥的做法是加字段、发新代码、确认所有写入路径都带上了 version 条件这三步之间留出足够的观察窗口别在发布高峰期做。另外如果表里有逻辑删除或者软删除标记version 更新要不要覆盖已删除的行也要想清楚。我的建议是更新条件里带上deleted 0避免对已删除数据做无意义的版本自增。5. 和其他并发方案怎么选5.1 version 字段、唯一索引、状态机三者的分工防重复更新不是只有 version 一条路实际项目里往往是组合使用。我把常见方案的分工整理成一张表方便对照方案防的是什么优点局限version 字段并发写冲突、基于旧值的覆盖写无锁、开销小、实现简单不防消息级重复、批量场景弱唯一索引重复插入如重复下单数据库强约束、绝对可靠只管插入不管更新状态机校验非法状态流转如已支付再支付业务语义清晰需要状态设计完整去重表消息/请求级幂等精确到单次请求多一张表、要清理version 字段的定位很明确它管的是更新时的并发冲突不是请求级去重。把这两件事混在一起就会写出既复杂又不可靠的代码。我的经验是一个健壮的写接口通常同时具备状态机前置判断挡掉明显非法的重复和 version 条件更新挡住并发窗口里的冲突两者配合覆盖面才完整。5.2 什么情况下该放弃 version 改用悲观锁version 不是银弹有几类场景我会直接放弃它。第一类是冲突率极高的热点行比如秒杀库存成千上万的请求同时更新同一行乐观锁会导致海量失败重试这时候用数据库行锁或者把库存拆到多行、用队列串行化更合适。第二类是更新逻辑必须读后立即写且不能失败的场景比如某些账务处理失败重试的代价太高宁可排队也不能让请求失败。第三类是更新涉及多行且要求整体一致单行 version 管不了跨行的事务性。判断标准可以简化成一句话冲突偶发、失败可接受、重试成本低就用 version冲突密集、失败不可接受、必须串行就用锁。这个判断在项目初期做对能省掉后期大量的重构。5.3 一个组合方案的参考结构把前面说的拼起来一个比较完整的防重复更新结构大概是这样入口先做请求级去重唯一 ID 或去重表业务层做状态机前置校验数据层用 version 条件更新兜底冲突时按业务决定重试或返回。这个结构里每一层职责单一出问题时也容易定位是哪一层没挡住。我在几个项目里用这套结构实际效果是绝大多数重复请求在入口或状态机层就被挡掉了真正走到 version 校验的冲突少之又少数据库压力很小。version 更像是最后一道保险平时不显眼但一旦有并发窗口漏过来它能保证数据不被写乱。这种多层防御、各司其职的思路比指望单一机制解决所有问题要靠谱得多。6. 我在实际项目里踩过的几个具体坑6.1 ORM 自动更新把 version 条件吃掉了用 ORM 的时候要特别小心有些框架的更新实体方法会生成UPDATE ... WHERE id ?把你手动加的 version 条件丢掉。我遇到过一次代码里明明写了版本校验测试环境并发压测却还是出现了重复更新排查半天才发现是 ORM 的批量更新方法忽略了自定义条件。解决办法是用框架提供的带条件更新接口或者干脆手写 SQL别图省事用全量更新方法。上线前一定要打开 SQL 日志确认最终执行的语句里真的带了AND version ?。6.2 版本号被业务代码意外重置有次做数据修复运维同学手动执行了一条 UPDATE 把某些字段改回默认值顺手把 version 也重置成了 0。结果这些数据的版本号比实际状态年轻了很多后续带版本更新时拿着旧版本号居然能匹配成功防护出现漏洞。教训是version 字段应该被视为只增不减的内部字段任何人工修数据、数据同步、ETL 流程都不能碰它除非明确知道后果。我在后来的项目里会把 version 字段加进禁止人工修改的规范清单。6.3 高并发下重试风暴把数据库打挂早期有个接口版本冲突后无脑重试 5 次、没有退避结果在一个流量高峰大量请求冲突后同时重试数据库 QPS 瞬间翻了几倍直接把连接池打满。后来改成最多重试 2 次、带随机退避、并且对同一行的重试做限流才稳住。这个坑的根源是把乐观锁当成了失败就重试直到成功的万能药忽略了重试本身也是有成本的。冲突重试必须设上限、加退避最好还能监控冲突率冲突率异常升高时及时告警。6.4 把 version 当成分布式锁用见过有人拿 version 字段做抢占式控制谁先把 version 从 0 改成 1谁就获得处理权。这个用法在单行、单次抢占时勉强能用但它不是锁——它没有锁的释放语义也没有超时机制一旦抢占成功的进程挂了这行数据就永远卡在被占用状态。version 的定位是并发更新的冲突检测不是资源互斥。需要互斥就用专门的锁机制别让 version 承担它不该承担的职责否则出了问题很难排查。7. 监控与验证怎么确认它真的生效了7.1 用受影响行数做埋点version 方案是否生效最直接的信号就是更新语句的受影响行数。我会在数据访问层对带版本更新返回 0 行的情况打点统计按接口、按表维度看冲突率。正常情况下这个比例应该很低如果某个接口的冲突率突然飙升要么是并发上来了要么是某段代码在拿旧版本反复更新都是值得排查的信号。这个埋点成本极低但排查问题时非常有用。7.2 压测时专门构造并发场景功能测试很难暴露 version 的问题因为单线程顺序执行永远不冲突。验证必须靠并发压测用多个线程同时读同一行、同时更新观察最终数据是否符合预期、冲突是否被正确拦截。我一般会写一个简单的并发测试脚本起 20 个线程对同一行做 100 次更新最后检查 version 是否恰好增加了 100如果每次都成功或者业务字段是否只被正确更新了预期次数。这个测试能有效验证条件更新 自增这条链路没有断。7.3 上线后的观察窗口新加 version 字段上线后建议留一到两周的观察期重点看三件事更新失败率是否在预期范围内、有没有出现该成功却失败的误伤、历史数据迁移后版本是否连续。误伤通常来自代码里某处没带版本条件或者版本被意外重置观察期能及早发现。等数据稳定了这套机制就可以安静地待在后台成为数据一致性的隐形保障。最后分享一个我自己的习惯每次设计一张会被并发更新的业务表我都会在表结构评审时问一句这张表的更新需不需要版本控制。大部分表其实不需要但凡是涉及金额、库存、状态流转、积分这类错一次就麻烦的字段加个 version 字段的成本几乎可以忽略收益却是长期的。它不是什么高深技术就是一个朴素但极其有效的工程习惯——用一行字段和一条带条件的 SQL把并发世界里最容易出乱子的那部分稳稳地兜住。