GCP Cloud Run中Flask SocketIO结合Redis Pub/Sub运行一段时间后异常

我们在GCP Cloud Run部署Flask SocketIO服务，通过VPC网络连接GCP Redis（Memorystore）作为message_queue，环境配置如下：

• Redis实例：Basic类型，12GB容量
• Cloud Run配置：最小2个实例、最大3个实例，当前运行3个活跃实例，VPC网络有其他服务器共用
• 依赖版本：Flask SocketIO 5.3.2，Python redis包4.4.0

初始运行正常，但运行一段时间后出现跨实例消息同步失效的异常：

1. 首次异常：运行约10小时后触发，添加日志重新部署服务后恢复正常
2. 第二次异常（跨版本测试）：
   • 切换至旧版本（版本1）：服务恢复正常
   • 切回新版本（版本2）：服务再次异常
   • 再次切回版本1：服务恢复正常
   • 间隔一段时间后切回版本2：服务又恢复正常

• 异常时段仅出现ERROR:socketio:Cannot publish to Redis... retrying日志，未出现Cannot publish to Redis... giving up日志
• 异常时仅能看到Python-SocketIO的emitting event "message" to room_1 [/some-namespace]日志，缺失pubsub message: emit日志（该日志由PubSubManager的_thread函数在从Redis接收消息时生成）

1. Redis连接与资源排查 #

• 检查Redis实例连接数：通过GCP Memorystore控制台查看连接数峰值，确认是否达到Basic实例的连接上限（默认10000），是否因VPC内其他服务占用过多连接导致SocketIO无法获取连接
• 优化Redis连接池配置：为redis客户端启用连接池并合理设置参数，避免频繁创建销毁连接，示例代码：

  from redis import ConnectionPool
  pool = ConnectionPool(host="redis-instance-ip", port=6379, max_connections=100)
  socketio = SocketIO(app, message_queue="redis://redis-instance-ip:6379", redis_options={"connection_pool": pool})
  

• 排查VPC网络稳定性：确认是否存在临时网络波动、防火墙规则变更，导致Cloud Run与Redis之间的连接间歇性中断

2. 代码版本与依赖差异排查 #

• 对比版本1和版本2的业务代码：重点检查SocketIO初始化配置（如message_queue参数、命名空间配置）、事件处理逻辑是否有变更
• 锁定依赖版本：确认版本2是否意外升级了Python-SocketIO/Python-EngineIO底层依赖，使用requirements.txt或pyproject.toml固定所有依赖的版本号，避免版本兼容问题

3. Cloud Run实例生命周期校验 #

• 检查实例启停日志：确认异常时段是否有Cloud Run实例因空闲或资源限制被回收，重新启动的实例是否能正常重建Redis PubSub连接
• 添加启动连接校验：在服务启动时增加Redis连接与PubSub订阅的校验逻辑，确保实例启动后能正常接入消息队列

4. Redis PubSub状态排查 #

• 手动检查Redis频道状态：连接Redis实例，执行PUBSUB CHANNELS命令查看SocketIO使用的订阅频道是否存在、正常
• 监控Redis内存使用：确认Redis内存占用是否过高，避免因内存不足导致响应延迟，影响PubSub消息传递

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