深入解析
深入了解 Edgegap 的无代码配对器概念，并根据您的需求进行自定义。
✔️ 介绍
在 5 分钟内开始并免费测试所有功能，无需信用卡。
在准备好使用更强大、私有（专用）集群时升级。与 Edgegap 的原生集成 部署 可在任何玩家所在地提供同类最佳的延迟表现。
免费层在每次重启后允许 3 小时运行时间。您的配对器将运行在资源有限的共享基础设施上，适用于测试。 在公开发布后，配对器需要 24/7 不间断运行。
每个配对器有三个基本概念：
深入解析 - 由 Edgegap 完全托管和运营的底层服务器基础设施。
深入解析 - 定义配对器如何运行的一组规则和设置。
🌐 服务实例 - 在集群上 24/7 运行的实时匹配服务，使用配置将玩家配对并生成部署（服务器）分配。
经常更新您的配对器版本 以便 利用新功能和错误修复。
▶️ 开始匹配
了解匹配流程以定制、排查和优化您的游戏集成。
玩家认证 - 防止盗版副本在线游玩，
创建大厅 - 与朋友一起加入并共享玩家/匹配偏好，
组队 - 将您的大厅注册为匹配组，
查找匹配 - 准备并开始寻找匹配（新的或现有的），
分配服务器并注入票据 - 服务器会在几秒钟后自动分配，
连接并认证 - 尝试与游戏服务器建立安全连接，
确认身份 - 服务器使用第三方令牌验证游戏客户端的身份，
接受玩家或踢出玩家 - 服务器决定是否允许玩家加入。
快速入门 - 将我们的匹配入门示例添加到您的游戏中:
认证
该令牌可以安全地包含在您的游戏客户端中，因为它不会授予对 Edgegap API 的访问权限。
可以使用客户端和服务器上可用的票据 ID 来识别单个玩家。可选地，通过自定义代理使用自定义认证或限制，使用 服务器到服务器 API。
组队
创建一个组（队伍）可确保玩家与朋友加入相同的队伍和服务器。
创建一个标记为已准备好的组以 深入解析 尽快作为 没有组员的单人玩家.
大厅和组
如果您的游戏设计需要设置玩家可控的匹配偏好（例如角色选择、难度、地图等），请使用大厅服务。随着玩家加入和离开大厅，他们也会更新匹配组以准备稍后查找匹配。
没有时间维护大厅服务？ 引导玩家通过 Discord 或私信分享组 ID。
邀请朋友与我一起游玩
✅
✅
修改我的玩家/匹配偏好
✅
❌
查看其他大厅成员的偏好
✅
❌
存储和管理自定义键值数据
✅
❌
通知组员我已准备好游戏
❌
✅
显示匹配进度并查找匹配
❌
✅
获取玩家/组的队伍分配
❌
✅
检索游戏服务器连接详情
❌
✅
我们的跨平台配对器支持所有商业和自定义大厅服务：
Epic Online Services 大厅 （Epic Games）
Steamworks 大厅 （Valve Corporation）
Nakama 组 （Heroic Labs）
Playfab 大厅 （Microsoft）
brainCloud 大厅 （bitHeads）
Gamekit 好友 （Apple）
自定义大厅 （您的公司）
大厅拥有者（发送邀请的玩家）也必须创建匹配组。
将您组的 ID 存储在共享大厅数据中，以便其他大厅成员可以轻松找到并加入与第三方大厅关联的匹配组。被邀请加入组的玩家使用组 ID 来 创建他们的成员（加入），并且来 安全地存储他们的 匹配属性.
一旦组开始匹配，就无法加入。 深入解析 并创建一个新组。
Ping 优化
如果 深入解析 包括 延迟 规则 所有组员将他们的 Ping 信标 测量值发送到 以防止在相距较远的区域匹配玩家， 或延迟（响应时间）高得多/低得多的玩家。
放弃队列
组拥有者可以删除组，同时自动删除所有组成员。匹配开始后删除组将取消所有成员，并在不久后删除它们。
组成员（除拥有者外）可以在任何时候在 深入解析之前删除他们的成员资格（离开组）。之后删除成员资格将取消整个组的匹配。
一旦匹配被取消，成员将 自动从匹配中移除 并通过成员资格收到通知， 状态:CANCELLED 在他们下次的状态轮询响应中。
取消后，如果组希望重新开始匹配，组拥有者必须重新创建组，将新的组 ID 分享给成员，并让他们重新创建成员资格。
一旦找到匹配，组就无法被删除 (409 冲突），并将被 自动移除。您的服务器应允许一些时间（例如 60 秒）让玩家连接，然后再假定玩家已放弃。在这种情况下，您的服务器可以：
用 AI 角色替换离开者以立即开始比赛，
或创建一个 回填（补位） 以查找新的玩家替换离开者，
或者如果您的游戏设计允许可变玩家数量，则不替换离开者继续进行。
查找匹配
要开始寻找匹配，所有成员和拥有者都必须将自己标记为已准备。
为让组拥有者 立即开始匹配，请在创建时将成员标记为已准备。一旦拥有者将自己标记为已准备，由于所有人都已准备，匹配将开始。
为获得最佳体验， 使用游戏内 UI 向玩家提供状态更新.
所有玩家必须定期轮询其成员资格 （建议 3-5 秒）以检测匹配何时开始，并通过游戏内 UI 通信匹配进度。
玩家应当 持久保存他们的成员和组 ID，以便在游戏客户端崩溃的情况下，他们可以重新启动游戏并继续而不会丢失匹配进度。
一旦我们找到足够的玩家将其放入遵循您配置的同一队伍， 规则玩家将在其成员响应中收到通知，带有 状态:TEAM_FOUND.
在此阶段删除成员资格将导致所有组成员资格被取消，并且所有分配到同一队伍的其他组将返回到 状态:SEARCHING .
队伍使用其组之间的重叠值（或在 number_difference 的情况下取平均）继续与其他队伍匹配，直到组装出足够的队伍。成员资格通过响应指示这一点， 状态:MATCH_FOUND ，这意味着您的 部署正在启动.
配对器旨在最大化匹配填充率，并且在以下情况之前不会进入 MATCH_FOUND ，直到满足下列任一条件：
足够的队伍与配置的最大队伍大小匹配，
或者如果定义了 深入解析 并且扩展时间已到，且足够的队伍与配置的最小队伍大小匹配，
或者配置的票据过期时间已到且足够的队伍与配置的最小队伍大小匹配。
如果在配置的票据过期之前两种情况都未成功，组和票据将被取消。
在测试期间或玩家位于不太热门的区域时遇到长时间排队？将票据过期时间设置得更短（例如 30 秒），并在过期后在客户端重新创建组（或票据）。
票据过期会在组（或玩家）被匹配到队伍时自动重置。
存储 team_id 和 match_id 在您的游戏后端以在游戏中显示队伍成员信息。
每位玩家都会收到一个 唯一的票据 ID，可用于 深入解析 与游戏服务器进行通信。
如果玩家已被匹配并分配到游戏服务器，他们的票据会被自动删除。在 状态:HOST_ASSIGNED 之后放弃队列的玩家可以被替换为 回填（补位）.
一旦玩家收到 状态:HOST_ASSIGNED 他们将继续 深入解析.
连接到服务器
回填匹配
一旦游戏服务器初始化完成， 您的服务器应当:
为每个新玩家启动放弃计时器。 我们建议通过加载场景/关卡向已连接的玩家显示加载进度——可以是完整的 3D 场景、类似大厅的社交 UI，或带有进度条的加载屏幕。
跟踪新玩家连接或现有玩家随时间离开的情况:
新玩家必须向服务器宣告票据 ID 以进行认证并将其连接映射到配对器 深入解析 或
assigned_ticket（如果是回填）。在服务器生命周期内为未使用的玩家容量（离开者）创建新的回填。
续订已过期的回填，这些回填将在
ticket_expiration_period.
之后被删除。 清理（删除）任何剩余的回填 部署:
一旦
Unity -OnApplicationQuit回调或自定义游戏结束回调，
虚幻引擎（Unreal Engine） -,OnWorldDestroyedPreExit
，或自定义游戏结束回调。 匹配服务 任何配置文件都可以用于回填，只要提供有效的服务器分配并至少提供一个票据。参见
以获取最小示例。
⚙️ 配置
匹配器 API 是根据您创建新配对器（或快速重启）时指定的 JSON 配置生成的。您可以为不同比例和扩展指定任意数量的配置文件： 匹配服务 请参阅
以查看我们的 SDK 和详细示例场景。 编辑正在运行的配对器将会触发快速重载
，删除所有票据并导致短暂停机。配置文件（队列）
配置文件表示完全独立的匹配队列，共享相同的匹配器版本。您可以 为每个匹配器配置任意数量的配置文件。 将玩家群体拆分到多个配置文件可能会导致玩家的等待队列时间更长。
每个匹配器配置文件使用一个 应用版本 作为启动新部署（服务器）的模板。
某些游戏模式可能需要更多的 vCPU / 内存，尤其是在支持更多玩家的情况下。每个 匹配器可以包含多个配置文件, 每个配置文件链接到具有调整资源的应用版本。
规则
每个玩家和小组加入匹配队列并使用 初始 规则开始匹配。
配置文件中路径为 .rules.initial 的每一项都代表一条规则，其中：
键 是一个字符串值，用于按您喜欢的方式命名规则；例如
match_size, 和值 是一个对象，定义规则的类型和属性，遵循我们的标准规则集。
要启动主机分配并开始或查找部署，必须同时满足所有规则。
运算符（规则类型）
player_count 是一条特殊规则，定义需要多少玩家匹配以启动分配。
规则 player_count 是必需的，并且在 您的初始配置规则中只能定义一次。
匹配器始终努力最大化匹配填充率，直到指定的 max_team_size :
如果达到最大队伍大小，则立即生成比赛，
否则，玩家将在队列中等待填满比赛直到 扩展 （或过期）即将到期，
在 扩展 （或过期）之前不久，如果可能进行部分匹配（≥ 最小且 < 最大队伍大小），则该比赛将与处于相同扩展阶段的所有玩家一起生成（假设其他规则通过）。
对于合作、乱斗或不对称队伍规模的游戏模式，请将您的 "team_count": 1 .
队伍数量可以配置为为竞技游戏组成多个平衡队伍：
组属性按其 玩家属性的平均/重叠 计算，
队伍属性按其 组属性的平均/重叠 计算。
假设固定队伍规模为 4 名玩家：
组在不超载的情况下匹配到队伍中， 仅当某队有足够的容量容纳整个小组时。
string_equality 将具有完全相同字符串值的玩家匹配在一起。
规则示例： selected_game_mode
selected_game_mode 规则将区分大小写匹配玩家：
✅ Alice + Bob + Dave 可能匹配，
❌ Alice + Erin，或 Charlie + Frank 永远不会匹配。
Alice
Erin
Frank
Bob
Charlie
Dave
number_difference 在玩家之间按绝对数值差异进行匹配。
规则示例： elo_rating
elo_rating 上述规则与 "max_difference": 50 最初：
✅ Alice + Bob 可能匹配，或 Bob + Charlie 可能匹配，
❌ Alice + Bob + Charlie 永远不会匹配。
intersection 将具有一个或多个重叠字符串值的玩家匹配在一起，区分大小写。
规则示例： selected_map
selected_map 上述规则与 "overlap": 1 将匹配：
✅ Alice + Bob + Charlie 可能匹配，或 Alice + Bob + Dave 可能匹配，
❌ Alice + Bob + Charlie + Dave 永远不会匹配。
规则扩展
可选地， 扩展 在玩家在队列中等待一段时间后修改规则的属性，以放宽限制并扩展可匹配的玩家池， 从而加快匹配速度.
示例场景：扩展
最初，我们要求 1 支队伍，由恰好 4 名玩家组成（可能由小组拆分） 并且：
对同一（任一）信标的最大延迟为 125 毫秒，
对同一信标最低/最高值之间的延迟差异为 125 毫秒或更少，
最低与最高排名玩家之间的技能评分差异不超过 50 分，
完全相同（区分大小写）的所选游戏模式，
玩家之间至少有一个匹配的地图选择（区分大小写），
玩家之间至少有一个匹配的 回填组大小 值。
在上面的示例中，我们 通过修改属性来扩展搜索， 在以下时间后：
30 秒：
4 名玩家
150 技能评分范围
最大 250 毫秒延迟
60 秒：
4 名玩家
200 技能评分范围
最大 250ms 延迟
3 分钟（180 秒）：
1-4 名玩家
200 技能评分范围
任意延迟
微调扩展
预测玩家偏好类似于射击移动的目标。在发布时从较不严格的规则集开始，然后通过迭代优化， 深入解析.
这些问题可以帮助构建您的思考过程：
我的游玩时长是多长？
5 分钟的游玩时长意味着每位玩家每 5 分钟重新加入队列一次，这将间接减少队列时间，因为在任意给定时间会有更多玩家在排队。
我的 峰值 CCU 以及我的 低潮 CCU?
如果低/高之间存在高方差（超过 60%），您可能需要为低潮期设置单独的配置文件，在每次扩展中等待更长时间以积累更多玩家。
我的玩家的地理分布是怎样的？
跨多个时区的均匀分布意味着峰值和低潮的差异较小，但如果您的 深入解析 配置正确（会导致高延迟），则不会提高匹配速度，因此不同地区的玩家不应匹配。
我每个区域的技能评分分布如何？
技能分布通常遵循 钟形曲线 （自然分布），因此每偏离平均值一个标准差，您会发现更少的玩家位于远离平均值的位置。具有平均值的玩家将在第一次扩展中快速匹配，但极端值是一个问题。
我们建议在每次扩展时增加扩展的差异量，例如 25 -> 50 -> 100，以便考虑到曲线极端位置上的玩家较少。
如果您有任何挑战者层（职业玩家），我们建议使用自定义技能设置创建单独的配置文件，因为样本较小且通常不遵循整个玩家群的宏观趋势。（倾向于极端，反向钟形曲线）
如何在玩家基数较小的情况下提高匹配速度和匹配填充率？
尽可能多地了解您的玩家及其偏好！
考虑在初始阶段移除一些规则或放宽限制。
随时间放宽队伍大小或队伍数量——部分匹配总比没有匹配好。
增加扩展之间的持续时间以积累更多玩家。
就您的游戏设计向我们咨询更多提示和技巧。
任何规则属性的扩展将会 覆盖该属性的先前值。 📌 注入变量
您的服务器可能需要了解其玩家的详细信息。玩家属性、解析出的匹配值和其他值会与通常的
一并注入到您的部署中， 应用与版本.
预览未格式化 🏁 高级示例变量：
环境变量是 以字符串化 JSON 存储的，请使用我们的 SDK 或自定义方法解析它们。
服务器可以在玩家将其票证 ID 发送到服务器后将玩家连接映射到组和属性， 。
🧵 玩家追踪
如果您的玩家遇到任何问题，将他们到服务器日志的路径进行追踪会很有帮助。每个匹配器 部署 都会带有所分配的玩家票证 ID 的标签， 以便您可以轻松地 部署 并找到 部署 以帮助您进行故障排除。
在客户端匹配历史界面中显示票证 ID 和部署 ID 以在故障排除时追踪玩家。
匹配器 API 是根据您创建新配对器（或快速重启）时指定的 JSON 配置生成的。您可以为不同比例和扩展指定任意数量的配置文件： 部署 以了解有关部署故障排除的信息。
👀 分析
深入了解您的匹配器负载和性能，无需编写代码或配置。
🌟 将匹配器升级到企业版层级 以解锁匹配指标和洞察：
☁️ 托管集群
匹配器由 Edgegap 提供便捷托管并全天候 24/7 管理。
选择最适合您目标的托管选项：
私有集群层级
一键升级到私有集群。发布后更改私有集群层级也可以在不造成玩家停机的情况下进行， ⏩ 滚动更新. 托管集群由 Edgegap 维护，提供高可用性服务托管并为公开发布的游戏提供 24/7 实时支持。
实例的资源需求将取决于以下因素：
玩家数量 - 更多玩家会产生更多票证和 API 请求，
每位玩家的请求数量 - 更快的重试会增加服务负载并消耗资源，
配置复杂性 - 交集规则和扩展尤其要求较高，
平均匹配时长 - 较短的会话会使玩家更频繁地重新加入匹配，
过期和移除周期 - 陈旧的票证会随着时间堆积并消耗资源，
客户端重试回退逻辑 - 带抖动的指数回退重试有助于分散流量高峰。
为成功做好准备并在发布后优化，这样您就不会在发布日期阻塞玩家。 使用 开发者工具 或 实现带抖动的指数回退 以从高负载中恢复。
速率限制
为了保护您的集群不超出其突发容量并崩溃，我们基于内部负载测试限制每秒请求数，使用 匹配服务 配置。
总体限制
100
200
750
2,000
创建部署
5
10
30
30
列出信标
10
20
75
200
创建组 + 创建工单 + 创建组工单
10
20
75
200
读取成员资格 + 读取组 + 读取工单
10
120
450
1,300
创建回填
5
10
37
100
速率限制以…表示 对指定 API 端点集合的合并每秒请求数.
如果你的游戏客户端在收到响应 429 请求过多 你的部署可能会缺少玩家， 这些玩家由于高负载而停止读取他们的分配。
负载测试
配对和分配需要 CPU 和内存使用，为每个私有配对服务需要托管成本。请参阅每个等级相关的资源和价格，见 我们的定价页面.
始终使用 私有集群 用于压力测试。 免费配对服务严格仅限于开发测试。
在设计你的负载测试时， 请考虑真实的玩家模式:
✅ 玩家逐步加入配对，数小时内请求/秒逐渐增加。
❌ 所有玩家在完全相同的那一秒协调并创建他们的工单。
✅ 玩家在重试之间等待越来越长的时间（例如 1s-5s-10s-10s）。
❌ 所有玩家在收到 429 请求过多 响应后立即重试。
✅ 大多数玩家会在短时间内（10-60 秒）收到他们的分配并停止轮询。
❌ 即使在收到分配后，所有玩家仍会在预定时间内持续轮询。
✅ 大多数玩家在重新开始配对之前会先完成他们的游戏（需要时间）。
❌ 所有玩家在收到分配后立即重新开始新的配对。
✅ 峰值流量每天持续 6-8 小时，然后某些时区流量会下降。
❌ 峰值流量全天 24 小时持续，所有玩家日夜不停地玩。
如果配对服务正经历高负载：
如果 CPU 被限流，配对速度可能会变慢，
如果配对服务耗尽内存，它将重启但不会丢失工单信息，希望客户端会实现指数退避并将突发流量分散到更长的时间段内。
⏩ 滚动更新
跟踪服务端与客户端版本之间的兼容性可能会变得复杂。请遵循我们的提示以实现可靠的发布、更新，并防止停机或兼容性问题。
在重启后，你的配对服务 URL 和认证令牌将始终保持不变。
为开发和生产创建独立的配对服务 环境以安全地进行实验。
⚠️ 上线前
我们建议提前创建多个配对服务副本： 绿色, 蓝色 和 橙色。在发布更新时，你可以轮换正在使用的配对服务（蓝绿策略).
为每个实例选择不同的区域以防止在局部故障期间出现停机。 在局部故障期间。
🔃 客户端 + 服务端更新
先决条件： 本节假定你已完成 深入解析.
为了 发布游戏客户端 + 服务端更新，你可以：
准备新的服务器应用版本
v1.2.0-rc在 Edgegap 上：将新的镜像标签推送到你的容器注册表
t1.2.0,创建新应用版本
v1.2.0-rc,
通过执行任何开发测试 部署你的新应用版本
v1.2.0-rc:将你的游戏引擎编辑器连接到提供的 URL + 外部端口，
更新未使用的配对服务
蓝色以链接到你的新镜像标签t1.2.0,为新应用版本启用缓存
v1.2.0-rc，为该版本启用缓存将确保该镜像也为版本缓存，v-blue因为它们引用相同的标签，等待版本中缓存指示器
v1.2.0-rc达到 🟢 绿色，
更新你的新游戏客户端
c2以使用新版本v-blue在创建工单时：在游戏客户端中更新你的基础 URL 和授权令牌，
执行 QA 测试并对你新的游戏客户端进行最终验证
c2:如果你发现并解决任何问题，请从头重复该过程，
在配对服务已停止后，等待 3-7 天以便配对服务的 DNS 更改传播到全球 ISP（快速重启不需要 DNS 更新或等待期），
发布你的新游戏客户端更新
c2在游戏分发平台上，给予时间让新的游戏客户端
c2分发到玩家设备（通常最多 3-7 天）：监控过期的游戏客户端
c1使用部署 部署,
清理你 Edgegap 帐户中未使用的资源：
删除镜像标签
t1.0.0以释放容器注册表容量，删除镜像标签
t1.1.0以释放容器注册表容量，关闭你的
绿色配对服务以暂停计费直到你的下一次更新。
对于你的下一次更新，增加版本号并交换指南中的 绿色 和 蓝色 关键字。
⚡ 服务热修复
先决条件： 本节假定你已完成 深入解析.
要 在不要求游戏客户端更新的情况下发布服务器补丁，你可以：
准备新的服务器应用版本
v1.2.0-rc在 Edgegap 上：将新的镜像标签推送到你的容器注册表
t1.2.0,创建新应用版本
v1.2.0-rc,
通过执行测试和验证来 部署你的新应用版本
v1.2.0-rc:将你的游戏引擎编辑器连接到提供的 URL + 外部端口，
如果你发现并解决任何问题，请从头重复该过程，
为新应用版本启用缓存
v1.2.0-rc，为该版本启用缓存将确保该镜像也为版本缓存，v-green稍后，因为它们将引用相同的标签，等待版本中缓存指示器
v1.2.0-rc达到 🟢 绿色，
更新版本
v-green以链接到你的新镜像标签t1.2.0,新的匹配将自动使用已更新的标签启动分配
t1.2.0,监控过期的游戏客户端
c1使用部署 部署,
清理你 Edgegap 帐户中未使用的资源：
删除镜像标签
t1.1.0以释放容器注册表容量。
📗 API
客户端和服务器可以直接调用 API 或使用游戏引擎 SDK，另见 匹配服务.
服务器到服务器
对配对流程添加增强或自定义控制——使用我们的实现自定义代理，或使用任何云 托管集群 或任何云 FaaS 计算平台，以实现以下任何目的：
关联敏感的玩家属性 — 例如 作弊标记、技能评分或类似项，
在游戏中提供队伍和比赛上下文 — 在加载时列出我的队友和对手，
限制特定边缘情况 — 例如 在任何时间点只允许每名玩家有 1 个组，
添加缓存或 API 速率限制 — 减少对配对服务的请求数量和负载，
自定义大厅-组集成 — 在匹配前创建不对称/基于角色的大厅。
包含参数 player_ip 使用成员的公网 IP 地址 以确保尽可能低的玩家延迟并利用 部署.
游戏客户端可以使用 ipify.org 免费服务来查找它们的公网 IP。VPN 可能会掩盖公网 IP 地址。
跨域资源共享（CORS）
对于托管在第三方分发平台（例如）上的 WebGL 游戏， itch.io从游戏客户端发送任何请求到配对服务可能会导致 跨域资源共享 策略违规。大多数现代网络浏览器会发送一个 预检请求 以验证后端服务（配对服务）是否理解并接受来自你的游戏客户端的通信。
未通过预检检查（出于安全原因默认）可能导致 几种可能的 CORS 相关错误之一，最常见的是 缺少 CORS 头 'Access-Control-Allow-Origin' .
要解决此错误，请将 allowed_cors_origin 参数添加到你的配置以：
将你的确切客户端托管域列入白名单：
或将通配符域列入白名单（包括所有子域）：
配对服务的预检请求不需要凭证，如果域配置正确。
🚨 故障排除
你的成功是我们的优先事项。 如果你想发送自定义请求、请求缺少的关键功能，或表达任何想法， 请在我们的社区 Discord 中联系我们.
为什么我在尝试创建新的配对服务时会出错？
请阅读错误信息，你可能拼错了标识符、规则或运算符。- 使用 JSONLint 来验证你的 JSON 格式，你可能漏掉了逗号或括号。- 通过 我们的社区 Discord 寻求帮助，我们很乐意协助。🙏
为什么我的配对服务在 3 小时后自动关闭？
免费等级的配对服务用于初始测试，会在 3 小时后自动关闭。要继续测试，你可以 重新启动你的配对服务.
考虑升级到付费等级以获得无限运行时间。
为什么我会在随机时间收到分配/部署，而不考虑 player_count?
你或其他团队成员可能在之前的测试会话中创建了未被分配的工单。请 重新启动你的配对服务.
我的匹配器显示错误，我该怎么办？
如果这是开发或测试实例，请先尝试重启您的匹配器。 - 请通过报告任何问题 我们的社区 Discord.
如果此问题影响到线上游戏，请创建一个 紧急支持请求.
🔖 更新日志
您的配置文件将根据所使用的匹配器版本进行验证，请确保您的规则与匹配器版本的功能相匹配。
匹配器的最新版本是 3.2.1。本页上的所有示例均为最新。请注意您所用匹配器版本的支持结束通知。另见 ⏩ 滚动更新.
3.2.1（2025年11月24日）
这是最新的匹配器服务版本，推荐用于生产环境。
要升级您的匹配器版本 - 停止、编辑、重启。 快速重启不会应用版本更改。
🩹 修复：
修正了小规模部署错误，解决了启动匹配器时的若干错误。
3.2.0（2025年10月31日）
🩹 修复：
各种较小的规范修正和文档一致性更新。
匹配器基础设施各处的多项稳定性和自愈性修复。
✨ 改进与新功能：
引入 深入解析 功能 - 现在管理组变得简单，不再需要第三方！
无需在组成员之间共享复杂的票据属性，您只需使用组 ID。
一旦所有玩家标记为准备，便可作为一个组开始匹配。
在加入时对照组长验证组成员属性，防止产生无法匹配的组（组内玩家的属性在配置规则下不匹配）。
验证组大小并在达到最大队伍人数时拒绝新的加入。
阅读我们更新的文档，了解新的用户流程，SDK 更新即将推出！
票据（会员）现在包含您的匹配 ID —— 跟踪玩家并添加 UI 元素以共享您的队伍或对手的昵称、技巧评分或存储在第三方的其他属性。
重大 深入解析 基于内部压力测试的全面重构，更好地处理短时间激增。
通过将部分匹配的大小延迟到扩展结束，改善了匹配填充率。
如果达到最大队伍人数，则立即匹配。
否则在当前扩展结束时匹配（如果达到最小队伍人数）。
为每个配置文件设置到期和移除周期，并为最佳玩家体验进行优化。
要更新您的配置，增加版本号，并将到期和移除字段复制到每个配置文件。
3.1.0（2025年6月10日）
🩹 修复：
匹配器现在可正确验证包含不同规则的多个配置文件的票据。
✨ 改进与新功能：
更多优化以在以下情况下最大化匹配填充率： player_count 规则。如果只有部分匹配可行（>最小且<最大队伍人数），票据现在将等待直到扩展结束（或到期）。
完整匹配（达到最大队伍人数）将立即进行（无变化）。
改进的 规则 文档，具有更好的示例和视觉效果。
3.0.0（2025年5月20日）
⚠️ 不兼容变更：
使用 为了更有效地填充队伍的最小/最大队伍人数 （替代玩家数扩展）：
在您的配置中
player_count规则，将team_size替换为min_team_size和max_team_size以实现“尽力而为”匹配，尝试最大化匹配填充率，若要要求每队具有特定人数，请将最小值和最大值设置为相同的值，
回填会绕过
player_count规则并始终以 1 张票据进行匹配（未更改）。
具有所有延迟都高于给定配置文件中最高
max_latency的票据、组票据和回填将被立即以400 错误请求响应票据创建请求，而不是过期：仅在 延迟规则 已配置时适用，
要绕过此行为，请创建一个扩展并设置
max_latency: 99999（任何高于您客户端延迟测量超时的值）。
🩹 修复：
深入解析 现使用配置的删除和到期周期（如票据和组票据）。
深入解析 现在可使用配置的
intersection规则.修复了 openAPI 规范 针对 POST 的 深入解析 请求（需要
public_ip）和 GET /tickets 响应（team_id是可选的），包括示例。
✨ 改进与新功能：
现在最多考虑多达 3 倍的潜在匹配，生成更优的组并最大化匹配填充率。
由于并发性优化，匹配速度最多提高 200%。
由于扩展算法的优化，匹配填充率最多提高 40%。
改进了服务稳定性并提高了快速重启速度。
基准使用混沌生成的数据并使用以下配置产生： 高级示例配置.
2.1.0（2025年2月24日）
⚠️ 不兼容变更：
在 深入解析:
MM_MATCH_PROFILE中将游戏配置文件和扩展阶段信息分离。引入了
MM_EXPANSION_STAGE其将包含扩展阶段作为字符串（例如 “initial”、“15”、“30”）。
深入解析 attributes.deployment_request_id
已移动到attributes.assignment.request_id请求体现在要求将完整的分配详细信息作为.深入解析 attributes
参数的一部分，此外还有request_id解析后的交集规则值现在在.
🩹 修复：
MM_INTERSECTION 深入解析 环境变量中以
形式提供。快速重启功能现在在配置更改时可靠地重新生成 API 端点和 openAPI 规范。修复了在匹配器（重新）启动期间导致启动时间延长或匹配器卡住的若干错误。
提高了所有 API 端点在所有匹配器层级上的速率限制和可扩展性。
✨ 改进与新功能：
当将玩家分配到一个
为 swagger UI 添加了身份验证功能，可在 Web UI 中直接测试 API，无需使用 Postman。
改进了 openAPI 示例，使其更接近真实的请求和响应。
添加了新的 深入解析 ，用于开发和调试目的。
允许在分页列表中列出所有当前玩家票据。
允许在分页列表中列出所有当前匹配。
1.0.0（2024年12月9日）
深入解析：根据（广泛）请求，我们重新添加了带有自动票据分配的回填，允许在玩家离开会话时重用服务器席位。
非常适合在比赛开始后填充空置玩家席位，或替换比赛中离开的玩家。
深入解析：我们在已提供的用以填充多支队伍玩家的功能中新增了以组身份加入的能力。
非常适合与一群朋友或来自同一大厅的玩家一起加入匹配队列。
修复了一个未正确应用 深入解析 的错误。
如果票据在 深入解析 内未分配到部署，票据现在将被自动取消。
您现在可以 深入解析 以增强匹配流程的流畅性。
匹配器创建的部署现在带有票据 ID 标签。
您现在可以在匹配器运行时编辑配置。这会触发对配置的快速重载，而无需对匹配器进行完整的开/关循环。注意：此功能不建议在生产环境中使用，因为它会删除所有当前票据并暂时使 API 无响应。
修复了 深入解析 以使用正确的原始类型而不是数组。
修复了 深入解析 JSON 值，此前包含转义字符。
0.2.3（2024年10月8日）
修复了一个错误，该错误导致当请求来自 WebGL 应用时（CORS 策略）某些头部未被匹配器接受。
0.2.2（2024年10月3日）
修复了阻止匹配器启动的 TLS/SSL 证书验证问题。
0.2.1（2024年9月30日）
修复了导致 beacons 端点返回 500 错误的错误。
0.2.0（2024年9月25日）
所有端点现在强制要求基本认证。
添加了在服务器分配失败时配置重试次数的能力。
基于队伍的匹配现在成为所有匹配配置的默认设置。
配置文件中现在要求提供 application 和 version 两个字段。
引入了一个用于监控匹配器状态的新端点。
更新了部署中 tickets 环境变量的格式。
添加了一个配置选项以允许主机与匹配器通信。
调试 API 现在仅在配置中显式启用时可用（目前为重构而禁用）。
在 GET 票据响应中，
game_profile键已被替换为profile.
最后更新于
这有帮助吗？