BP5 · WebSocket 实时通信与异步任务管理#
定位：面试官追问实时通信与并发任务管理时的拷问预备。
核心口述（30 秒）#
“connect-first 协议零事件丢失：先连 WS 再 POST 任务。双池优先级队列：normal/heavy 分池，长任务堵不死短任务。事件回放：Redis Stream + last_event_id 补发。收尾流式：商品卡先出、文案逐字补。“
拷问链#
Q: 为什么 connect-first 而不是缓冲早期事件？#
缓冲需要知道”缓冲到什么时候为止”——WS 建连时间不确定。connect-first 协议层关死竞态。
Q: 为什么双池不是单池加优先级？#
单池长任务占满槽位，新的简单查询（2 步出结果）也要排队。双池保证 normal 不被 heavy 堵死。
Q: active_tasks 按 key 盲删的竞态怎么修？#
同 tid 快速重发，新任务 TaskHandle 被旧任务 finally 删。改按对象身份校验：if tasks.get(tid) is self_handle。
Q: 事件回放保证不重复？#
每个事件有单调递增 event_id。断线重连带 last_event_id，只推 > 该 id 的事件。
Q: 冷启动续看怎么做？#
GET /api/task/{tid}/inflight 探口 → replay_current_run 按轮回放 → 前端 resumeIfRunning 自动重建。
Q: 收尾流式的 items_preview 和 summary_delta 什么关系？#
items_preview 是一次性推所有商品卡（结构化数据）。summary_delta 是逐 token 流式推文案。先出货后出文案。
压力题#
Q: 进程内 ConnectionManager 多副本怎么办？#
改 Redis Pub/Sub。当前单进程够用，有明确升级路径。