选择器过滤
Selectors 是可选的过滤数据，您可以在会话创建请求中包含它们以筛选将被考虑用于托管会话的部署。简单来说，我们只会选择那些请求中包含的所有指定标签的部署来托管您的会话。您也可以使用标签在部署中动态添加环境变量。
何时应考虑使用 Selectors
可能“总是”是正确答案，因为迟早您可能需要在过滤中管理不同的内容，例如地图、游戏类型、玩家统计等。然而，我们理解有时您可能只想快速测试。因此，以下是一些常见的 selectors 用例：
使用特定标签筛选部署以托管您的会话。
为您的会话添加标签以便识别。
在使用
autodeploy选项时，动态注入环境变量。
通过为每个配置创建多个应用版本，您也可以实现与使用 selectors 大致相同的结果。但是，使用 selectors 可以简化您的开发，因为您需要管理的应用版本更少：您可以在相同版本上使用不同的 selectors 和上下文。
如何使用它们
这些概念可以相互构建，但我们将分别在各自的部分中逐一讲解。
所有过滤都将在会话请求开始时设定的范围内应用。这意味着如果存在与 selectors 匹配的部署，但该部署不在合适的范围内，则该部署不会被选择来托管会话。
该 autodeploy 选项将在可用的最佳位置创建一个新的部署。您可以在此处阅读更多相关内容： 这里.
按标签过滤
像这样将标签添加到 selectors 列表将使您的会话请求搜索带有标签 Ranked 和 Map A的部署。如果您没有启用 autodeploy 选项并且没有带有这些标签的部署，您的会话请求将被设置为 不可处理（unprocessable） 状态。另一方面，如果启用了 autodeploy，我们会自动创建一个带有这些标签的新部署，然后将其链接到您的会话。
一个部署需要拥有 所有 指定的标签，才会被视为适合托管会话。
{
"app_name": "demo",
"version_name": "v1",
"ip_list": ["1.2.3.4"],
"selectors": [
{
"tag": "Ranked"
},
{
"tag": "Map A"
}
]
}动态添加环境变量
此示例应用与上文相同的概念，因此如果没有带有标签 Map A 的部署并且启用了 autodeploy，我们会创建一个带标签的新部署。但我们在 selector 对象中添加了 env 键，这将向部署中注入 MAP_ID 环境变量，其值为 1 。该环境变量将在服务器内部可用。
如果您之前创建了一个带有标签 Map A 的部署，但没有 env 参数，然后您发起了一个将使用 env 参数链接到该部署的会话请求，环境变量不会被动态添加，因为我们无法修改正在运行的部署的环境变量。
与之前的警告类似，如果您使用相同标签但不同环境变量创建了两个不同的会话，则只有触发 autodeploy 的会话的环境变量会被应用。
向会话添加标签而不进行过滤
如果您只想向会话添加标签而不筛选部署，可以在会话请求中使用 tag_only 属性。这样可以在不实际筛选部署的情况下为会话添加标签。
但是，请注意您不能将 tag_only 与使用 env 属性注入环境变量结合使用。
在此示例中，我们将向通过此请求创建的每个会话添加标签 Europe 。标签 Europe 仅应用于会话，而不应用于部署。它不会以任何方式影响部署的过滤。
完整示例
我们有一个单一的应用版本，具有两种模式： Ranked 和 Casual。启用了 autodeploy。我们有两张地图： Map A 和 Map B。每种模式都可以使用每张地图。我们想为每场比赛添加标签 Matchmaker #1234，以表示请求的来源。我们仅将此标签用于跟踪目的，并且不会影响部署的过滤。
游戏根据注入的环境变量加载地图资源。
在像这样的场景中使用 selectors 是非常有意义的，因为没有它们，您将需要为每张地图管理不同的应用版本，这会导致更高的复杂性和管理开销。
有人想在 Map A 玩一场 Ranked。该地图的 ID 是 1。我们不希望把想在 Map A 玩的人放到 Map B 中，所以我们需要妥善处理。这将是一个正确的请求：
此请求将搜索同时带有 Ranked 和 Map A 标签的部署，如果找不到，它将创建一个新的并为其打上这两个标签。在这两种情况下，会话都会被标记为 Matchmaker #1234.
如果我们发送另一个请求，在 Map B 地图中进行一场 Casual 游戏，请求将如下所示。Map B 地图的 ID 是 2。预期结果与另一个请求相同。
最后更新于
这有帮助吗？