一场对决如何诞生，逐秒还原

第一幕 · 那四秒

三个角色接力，把玩家送进竞技场。

在按下「进入竞技场」这个动作的背后，三个系统像接力赛一样传递接力棒。第一个 看守队列：收下想要开战的请求，并一直保管，直到找到对手。第二个是 配对仲裁者：决定谁对上谁，好让较量势均力敌，并分配一座竞技场。第三个 点亮那座竞技场—一台专用服务器，位于离双方最近的那个角落。把这些角色分开 是有明确理由的：这样每个只做一件事，一旦哪里变慢，立刻就知道该盯这三者中的哪一个。

第一幕 · 流程，逐秒还原

等待的转圈背后发生了什么。

对玩家来说，这只是几秒钟的等待。在那个转圈背后，三个角色沿着一条精确的接力线 传递接力棒：收下玩家、找到 对手、点亮竞技场、把进场的钥匙交到两人手里。下方这条线 逐秒展示这场接力，并标出每一步可能 花费的时间。

底层原理。 玩家的应用只发出一个请求；其余一切 都在我们的服务器上完成。七个系统沿着一条带有三次 签名交接的路径协同工作—这样没人能冒充别人。

第二幕 · 势均力敌的对手，而非随机

一名玩家值多少 — 以及我们有多确信。

随手抓来的对手就是一场抛硬币：对强者是无聊， 对新手是折磨。所以配对并不随机。在让两个 人面对面之前，系统会问两个问题：每人有多强，以及有多确信。一名刚注册的玩家和一名歇了 一个月才回归的老手，纸面上可能分数相同，但对 前者我们了解得少得多 — 若把他们当作了解程度 相同来对待，就会产生不平衡的对局。连同 我们自己的不确定度一起衡量，正是这一点把配对 从掷骰子变成了一场真正的 较量。

底层原理。 一个朴素的评分系统只为每名玩家保留一个数字： 他有多强。我们的系统保留三个：我们认为他值多少 （μ）、这个值有多少不确定度 （φ），以及这个值随时间有多不稳定 （σ）。举例来说，当一名歇了一个月的老手，遇上某个 强者用来混在新手里、也许正打着连胜的小号时， 这三个数字都很重要。在这三个数字之上，我们的 系统又加了四项自研修正，每一项都用来堵住回合制 竞技游戏里试图钻评分空子的四种方式 之一。

第二幕 · 让队列动起来的旋钮

在放宽搜索之前该等多久。

找到势均力敌的对手要花时间：搜索 保持得越紧，配对越好 — 但 没人愿意无休止地盯着一个转圈。这部分的全部 调校都在这份张力中反复权衡：等得足够久， 好找到合适的对手，在等待变成烦躁之前放宽搜索， 并且即使成千上万的请求在同一刻涌来， 也让队列继续流动。

底层原理。 掌控这份节奏的， 是我们主服务器上的少数几个数字 — 多久 看一次队列、一个请求保活多久、同时 能撑住多少个。默认设置面对最坏情况 — 数万名 玩家在同一时刻排队 — 保守得过了头。下方这些 数值，才是让队列持续流动、而不是越积越堵的 那一组。

第二幕 · 剖开仲裁者

配对仲裁者，以及它绝不违背的两个承诺。

真正决定谁对上谁的那一块，是一个 自成一体的小服务：仲裁者。每提出一对配对，它就计算 这场对决是否会势均力敌，分配一座竞技场，并把 进场的钥匙交给每一方。它运行起来又快又省， 而这一部分会把它一块块拆开来看。

底层原理。 这是一个专用的小 服务，只有少数几个功能，状态模型精简 到极致。在表象之下，「两个承诺」是 两条技术保证：一局对局的身份只能被 兑现一次；胜者与败者始终恰好绑定在配好对的 那两名玩家身上。下面就来看这个服务对外的样子，以及那两条不变量。

第三幕 · 杜绝作弊

一个服务如何证明自己确实是它本人。

手机是一块屏幕，不是裁判。当它报出一个 分数、宣称一场胜利、或声明自己是谁时，都不能 仅凭它一面之词就相信。这一部分的整套架构正由此 而来：每条消息都带签名，每局对局都发一次性钥匙，每个 结果都要先在我们的服务器上重新校验，然后 金币或排行榜名次才会变动。就从签名讲起 — 有了它， 即便在我们自己的服务器之间，也能 证明自己确实是本人、而非冒充者，就像一枚谁也 仿不来的火漆封印。

底层原理。 每一次通往 配对服务的内部调用都是一个带签名的请求：签名 随消息一同传送，接收方在采信任何一个字之前，会 先核实它是否真实。讲的是思路，而非 配方。

