[{"data":1,"prerenderedAt":326},["ShallowReactive",2],{"learn-concept-/zh/learn/single-source-of-truth":3},{"id":4,"title":5,"body":6,"cardImage":256,"cardImageAlt":257,"date":258,"description":259,"domain":260,"domainKey":261,"extension":262,"featured":263,"fullName":264,"interaction":265,"maturity":266,"mentalModel":267,"meta":268,"navigation":269,"neighbors":270,"ogImage":301,"path":302,"published":269,"robots":301,"seo":303,"shortName":304,"sitemap":305,"socialImage":301,"socialImageAlt":301,"sources":306,"stem":319,"tags":320,"translationKey":265,"updated":258,"__hash__":325},"learnZh/zh/learn/single-source-of-truth.md","单一事实来源",{"type":7,"value":8,"toc":244},"minimal",[9,12,20,23,28,31,42,49,52,68,72,75,90,93,100,103,109,112,118,125,128,131,134,140,143,146,149,153,156,176,179,182,214,218,221,224,227],[10,11,5],"h1",{"id":5},[13,14,15,16],"p",{},"Single Source of Truth（SSOT，单一事实来源）解决的是所有重复信息背后的同一个问题：",[17,18,19],"strong",{},"当多个副本互相矛盾时，谁有权决定“现在是什么”？",[13,21,22],{},"它的答案不是“删除所有副本”。缓存、搜索索引、报表、replica（副本）、双语发布包和生产页面都很有用。这个 pattern 要做的是：让一个边界清楚的事实只有一个权威拥有者，其余表示都成为可追踪的派生物。",[24,25,27],"h2",{"id":26},"它要阻止的失败drift","它要阻止的失败：drift",[13,29,30],{},"假设同一篇文章出现在四个地方：",[32,33,39],"pre",{"className":34,"code":36,"language":37,"meta":38},[35],"language-text","source.md       version 3\npublic package  version 3\nblog copy       version 4\nproduction      version 3 + 一次手工 hotfix\n","text","",[40,41,36],"code",{"__ignoreMap":38},[13,43,44,45,48],{},"四个版本看起来都合理。下一次同步却可能删掉最好的修改，因为没有人知道更新应该朝哪个方向流动。这就是 ",[17,46,47],{},"drift（漂移）","：本来应该一致的表示悄悄分叉。",[13,50,51],{},"一个健康的 SSOT 会明确四件事：",[53,54,55,59,62,65],"ol",{},[56,57,58],"li",{},"谁可以定义这个事实？",[56,60,61],{},"更新从哪里流向哪里？",[56,63,64],{},"一个派生副本允许落后多久？",[56,66,67],{},"分叉以后怎样重建或对账？",[24,69,71],{"id":70},"一个事实一个主人不是所有东西一个数据库","一个事实一个主人，不是所有东西一个数据库",[13,73,74],{},"Authority（权威）应该按事实或领域划分：",[76,77,78,81,84,87],"ul",{},[56,79,80],{},"Order Service 拥有订单生命周期；",[56,82,83],{},"身份系统拥有客户法定姓名；",[56,85,86],{},"source Markdown 拥有一篇文章真正表达的意思；",[56,88,89],{},"已提交的 main revision 拥有生产 release。",[13,91,92],{},"这些事实不需要住在同一个物理存储里。相反，把无关领域强塞进一个巨大数据库，可能让所有权更模糊。",[13,94,95,96,99],{},"一个很好用的判断题是：",[17,97,98],{},"哪个系统有权发起一次修正？"," 其他系统可以读取、订阅、缓存、索引、翻译或投影这个事实，但不能悄悄成为第二个独立写入者。",[24,101,102],{"id":102},"一个实用发布链",[32,104,107],{"className":105,"code":106,"language":37,"meta":38},[35],"权威源 ──► 公开内容包 ──► 站点副本 ──► 部署结果\n在这里修改       派生          派生         发布证据\n",[40,108,106],{"__ignoreMap":38},[13,110,111],{},"一个健康的派生物应该带有足够的 Data Lineage（数据血缘）：",[32,113,116],{"className":114,"code":115,"language":37,"meta":38},[35],"derived_from   = 源标识\nsource_version = commit / offset / version\ngenerated_at   = 生成时间\nrefresh_policy = 每次提交 / 每五分钟 / 每晚\nrebuild_path   = 可重复的命令或流程\n",[40,117,115],{"__ignoreMap":38},[13,119,120,121,124],{},"最容易推理的默认结构，是单向、可重复地生成。",[40,122,123],{},"A ⇄ B ⇄ C ⇄ A"," 这种环形同步会让每一方都可能成为权威，于是必须额外定义复杂的冲突语义。",[24,126,127],{"id":127},"一个服务例子",[13,129,130],{},"假设 Order Service 拥有订单状态。它发布更新事件，供搜索索引、分析表和推荐系统消费。",[13,132,133],{},"这些副本可以针对不同查询优化，也可以只有 eventual consistency（最终一致性）。但退款仍然必须询问 Order Service，因为它拥有完整交易历史。一个更快、更近的副本，不会因为方便就自动获得权威。",[13,135,136,137],{},"所以 SSOT 完全可以和复制、高读取吞吐同时存在：",[17,138,139],{},"物理副本可以很多，权威不能含糊。",[24,141,142],{"id":142},"权威不等于永远正确",[13,144,145],{},"权威源仍可能包含 bug、错误录入或过期规则。SSOT 不会让它永不犯错；它让修复有方向：先修正拥有者，再重新生成或对账所有派生物。",[13,147,148],{},"如果没有这个方向，团队会在许多副本里分别打补丁，却永远无法确认修复是否完整。",[24,150,152],{"id":151},"分叉以后怎样恢复","分叉以后怎样恢复？",[13,154,155],{},"当两个副本都出现了看似有效的修改：",[53,157,158,161,164,167,170,173],{},[56,159,160],{},"暂停会继续扩大分叉的写入或发布。",[56,162,163],{},"说清楚发生冲突的是哪一类事实。",[56,165,166],{},"根据所有权、完整性、时间线和审计证据确认权威。",[56,168,169],{},"把下游独有且正确的修改带回源头。",[56,171,172],{},"从修复后的源重新生成所有派生物。",[56,174,175],{},"增加 lineage、diff check、写权限或单向发布路径。",[13,177,178],{},"顺序很重要：先恢复 authority，再恢复 consistency（数据一致性）。如果不先选择裁判，同步只是随便让一个版本覆盖另一个。",[24,180,181],{"id":181},"它不是什么",[76,183,184,190,196,202,208],{},[56,185,186,189],{},[17,187,188],{},"不是一个巨大数据库。"," SSOT 关心有边界的权威，而不是物理集中。",[56,191,192,195],{},[17,193,194],{},"不是禁止副本。"," 缓存、replica、materialized view（物化视图）和报表本来就应该存在。",[56,197,198,201],{},[17,199,200],{},"不是自动保证正确。"," 它告诉我们一次修正应该发生在哪里。",[56,203,204,207],{},[17,205,206],{},"不是 Event Sourcing（事件溯源）。"," 事件日志可以实现 SSOT，但只是其中一种实现模式。",[56,209,210,213],{},[17,211,212],{},"不是 Single Version of Truth（SVOT，单一版本的真相）。"," SVOT 强调消费者对统一定义或结果达成一致；SSOT 强调权威从哪里产生。",[24,215,217],{"id":216},"什么时候会变难","什么时候会变难？",[13,219,220],{},"离线优先协作、active-active（双活）多地域写入、network partition（网络分区），以及真正需要多个独立作者共同定义事实的系统，都会让简单的“单写者”模型变难。",[13,222,223],{},"这些系统仍然需要显式权威和冲突语义，只是可能通过 leader（领导者）、quorum（法定人数）、merge rule（合并规则）或 CRDT（Conflict-free Replicated Data Type，无冲突复制数据类型）来分布式地实现。“我们有多个写入者”不等于可以不定义分歧怎样解决。",[24,225,226],{"id":226},"最后记住五件事",[53,228,229,232,235,238,241],{},[56,230,231],{},"一个事实可以有很多副本，但需要一个被明确命名的权威。",[56,233,234],{},"每个派生物都应该暴露 source、version、freshness 和 rebuild path。",[56,236,237],{},"业务不需要多写者时，优先使用单向、幂等的生成流程。",[56,239,240],{},"先修改源，再重新生成下游；直接编辑 projection（投影）会制造 drift。",[56,242,243],{},"SSOT 让错误可以修复、可以审计，而不是让错误从此不可能发生。",{"title":38,"searchDepth":245,"depth":245,"links":246},2,[247,248,249,250,251,252,253,254,255],{"id":26,"depth":245,"text":27},{"id":70,"depth":245,"text":71},{"id":102,"depth":245,"text":102},{"id":127,"depth":245,"text":127},{"id":142,"depth":245,"text":142},{"id":151,"depth":245,"text":152},{"id":181,"depth":245,"text":181},{"id":216,"depth":245,"text":217},{"id":226,"depth":245,"text":226},"/learn-img/single-source-of-truth/card-4x5.jpg","一份放在深色基座上的纸艺主记录分流到仪表盘、报告与缓存，表示一个权威来源生成多个派生视图。","2026-07-16","让每一类事实只有一个权威拥有者；其余副本都可追踪、可过期、可重建。","信息系统","information-systems","md",false,"Single Source of Truth · 单一事实来源","single-source-of-truth","持续生长","一个事实可以有很多副本，但只能有一个地方被授权回答“现在是什么”。",{},true,[271,276,281,286,291,296],{"name":272,"fullName":273,"category":274,"summary":275},"Canonical Source","Canonical Source · 规范源","权威机制","被正式选为某类事实权威表示的具体文件、存储或日志。",{"name":277,"fullName":278,"category":279,"summary":280},"Data Lineage","Data Lineage · 数据血缘","来源追踪","记录数据来自哪里、经过哪些转换，以及由哪个源版本产生。",{"name":282,"fullName":283,"category":284,"summary":285},"Materialized View","Materialized View · 物化视图","派生投影","为查询保存的派生表示；它可以落后，并且应该能从源头重新生成。",{"name":287,"fullName":288,"category":289,"summary":290},"Event Sourcing","Event Sourcing · 事件溯源","实现模式","把按顺序排列的事件日志作为权威记录，通过重放构建当前状态。",{"name":292,"fullName":293,"category":294,"summary":295},"CQRS","Command Query Responsibility Segregation · 命令查询职责分离","架构模式","把权威命令与读优化投影分开，同时引入明确的同步边界。",{"name":297,"fullName":298,"category":299,"summary":300},"SVOT","Single Version of Truth · 单一版本的真相","消费共识","让消费者对一套定义或结果达成一致；它与确定权威位置相关，但并不相同。",null,"/zh/learn/single-source-of-truth",{"title":5,"description":259},"SSOT",{"loc":302},[307,310,313,316],{"title":308,"url":309},"Microsoft · 微服务的数据考量","https://learn.microsoft.com/en-us/azure/architecture/microservices/design/data-considerations",{"title":311,"url":312},"Microsoft · CQRS 模式","https://learn.microsoft.com/en-us/azure/architecture/patterns/cqrs",{"title":314,"url":315},"HashiCorp · Terraform State 的用途","https://developer.hashicorp.com/terraform/language/state/purpose",{"title":317,"url":318},"Kubernetes · 声明式对象配置","https://kubernetes.io/docs/tasks/manage-kubernetes-objects/declarative-config/","zh/learn/single-source-of-truth",[321,322,323,324],"权威来源","数据血缘","同步","知识系统","h1AkvbrLGiEFOE7XVMGBVduTF1IUQ2MazQ6rFL9dERs",1785418435121]