[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fL_OyRcyiSB02uPdn7JZ94KSKt8LToiy3hMwQaJlOXSE":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},"0192313b-fec3-4f3c-8f8c-3ea32f4c1ccf","article","Vector Clock：多个副本同时修改，系统怎样知道是先后还是冲突？","vector-clocks-causality-conflicts","向量时钟用每个副本的计数记录因果历史，通过逐项比较识别祖先版本与并发冲突，为多副本合并提供依据。","当一个分布式数据库有多个副本时，两个客户端可能同时修改同一条记录。系统看到的不是简单的“后来覆盖先来”，而是要判断两个版本存在先后关系，还是彼此并发、需要合并。Vector Clock（向量时钟）就是用来记录这种因果关系的工具。\n\n把每个副本想成一本自己的日记。每发生一次本地更新，它就把自己的计数加一；向另一个副本发送版本时，也把整本计数摘要带上。收到消息的副本会逐项比较两个向量：如果一个向量在所有位置都不小于另一个，它就包含了后者的历史；如果各自有一部分更大，则表示两次更新存在并发分支。\n\n例如副本 A 的向量是 A:3、B:1，副本 B 的向量是 A:3、B:2，那么后者可以看作前者之后发生的版本。但如果一个版本是 A:4、B:1，另一个是 A:3、B:2，谁也没有在所有维度上领先，它们就是并发冲突。系统可以保留两个版本交给应用合并，也可以根据业务规则选择结果。\n\n向量时钟的优点是语义清楚，能显式表示祖先和并发。缺点是向量大小通常随参与副本数增长；副本频繁加入、离开或版本传播不完整时，管理成本会变高。实际系统可能压缩向量、限制版本历史，或者使用其他逻辑时间结构做折中。\n\n它提醒我们，“时间更晚”不一定等于“逻辑上覆盖”。在分布式系统中，因果链和并发分支是两种不同事实。向量时钟不替业务解决冲突，但它先把冲突识别准确，让应用知道什么时候可以覆盖，什么时候必须合并。\n\n当副本数量很大时，完整向量会显得笨重，因此系统常用稀疏表示、截断历史或改用近似结构。无论采用哪种压缩，都要清楚它可能丢失哪些因果信息：如果把两个本来并发的版本错误合并，冲突就会从“可见的分支”变成“悄悄丢数据”。\n\n资料来源：[Amazon Dynamo：Highly Available Key-value Store](https:\u002F\u002Fwww.amazon.science\u002Fpublications\u002Fdynamo-amazons-highly-available-key-value-store)","\u002Fuploads\u002F2026-09-26\u002F9a2bcf83-a49d-4481-b5cc-83bbb7c8e788.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,"Amazon Dynamo：Highly Available Key-value Store","https:\u002F\u002Fwww.amazon.science\u002Fpublications\u002Fdynamo-amazons-highly-available-key-value-store","published",false,57,0,"2026-09-27T00:00:00.000Z","2026-09-26T16:26:35.391Z",[45,54,62],{"id":46,"type":6,"title":47,"slug":48,"summary":49,"coverUrl":50,"authorName":14,"sno":51,"publishedAt":52,"createdAt":53},"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-06T00:00:00.000Z","2026-10-06T07:51:36.206Z",{"id":55,"type":6,"title":56,"slug":57,"summary":58,"coverUrl":59,"authorName":14,"sno":60,"publishedAt":52,"createdAt":61},"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":63,"type":6,"title":64,"slug":65,"summary":66,"coverUrl":67,"authorName":14,"sno":60,"publishedAt":42,"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-26T16:26:20.942Z"]