使用Sidekiq-sequence Gem时出现RecordNotFound错误的排查求助

可能的触发原因 #

• 核心是Sidekiq-sequence依赖的序列跟踪记录被提前删除或查询时出现竞争：
  • 多进程/线程同时处理同序列任务时，可能出现一个进程刚删除记录，另一个进程还在尝试读取的情况；
  • 项目里如果有清理Sidekiq相关旧数据的脚本，误删了还在使用的Sidekiq::Sequence::Record；
  • 任务重试间隔太长，期间记录被自动清理（如果gem有默认过期机制的话）。

错误的实际影响 #

• 从你的数据来看，这个错误的影响可以忽略不计，99.999%的任务正常运行说明只是极端偶发情况。
• 出现错误时，当前重试的任务会失败，但Sidekiq会自动重试。这里分两种情况：
  • 如果记录只是临时查询不到（比如锁冲突），重试时大概率能找到记录，继续按原序列执行；
  • 如果记录已经被彻底删除，重试时可能会生成新的序列记录，导致这个任务脱离原序列，变成独立执行——如果你的业务对顺序要求不是极端严格，这种情况基本不影响；如果严格要求顺序，可能会出现任务乱序的小概率问题。

可行的解决办法 #

• 检查清理脚本：排查项目中是否有清理sidekiq_sequence_records表的脚本，修改为只清理状态为已完成、且创建时间超过业务允许周期的记录，清理时加上行锁或者事务，避免删到正在使用的记录。
• 捕获异常处理：在你的序列任务代码里，主动捕获ActiveRecord::RecordNotFound异常，根据业务场景处理：

  def perform(args)
    begin
      # 原任务逻辑
    rescue ActiveRecord::RecordNotFound => e
      # 可以尝试重新初始化序列记录，或者记录日志后跳过
      Sidekiq::Sequence::Record.find_or_create_by(sequence_key: your_sequence_key)
      retry # 或者根据情况决定是否重试
    end
  end
  

• 优化序列key的设计：确保每个任务序列的key唯一且不会重复使用，避免不同任务池共享同一个key导致的竞争。
• 给查询加重试逻辑：如果不想改业务代码，可以给Sidekiq-sequence内部查询记录的逻辑加重试，比如通过monkey patch把查询操作包裹在重试块里：

  module Sidekiq
    module Sequence
      class Record
        def self.find_by_sequence_key(key)
          retry_count = 0
          begin
            find_by(sequence_key: key)
          rescue ActiveRecord::RecordNotFound
            retry_count += 1
            retry if retry_count < 3
            raise
          end
        end
      end
    end
  end
  

• 监控日志补充：给这个错误添加更详细的日志，记录序列key、任务参数、当前重试次数，方便定位到底是哪些序列出问题，针对性优化。

内容的提问来源于stack exchange，提问作者ToddT