第三幕 · 对局的钥匙

为对的两名玩家、打开对的那扇门的一次性钥匙。

配好对之后，两名玩家各拿到一把钥匙 — 不是随便一把，而是恰好只开一扇门、只开一 次、并在几分钟后自行失效的那种。 这跟酒店房卡是同一个道理：只有对的客人才能进 对的房间，住期一过，它就再无用处。这样， 配好对的两名对手 — 别无他人 — 才会落进 同一座竞技场，而那把钥匙也无法被重用去 第二次溜进来。

底层原理。 钥匙是两枚带签名 的令牌，每席一枚，只在几分钟内有效，不可续期。 让它们不仅仅是「存在」、而是「安全」的，是它们 被「消耗」的方式：两人中任一方第一次进入竞技场时， 钥匙会在一个不可分割的操作中被标记为已花费， 之后的任何尝试都会被拒绝。就是这个思路。

第三幕 · 结果，以及我们堵上的漏洞

一局打完的对决如何变成奖励、排行榜与训练数据 — 且无人能作假。

对局结束后，不能仅凭玩家一面之词就相信 结果：裁定会先在我们的服务器上被重建并重新校验， 然后才会有哪怕一枚金币易手、或哪怕一个 排行榜名次挪动。也只有到那时，同一个结果才会 同时化作三样东西 — 给胜者的奖励、 排行榜的更新，以及一行数据，我们用它来训练 那个终有一天将以冠军水准对战的人工智能。

底层原理。 一局结束时，战斗服务器并不 自行发放奖励：它从不触碰钱包 或排行榜。它为裁定签名，并用两条各自独立 的带签名消息，发给两个有权让其生效的 服务 — 一个入账金币并更新排行榜，另一个 更新评分。在动任何东西之前，各自都会 重做自己的检查。

只有当所有这些检查都通过 — 再加上另一层 对外保密、用于核验消息流转的安全机制 一并通过 — 结果才会 生效。

第四幕 · 战斗在玩家身边运行

在两名玩家身旁诞生的微型竞技场，遍及世界各地。

一场对决并不在地球另一端某个庞大的计算中心里 运行：它运行在一座独立的小竞技场里，这座竞技场 诞生于离两名玩家最近的区域，托管这场对局，并在 结束后立刻消失。这是一套先进的、就近部署的 战斗微型实例系统 — 许许多多独立的小竞技场， 在需要的地方、需要的时候出现。 这样，无论对战双方身在何处，从米兰到东京， 对决都灵敏而公平。

底层原理。 这是一套由我们自己构建和运维的 分布式架构，跑在真正的生产级云基础设施上， 带来四项实实在在的好处。

• 延迟 竞技场在离双方最近的区域点亮，因此指令走的路很短，对决即刻响应。
• 韧性 若某个区域出问题，对决会自动改道到邻近区域 — 不丢一局，不停一次。
• 弹性伸缩 容量实时跟随全球需求，峰值时数千座竞技场，平静时几乎一座不留，毫不浪费。
• 深度集成 这一切与平台其余部分深度交织，而非搁在一旁 — 是一套扎实的分布式系统，而不是一页幻灯片。

战斗负载是我们基础设施中最难预测 的部分：在同一个 24 小时里，高峰时段欧洲的 需求可以是亚洲低谷时段的四倍。 一套按区域自行开启与关闭的微型竞技场系统，能 跟上这道波峰波谷，而无需照着峰值养一支 空转的机队。

第四幕 · 数字，实地测量

到底能扛住多少，用真实数据测量。

这一部分的每个数字都来自负载下的实测， 而非估算。目标是精确说明：把这套系统往上推时它 能扛住什么，又从哪里开始出现裂纹 — 哪怕答案并不好看：只用挂靠在真实跑过的 负载测试上的数字，绝不在测量结果只是千级时 报出「百万级」的数字。

底层原理。 以下是实测的上限，逐行 列出 — 持续负载、最坏情况、把配对仲裁者 从主服务器分离之后的收益 — 每个数字旁边都附上出处；凡是某个数字属于设计 目标、而非已经拿到的测量值，都会 明说。

本章中关于容量的每一句话，都 挂靠在我们内部文档所记录的一次负载测试上。 下方的数字来自负载下的实测， 而非估算。

第四幕 · 当队列停下时

当某处卡住时我们怎么做。

任何系统迟早都会卡住。把成熟的 服务和脆弱的服务区分开来的，不是从不 出故障，而是提前知道它怎样出故障，并且 早已备好让它重新运转的那一手。

底层原理。 真正要紧的不 是可能故障的清单，而是故障出现时会发生什么： 多数情况下系统会自行恢复，而任何情况下，一次 故障都不会留下一个错误的评分。