权威状态

Category

glossary 词条。节点定位：权威状态是最终裁决所依赖的那份状态——同一份状态存在多个事实来源是多数混乱的根源。

Definition

权威状态指的是最终裁决所依赖的那份状态：位置、伤害、资产、进度，发生争议时以谁为准，谁就是权威。这个词在同步、数据和服务拆分的讨论里反复出现，因为大量混乱的根源，是同一份状态存在多个事实来源。

Problem

位置、伤害、资产的争议若没有权威定义，同步、持久化、排障全部失去裁决依据。权威不等于性能最优、权威转移是高成本动作，这两条常见误解导致架构反复摇摆。

它回答的核心问题

不是“数据存在哪里”，而是“以谁为准”。一份状态可以有多份副本、多层缓存、多个展示口径，但承认权只有一份。排行榜副本再新，也不是资产真相；客户端预测再准，也不拥有裁决权。判断一个系统的状态设计是否清楚，通常就看它能不能一句话说出每类状态的权威在哪。

同一份状态常常有好几个名字

一份玩家资产，往往同时存在于内存对象、缓存副本、数据库行、展示接口返回和报表聚合里。这些形态互相派生，各有各的更新时机。权威状态这个词要回答的就是：这几个名字里哪一个说了算，其余的怎么跟上、失配了怎么办。说不清这个，几个副本各自为政只是时间问题。

在同步讨论里的位置

服务端权威状态同步之所以成为主流，正是因为把权威放在服务端最容易统一裁决、约束作弊、支持审计。客户端通常可以预测、可以先播，但预测结果只是暂时的，服务端权威结果回来后要重新收拢。预测、补偿与纠正整套机制，都是围绕“权威不在本地”这个事实搭建的。

在数据讨论里的位置

权威源数据和派生副本要分清：谁是权威源，谁是性能副本，副本何时更新，失效时如何重建。长线项目里最难拆的结构性问题，往往就是派生数据慢慢反向变成了事实来源——报表被拿来裁决，展示副本被当成资产真相，错误从展示层渗透进结算层。

和单写者的关系

权威通常和单写者配套：一份状态如果多个进程都能直接改，权威就名存实亡。常见做法是把写入口收敛到一个服务或一个执行单位，其他系统通过它读、通过它改。单写不是为了性能，而是为了让“谁最后说了算”这个问题有唯一答案，审计和回滚也才有落点。

权威不等于性能最优

把权威放在裁决最稳的位置，往往意味着它不是延迟最低的位置。工程上通常用预测、缓存和异步确认把体验补回来，而不是把权威挪到离玩家更近的地方。一旦为了手感把裁决权下放，就要准备用事后稽核和补偿机制把治理成本补回去，这笔账通常不会更便宜。

权威转移是高成本动作

项目早期用客户端权威换开发速度，进入商业化后再转服务端权威，是常见的路径，也是常见的代价放大器：历史数据缺审计、协议缺校验、玩家已经习惯了客户端行为。如果立项时能预见到商业化，权威位置尽量早定；做不到，也起码要把转移的迁移成本记进技术债，而不是当作顺手重构。

权威和一致性的关系

权威回答以谁为准，一致性回答多份副本之间偏差多大、多快收敛。权威清晰的项目，一致性策略才有的放矢：哪些状态要求强一致，哪些允许最终一致，都围绕权威源来定。反过来，权威不清时讨论一致性方案，通常是在给错误的状态结构打补丁。

检验权威清晰度的一组问题

• 随便挑一份关键状态，团队能否在三句话内说出权威在哪。
• 修复数据时，有没有唯一允许的入口。
• 出现对不上的展示数据，排障时先信哪份。
• 副本坏了，能否从权威源重建，重建要多久。

这组问题在盘点和评审里都好用，答不上来的每一题都对应一个真实风险。

常见的权威错位场景

• 房间内位置：服务端权威，客户端只做预测表现。
• 队伍和好友关系：常见做法以社交服务为准，房间内只留副本。
• 限时活动进度：配置侧定规则，进度权威在活动服务，客户端只展示。
• 跨服战力：来源服权威，目标服只读副本，不自行计算。

场景不同，权威归属可能不同；同一个场景里的多份状态也各有归属。评审时逐条列出来，比笼统一句“服务端权威”有用得多。

常见误区

• 把“最先算出来的”当权威，结算和展示各算各的，对不齐时只能人工补数。
• 权威状态被多处直改，审计链路断裂，出错无法回滚。
• 为了性能把派生副本当真相，副本一坏就是资损事故。
• 以为指定了权威服务就完成了设计，实际写路径仍然分散在多个系统。

Used By

状态权威归属约定；同步与持久化设计的前提；多源数据争议的裁决。

Related

关系链：核心问题 → 别名 → 同步中的位置 → 数据中的位置 → 单写者 → 转移成本。上游：glossary/01。下游：glossary/05（变更的生效方式）、server 树（同步节点，server/sync）。

Reference

本页为工程经验归纳。