Rails应用启动时初始化Redis Pub/Sub订阅的最佳实践

方案一：在config/initializers里启动线程 #

• 好处：实现起来最简单，Rails启动时自动触发，不用额外依赖其他工具
• 问题：
  • 订阅线程和Rails进程绑定，进程重启（部署、内存溢出被杀）时订阅直接中断，得靠进程管理器重启才能恢复
  • 线程如果没做好异常捕获，一旦崩了可能带垮整个Rails进程
  • 多进程部署（比如Puma开多个worker）会生成多个订阅者，容易重复消费消息
• 注意：真要选这个，务必给线程加完整的异常捕获逻辑，同时在多进程场景下，要通过环境变量或者其他方式限制每个环境只启动一个订阅者

方案二：Resque专属队列+专用Worker #

• 好处：
  • 订阅逻辑和Rails主进程完全解耦，Worker崩了不会影响主应用正常运行
  • Resque自带进程管理，Worker崩溃后能自动重启
  • 可以单独控制订阅Worker的数量，避免多进程重复订阅的问题
• 问题：
  • 要额外维护一套Worker进程，增加了部署和监控的复杂度
  • 部署时得确保专属队列的Worker被正确启动，可能要配合部署脚本（比如Capistrano的resque重启任务）
• 实操思路：写一个Resque Job，把redis.subscribe的逻辑封装进去，部署后启动这个专属队列的Worker，注意让Job保持阻塞运行（不要让它执行完就退出）

其他可选方案 #

• 独立Ruby脚本+进程管理器：写一个不依赖完整Rails环境的独立脚本（只加载Redis和组织处理的必要逻辑），用systemd、supervisord这类进程管理器托管。这种方案隔离性最好，完全和Rails应用分开，适合长期运行的订阅任务，进程管理器还能帮你处理启动、重启、日志收集的问题。
• Sidekiq订阅插件：如果已经在用Sidekiq，可以用sidekiq-redis-pubsub这类插件实现订阅，利用Sidekiq的Worker管理机制，比Resque更轻量，还自带进程监控功能。
• 替换成Kafka：如果对消息可靠性要求很高（比如不能丢组织合并的消息），Redis Pub/Sub的“发完就丢”特性可能满足不了，可以考虑换成Kafka，然后用单独的消费者进程运行。不过这个改动比较大，适合有强可靠性需求的场景。

推荐方向 #

如果你的场景比较简单，而且已经在用Resque，方案二是最省心的选择；要是想追求最高的稳定性，不想订阅逻辑影响主应用，那独立脚本加进程管理器的方案绝对是最优解。

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