分布式匹配系统工程 2026:Elo、TrueSkill 与 RL 的统一取舍
当竞技游戏的 DAU 跨过百万门槛，匹配系统就从算法小工具变成分布式在线决策系统——它要同时回答胜率预测、置信度更新、组队组合、延迟感知、跨服一致、在线学习六个问题，且每一个都不能拖慢出房间节奏。
约 38 分钟阅读11,298 字2 次阅读博主
当竞技游戏的 DAU 跨过百万门槛，匹配系统就从算法小工具变成分布式在线决策系统——它要同时回答胜率预测、置信度更新、组队组合、延迟感知、跨服一致、在线学习六个问题，且每一个都不能拖慢出房间节奏。
一句话摘要：当竞技游戏的 DAU 跨过百万门槛，匹配系统就从"算法小工具"变成"分布式在线决策系统"——它要同时回答胜率预测、置信度更新、组队组合、延迟感知、跨服一致、在线学习六个问题，且每一个都不能拖慢出房间节奏。
任何一个超过 5 万 DAU 的 PvP 游戏都会在某个时间点撞上同一个问题：玩家抱怨"队友太菜""对手太强""匹配不公平"。运营侧给的第一反应往往是"匹配算法不够好"——然后把 Elo 替换成 TrueSkill、把单变量换成多变量、把确定匹配换成机器学习。这个方向大多数时候不会让问题变好，反而会让延迟从 200ms 涨到 1.5s，把一个工程问题升级成 SRE 事件。匹配系统不是一个静态算法问题，它是一个在 公平、质量、延迟 三者之间持续做取舍的分布式在线决策问题。
我们用三个问题把整篇文章的边界划清楚。第一，"公平"是不是可计算的？很多玩家认为匹配系统应该像主考官一样给出绝对公平的胜负——但 Elo、TrueSkill、Glicko-2 都只是用 胜率预测误差 来近似公平，没有任何一种评分系统能保证每次匹配都贴近 50% 胜率。第二，"质量"应该用什么指标衡量？单局赛后玩家的"主观打分"是被噪声严重污染的，而真实的质量信号来自 次局留存率、举报率、战斗时长分布，但这三个指标的反馈周期太长，无法直接驱动在线决策。第三，"延迟"的下限在哪里？MOBA 类游戏的匹配窗口通常只有 30 秒到 2 分钟——在窗口结束之前必须给出 10 个玩家分两组的解，而搜索空间是 C(N,5) 的组合爆炸。三个问题互相约束：增加搜索时间能提高匹配质量，但会拉长延迟；引入机器学习能提高胜率预测精度，但会拉长推理时间；扩展池子能提高公平性，但会引入高延迟的跨服玩家。
这篇文章的目标读者是游戏后端工程师与架构师，我们假设你已经熟悉 Redis、Kafka 与 gRPC 三件套，不打算讲这些基础设施本身；我们关注的是这些基础设施之上的"匹配服务"如何设计、为什么这样设计、以及当玩家量级从十万涨到千万时哪些设计会被迫重构。文章的结论是：Elo 仍是入门门槛，Glicko-2 是大多数竞技游戏的甜点，TrueSkill 2 在大型赛事排位中是必要的，机器学习匹配在用户量级跨过千万、且具备次局反馈闭环后才能真正发挥价值——并且这四个阶段对应的服务架构、状态机、分布式拓扑完全不一样，必须分开实现。
Elo 是国际象棋协会在 1960 年代提出的评分模型，核心假设只有一条：两个玩家的胜负概率由他们的评分差通过 logistic 函数映射。给定玩家 A 评分 R_A 与玩家 B 评分 R_B，A 战胜 B 的概率为
每局比赛结束后，玩家的评分更新为
其中 S_A ∈ {1, 0.5, 0} 是实际比赛结果。Elo 的优点是 极简：评分是单变量实数，更新公式是 O(1)，分布式存储与同步都很轻；缺点是 所有玩家的评分精度都一样——一个今天才注册的"小号"和一个玩了十年的老号使用同一个 K 因子，这在赛季初的鱼塘里会产生大量"老号炸鱼"事件。
Glicko 与 Glicko-2 是 Elo 的贝叶斯升级，由 Mark Glickman 在 2013 年提出。核心洞察是：每个玩家除了评分 R 还应该有一个评分精度（rating deviation, RD）——RD 越大表示该玩家的真实实力越不确定，匹配系统应该尽早把这些玩家放进匹配池里以"试探"他们的真实实力。Glicko-2 的更新公式比 Elo 复杂很多，引入 RD 与一个系统常数 τ（volatility，控制评分随时间的"漂移"），但要点是：更新不再是对称 logistic 映射，而是带置信区间的加权更新。
工程上的差异点有三个。第一，存储从单 float 变成 (R, RD, σ) 三元组，Redis Hash 的字段数从 1 涨到 3，单玩家 key 的内存涨到 24 字节，匹配池里 1000 万玩家的存储成本从 80MB 涨到 240MB——这个量级在现代数据中心不算什么，但 10 年前的低端服务器会被这个数据量拖累。第二，匹配时的搜索半径从固定窗口变成 RD-aware 窗口：RD 高的玩家搜索半径更大，因为他们更可能匹配到任何评分段的对手；RD 低的玩家搜索半径更小，避免不公平的"老号炸鱼"。第三，RD 衰减与赛季重置：玩家每过一段时间不打比赛，RD 会自动增加（表示系统对其实力的把握在变弱）；赛季切换时，系统会主动把所有玩家 RD 拉高，鼓励新一轮的"试探"。Glicko-2 在《英雄联盟》从 2014 年开始替代 Elo，目前是大多数竞技游戏的默认选择。
需要强调的是 Glicko-2 不是 Elo 的完美替代：当玩家极度活跃（每天 50 局以上）时，RD 会快速收敛到极小值，Glicko-2 与 Elo 的表现几乎一致；当玩家极度不活跃（每月 1 局）时，RD 会涨到 200 以上，Glicko-2 实际上退化成"宽匹配"模式。只有在活跃玩家群体足够大且活跃度差异显著的池子里，Glicko-2 的优势才会体现——这也是为什么棋牌类与轻量级手游可以继续用 Elo 而不需要 Glicko-2。
TrueSkill 是微软 2006 年为 Xbox Live 设计的评分系统，目标是解决"多人对战"（N 人队伍对 M 人队伍）中每个人的评分更新问题。TrueSkill 的核心抽象是一个 因子图（factor graph）：每个玩家的实力 μ_i 是一个高斯分布 N(μ_i, σ_i²)，比赛结果 S 是 N 人与 M 人的实力差的函数，因子图通过消息传递（belief propagation）来更新 μ 与 σ。直觉上，TrueSkill 把 Glicko-2 的"单变量 + 单 RD"扩展成"每个玩家独立的高斯分布"，比赛结果提供了高斯分布之间的相互约束。
TrueSkill 的更新算法是 O(N+M) 的消息传递，比 Naive Bayes 更新快得多，但仍比 Elo 慢 5-10 倍。工程上的实际影响是：每场比赛结束后，TrueSkill 需要异步更新每个玩家的评分与精度，不能像 Elo 那样在请求线程同步完成。一个典型的实现是把比赛结果写 Kafka，后端一组 worker 订阅 Kafka 消息、跑 TrueSkill 更新、写入 Redis——这套管线的延迟从 50ms 涨到 1-2 秒，但匹配查询接口不感知这个延迟，因为匹配时只读不写。
TrueSkill 2 是微软 2018 年发布的升级版，主要改进有四点：第一，引入了 队伍内部差异（intra-team skill variance）——避免"5 个高分玩家组成的队伍"被认为远超"5 个中分玩家组成的队伍"，实际上高分玩家之间的方差可能更大；第二，引入了 可配置的吸引力（draw margin）——支持平局机制（围棋、象棋的平局、电竞中的弃赛平局）；第三，引入了 质量评分（quality score），量化任意两队的预期比赛质量，作为匹配优化目标；第四，引入了 元参数学习，从大量比赛数据中自动学习先验参数。TrueSkill 2 的代码库在 GitHub 上开源（microsoft/TrueSkill2），截至 2026 年 9 月已有 2.1k Star，主要被 Halo 与 Forza 系列使用。
工程上的取舍是：TrueSkill 2 比 Glicko-2 更重，但当比赛模式从 1v1 扩展到 5v5、10v10、20v20 时，它的多人能力扩展是 Glicko-2 无法比拟的。Glicko-2 在多人场景下只能把多人队伍视为"队伍评分 = 玩家评分加权平均"——这忽略了队伍内部的方差。TrueSkill 2 通过因子图天然地建模了队伍内部方差，所以 5v5 场景下 TrueSkill 2 的胜率预测误差比 Glicko-2 低 15-20%。但代价是 TrueSkill 2 的服务部署更复杂：因子图消息传递需要单线程顺序执行（保证收敛），所以 TrueSkill 2 更新服务通常是一个有状态 actor，不能像 Glicko-2 那样用 stateless worker 并行处理。
需要指出一个常被忽略的工程陷阱：TrueSkill 因子图在某些比赛结果组合下不收敛——例如当 5 个玩家对 5 个玩家的结果是 5:0（完胜），因子图会把 5 个胜者的方差压到极小、把 5 个败者的方差压到极大，下次匹配时这些玩家的 RD 跨度会非常悬殊。TrueSkill 2 引入了 钳制（clamping） 机制来缓解这个问题，但仍不是完美解。生产中通常的兜底是 为 TrueSkill 2 评分设定上限/下限，避免极端 RD 漂移到新赛季带来灾难性匹配体验。
评分系统只回答了"谁强谁弱"，匹配系统还需要回答"把谁和谁配在一起"。这是两个不同的问题：前者是 评分学习，后者是 组合优化。直觉上，把评分接近的玩家配在一起能让胜率接近 50%，但"评分接近"不等于"匹配质量高"——例如两个 1500 分玩家可能来自完全不同的玩法风格（一个激进、一个保守），把他们配在一起会让他们都觉得队友"难以理解"。一个好的匹配系统需要定义一个 匹配质量函数 Q：
四个分量的含义分别是：WinProb 是基于评分的胜率预测，越接近 50% 越好；LatencyScore 是两队所有玩家的网络延迟相似度；BehaviorScore 是两队玩家的举报率/退游戏率相似度；WaitPenalty 是匹配池里等待时间超过阈值的玩家的惩罚项。系数 α、β、γ、δ 是人工设定的超参数，多个目标的加权和形成了 多目标优化（Pareto 优化） 问题。
Pareto 优化的工程难点在于 目标间的取舍：把 WaitPenalty 的权重 δ 调高可以让老玩家更快匹配，但会牺牲 WinProb 与 LatencyScore；把 BehaviorScore 的权重 γ 调高可以减少"喷子 vs 喷子"的极端匹配，但会拉长等待时间。运营侧的需求和工程侧的目标经常冲突：运营侧希望"快速出房间"以减少玩家流失，工程侧希望"高质量匹配"以减少赛后投诉。生产中通常的做法是 A/B 测试不同系数组合：把玩家随机分成 4 组，分别用 (α=1, δ=0.3)、(α=1, δ=0.5)、(α=1, δ=0.7)、(α=1, δ=1.0) 跑 7 天，观察次局留存率与赛后评分，找出 Pareto 前沿上的最优组合。
机器学习匹配的第一阶段不是强化学习，而是 学习 WinProb 这个分量：用历史比赛数据训练一个胜率预测模型，把"评分差 + 玩家风格 + 历史表现 + 装备水平"等特征输入，输出真实的胜率预测。这个模型可以用 LightGBM、CatBoost 或简单的 Wide & Deep，但关键是 模型的推理延迟必须控制在 5ms 以内——一次匹配查询要做几千到几万次胜率预测，如果每次 5ms 就会让匹配接口从 50ms 涨到几十秒。生产中通常用 模型蒸馏 + GPU/TPU 推理 或 预计算所有可能组合的胜率。后者在 5v5 场景下不可行（C(10,5)=252 种分组已经够大，加上每个玩家有 10 种评分段就是 252×10^10=252 亿种组合），所以通常是前者 + 在线缓存最近 N 个组合的胜率。
需要强调的是 行为分数（BehaviorScore） 是工程上最容易被忽略的维度，但它的影响远大于胜率预测。两个 1500 分玩家如果一个是举报率 0% 的"老好人"、一个是举报率 25% 的"喷子"，把他们配在一起几乎注定赛后双向举报。BehaviorScore 通常由玩家最近 30 天的赛后评分、举报次数、退游戏次数综合计算得到，存储在玩家的 profile 表里，匹配时直接读取——不需要 ML 模型，但需要人工设定阈值（例如举报率 > 15% 的玩家只能在 BehaviorScore 接近的玩家池里匹配）。
房间制游戏的核心场景是 5v5 组队匹配：5 个玩家组成一队，与另一队匹配。组队匹配比单人匹配的复杂度高一个数量级，因为 队伍内部约束 + 队伍间公平 是两个独立的问题。直觉上，把 5 个 1500 分玩家组成的队伍 A 与 5 个 1500 分玩家组成的队伍 B 匹配是公平的，但实际上队伍 A 内部可能已经磨合了很久，配合默契度远超队伍 B——这种情况下"评分公平"不等于"体验公平"。
工程上的解决方案是 引入队伍协作分（party synergy score）：用队伍成员历史共同比赛的胜率作为队伍内部的"协作分"，匹配时不仅比较两个队伍的评分和，还比较两个队伍的协作分分布。当队伍 A 的协作分显著高于队伍 B 时，匹配系统会主动给队伍 B 找一个协作分更高的对手——这种"软匹配"会导致队伍 A 的等待时间变长，但赛后评分会显著提高。
组队匹配的另一个工程难点是 匹配池的拆分：当队伍 A 与队伍 B 匹配时，匹配池里其他等待玩家不能与 A 或 B 的成员形成新的队伍。这需要在匹配服务里维护一个 lock-and-release 机制：当一个队伍锁定一组候选对手时，其他队伍不能与这组候选对手的任何成员组队匹配，直到锁释放（典型释放时机：候选对手确认进入比赛 / 候选对手拒绝匹配 / 候选对手超时）。lock-and-release 的工程实现通常用 Redis 的 SETNX 加 TTL：每个匹配请求在 Redis 里写一个临时 key，匹配完成或超时后删除；其他匹配请求用 SETNX 抢占这个 key。
组队匹配的博弈论分析告诉我们一个反直觉的事实：完全公平的 5v5 匹配在纳什均衡下会导致"恶意组队"问题。具体来说，当匹配系统对 5 黑队伍的要求过于宽松时，玩家会自发组织"5 黑陪玩"车队（5 个高玩组队虐鱼），这种车队的胜率远超随机匹配预期，导致其他玩家大量流失。生产中通常用 组队限制（party restriction） 来约束：限制 5 黑队伍的最大评分差（例如 5 个玩家评分差不超过 200 分），限制 5 黑队伍的最大段位差（例如 5 个玩家段位差不超过 2 个段位）。这些限制本质上是对纳什均衡的"扰动"——牺牲部分公平性来避免恶意组队。
需要强调的是 跨段位匹配的限制：当一个王者段位玩家带一个青铜段位玩家组队时，匹配系统应该要么禁止匹配、要么让王者段位玩家的评分自动"贬值"以匹配对手。后者是更人性化的做法，但需要匹配系统引入 评分缩放（rating adjustment） 机制：当检测到段位差超过阈值时，系统自动把高段位玩家的"有效评分"压低 50-100 分，使匹配结果接近两队的真实期望胜率。这种机制在《英雄联盟》的"灵活组排"与《Dota 2》的"普通匹配"中都有应用。
竞技游戏的延迟敏感度极高——FPS 游戏的 50ms 延迟足以让玩家的命中率下降 10-15%，MOBA 游戏的 100ms 延迟足以让玩家的操作失误率翻倍。但 低延迟的匹配池是有限的——北京、上海、广州的匹配池是分开的，跨区域匹配必然引入 30-50ms 的网络延迟。如何在"匹配质量"与"网络延迟"之间取舍，是分布式匹配系统的核心难题。
延迟感知匹配的工程实现分为三个阶段。第一阶段是 地理分池（geo-shard）：把玩家按 IP 地址或 GPS 定位分配到不同区域的匹配池，每个池子独立运行匹配算法。这是绝大多数竞技游戏的默认方案，但缺点是 小池子匹配质量差：凌晨 3 点的北京池子可能只有 100 个在线玩家，匹配质量必然下降。第二阶段是 跨区域匹配（cross-region）：当地理池子里的等待时间超过阈值时，系统自动把请求路由到相邻区域的池子。跨区域匹配需要处理 延迟补偿（latency compensation）——给低延迟一方玩家一定评分补偿，让胜率预测更公平。第三阶段是 边缘节点匹配（edge node）：把匹配服务部署到 CDN 边缘节点，让玩家连接到最近的边缘节点进行匹配，从根本上降低跨区域延迟。Cloudflare、Fastly、AWS Global Accelerator 都在 2025-2026 年推出了针对游戏匹配的边缘服务，典型的延迟可以从 50ms 降到 10-15ms。
延迟感知匹配的核心是 QoS 评分（quality of service score）：每个玩家在匹配前先做一次 QoS 探测——向最近的几个边缘节点发送 ICMP 与 TCP probe，测量 RTT、丢包率、抖动；探测结果聚合成一个 QoS 评分，存储在玩家的 session 里。匹配时，匹配系统优先把 QoS 评分接近的玩家配在一起，避免"光纤玩家 + 4G 玩家"的极端匹配。当地理池子耗尽时，匹配系统会扩展到 QoS 评分稍差的池子，但仍要求两队的 QoS 评分方差在阈值内。
需要指出一个常见的工程误区：延迟补偿不能完全替代低延迟。FPS 游戏的命中判定是"客户端时间戳 → 服务端 rewind"——服务端会回滚到攻击发生时的时间戳来判断是否命中。如果客户端延迟 100ms，服务端需要 rewind 100ms 来匹配攻击时间，但其他玩家的移动在这 100ms 内已经走了很远，命中判定会变得"诡异"。MOBA 游戏的技能判定也有类似的 lag compensation，但通常通过"预测 + 客户端修正"来缓解。所以 跨区域匹配的延迟上限是 80ms 左右——超过这个阈值，即使有 lag compensation，游戏的体验也会显著下降。
延迟感知的另一个维度是 网络抖动（jitter）：稳定 80ms 的玩家比波动 50-150ms 的玩家体验更好，因为玩家可以适应稳定的延迟但无法适应不可预测的抖动。QoS 探测应该同时测量平均延迟与抖动（P95 - P50 延迟差），匹配时优先把抖动相近的玩家配在一起。这个细节在大多数开源匹配系统里没有实现，但《Valorant》、《CS:GO》等头部 FPS 游戏的匹配服务里都有专门的 jitter-aware 匹配。
当玩家量级跨过千万、且具备次局反馈闭环时，机器学习匹配才真正发挥价值。传统的 Elo/TrueSkill/Glicko-2 都是 监督学习——用历史比赛的胜负结果来更新评分，匹配时用评分预测胜率。但次局留存率、举报率、战斗时长分布这些真正反映"匹配质量"的指标，并不能直接驱动 Elo 更新——它们是 延迟反馈 的，需要 24-48 小时才能收集到。
强化学习匹配的第一阶段是 Contextual Bandit：把每个匹配候选决策视为一个 bandit arm，玩家上下文（评分、QoS、行为分）作为 context，赛后反馈（次局留存率、赛后评分）作为 reward。Contextual Bandit 模型可以在线学习"什么样的玩家配对能让次局留存率最高"，但它的局限是 只考虑当前决策的即时奖励，不考虑长期影响——例如某次匹配虽然让两个玩家赛后评分高，但他们可能因此被推到错误的分段，长期留存率反而下降。
第二阶段是 Full RL（强化学习）：把匹配过程视为一个 MDP（Markov Decision Process），状态是当前匹配池的玩家分布，动作是"选择哪两个队伍匹配"，奖励是次局留存率与赛后评分的长期加权和。Full RL 的典型实现是 DQN（Deep Q-Network） 或 PPO（Proximal Policy Optimization），但工程难点是 奖励函数的设计：次局留存率反馈周期 24-48 小时、举报率反馈周期 1-7 天、长期留存反馈周期 30+ 天，需要把这些不同周期的奖励聚合成一个可微的奖励函数。生产中通常用 逆倾向得分（Inverse Propensity Scoring, IPS） 来矫正反馈偏差——只有被匹配系统选中的玩家组合才能观测到结果，未被选中的玩家组合无法观测，需要用 IPS 估计"如果被选中会怎样"。
工程上的实际挑战是 冷启动——RL 模型需要大量历史数据训练，但 RL 训练时不能用现有玩家做实验（会影响真实体验）。生产中通常的做法是 离线训练 + 在线 A/B 测试：先用历史比赛数据训练一个 RL 模型（输入是匹配池状态，输出是匹配决策），然后用历史数据做 off-policy evaluation（OPE）评估模型表现；如果 OPE 显示模型比当前匹配算法好 5% 以上，再上线 A/B 测试。A/B 测试的流量通常限制在 1-5%（避免大规模事故），跑 2-4 周后才扩大流量。
需要指出一个反直觉的事实：RL 匹配系统并不总是优于 Elo/TrueSkill。在玩家量级小（< 100 万 DAU）时，RL 模型的训练数据不足，模型表现不如简单的 Elo；在玩家量级极大（> 1 亿 DAU）且玩法模式复杂时，RL 模型可以捕捉到人类专家设计评分系统时无法显式建模的隐式模式，但这种优势通常在 5-10% 的胜率预测精度范围内——而不是数量级。RL 匹配系统的真正价值不是"更准的胜率预测"，而是"更自动的策略迭代"——RL 模型可以持续学习新的玩法模式与玩家行为，而评分系统需要工程师手动调整超参数。
把上面六节的算法放到生产环境，需要一套完整的分布式服务架构。匹配服务的核心状态机有四个：IDLE（空闲）、SEARCHING（搜索中）、MATCHED（已匹配）、CONFIRMED（已确认）。每个玩家进入匹配系统时处于 IDLE 状态；提交匹配请求后进入 SEARCHING 状态，由匹配调度器定期（每 1-2 秒）查询匹配池寻找候选对手；当找到候选对手时进入 MATCHED 状态，等待客户端确认；客户端确认后进入 CONFIRMED 状态，触发游戏会话创建。
匹配调度器的核心数据结构是 匹配池（matchmaking pool）：每个匹配模式（5v5 排位、3v3 休闲、单人乱斗等）对应一个匹配池，匹配池里按评分段位分组（例如 0-1000、1000-1500、1500-2000、2000+），每组用 Redis Sorted Set 存储玩家（key 是评分，value 是玩家 ID）。匹配时按评分段位分组扫描，每组内做 O(N²) 的候选配对搜索，找到 Q 值最高的候选配对。
跨服一致性是分布式匹配的最大工程挑战。当匹配池分布在多个区域时，每个池子有自己的状态，但玩家可能在不同池子之间移动（断线重连、跨区域匹配）。这要求匹配服务实现 分布式事务：当一个玩家从区域 A 的池子转移到区域 B 的池子时，必须保证两个池子的状态都正确更新——否则会出现"双重匹配"（一个玩家同时被两场比赛锁定）或"漏匹配"（一个玩家在两个池子里都不存在）。
分布式事务的实现通常用 两阶段提交（Two-Phase Commit, 2PC） 或 Saga 模式。2PC 保证强一致性但容易死锁，Saga 保证最终一致性但需要在失败时回滚。生产中匹配系统通常用 Saga + 幂等键 的组合：每个匹配请求带一个全局唯一的幂等键，每个状态的转移都记录这个幂等键；当状态转移失败时，根据幂等键回滚到上一状态。Saga 的优势是 不需要全局锁，匹配服务可以水平扩展；缺点是 回滚期间可能出现短暂不一致（玩家可能在 100ms 内同时被两场比赛锁定），但这种不一致对玩家的影响极小（客户端会收到两次进入比赛的邀请，玩家选一个即可）。
Redis 在匹配系统里的角色是 状态层 + 评分层：匹配池的状态、玩家的评分、QoS 评分、行为分等都存储在 Redis 里。Redis 的优势是 O(1) 的读写延迟（< 1ms），支持 Sorted Set、Hash、Set 等丰富的数据结构；劣势是 内存成本高、集群模式下不支持跨 key 事务。生产中通常用 Redis Cluster + 一致性哈希来分布匹配池，每个池子的数据分片到 3-6 个 Redis 节点，每个分片有一个主节点与两个从节点。
Kafka 在匹配系统里的角色是 事件流：玩家进入匹配、找到候选对手、确认匹配、创建游戏会话等事件都写入 Kafka，下游的统计服务、监控服务、推荐服务订阅 Kafka 事件做实时计算。Kafka 的优势是 高吞吐量与可重放性——每秒处理百万级事件，事件可以重放用于离线分析；劣势是 延迟较大（默认 100ms-1s），不适合做实时匹配的同步状态传递。
最后给游戏后端的架构师与工程师一份"分布式匹配系统"的工程清单，按优先级排序：
第一优先级——评分系统选择：玩家量级 < 10 万 DAU 且玩法是 1v1（棋牌、格斗）→ Elo；玩家量级 10 万 - 100 万 DAU 且玩法是 1v1 → Glicko-2；玩家量级 > 100 万 DAU 且玩法是多人对战（5v5、10v10） → TrueSkill 2；玩家量级 > 1000 万 DAU 且具备次局反馈闭环 → 在 TrueSkill 2 之上叠加 RL 匹配。
第二优先级——匹配质量函数：先用简单加权（α·WinProb + β·LatencyScore + γ·BehaviorScore - δ·WaitPenalty）跑 3-6 个月，收集玩家反馈；再用 A/B 测试调权重，找出 Pareto 前沿；最后用机器学习替代 WinProb 的简单预测。
第三优先级——延迟感知：先做地理分池，再做跨区域匹配，最后做边缘节点；QoS 探测必须测量 RTT、丢包率、抖动三个指标；跨区域匹配延迟上限 80ms，超过则放弃匹配等待更好时机。
第四优先级——组队匹配：必须有队伍内部协作分、组队评分差限制、跨段位匹配限制；lock-and-release 机制必须用 Redis SETNX + TTL 实现；组队匹配的等待时间应该比单人匹配长 20-30%，作为"组队公平性"的代价。
第五优先级——状态机与一致性：必须实现 IDLE → SEARCHING → MATCHED → CONFIRMED 的完整状态机；跨服状态转移必须用 Saga + 幂等键；Redis Cluster 至少 3 主 3 从；Kafka 事件流必须记录所有状态转移以供审计。
第六优先级——数据闭环：每个匹配决策必须记录完整的上下文（玩家评分、QoS、行为分、候选对手列表、Q 值计算结果）；每个赛后反馈必须回流到匹配服务（次局留存率、赛后评分、举报率）；每周必须有 OPE（off-policy evaluation）报告对比当前算法与 RL 模型；如果 RL 模型表现更好，扩大 A/B 测试流量。
第七优先级——监控与告警：匹配服务的 P99 延迟必须 < 500ms；匹配失败率（找不到候选对手）必须 < 5%；平均等待时间必须 < 60 秒（5v5 排位）；跨区域匹配延迟 P95 必须 < 80ms。任何一项超过阈值都触发告警。
数据闭环在生产中的具体形态是 反馈管线（feedback pipeline）：客户端 SDK 在赛后上报赛后评分与行为事件 → 服务端聚合到 Kafka → 数仓（ClickHouse / Druid）做分析 → 匹配服务的 RL 模型每周重新训练 → A/B 测试验证 → 全量上线。这套管线的工程成本极高（一个成熟团队需要 5-10 人维护），但它是把匹配系统从"算法小工具"变成"分布式在线决策系统"的必经之路。
最后强调一个常被忽略的事实：匹配系统的最终目标不是"完美的胜率预测"，而是"玩家长期留存"。一个让所有玩家赛后评分都接近 8/10 的匹配系统，可能在长期留存率上不如一个让玩家赛后评分 7/10 但匹配速度更快的系统——因为"快速开始比赛"本身就是一个留存驱动因素。匹配系统的优化目标应该始终指向 长期留存，短期指标（赛后评分、举报率）只是优化的代理指标。
Conversation
0 条