{{< alert type=”warning” >}}

这些都是高级设置。尽管这些（配置）在极狐GitLab官网（JihuLab.com）中使用，但大多数极狐GitLab实例只需增加监听所有队列的进程即可。这和在参考架构中描述的一样。

{{< /alert >}}

大多数极狐GitLab 实例应该让所有进程监听所有队列。

另一种选择是使用路由规则，将应用程序内部的特定作业类引导到您配置的队列名称。然后，Sidekiq 进程只需监听少数配置的队列。这种做法可以降低 Redis 的负载，这在非常大规模的部署中尤为重要。

路由规则

{{< history >}}

  • 默认路由规则值在极狐GitLab 15.4 中引入。
  • 队列选择器在极狐GitLab 17.0 中被路由规则取代。

{{< /history >}}

{{< alert type=”note” >}}

邮件任务无法通过路由规则进行路由，并始终进入 mailers 队列。在使用路由规则时，请确保至少有一个进程正在监听 mailers 队列。通常这可以与 default 队列一起放置。

{{< /alert >}}

我们建议大多数极狐GitLab 实例使用路由规则来管理其 Sidekiq 队列。这允许管理员根据作业类的属性为作业类组选择单个队列名称。语法是 [query, queue] 的有序对数组：

  1. 查询是一个工作者匹配查询。
  2. 队列名称必须是有效的 Sidekiq 队列名称。如果队列名称是 nil 或空字符串，则工作者将被路由到由工作者名称生成的队列。（有关详细信息，请参阅可用作业类列表）。 队列名称不必与可用作业类列表中的任何现有队列名称匹配。
  3. 匹配工作的第一个查询被选择用于该工作；后面的规则被忽略。

路由规则迁移

在更改 Sidekiq 路由规则后，您必须小心迁移，以避免在具有长任务队列的系统中完全丢失任务。可以通过遵循Sidekiq 任务迁移中提到的迁移步骤来完成迁移。

在扩展架构中的路由规则

路由规则必须在所有极狐GitLab 节点（特别是极狐GitLab Rails 和 Sidekiq 节点）之间保持一致，因为它们是应用程序配置的一部分。

详细示例

这是一个全面的示例，旨在展示不同的可能性。Helm chart 示例也可用。 这些不是建议。

  1. 编辑 /etc/gitlab/gitlab.rb：

    sidekiq['routing_rules'] = [
  # 将所有非 CPU 限制的高紧急性工作路由到 `high-urgency` 队列
  ['resource_boundary!=cpu&urgency=high', 'high-urgency'],
  # 将所有数据库、gitaly 和全球搜索的节流工作路由到 `throttled` 队列
  ['feature_category=database,gitaly,global_search&urgency=throttled', 'throttled'],
  # 将所有与外界接触的工作路由到 `network-intensive` 队列
  ['has_external_dependencies=true|feature_category=hooks|tags=network', 'network-intensive'],
  # 通配符匹配，将剩余的路由到 `default` 队列
  ['*', 'default']
]

    然后可以设置 queue_groups 以匹配这些生成的队列名称。例如：

    sidekiq['queue_groups'] = [
  # 运行两个高紧急性进程
  'high-urgency',
  'high-urgency',
  # 为节流和网络密集型运行一个进程
  'throttled,network-intensive',
  # 在默认和邮件队列上运行一个“捕获所有”的进程
  'default,mailers'
]

  2. 保存文件并重新配置极狐GitLab：

    sudo gitlab-ctl reconfigure

工作者匹配查询

极狐GitLab 提供了一种查询语法，用于根据属性匹配工作者，由路由规则使用。查询包括两个组件：

  • 可选择的属性。
  • 用于构建查询的操作符。

可用属性

队列匹配查询基于工作者属性工作，在 Sidekiq 样式指南中描述。我们支持基于一部分工作者属性进行查询：

  • feature_category - 队列所属的极狐GitLab 功能类别。例如，merge 队列属于 source_code_management 类别。
  • has_external_dependencies - 队列是否连接到外部服务。例如，所有导入器都将此设置为 true。
  • urgency - 这个队列的任务运行速度的重要性。可以是 high、low 或 throttled。例如，authorized_projects 队列用于刷新用户权限，属于 high 紧急性。
  • worker_name - 工作者名称。使用此属性选择特定的工作者。在下面的作业类列表中找到所有可用名称。
  • name - 从工作者名称生成的队列名称。使用此属性选择特定的队列。因为这是从工作者名称生成的，所以不会根据其他路由规则的结果而改变。
  • resource_boundary - 队列是否受 cpu、memory 或 unknown 限制。例如，ProjectExportWorker 是内存限制的，因为它必须在保存之前加载数据。
  • tags - 队列的短期注释。预计这些会经常从一个版本更改到另一个版本，并可能完全删除。
  • queue_namespace - 一些工作者按命名空间分组，而 name 则以 <queue_namespace>: 为前缀。例如，对于 name 为 cronjob:admin_email 的队列，queue_namespace 是 cronjob。使用此属性选择一组工作者。

has_external_dependencies 是一个布尔属性：只有确切的字符串 true 被视为真，其他一切都被视为假。

tags 是一个集合，这意味着 = 检查交集集合，而 != 检查不相交集合。例如，tags=a,b 选择具有标签 a、b 或两者的队列。tags!=a,b 选择没有这些标签的队列。

可用操作符

路由规则支持以下操作符，从高到低优先级列出：

  • | - 逻辑 OR 操作符。例如，query_a|query_b（其中 query_a 和 query_b 是由此处其他操作符组成的查询）包括匹配任一查询的队列。
  • & - 逻辑 AND 操作符。例如，query_a&query_b（其中 query_a 和 query_b 是由此处其他操作符组成的查询）仅包括匹配两个查询的队列。
  • != - NOT IN 操作符。例如，feature_category!=issue_tracking 排除所有来自 issue_tracking 功能类别的队列。
  • = - IN 操作符。例如，resource_boundary=cpu 包括所有受 CPU 限制的队列。
  • , - 连接集合操作符。例如，feature_category=continuous_integration,pages 包括来自 continuous_integration 类别或 pages 类别的所有队列。这个例子也可以使用 OR 操作符实现，但允许更高的简洁性，并且优先级较低。

此语法的操作符优先级是固定的：无法使 AND 的优先级高于 OR。

与上面的标准队列组语法一样，单个 * 作为整个队列组选择所有队列。

可用作业类列表

要查看现有 Sidekiq 作业类和队列的列表，请检查以下文件：