Ruby on Rails使用SQS最佳实践及自定义消费端问题咨询

启动方案优化 #

你现在把启动逻辑放在Sidekiq的config.on(:startup)钩子的方案存在两个明显问题：一是如果Sidekiq进程优雅重启时，常驻的消费worker被意外终止，没有兜底的恢复逻辑，会导致消费中断；二是初始化器里的限流逻辑如果有异常，很容易导致Sidekiq进程启动失败。
更稳定的实现方案如下：

• 给SqsConsumerWorker单独设置专用队列，且关闭自动重试：

class SqsConsumerWorker
  include Sidekiq::Worker
  # 单独队列避免被业务任务阻塞，关闭重试，由健康检查任务调度重启
  sidekiq_options retry: 0, queue: :sqs_poller

  def perform
    # 原有轮询逻辑
    poller = Aws::SQS::QueuePoller.new(<queue_url>, client: <sqs_instance>)
    # 增加退出信号监听逻辑，避免进程重启时丢失消息
    exit_flag = false
    Signal.trap('SIGTERM') { exit_flag = true }

    poller.poll(
      wait_time_seconds: 20, 
      max_number_of_messages: 10, 
      visibility_timeout: 180, 
      before_request: -> { throw :stop_polling if exit_flag }
    ) do |messages|
      messages.each do |message|
        # 不要在这里处理业务逻辑，把消息转成业务任务丢到对应队列
        SqsMessageHandlerWorker.perform_async(message.body, message.receipt_handle)
      end
    end  
  end
end

• 新增一个定时健康检查任务（可以用sidekiq-cron实现，1分钟执行一次），检查当前sqs_poller队列中运行/待调度的SqsConsumerWorker数量，如果低于你设置的上限，就补充触发新的worker实例，这样可以兜底解决worker意外崩溃的问题。
• 轮询worker只做消息拉取和分发，业务逻辑放到单独的SqsMessageHandlerWorker中处理，避免业务逻辑异常或者耗时太长阻塞长轮询。

扩缩容实现 #

基于你当前的自定义实现，可以通过两种方式实现扩缩容：

• 静态扩缩容：如果你的SQS流量波动不大，可以直接通过调整部署的Sidekiq实例数量、以及单个实例中sqs_poller队列的并发数来调整消费能力。比如你需要2个消费进程，就启动2个Sidekiq实例，每个实例分配1个线程处理sqs_poller队列即可，要注意实例总数不要超过你设置的worker数量上限。
• 动态扩缩容：如果你的流量波动大，需要自动扩缩容，可以做以下改造：
  • 对接AWS CloudWatch监控，采集SQS队列的ApproximateNumberOfMessagesVisible（待消费消息数）和ApproximateAgeOfOldestMessage（最老消息等待时间）两个核心指标。
  • 如果用K8s/ECS等容器部署，可以基于上述两个指标配置自动扩缩容策略，当待消费消息超过阈值或者最老消息等待超过阈值时，自动增加Sidekiq实例数量，反之则减少实例。
  • 可以在轮询逻辑中新增动态调整拉取参数的逻辑：当队列堆积时把max_number_of_messages调到上限10，提升拉取效率；当队列空闲时降到1，减少空轮询的资源消耗。

其他注意事项 #

• 建议在轮询逻辑中增加消息删除的显式控制：只有当消息对应的业务任务执行成功后，再调用接口删除SQS中的消息，避免消息丢失。
• 要注意visibility_timeout的设置要大于业务任务的最大执行时间，避免消息还没处理完就被SQS重新投放，导致重复消费。

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