Shoryuken重复处理飞行中SQS消息致连接池耗尽问题求助

核心问题分析 #

你遇到的重复触发+连接池耗尽，本质是SQS可见性超时过短，导致Shoryuken还在处理的Job被SQS重新放回队列，重复消费占满线程后耗空数据库连接池。另外线程池与连接池不匹配、连接未正确释放也会加剧这个问题。

具体解决步骤 #

• 调整SQS队列的可见性超时
  可见性超时是指Job被消费者取走后，SQS在这段时间内不会把它再分给其他消费者。如果你的Job处理时间超过这个值，SQS就会默认处理失败，将Job重新放回队列。

  • 先统计你Job的最长处理时间，把超时设为它的1.5-2倍（比如Job最多跑10秒，就设15-20秒）。
  • 可直接在AWS控制台的SQS队列配置里修改，也能在config/shoryuken.yml里针对队列配置：

    queues:
      my-queue-name:
        visibility_timeout: 180 # 单位秒，根据实际情况调整
    

• 匹配线程池与数据库连接池大小
  Shoryuken默认线程数是25，但Rails默认数据库连接池仅5个，完全不匹配。

  • 在config/shoryuken.yml里设置合理的并发数（根据服务器CPU/内存调整，别贪多）：

    concurrency: 10
    

  • 同步修改config/database.yml里的连接池大小，至少等于Shoryuken的并发数：

    production:
      pool: 10
    

• 确保数据库连接正确释放
  长时间持有连接会快速耗尽池资源，尤其是图片处理这类IO密集任务：

  • 把数据库操作放在图片处理之前，让连接尽早释放；
  • 若Job里有复杂数据库操作，用块式获取连接确保自动释放：

    ActiveRecord::Base.connection_pool.with_connection do
      # 你的数据库操作代码
    end
    

  • 若手动获取了连接，记得在任务结束前释放：

    ActiveRecord::Base.connection_pool.release_connection
    

• 配置Shoryuken重试策略
  即使Job是幂等的，无限制重试也会浪费资源，给Worker加重试限制：

  class ImageProcessingWorker
    include Shoryuken::Worker
    shoryuken_options queue: 'my-queue-name', retry_limit: 3, retry_delay: 60 # 最多重试3次，每次间隔60秒
  end
  

  也可以在shoryuken.yml里全局配置重试参数，避免每个Worker重复设置。

• 排查Job处理时长
  在Job里加日志记录开始/结束时间，确认是否有大图片导致处理超时：

  def perform(image_id)
    puts "Job start: #{Time.now}"
    # 图片处理逻辑
    puts "Job end: #{Time.now}"
  end
  

  如果确实有超长任务，考虑拆分步骤（比如先上传原图，再异步处理缩略图），或者优化图片处理逻辑。

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