多前后端部署场景下Kafka订阅运行一段时间后无数据返回问题咨询

1. 场景合理性与故障原因分析 #

• 你描述的场景完全合理，属于无状态多副本服务对接有状态订阅逻辑的典型故障。
• 具体故障原因如下：
  • 当前架构里的.NET Core API实例是无状态部署的，负载均衡默认采用轮询、最少连接等无状态路由策略，同一个浏览器端的多次请求会被随机分配到不同的API实例。
  • Kafka消费者订阅是和具体的API进程绑定的，只有执行了订阅逻辑的那一个API实例（你例子里的后端#5）会持续从Kafka拉取对应主题/分区的消息，其他未执行订阅的实例完全没有相关数据。
  • 如果前端和后端的交互是短连接模式（比如普通HTTP请求轮询拉取消息），或者长连接中途断连重连，后续请求被分配到其他API实例时，自然就拿不到订阅数据，表现为前端突然收不到消息。
  • 额外说明：就算用的是WebSocket长连接，如果你的网关没有开启会话保持，或者API实例重启、连接超时断连后重连，也会出现同样的问题。
• 针对你补充的疑问：Vue前端请求不同的后端API实例确实会直接导致该功能异常，核心问题是订阅状态没有在多个API实例间共享。

2. 正确实现方案 #

你当前的思路存在的核心问题是：将有状态的Kafka订阅逻辑和无状态的API实例耦合了，正确的方案可根据业务量级从三类中选择：

方案1：会话粘滞（快速修复，适合小流量场景） #

• 在负载均衡/网关层开启会话保持（也叫粘性会话），可以基于Cookie或者客户端IP做绑定，同一个前端用户的所有请求在设定的会话有效期内都会路由到同一个API实例。
• 注意风险：如果绑定的API实例重启、扩容缩容下线，用户还是会断连，需要前端做异常捕获后触发重新订阅逻辑，不适合高可用要求高的场景。

方案2：订阅状态全局共享（推荐，适合大多数场景） #

• 把Kafka消费逻辑从API层抽离，单独部署独立的Kafka消费者组，所有消费者拉到消息后统一写入分布式缓存（比如Redis）或者数据库，缓存key可以用用户ID+订阅主题的组合。
• 所有无状态的API实例收到前端拉取消息的请求时，直接从公共缓存里查对应key的消息返回即可，不需要每个API实例自己维护Kafka订阅。
• 优势：完全兼容无状态API的扩缩容，负载均衡不需要做任何调整，可用性高。

方案3：后端推送架构改造（适合实时性要求高的场景） #

• 用WebSocket或者SSE做前端和后端的长连接，配合支持长连接粘滞的网关，保证同一个连接生命周期内一直绑定同一个API实例。
• 每个API实例只给和自己保持长连接的前端推送自己订阅到的Kafka消息，连接断连后前端自动重连并重新发起订阅即可。

内容的提问来源于stack exchange，提问作者Camille Sévigny