[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fky6bPa82RK9mWYr_9Mvmf4RxtI6h6_iHIwPliJ3cEN8":3},{"item":4,"related":44},{"id":5,"type":6,"title":7,"slug":8,"summary":9,"body":10,"coverUrl":11,"productScreenshots":12,"productLinks":13,"authorName":14,"authorUrl":15,"authorSubject":16,"category":17,"tags":22,"sourceLabel":35,"sourceName":36,"sourceUrl":37,"status":38,"seoTitle":7,"seoDescription":9,"canonicalUrl":35,"isFeatured":39,"sno":40,"sortOrder":41,"publishedAt":42,"updatedAt":43,"createdAt":43},"30148db9-1cf6-410e-8f34-8236aad167ad","article","Fencing Token：分布式锁过期后，怎样挡住迟到的旧写入？","fencing-token-prevent-stale-lock-writes","Fencing Token 用单调递增的代次号让存储端拒绝过期持有者的迟到写入。本文解释为什么必须由受保护资源校验令牌。","分布式系统中，拿到锁并不意味着你永远拥有它。客户端可能因网络暂停、长时间 GC 或机器休眠错过租约期限；锁服务随后把资源交给另一个客户端。最危险的情况是：旧客户端恢复运行，以为自己仍持有锁，继续向存储系统写入，把新持有者刚写的数据覆盖掉。Fencing Token（栅栏令牌）就是为迟到的旧操作设置一道屏障。\n\n做法通常是在每次成功获得锁时分配一个单调递增的代次号，例如 41、42、43。持有者每次向受保护资源写入时都附上自己的 token。资源端记录目前见过的最大 token，只接受不小于当前有效代次的操作。若旧持有者拿着 41 迟到，而新持有者已经用 42 写过数据，资源端就能拒绝这笔旧写入。\n\n关键点是“由资源端执行检查”。如果 token 只在锁服务里递增，却没有被存储系统、数据库或写入目标检查，迟到者仍可能直接覆盖结果。这个方案把锁所有权的时间变化转成资源可以验证的顺序关系。Chubby 论文中的 sequencer 机制就是相关设计背景之一：应用把 sequencer 附在操作上，服务端能够验证当前锁代次。\n\n栅栏令牌也有工程前提：token 必须在所有持有者之间单调增长且不会意外复用；资源端应可靠持久地保存最大值；并发操作如何比较、重试及处理批量写入，也要定义清楚。若资源跨多个独立系统，所有相关写入面都需要遵守同一规则。token 不能自动让锁服务、数据库和缓存保持一致。\n\n它和普通租约锁保护的侧重点不同。租约帮助协调“谁此刻应当工作”，fencing 则让资源拒绝已经过时的写入，即使旧客户端不知自己过期。两者结合更能抵抗暂停与网络分区造成的迟到请求；如果写入目标无法校验令牌，就不能假设单靠锁租约已彻底消除风险。\n\n理解 fencing token 时，可以记住一句话：旧持有者不需要知道自己已经过期，真正受保护的资源也能识别并拒绝它。这正是分布式系统中把“过期”变成可执行安全规则的关键。\n\n来源：[Burrows，The Chubby Lock Service for Loosely-Coupled Distributed Systems](https:\u002F\u002Fwww.usenix.org\u002Flegacy\u002Fevent\u002Fosdi06\u002Ftech\u002Ffull_papers\u002Fburrows\u002Fburrows_html\u002F)","\u002Fuploads\u002F2026-10-06\u002F585bd0e1-74c1-4d00-b887-2ab5895aa55e.jpg",[],[],"Foundit","https:\u002F\u002Ffoundit.cn","foundit-ai-editorial",{"id":18,"name":19,"slug":20,"description":21},"6179d3b6-dc34-4483-9ded-3cd9f1b37a47","科普","abbreviation","介绍各领域新兴概念",[23,27,31],{"id":24,"name":25,"slug":26},"7c76bfc2-f80f-4ee0-a95d-27bd8708b434","技术","slug",{"id":28,"name":29,"slug":30},"4c2bbea6-eab7-40a8-8447-1de478ff7749","分析","analyse",{"id":32,"name":33,"slug":34},"68cedb55-2cac-412f-8f81-fda8c7d686dd","思考","thought",null,"Burrows：The Chubby Lock Service for Loosely-Coupled Distributed Systems","https:\u002F\u002Fwww.usenix.org\u002Flegacy\u002Fevent\u002Fosdi06\u002Ftech\u002Ffull_papers\u002Fburrows\u002Fburrows_html\u002F","published",false,59,0,"2026-10-06T00:00:00.000Z","2026-10-06T07:51:42.911Z",[45,53,61],{"id":46,"type":6,"title":47,"slug":48,"summary":49,"coverUrl":50,"authorName":14,"sno":51,"publishedAt":42,"createdAt":52},"58fc0fe2-4392-402e-bd43-68da30f7b50f","RPKI 路由源验证：怎样确认一个网络前缀确实由某个 AS 宣告？","rpki-bgp-route-origin-validation","RPKI 路由源验证通过 ROA 检查前缀与起源 AS 是否匹配。本文解释 Valid、Invalid、NotFound 的含义，以及它为何不验证整条路由路径。","\u002Fuploads\u002F2026-10-06\u002F073132a3-dfee-42bd-b7f1-9f6805946e8b.jpg",40,"2026-10-06T07:51:36.206Z",{"id":54,"type":6,"title":55,"slug":56,"summary":57,"coverUrl":58,"authorName":14,"sno":59,"publishedAt":42,"createdAt":60},"d9dbb54d-46d3-4b1b-ad49-e4e049264170","Sloppy Quorum 与 Hinted Handoff：副本故障时，数据能先寄存到别处吗？","sloppy-quorum-hinted-handoff-replica-recovery","Dynamo 风格的宽松 quorum 可在首选副本不可达时暂存写入，并通过 hinted handoff 在故障恢复后补回。本文解释其可用性收益与一致性边界。","\u002Fuploads\u002F2026-10-06\u002Fc62b7ad0-304e-4a21-a245-aeee01573342.jpg",53,"2026-10-06T07:51:44.617Z",{"id":62,"type":6,"title":63,"slug":64,"summary":65,"coverUrl":66,"authorName":14,"sno":59,"publishedAt":67,"createdAt":68},"e4131e64-25af-4b75-8c90-d78212d5b7d9","BBR：网络拥塞为什么不能只看丢包？","bbr-bandwidth-round-trip-congestion-control","BBR 通过估计瓶颈带宽和往返传播时间来调节发送速率，把吞吐、延迟与在途数据纳入拥塞控制，而不是只等待丢包。","\u002Fuploads\u002F2026-09-26\u002F7a21c7b9-a2ee-4f70-b3fe-b10fca22655d.jpg","2026-09-27T00:00:00.000Z","2026-09-26T16:26:20.942Z"]