服务器分配
服务器分配是将准备好的比赛绑定到特定位置的特定游戏服务器实例的步骤。撮合机制决定谁一起玩；分配决定他们在哪里玩。如果分配出错，一个完美匹配的小组将在可以避免的延迟下进行游戏。
又称
分配
，
服务器分配在对局生命周期中处于什么位置？
分配是两个系统之间的交接。当匹配系统凑够一组玩家时，它的工作就结束了。而当这组玩家需要一个游戏场所时，基础设施的工作就开始了。
比赛形成。 匹配系统确定了玩家、模式以及通常还有地图。
请求发出。 它携带了放置所需的要素：玩家、他们的 IP 地址或测得 cleavage 的延迟，以及他们客户端运行的版本。
服务器与比赛绑定。 要么占用一个已经在运行的服务器，要么为此启动一个新的服务器。
服务器获悉其比赛信息。 比赛 ID、队伍和预期的玩家到达服务器，以便它知道允许谁加入以及加载什么内容。
玩家获取地址。 每个客户端收到服务器的 IP 地址或主机名和端口，并进行连接。
服务器被释放。 当比赛结束时，服务器会被释放回资源池或关闭。
步骤 2 到 5 通常需要几秒钟，在匹配屏幕上度过。伴随着它所决定的延迟，这段等待时间使得分配成为了玩家最能切身感受到的基础设施部分。
实践中 - 来自 Edgegap 博客的见解
文章的核心洞察
选择地区是玩家的抱怨，而不是功能需求：当玩家要求选择服务器地区时，他们实际上是在报告一个他们无法看到或控制的延迟问题。他们要求的功能只是其中一种可能的解决方案，而在玩家基数较小的情况下，这会用糟糕的比赛匹配换来无法满员的比赛。
基于延迟的分组解决了区域限制试图缓解的问题：区域是行政边界，而延迟是可以测量的。通过测量的延迟（Ping值）将玩家分组，可以将远距离的玩家排除在同一个大厅之外，而无需按地理位置划分队列。
随着时间的推移放宽规则是大多数匹配机制未充分利用的杠杆：动视（Activision）发布的研究表明，随着排队时间的增加，放宽技能限制的速度要快于放宽连接限制的速度。同样的渐进方法也适用于任何池化规则。
当权衡过程可见时，排队时间是可以商榷的：几个社区的玩家都自愿等待更长时间，以获得更好的连接或人数更满的比赛。让他们感到沮丧的不是等待本身，而是不知道等待能换来什么。
透明度和自主权缩短了反馈循环：可见的 Ping 值和选择等待更近服务器的选项，可以将模糊的指责转化为玩家可以采取的行动，代价是可能会暴露你不想公开的数据。
申领现有服务器还是启动新服务器？
完成步骤 3 有两种方法，它们之间较大的区别不在于速度，而在于何时决定位置。
认领就绪服务器。 服务器池已经运行，每个服务器都处于就绪状态并等待中。分配操作会标记其中一个已被占用，并分发其地址。在任何玩家排队之前，当服务器池被填满时，位置就已经固定了。
为比赛启动服务器。 没有等待中的服务器。分配操作会为此组玩家选择一个位置并在该处启动服务器，因此所需的时间是服务器的冷启动时间。位置是在玩家确定之后才选择的。
当服务器池在合适的位置保有服务器时，认领的感觉是瞬间完成的。当服务器池耗尽，或者在该组玩家所在的城市没有服务器时，比赛就需要等待补充，或者在不太适合的地方进行。热备池介绍了保留该容量的成本。
了解玩家也改变了“合适的位置”的含义：针对一个团队的放置会权衡每位玩家的延迟，而不仅仅是第一位玩家的延迟（服务器区域将其与提前分配区域进行了比较）。
为什么服务器分配会失败？
玩家们通过其错误消息了解此步骤。在《战争机器 5》（Gears 5）和《极限竞速》（Forza Motorsport）等游戏中，“服务器分配失败”（Server allocation failed）经常出现，以至于玩家会去搜索它。在该消息背后，原因通常很少：
请求的位置没有容量。 该位置的连接池已空，或者该位置没有空间容纳新服务器。
没有运行该比赛版本的服务器。 在补丁日，新版本的客户端需要新版本的服务器，反之亦然。在更新的双方都拥有容量之前，某些请求将无处可去。
服务器未及时准备就绪。 未在主机上缓存的大型镜像或缓慢的游戏启动，都可能超出请求的超时限制。
一个构建良好的分配流程会将失败视为一个正常的分支，而不是一个异常。它会重试有限的次数，回退到另一个位置或服务商，并保留玩家在队列中的位置，而不是将他们送回起点。客户端也会在很短的时间窗口内重试连接，因为在服务器仍在启动时，地址就已经到达了。
玩家是否可以被分配到正在运行的服务器？
分配不仅适用于新比赛。以下情况会将玩家送入已经运行的服务器中：
补位 (Backfill) 用于在玩家离开时填补比赛中途空出的席位。运行中的服务器会向匹配系统请求玩家，这与通常的请求方向相反。
多房间服务器 在一个进程中托管许多小型比赛，因此新比赛分配的是一个房间，而不是整台服务器。
基于席位的会话在社交中心和持久化世界中很常见，它会在玩家离开之前，一直在服务器上为该玩家提供一个位置。
在每种情况下，分配器不仅跟踪服务器，还跟踪服务器内部的容量。拥有两个空闲席位的服务器可以容纳一个两人队伍，但不能容纳三人队伍，因此这种簿记决定了服务器实际运行的饱满程度，并以此决定了会话填充率。
来自我们的赞助商（其实就是我们自己！）的寄语
发布当天绝不是发现编排系统边缘情况的好时机。自2019年2月以来，Edgegap的自动化编排系统已在其分布式多云网络上运行了1.35亿次游戏服务器部署。如今，它每天都在为数千款游戏和数百万玩家进行部署。
Edgegap 的观点（仅代表个人意见，姑且听之即可！）
记住要为可能失败 heavy 的分配做好预案
大多数团队追踪的分配数量描述的是成功的分配：服务器启动有多快，资源池分发有多迅速。但玩家们也同样经历着那些失败 environmental 的分配。
因此，在发布前，请在“为什么服务器分配会失败？”一节中决定每次失败时会发生什么：重试多少次、下一个是哪个位置或服务商、玩家是否保留在队列中的位置，以及在发生这种情况时他们会看到什么。然后，测量在高峰期（而非平均水平下）最终所有玩家成功连接的已组建比赛的比例。如果没人能提供这个数据，说明失败路径还没有经过测试。
Edgegap 的平台数据显示，自 2019 年 2 月以来已有 1.35 亿次部署，其中包括未能启动的部署（平台数据，2026 年 9 月 18 日）。备用方案也需要有去处：Edgegap 跨越 17 个以上服务商的 615 多个位置，并在它们之间提供自动故障转移。
，
