Redis故障致Heroku部署的应用宕机，如何制定后续故障规避方案？

默认Rails + ActionCable的官方配置未做异常隔离，当ActionCable依赖的Redis实例无法连接时，会抛出Redis::CannotConnectError未捕获异常，该异常会渗透到主应用的全链路请求处理流程，哪怕当前请求完全不涉及WebSocket/ActionCable功能，最终导致整个应用返回500错误，这是Rails生态非常常见的踩坑点。

• 调整Redis客户端连接配置，在config/cable.yml中添加短超时和有限重试规则，避免连接请求长时间阻塞主应用线程，参考配置：

  production:
    adapter: redis
    url: <%= ENV.fetch("REDIS_URL") { "redis://localhost:6379/1" } %>
    timeout: 1
    reconnect_attempts: 2
    id: nil
  

• 全局异常捕获隔离：在主应用的全局异常处理层添加Redis::CannotConnectError的捕获规则，仅ActionCable相关请求返回错误，普通业务请求正常响应，快速恢复主应用可用性
• 临时降级ActionCable功能：如果业务允许短时间关闭实时推送能力，可直接将ActionCable适配器临时切换为async（单进程部署场景可用），或者临时移除ActionCable的路由挂载，优先保障核心业务可用

• 依赖服务异常隔离：为ActionCable配置独立的Redis实例，不和其他业务缓存、队列服务共享实例，同时为其配置独立的熔断降级策略，彻底避免单点故障传导到主应用
• 多区域容灾部署：如果使用Heroku托管的Redis服务，可开启跨区域副本和自动故障切换能力，当单区域AWS节点故障时，自动切换到可用副本节点，降低故障影响时长
• 主动故障演练：后续迭代过程中新增依赖服务故障场景的压测环节，主动模拟Redis、数据库等配套服务宕机的情况，验证主应用的可用性是否符合预期，提前发现潜在的单点故障风险
• 熔断机制落地：引入服务熔断组件，当检测到ActionCable Redis连接失败率超过阈值时，自动触发降级，停止向故障Redis实例发起连接请求，间隔固定时间后自动重试恢复

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