对于一个 AI 大模型评测平台，需要向用户实时展示批量测试的进度，你会如何设计基于 WebSocket 的推送方案？请说明整体架构、消息协议、异常处理以及多客户端场景下的实现要点。
考察说明
考察基于 WebSocket 的实时进度推送方案设计能力，包括架构、可靠性、性能。
回答思路
- 【回答框架 1】整体架构采用客户端-服务端直连模式：客户端建立 WebSocket 连接后，服务端在批量测试任务执行时，通过该连接推送进度事件。为避免单点瓶颈，可引入网关层（如 Nginx 或 API 网关）负责连接保持和负载均衡。
- 【回答框架 2】消息协议定义标准化事件，包括 taskId、status、progress、currentIndex、totalCount、message 等字段，使用 JSON 格式，区分进度更新、状态变更和错误事件，方便客户端渲染。
- 【回答框架 3】批量测试由任务管理器分配至执行器，执行器实时上报进度至消息中间件（如 Redis Pub/Sub 或消息队列），推送服务订阅后转发给对应客户端，实现解耦和水平扩展。
- 【回答框架 4】异常处理策略：服务端心跳检测、客户端断线重连并携带上次接收序号，服务端基于序号补发遗漏消息；推送失败放入重试队列，超过阈值标记离线。
- 【回答框架 5】多客户端场景下，同一任务可推送给多个会话（如多标签页），需维护连接映射，并控制推送频率，避免消息洪峰，可采用批量聚合或节流策略。
- 【关键点 1】采用 WebSocket 长连接 + 消息中间件解耦任务执行与推送。
- 【关键点 2】消息协议需包含 taskId 和进度字段，支持断点续传。
- 【关键点 3】心跳检测与重连机制保障可靠性。
- 【关键点 4】通过网关层水平扩展，用于大量并发连接。
- 【易错点 1】避免把进度存储于单实例内存，重启会丢失。
- 【易错点 2】不做幂等处理时，重复或乱序消息会影响客户端展示。
- 【易错点 3】同任务多客户端需独立推送，不可共享单一连接状态。