📦 Sidekiq Job 分析器

Sidekiq Job Analyzer 分析 Sidekiq 任务配置的可靠性、性能、队列设计、重试策略与内存安全。审计 worker 类、队列优先级、并发设置与 Redis 使用。适用于任务变慢、静默失败或内存占用过高时。

用法 “分析我的 Sidekiq 任务问题” “检查队列配置与优先级” “审计重试策略与错误处理” “优化 Sidekiq 性能与内存使用”

工作原理

• 任务发现

# 查找所有 Sidekiq worker/任务 grep -rn "include Sidekiq::Job\|include Sidekiq::Worker" app/ lib/ | head -30 # 查看 Sidekiq 配置 cat config/sidekiq.yml 2>/dev/null cat config/initializers/sidekiq.rb 2>/dev/null # 查看队列定义 grep -rn "sidekiq_options" app/ lib/ | head -20

• 任务配置审计

重试策略：

• 未显式设置重试次数（默认 25 次，持续 21 天）
• 非关键任务未设置 dead: false
• 缺少自定义错误处理或 sidekiq_retries_exhausted 回调
• 指数退避 vs 固定间隔重试

队列设计：

• 队列过多（调度开销）
• 关键任务与批量任务混用队列
• 缺少队列权重/优先级
• 任务放错队列（重任务阻塞轻任务）

幂等性：

• 重试不安全任务（重复扣款、重复发送）
• 缺少唯一任务约束（sidekiq-unique-jobs）
• 状态变更无锁保护

性能：

• 长任务阻塞队列
• 应批量处理的任务未使用 Sidekiq Pro/Enterprise
• 数据库密集型 worker 缺少连接池
• 任务代码线程安全问题

• 内存分析
• 任务将大数据集载入内存
• ActiveRecord 查询未用 find_each / find_in_batches
• 循环内字符串拼接（内存碎片）
• 任务内存无限增长
• 队列与重试集占用 Redis 内存

• 监控与可观测性
• Sidekiq Web UI 已配置并可访问？
• 死任务监控与告警
• 队列延迟监控
• 错误追踪集成（Sentry、Bugsnag）
• 关键业务任务自定义指标

• Redis 配置
• Redis 连接池大小
• Redis 内存上限与淘汰策略
• Redis 持久化设置保障任务耐久性
• Sentinel/Cluster 高可用

输出

Sidekiq 任务分析

Workers： 23 | Queues： 5 | Redis： 512 MB 已用

🔴 严重（2）

• 非幂等支付任务 — PaymentProcessor 无唯一性保护

重试会导致多次扣款 → 添加 sidekiq_options unique: :until_executed

• ReportGenerator 内存泄漏 — 按租户加载全部记录

大租户占用 2 GB+，触发 OOM → 使用 find_in_batches(batch_size: 1000) 并流式输出

🟡 待改进（4）

• BulkEmailJob 使用默认重试 25 次 — 营销邮件重试 21 天
• default 队列混杂 15 种任务 — 需拆分关键与批量
• 23 个 worker 中 18 个未定义 sidekiq_retries_exhausted
• 缺少死任务监控（已积压 12,847 条）

📊 队列健康度

| Queue | Jobs/hr | Latency | Workers | |---------|---------|---------|---------| | critical | 120 | 0.1 s | 5 | | default | 3,400 | 45 s ⚠️ | 10 | | mailers | 800 | 2 s | 3 | | reports | 50 | 5 min ⚠️| 2 | | bulk | 12,000 | 30 min | 5 |

✅ 良好实践

• 按优先级分队列
• 集成 Sentry 错误追踪
• Redis Sentinel 高可用已配置