处理特定的作业类别

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

另一种选择是使用路由规则，它可以将应用内的特定作业类别引导至您配置的队列名称。这样，Sidekiq 进程就只需要监听少数几个已配置的队列。这样做可以降低 Redis 的负载，这对于大规模部署来说非常重要。

路由规则

我们建议大多数 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',
     'high-urgency',
     # 为 throttled 和 network-intensive 运行一个进程
     'throttled,network-intensive',
     # 在 default 和 mailers 队列上运行一个“全能”进程
     'default,mailers'
   ]

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

   sudo gitlab-ctl reconfigure

工作器匹配查询

GitLab 提供了一种查询语法，用于根据路由规则所使用的工作器属性来匹配工作器。查询包含两个组成部分：

• 可选择的属性。
• 用于构建查询的运算符。

可用属性

队列匹配查询基于工作器属性运行，这些属性在 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>: 为前缀。例如，对于队列名称 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 作业类别和队列列表，请查看以下文件：

• 所有 GitLab 版本的队列
• 仅 GitLab 企业版的队列