Oban Pro 高并发场景下的唯一性检查优化实践

问题背景

在使用Oban Pro进行大规模任务调度时，我们遇到了数据库连接错误的问题。具体表现为在短时间内快速插入大量唯一性任务时，系统频繁出现连接超时错误。经过分析，发现问题的根源在于Oban Pro的唯一性检查机制在高并发场景下的性能瓶颈。

问题现象

在测试环境中，我们尝试为78个父模型创建约5.4万个任务，为117个父模型创建约7.38万个任务时，系统出现了以下典型症状：

1. 数据库连接超时错误频繁发生
2. 监控显示唯一性检查查询成为长查询
3. 数据库表锁持续时间超过30秒
4. 移除唯一性检查配置后问题消失

技术分析

唯一性检查机制

Oban Pro提供了强大的唯一性检查功能，可以通过配置确保相同特征的任务不会被重复插入。在我们的案例中，配置如下：

use Oban.Pro.Worker,
  unique: [
    fields: [:args, :worker],
    keys: [:model_id, :model, :scrape_service],
    states: [:available, :executing],
    period: :infinity
  ],
  max_attempts: 1

这种配置理论上应该能够防止重复任务的插入，但在高并发场景下却成为了性能瓶颈。

问题根源

经过深入排查，发现问题出在Oban Pro的版本迁移上。虽然我们执行了迁移脚本，但实际上系统仍在使用旧版的唯一性检查机制（1.4.0版本），而非最新的增强型唯一性检查（1.5.0版本）。

关键诊断点包括：

1. 数据库表中缺少uniq_key列
2. 生产者表版本显示为1.4.0而非1.5.0
3. 唯一性检查键值存储在meta字段而非专用列中

解决方案

正确执行迁移

确保执行正确的迁移脚本是解决问题的第一步。对于Oban Pro 1.5.0，应采用以下迁移方式：

defmodule MyApp.Repo.Migrations.AddObanPro do
  use Ecto.Migration

  def up, do: Oban.Pro.Migration.up(version: "1.5.0")
  def down, do: Oban.Pro.Migration.down()
end

配置优化建议

1. 状态配置：建议包含所有相关状态，而不仅仅是部分状态。完整配置应为：

   states: [:available, :scheduled, :executing, :retryable]
   

2. 字段配置：除非任务会被调度到多个队列，否则不建议覆盖默认的fields配置。

3. 数据库分离：对于高并发场景，考虑使用专用数据库来处理Oban任务。

性能对比

新版增强型唯一性检查机制相比旧版有显著性能提升：

1. 查询效率提高：专用列索引比meta字段查询更快
2. 锁竞争减少：优化后的检查机制减少了表锁时间
3. 并发能力增强：能够支持更高频率的任务插入

实施效果

在正确执行迁移并启用新版唯一性检查后：

1. 数据库连接错误消失
2. 长查询问题得到解决
3. 系统能够稳定处理每分钟上万次的任务插入
4. 表锁时间降至毫秒级别

经验总结

1. 版本验证：升级后务必验证实际运行的版本和迁移状态
2. 监控先行：高并发系统应建立完善的数据库监控
3. 配置审慎：唯一性检查的配置需要根据实际场景仔细调整
4. 渐进实施：大规模系统改造应采用渐进式策略

通过这次问题排查，我们不仅解决了当前的性能瓶颈，也为未来系统的扩展打下了坚实基础。Oban Pro的强大功能在正确配置下能够完美支持高并发任务调度场景。