实时与协同面试题

本题库共收录 65 道面试题（基础 14 / 进阶 27 / 深入 14 / 架构 10）。本文件收录实时与协同相关面试题，目标题量 150 道。题型覆盖：概念题、场景设计题、系统设计题、工程化题、性能优化题、安全题、软技能题、综合开放题。难度覆盖：基础、进阶、深入、架构。每道题除标准参考答案外，另附口头回答版，便于面试时快速组织语言。

基础题（8 道）

FB-32-CO-B-001：WebSocket、SSE、长轮询分别适用于什么场景？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：WebSocket、SSE、长轮询、实时通信 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请比较 WebSocket、Server-Sent Events（SSE）、长轮询三种实时通信方案，并说明各自适用场景。

参考答案：

方案	通信方向	协议	连接	适用场景
长轮询	客户端主动拉	HTTP	短连接	兼容旧浏览器、低频更新
SSE	服务端单向推	HTTP	长连接	股票行情、新闻推送、日志流
WebSocket	全双工	WS/WSS	长连接	聊天、协同编辑、游戏、控制信令

详细对比：

长轮询：客户端发起请求后服务端保持连接直到有数据或超时，再立即发起下一次。实现简单但延迟高、开销大。
SSE：基于 HTTP，浏览器原生 EventSource，服务端可主动推送文本流。支持自动重连、事件 ID，但只能服务端向客户端推。
WebSocket：建立后全双工、低延迟、头部开销小。需要处理连接管理、心跳、重连、二进制/文本帧。

选型建议：

服务端单向低频推送：SSE。
高频双向交互：WebSocket。
兼容性要求极高或无法维持长连接：长轮询。

评分维度：

三者区别（50%）：方向、协议、连接方式
适用场景（30%）：SSE 推送、WebSocket 双向、长轮询兼容
选型能力（20%）：根据业务特点选择

常见错误：

所有实时需求都用 WebSocket，忽略 SSE 更简单高效。
在只需要服务端推送的场景用 WebSocket 增加复杂度。

延伸追问：

SSE 在 HTTP/2 下有什么优势？
WebSocket 连接数过多时如何优化？

相关题目：

FB-32-CO-A-001 WebSocket 心跳与重连机制
FB-32-SD-R-002 设计一个实时聊天系统

参考资源：

口头回答版：

长轮询是客户端一直问服务端有没有新数据，兼容好但延迟高；SSE 是服务端通过 HTTP 长连接单向推，适合行情、日志流；WebSocket 是全双工长连接，适合聊天、协同编辑和游戏。选型上单向低频用 SSE，双向高频用 WebSocket。

FB-32-CO-B-002：WebRTC 的核心概念是什么？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：WebRTC、P2P、信令、STUN、TURN 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请简述 WebRTC 的适用场景和核心组件（信令、STUN、TURN、ICE、SDP）。

参考答案：

WebRTC 是浏览器原生支持的实时音视频通信技术，支持 P2P 数据传输，无需插件。

核心组件：

SDP（Session Description Protocol）：描述媒体能力（编解码、分辨率、网络候选）。
ICE（Interactive Connectivity Establishment）：收集候选地址并选择最优连接路径。
STUN（Session Traversal Utilities for NAT）：帮助内网设备获取公网 IP/端口，用于 P2P 直连。
TURN（Traversal Using Relays around NAT）：当 P2P 无法打通时，通过中继服务器转发媒体流。
信令服务器：用于交换 SDP 和 ICE 候选，本身不传输媒体数据。可由 WebSocket/SSE 实现。
DataChannel：WebRTC 提供的 P2P 数据通道，可传文本、二进制。

典型场景：

视频会议、语音通话、屏幕共享、P2P 文件传输、低延迟游戏。

评分维度：

组件理解（50%）：SDP、ICE、STUN、TURN、信令
场景认知（30%）：音视频、屏幕共享、P2P
P2P 概念（20%）：NAT 穿透、中继

常见错误：

认为 WebRTC 不需要服务器，实际上信令、STUN、TURN 都需要服务器。
混淆 STUN 和 TURN：STUN 只帮助发现地址，TURN 负责中继。

延伸追问：

ICE 候选有哪些类型（host/srflx/relay）？
为什么 WebRTC 音视频延迟通常比 RTMP/HLS 低？

相关题目：

FB-32-CO-A-003 WebRTC 信令服务器如何设计
FB-32-SD-R-003 设计一个实时视频会议系统

参考资源：

WebRTC.org

口头回答版：

WebRTC 是浏览器实时音视频技术。SDP 描述媒体能力，ICE 找最优连接路径，STUN 帮内网设备拿到公网地址，TURN 在 P2P 不通时中继，信令服务器只交换 SDP 和候选信息。适合会议、屏幕共享、P2P 传输。

FB-32-CO-B-003：实时系统中为什么要做心跳和重连？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：心跳、重连、长连接、WebSocket、可用性 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明心跳和重连机制在实时系统中的作用，并给出基本实现思路。

参考答案：

长连接可能因网络抖动、NAT 超时、负载均衡器空闲超时、客户端/服务端异常而断开，但 TCP/应用层不一定能立即感知。

心跳作用：

检测连接是否存活。
防止 NAT/负载均衡器因长时间无数据而切断连接。
及时发现对端异常。

重连作用：

连接断开后自动恢复，提升可用性。
重新订阅频道、恢复状态。

实现思路：

心跳：客户端/服务端定期互发 ping/pong，超时未收到则标记连接失效。
重连策略：
- 指数退避：首次 1s、2s、4s、8s… 最多到 30s 或 60s。
- 最大重试次数，超过后降级或提示用户。
- 区分可恢复错误（网络）与不可恢复错误（认证失败）。
状态恢复：
- 断连期间消息缓存或补推（基于 lastEventId/sequence）。
- 重连后重新加入房间、恢复订阅。

评分维度：

心跳原因（30%）：检测存活、防超时
重连策略（40%）：指数退避、最大次数、错误分类
状态恢复（30%）：消息补推、重新订阅

常见错误：

只重连不恢复状态，导致消息丢失或重复。
固定间隔重连，造成服务端雪崩。

延伸追问：

如何避免重连风暴拖垮服务端？
WebSocket 连接被防火墙拦截时如何降级？

相关题目：

FB-32-CO-B-001 WebSocket、SSE、长轮询对比
FB-32-CO-A-001 WebSocket 心跳与重连机制

参考资源：

MDN WebSocket

口头回答版：

实时系统中心跳用来检测连接还活着，防止 NAT 或负载均衡超时；重连是断开后自动恢复。实现要指数退避、限制最大次数、区分错误类型，重连后还要补发消息、恢复订阅。

FB-32-CO-B-004：如何保证实时消息的顺序和可靠性？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：消息顺序、可靠性、幂等、去重、序列号 出现频率：高频 预计回答时长：3-5 分钟

题目描述：在 WebSocket 等实时通道中，消息可能乱序、丢失或重复。请说明常见的保障手段。

参考答案：

保障手段：

序列号/版本号：每条消息带单调递增 seq，接收端按 seq 排序，缺失则请求补发。
ACK 确认：接收方回复 ACK，发送方未收到则重传。
去重：使用唯一消息 ID，接收端记录已处理 ID，忽略重复。
幂等设计：业务接口保证重复处理同一条消息结果一致。
缓冲区：接收端缓冲乱序消息，等待缺失消息到达后按序交付。
QoS 等级：
- 最多一次：允许丢失，适合实时性高、可容忍丢失（如位置更新）。
- 至少一次：保证送达但可能重复。
- 恰好一次：去重 + 幂等，适合交易类消息。

评分维度：

顺序保障（40%）：序列号、排序、缓冲
可靠性（40%）：ACK、重传、去重、幂等
QoS 选型（20%）：不同业务等级

常见错误：

依赖 WebSocket TCP 顺序，忽略应用层乱序和重连补推。
只重传不去重，导致业务重复执行。

延伸追问：

消息队列 Kafka 如何保证分区顺序？
多人协同编辑中如何平衡顺序与并发？

相关题目：

FB-32-CO-P-001 CRDT 与 OT 的区别
FB-32-CD-P-001 设计实时消息队列

参考资源：

MQTT QoS

口头回答版：

保证消息顺序可以加序列号排序和缓冲；保证可靠性用 ACK、重传、去重和幂等。业务不同选择不同 QoS：实时位置可容忍丢失，交易消息要恰好一次。不能只靠 TCP，应用层也要做。

FB-32-CO-B-005：实时系统中的房间/频道模型如何设计？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：房间、频道、发布订阅、实时通信 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明实时系统中“房间”或“频道”的作用，以及基本设计要点。

参考答案：

房间/频道用于把用户按业务维度分组，实现消息定向广播和隔离。

设计要点：

命名空间：如 room:{roomId}、channel:{biz}:{id}，避免冲突。
订阅/取消订阅：用户进入/离开房间时订阅/取消。
权限校验：订阅前校验用户是否有权加入该房间。
消息路由：服务端根据房间 ID 把消息只发给该房间在线用户。
状态管理：维护每个房间的在线用户列表、房间元数据、消息历史。
扩缩容：房间热度过高时考虑分片或限制人数；使用 Redis Pub/Sub 或 Kafka 做分布式广播。
离线消息：用户不在线时持久化消息，上线后推送或拉取。

评分维度：

模型理解（40%）：分组、广播、隔离
设计要点（40%）：命名、订阅、权限、路由、状态、扩缩容
离线处理（20%）：历史消息、补推

常见错误：

所有消息全局广播，造成带宽和隐私问题。
未校验房间权限，导致越权接收消息。

延伸追问：

如何实现房间的禁言和踢人？
百万观众直播间与普通聊天室的房间设计有何不同？

相关题目：

FB-32-SD-R-002 设计一个实时聊天系统
FB-32-CO-A-005 实时消息队列设计

参考资源：

Socket.io Rooms

口头回答版：

房间/频道把用户分组，实现定向广播和隔离。设计要点包括命名空间、订阅取消、权限校验、消息路由、房间状态、扩缩容和离线消息。要避免全局广播和越权。

FB-32-CO-B-006：Presence（在线状态）在实时系统中如何实现？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：Presence、在线状态、心跳、实时协同 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明实时协同系统中在线状态（Presence）的设计思路与常见问题。

参考答案：

Presence 用于展示用户是否在线、在哪些房间、当前操作（如光标位置、编辑中）。

设计思路：

状态来源：用户登录、加入房间、心跳续期、离开/断开。
存储：使用内存（每个服务节点）或 Redis/ETCD 等集中存储。
心跳检测：
- 客户端定时发送心跳，服务端超时未收到则标记离线。
- 也可采用服务端主动 ping 方式。
状态广播：用户状态变化时通知房间内其他用户。
批量聚合：大量用户同时在线时，按房间聚合状态，减少广播量。
隐私控制：仅向有权限的用户暴露在线状态。

常见问题：

心跳风暴：大量用户同时心跳，需合并或批量处理。
状态不一致：网络抖动导致在线/离线频繁切换，需设优雅期。
隐私泄露：暴露过多信息（如 IP、设备）。

评分维度：

设计思路（50%）：状态来源、存储、心跳、广播
问题处理（30%）：风暴、不一致、隐私
可扩展性（20%）：聚合、分片

常见错误：

每次心跳都广播全量状态，导致性能问题。
用户短暂断网就立即显示离线，体验差。

延伸追问：

如何实现“正在输入”而不产生过多消息？
在线状态与最后阅读时间如何结合？

相关题目：

FB-32-CO-B-003 心跳和重连
FB-32-CO-A-006 实时白板中的光标同步

参考资源：

Ably Presence

口头回答版：

Presence 实现在线状态需要状态来源、心跳续期、集中存储和状态广播。要注意心跳风暴、网络抖动导致的状态抖动和隐私问题。大量用户时要聚合状态、控制暴露信息。

FB-32-CO-B-007：实时应用有哪些常见的性能优化手段？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：实时性能、消息压缩、批量、节流、防抖 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请列举实时通信场景下前端的性能优化方法。

参考答案：

优化手段：

消息压缩：使用 MessagePack、Protobuf、二进制帧替代 JSON。
批量发送：合并短时间内多条消息，降低包数量和头部开销。
节流/防抖：光标、拖拽等高频事件节流后再发送。
差量更新：只发送变化部分，而非全量状态。
区域裁剪：协同白板/地图只同步可视区域内的对象。
连接合并：同一页面多个业务共享一条 WebSocket 连接。
优先级队列：重要消息优先发送，普通消息可合并或丢弃。
减少渲染抖动：使用 requestAnimationFrame 批量更新 UI。
Web Worker：复杂编解码/同步计算放 Worker，避免阻塞主线程。

评分维度：

传输优化（40%）：压缩、批量、差量
计算优化（30%）：节流、Worker、区域裁剪
渲染优化（30%）：RAF、优先级

常见错误：

实时性要求高时过度合并，导致延迟上升。
忽略前端渲染开销，消息到后频繁 setState。

延伸追问：

多人协作编辑器如何做到每秒 60 帧的光标同步？
消息压缩对移动端电量和流量有何影响？

相关题目：

FB-32-CO-A-006 实时白板中的光标同步
FB-32-SD-R-001 设计实时协同文档

参考资源：

MessagePack

口头回答版：

实时性能优化包括消息压缩、批量发送、差量更新、节流防抖、区域裁剪、连接合并、优先级队列、RAF 渲染和 Web Worker。要平衡实时性和开销，避免过度合并导致延迟。

FB-32-CO-B-008：实时系统中如何处理用户离线？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：离线、消息补发、持久化、实时同步 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明实时系统中用户离线时的消息处理策略。

参考答案：

离线处理策略：

消息持久化：服务端把消息写入数据库/消息队列，用户上线后拉取或推送到客户端。
消息补推：
- 基于 lastEventId/sequence 拉取断线期间消息。
- 服务端保存最近一段时间（如 7 天）的消息。
离线计数/摘要：对通知类消息只推送未读数或摘要，减少流量。
合并与去重：多条同类通知合并，避免用户上线后消息轰炸。
业务降级：离线时允许本地操作，待联网后同步（如离线编辑）。
过期清理：设置消息 TTL，避免存储无限增长。

评分维度：

持久化策略（30%）：存储、TTL
补推机制（30%）：lastEventId、拉取/推送
体验优化（40%）：合并、摘要、离线操作

常见错误：

用户上线后推送所有历史消息，造成流量和体验问题。
不持久化消息，离线即丢失。

延伸追问：

离线编辑与在线协同如何合并冲突？
消息 TTL 与业务合规（如金融留痕）如何平衡？

相关题目：

FB-32-CO-B-004 消息顺序和可靠性
FB-32-SD-R-004 实时与离线同步结合

参考资源：

MQTT Retained Messages

口头回答版：

用户离线时服务端要持久化消息，上线后基于 lastEventId 补推。通知类可以合并或只推未读数；可离线操作的场景要先本地执行再同步。要设消息 TTL 避免无限增长。

进阶题（8 道）

FB-32-CO-A-001：WebSocket 心跳与重连机制如何设计？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：32 实时与协同标签：WebSocket、心跳、重连、指数退避、连接管理 出现频率：高频 预计回答时长：5-7 分钟

题目描述：请设计一个健壮的 WebSocket 客户端心跳与重连模块，说明状态机、退避策略和消息恢复。

参考答案：

设计要点：

状态机：connecting、open、closing、closed、reconnecting。
心跳：
- 连接建立后启动定时器发送 ping，收到 pong 后重置超时。
- 超时未收到 pong 则主动关闭并触发重连。
重连：
- 非主动关闭（如网络异常）触发重连。
- 指数退避：1s、2s、4s、8s… 最大 60s。
- 随机抖动避免惊群。
- 设置最大重试次数或无限重试但通知用户。
消息恢复：
- 发送消息时若未连接，先缓存到队列。
- 重连成功后按序发送队列，并拉取断线期间服务端消息。
- 给每条消息分配唯一 ID，便于去重。
事件暴露：对外暴露 open、message、close、error、reconnect 事件。

伪代码：

class RobustWebSocket {
  constructor(url) { this.url=url; this.queue=[]; this.retry=0; }
  connect() {
    this.ws = new WebSocket(this.url);
    this.ws.onopen = () => { this.retry=0; this.flush(); this.startHeartbeat(); };
    this.ws.onclose = (e) => { clearInterval(this.heartbeat); if(!this.intentional) this.reconnect(); };
    this.ws.onmessage = (m) => { if(m.data==='pong') this.lastPong=Date.now(); else this.emit('message',m); };
  }
  reconnect() { const delay = Math.min(1000*2**this.retry, 60000) * (0.8+Math.random()*0.4); setTimeout(()=>this.connect(), delay); this.retry++; }
  send(data) { if(this.ws?.readyState===1) this.ws.send(data); else this.queue.push(data); }
}

评分维度：

状态机（20%）：连接各状态管理
心跳设计（30%）：ping/pong、超时处理
重连策略（30%）：指数退避、抖动、最大次数
消息恢复（20%）：队列、去重、补拉

常见错误：

心跳过于频繁导致耗电和流量。
重连时不恢复订阅和状态，消息丢失。

延伸追问：

如何在浏览器切后台时优化心跳？
多个 Tab 同时重连服务端如何避免压力？

相关题目：

FB-32-CO-B-003 心跳和重连
FB-32-SD-R-002 设计实时聊天系统

参考资源：

MDN WebSocket

口头回答版：

设计健壮 WebSocket 客户端要有状态机，连接稳定后定时发 ping 等 pong，超时主动断线重连。重连用指数退避加随机抖动，设置最大次数。消息先缓存，重连后按序发送并补拉断线消息，每条消息加唯一 ID 去重。

FB-32-CO-A-002：OT 与 CRDT 有什么区别？协同编辑如何选型？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：32 实时与协同标签：OT、CRDT、协同编辑、一致性 出现频率：高频 预计回答时长：5-7 分钟

题目描述：请比较 OT（Operational Transformation）与 CRDT（Conflict-free Replicated Data Type）的原理、优缺点和适用场景。

参考答案：

维度	OT	CRDT
核心思想	服务端对操作进行变换后再广播	数据结构天然满足交换律/结合律/幂等，本地合并
中心依赖	通常需要中央服务器做变换	可中心化也可完全去中心化
实现复杂度	高，变换规则随操作类型增加	相对低，但数据模型设计要求高
一致性	强一致，依赖服务端顺序	最终一致
离线支持	较弱	强，本地离线编辑后合并
代表	Google Docs、早期协同编辑	Figma、Notion、Yjs、Automerge

选型建议：

强一致、中心服务器、文档类：OT 或中心化 CRDT。
高并发、P2P、离线优先：CRDT。
现代协同编辑器多数采用 CRDT，因为其离线支持和实现可维护性更好。

评分维度：

原理理解（40%）：变换 vs 数据结构一致性
优缺点（30%）：复杂度、一致性、离线
选型能力（30%）：文档 vs 图形 vs P2P

常见错误：

认为 OT 和 CRDT 只是实现方式不同，忽略一致性模型差异。
在需要强一致的场景错误使用去中心化 CRDT。

延伸追问：

Yjs 的 CRDT 是如何处理冲突的？
在纯文本编辑器中，插入操作的 CRDT 如何设计？

相关题目：

FB-32-CO-P-001 CRDT 原理与分类
FB-32-SD-R-001 设计实时协同文档

参考资源：

口头回答版：

OT 是服务端把操作做变换后再广播，强一致但实现复杂，适合 Google Docs 这种；CRDT 是数据结构天然可合并，最终一致，支持离线，实现相对简单，适合 Figma、Notion。选型看是否需要强中心和离线支持。

FB-32-CO-A-003：WebRTC 信令服务器如何设计？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：32 实时与协同标签：WebRTC、信令服务器、SDP、ICE、房间 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请设计一个支持多房间的 WebRTC 信令服务器，说明其职责、消息协议和扩展性。

参考答案：

信令服务器职责：

协助两端交换 SDP Offer/Answer。
交换 ICE candidate。
房间管理：创建、加入、离开、踢人、权限校验。
可选：心跳、状态通知、转发控制消息。

消息协议：

join-room：用户加入房间。
offer / answer：SDP 交换。
ice-candidate：ICE 候选传递。
leave-room / kick：离开/踢人。
error / notification：错误与通知。

实现要点：

使用 WebSocket/Socket.io 维持长连接。
每个房间维护连接列表，按房间广播信令。
不转发媒体流，只转发信令。
对 SDP 和 candidate 做路由，不解析媒体内容（也可做编解码协商辅助）。
可扩展：
- 多个信令服务节点用 Redis Pub/Sub 做房间状态同步。
- 水平扩展时按 roomId 哈希路由到固定节点。

安全：

加入房间前鉴权。
校验 SDP 来源，防止伪造。
限制单个房间人数。

评分维度：

职责清晰（30%）：SDP/ICE 交换、房间管理
协议设计（30%）：消息类型与状态流转
扩展性（20%）：多节点、Redis、哈希路由
安全（20%）：鉴权、人数限制

常见错误：

信令服务器承担媒体转发（那是 TURN/MCU/SFU 的职责）。
不鉴权就允许加入房间，导致会议被爆破。

延伸追问：

信令服务器宕机如何不影响已建立的 P2P 连接？
如何支持匿名参会与密码房间？

相关题目：

FB-32-CO-B-002 WebRTC 核心概念
FB-32-SD-R-003 设计实时视频会议系统

参考资源：

WebRTC Signaling

口头回答版：

WebRTC 信令服务器负责交换 SDP Offer/Answer 和 ICE candidate，管理房间。用 WebSocket 实现，消息包括 join-room、offer、answer、ice-candidate。它不转发媒体流。多节点时可用 Redis Pub/Sub 同步房间状态，按 roomId 哈希路由。一定要做好鉴权和人数限制。

FB-32-CO-A-004：实时系统中的冲突解决有哪些策略？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：32 实时与协同标签：冲突解决、乐观锁、Last-Write-Wins、CRDT、版本向量 出现频率：中频 预计回答时长：5-7 分钟

题目描述：在多人实时编辑或状态同步中，冲突不可避免。请列举常见的冲突解决策略及其适用场景。

参考答案：

冲突解决策略：

Last-Write-Wins（LWW）：以时间戳或版本号最大的为准。
- 适用：简单 KV、配置、非关键状态。
- 缺点：可能丢数据。
乐观锁 / 版本号：每个数据带版本，更新时检查版本，冲突时重试或提示。
- 适用：数据库并发更新、表单提交。
合并策略（Merge）：自动合并两个版本的差异，如 JSON 深层合并。
- 适用：结构化配置、JSON 文档。
CRDT：数据结构本身保证最终一致，冲突按预定规则解决。
- 适用：文本、列表、计数器、协同白板。
OT：服务端变换操作顺序，保证强一致。
- 适用：中心式协同编辑。
用户介入：冲突无法自动解决时提示用户选择。
- 适用：重要文档、代码合并。

选择依据：

数据类型（文本、KV、图形）。
一致性要求（强一致 vs 最终一致）。
离线需求。
用户体验（自动合并 vs 提示）。

评分维度：

策略覆盖（50%）：LWW、乐观锁、合并、CRDT、OT、用户介入
适用场景（30%）：能根据业务选择
一致性理解（20%）：强一致 vs 最终一致

常见错误：

所有冲突都用 LWW，导致编辑内容丢失。
在文本协同中简单比较时间戳，破坏语义。

延伸追问：

版本向量（Vector Clock）如何解决并发冲突？
设计一个购物车合并策略。

相关题目：

FB-32-CO-A-002 OT 与 CRDT 区别
FB-32-CO-P-001 CRDT 原理与分类

参考资源：

CRDT.tech

口头回答版：

冲突解决策略有 Last-Write-Wins、乐观锁版本号、自动合并、CRDT、OT 和用户介入。简单 KV 可用 LWW，数据库更新用乐观锁，协同编辑用 CRDT 或 OT，无法自动解决时让用户选。要根据数据类型和一致性要求选。

FB-32-CO-A-005：实时消息队列/发布订阅如何设计？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：32 实时与协同标签：发布订阅、消息队列、Redis、Kafka、实时通信 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请设计一个支持多端实时推送的发布订阅系统，说明其架构、消息路由和可靠性保障。

参考答案：

架构：

客户端：WebSocket/SSE 连接到网关。
网关层：维护用户/设备与连接的映射，支持水平扩展。
消息队列：Redis Pub/Sub、RabbitMQ、Kafka 或自研消息总线，解耦业务与推送。
业务服务：产生消息后写入队列或调用推送服务。
持久化/存储：消息数据库、离线消息队列、用户订阅关系。

消息路由：

根据 channel 或 userId 路由。
维护 userId -> [connectionId] 映射。
对广播消息使用扇出（fan-out），大房间可升级为广播树或 CDN 边缘推送。

可靠性：

消息持久化 + ACK 确认。
离线消息补推。
去重 ID。
至少一次/恰好一次语义。
限流与降级：消息堆积时丢弃非关键消息。

扩展性：

网关无状态，用 Redis 共享会话。
按 userId/roomId 分片，避免单节点热点。
边缘节点就近接入。

评分维度：

架构清晰（30%）：客户端、网关、队列、存储
路由能力（30%）：订阅关系、扇出、分片
可靠性（20%）：ACK、持久化、去重、离线
扩展性（20%）：无状态、分片、边缘

常见错误：

网关直接连接数据库做广播，无法扩展。
不持久化消息，离线即丢失。

延伸追问：

百万在线的房间如何实现广播？
消息队列选型 Redis Pub/Sub 与 Kafka 各适合什么？

相关题目：

FB-32-SD-R-002 设计实时聊天系统
FB-32-CD-P-001 设计实时消息队列

参考资源：

Redis Pub/Sub

口头回答版：

实时发布订阅系统包括客户端长连接到网关，网关通过消息队列路由，业务服务写消息。要维护 userId 到连接的映射，支持广播和单播。可靠性靠 ACK、持久化、去重和离线补推。扩展性靠无状态网关、Redis 共享会话、按 roomId 分片。

FB-32-CO-A-006：实时白板中光标/选区同步如何优化？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：32 实时与协同标签：协同白板、光标同步、节流、差量、实时渲染 出现频率：中频 预计回答时长：5-7 分钟

题目描述：在实时白板或文档中，如何高效同步多个用户的光标位置、选区和操作？

参考答案：

优化策略：

节流/采样：光标移动等高频率事件做节流，如 30-60ms 发送一次，或按距离阈值。
差量同步：只发送坐标、选区起止变化，而非全量画面。
预测与插值：本地立即更新自己的光标，对他人的光标做插值平滑移动。
区域兴趣（AOI）：只同步可视区域内的光标，超出区域的隐藏或聚合。
批量渲染：使用 requestAnimationFrame 批量更新光标 DOM，避免每帧重排。
Web Worker：复杂图形计算或序列化放 Worker。
操作压缩：把连续移动合并为一个移动操作，减少消息量。

一致性：

光标是弱一致性场景，允许短暂位置不一致。
选区需要与文档版本对齐，避免在不同版本号下解释选区。

评分维度：

传输优化（40%）：节流、差量、压缩
渲染优化（30%）：RAF、插值、AOI
一致性（30%）：弱一致光标、版本对齐选区

常见错误：

每次鼠标移动都发送消息，导致网络拥塞。
用 setState 频繁更新光标，导致页面卡顿。

延伸追问：

光标冲突（两人重叠）如何可视化？
白板缩放/滚动时坐标如何统一？

相关题目：

FB-32-CO-B-007 实时应用性能优化
FB-32-SD-R-005 设计实时协同白板

参考资源：

Figma Engineering Blog

口头回答版：

光标同步要高效率，节流到 30-60ms、差量发送、连续移动合并、超出可视区域不同步。渲染用 requestAnimationFrame 批量更新，他人光标做插值平滑。光标可弱一致，选区要和文档版本对齐。

FB-32-CO-A-007：网络分区对实时系统有什么影响？如何处理？

题型：概念题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：32 实时与协同标签：网络分区、CAP、最终一致、离线优先 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请分析网络分区场景下实时系统面临的挑战，并给出处理策略。

参考答案：

网络分区影响：

客户端与服务端、服务端节点之间通信中断。
消息无法送达，状态出现分歧。
分区恢复后需要合并状态，可能产生冲突。

处理策略：

检测分区：心跳超时、ACK 未返回、连接断开。
本地优先（Offline-First）：允许用户在本地继续操作，待网络恢复后同步。
最终一致：使用 CRDT 或版本向量合并分区期间的操作。
冲突解决：LWW、用户介入、业务规则合并。
降级体验：只读模式、提示网络异常、禁用协同功能。
分区恢复：
- 拉取服务端状态，与本地状态合并。
- 重放操作日志（operation log）。
- 通知用户哪些操作可能冲突。

CAP 权衡：

实时协同通常选择 AP（可用 + 分区容错），牺牲强一致，保证用户体验。

评分维度：

分区影响（30%）：消息丢失、状态分歧
处理策略（50%）：检测、离线优先、CRDT、冲突解决、降级
CAP 理解（20%）：AP 选型

常见错误：

分区期间直接报错或锁定用户操作，体验差。
恢复后简单用服务端覆盖本地，导致用户数据丢失。

延伸追问：

如何设计“分区恢复”的 UI 反馈？
金融交易场景能否接受 AP？

相关题目：

FB-32-CO-A-002 OT 与 CRDT 区别
FB-32-SD-R-004 实时与离线同步结合

参考资源：

CAP Theorem

口头回答版：

网络分区会导致消息无法送达、状态分歧。处理策略是检测超时后允许本地操作，用 CRDT 或版本向量保证最终一致，恢复后合并冲突并提示用户。实时协同通常选 AP，优先保证可用性。

FB-32-CD-A-001：如何设计一个实时数据看板？

题型：场景设计题难度：🔵 进阶 岗位层级：高级 / 资深 面试知识域：32 实时与协同标签：实时看板、SSE、数据聚合、前端渲染、WebSocket 出现频率：中频 预计回答时长：5-7 分钟

题目描述：请设计一个展示实时业务指标的数据看板，说明数据采集、推送、前端渲染和性能优化。

参考答案：

设计要点：

数据源：业务日志、消息队列、时序数据库（如 InfluxDB、Prometheus）。
数据聚合：
- 服务端按时间窗口聚合（秒/分钟级）。
- 对大数据量做采样或 TopN，减少传输。
推送通道：
- 服务端单向推送优先用 SSE，简单且自动重连。
- 若需要交互控制可用 WebSocket。
前端渲染：
- 使用 ECharts/AntV 等图表库。
- 数据更新时增量更新图表数据，避免全量重绘。
- 对高频更新做节流，控制帧率。
性能优化：
- 只推送可视图表所需指标。
- 大数据量时使用数据下采样（LTTB）。
- Web Worker 处理数据转换。
- 虚拟化长列表告警。

稳定性：

断线后重连并补推最近窗口数据。
提供手动刷新和历史回放。

评分维度：

数据流设计（30%）：采集、聚合、推送
前端渲染（30%）：增量更新、节流、图表库
性能优化（30%）：采样、Worker、虚拟化
稳定性（10%）：重连、补推

常见错误：

每个数据点都推送到前端，导致浏览器卡死。
全量重绘图表，CPU 占用高。

延伸追问：

如何保障看板数据的准确性与延迟？
多个用户同时打开看板，服务端如何节省聚合计算？

相关题目：

FB-32-CO-B-007 实时应用性能优化
FB-32-SD-R-006 设计实时数据看板

参考资源：

ECharts 大数据量优化

口头回答版：

实时看板服务端聚合业务数据，用 SSE 单向推送；前端增量更新图表、节流渲染；大数据量要采样、用 Worker、虚拟化。断线后补推最近数据。关键是别每个点都推，避免前端卡死。

深入题（7 道）

FB-32-CO-P-001：CRDT 的原理与分类是什么？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：32 实时与协同标签：CRDT、状态型、操作型、最终一致、协同编辑 出现频率：高频 预计回答时长：7-10 分钟

题目描述：请深入解释 CRDT 的两种主要类型（State-based CRDT 与 Operation-based CRDT），并说明它们的优缺点。

参考答案：

CRDT 是一类数据结构，在满足交换律、结合律、幂等性的前提下，多个副本可以独立更新并自动合并到一致状态。

State-based CRDT（状态型）：

每次状态变化后传播完整状态或增量状态。
合并函数 merge(stateA, stateB) 必须满足交换律、结合律、幂等。
优点：实现简单，不需要可靠广播。
缺点：状态大时传输成本高。

Operation-based CRDT（操作型）：

传播操作（operation）本身，接收方在本地重放。
要求操作满足交换律、结合律，且需要因果广播（causal broadcast）保证操作按因果顺序到达。
优点：消息小，传输高效。
缺点：对网络传输可靠性要求高，需要处理乱序和丢失。

常见 CRDT：

G-Counter / PN-Counter：计数器。
G-Set / OR-Set：集合，支持增删。
LWW-Register：最后写入寄存器。
RGA / YATA：文本序列 CRDT。

选型：

小状态、低并发：State-based。
大文档、高并发：Operation-based（如 Yjs）。

评分维度：

两类 CRDT 原理（40%）：状态合并 vs 操作重放
性质理解（30%）：交换律、结合律、幂等、因果广播
应用能力（30%）：根据场景选择并举例

常见错误：

认为 CRDT 不需要任何网络保证，忽略 Operation-based 的因果广播要求。
混淆 CRDT 与 OT 的适用边界。

延伸追问：

如何在文本 CRDT 中实现撤销（undo）？
CRDT 的内存增长问题如何解决？

相关题目：

FB-32-CO-A-002 OT 与 CRDT 区别
FB-32-SD-R-001 设计实时协同文档

参考资源：

CRDT.tech

口头回答版：

CRDT 分状态型和操作型。状态型传播完整状态，合并函数满足交换结合幂等，实现简单但传输大；操作型传播操作，需要因果广播，消息小但可靠性要求高。常见有计数器、集合、寄存器、文本序列 CRDT。大文档高并发一般用操作型。

FB-32-CO-P-002：协同编辑中的光标/选区同步有什么难点？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：32 实时与协同标签：协同编辑、光标同步、选区、版本对齐、CRDT 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请分析多人协同编辑器中光标和选区同步的技术难点与解决方案。

参考答案：

难点：

位置漂移：其他用户插入/删除内容后，光标相对位置会变化。
版本对齐：选区基于某个文档版本，接收端版本不同会导致选区错位。
高频更新：光标移动频率高，易产生网络拥塞和渲染抖动。
多端差异：不同设备行高、字体、换行可能不同，像素坐标不统一。

解决方案：

基于 CRDT 索引：用稳定的 CRDT 位置标识（如 Yjs 的 relative position）代替纯字符偏移。
锚定策略：把选区锚定到最近的稳定边界（如段落、句子）。
节流与采样：光标移动节流，选区变化再发送。
版本向量：携带文档版本信息，接收端在本地版本上解释选区。
虚拟光标渲染：对他人光标做插值和平滑动画，允许短暂不一致。
坐标抽象：使用文档内相对位置而非屏幕像素。

评分维度：

难点识别（40%）：漂移、版本、高频、多端
解决方案（40%）：CRDT 索引、锚定、节流、版本向量
体验权衡（20%）：允许弱一致、平滑动画

常见错误：

用绝对字符偏移同步选区，导致其他用户编辑后完全错位。
忽视不同客户端渲染差异。

延伸追问：

如何表示“用户正在输入”的状态？
多人同时选中同一段文字时如何显示？

相关题目：

FB-32-CO-A-006 实时白板光标同步
FB-32-SD-R-001 设计实时协同文档

参考资源：

Yjs Relative Position

口头回答版：

光标同步难点是位置漂移、版本对齐、高频更新和多端渲染差异。解决方法是基于 CRDT 的相对位置或锚定到稳定边界，携带版本向量，节流发送，他人光标做插值动画。选区要用文档内相对位置而不是屏幕像素。

FB-32-PE-P-001：实时系统如何实现水平扩展？

题型：性能优化题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：32 实时与协同标签：水平扩展、分片、负载均衡、无状态、网关 出现频率：中频 预计回答时长：7-10 分钟

题目描述：当实时系统用户量和连接数增长时，如何进行水平扩展？请说明关键设计。

参考答案：

水平扩展关键点：

无状态网关：
- 每个网关节点只维护本地连接，用户/房间状态存到 Redis/ETCD。
- 新节点加入时自动分担连接。
连接路由：
- 四层负载均衡（LVS/Envoy）按连接分发。
- 避免按请求分发导致 WebSocket 断连。
房间/用户分片：
- 按 roomId 或 userId 哈希划分到不同消息队列分区，避免单点热点。
消息广播优化：
- 小房间：网关本地扇出。
- 大房间：使用发布订阅或广播树，避免单节点 O(N) 扇出。
资源隔离：
- 大房间单独部署高规格节点。
- 关键业务与普通业务拆分集群。
状态外部化：
- 在线状态、未读数、房间元数据存到分布式缓存。

监控：

连接数、消息 QPS、CPU/内存、延迟、丢包率。
自动扩容阈值。

评分维度：

无状态设计（30%）：网关、外部化状态
路由分片（30%）：连接路由、房间分片
广播优化（20%）：扇出、广播树
可观测性（20%）：监控、自动扩容

常见错误：

网关节点存储房间状态，导致无法水平扩展。
按 HTTP 请求负载均衡 WebSocket，导致频繁重连。

延伸追问：

百万人在线直播时，聊天消息如何广播？
跨地域部署时如何降低延迟？

相关题目：

FB-32-CO-A-005 实时消息队列设计
FB-32-SD-R-002 设计实时聊天系统

参考资源：

Scaling WebSockets

口头回答版：

实时系统水平扩展要保证网关无状态，连接状态存 Redis；负载均衡按连接分发；按 roomId 分片避免热点；小房间本地扇出，大房间用广播树；大房间独立集群；全链路监控自动扩容。不能按 HTTP 请求分发 WebSocket。

FB-32-CO-P-003：消息去重与幂等如何保证？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：32 实时与协同标签：去重、幂等、消息 ID、至少一次、恰好一次 出现频率：中频 预计回答时长：7-10 分钟

题目描述：在实时消息系统中，重复消息可能由重连、重传导致。请说明去重与幂等的设计方法。

参考答案：

去重方法：

全局唯一消息 ID：每条消息生成 UUID 或 seq + senderId + timestamp。
客户端去重表：记录最近 N 条已处理消息 ID，重复则忽略。
服务端去重表：对“发送”操作记录已确认 ID，避免重复投递。
幂等 Token：关键操作（如支付、下单）携带幂等键，服务端保证多次执行结果一致。

幂等设计：

操作语义幂等：
- 设置状态为某个值（幂等）优于累加（不幂等）。
- 使用 CRDT 的合并语义自然幂等。
服务端状态机：
- 记录操作结果，同一幂等键只处理一次。
- 对重试返回上次结果。
版本号/乐观锁：更新时检查版本，冲突则重试。

QoS 等级：

至少一次：去重。
恰好一次：去重 + 幂等。

评分维度：

去重机制（40%）：消息 ID、去重表、Token
幂等设计（40%）：语义幂等、状态机、版本号
QoS 选型（20%）：至少一次 vs 恰好一次

常见错误：

只去重不幂等，重试时业务重复执行。
消息 ID 生成依赖不可靠的时钟，导致冲突。

延伸追问：

分布式环境下如何保证 ID 唯一？
去重表应该设在客户端还是服务端？

相关题目：

FB-32-CO-B-004 消息顺序和可靠性
FB-32-CD-P-001 设计实时消息队列

参考资源：

Designing Data-Intensive Applications

口头回答版：

去重靠全局唯一消息 ID 和客户端/服务端去重表，幂等靠操作语义、服务端状态机或版本号。关键业务要实现恰好一次，既去重又幂等。ID 生成不要依赖不可靠时钟。

FB-32-CO-P-004：WebRTC 中 TURN 和媒体协商的作用是什么？

题型：概念题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：32 实时与协同标签：WebRTC、TURN、ICE、SDP、媒体协商 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请解释 WebRTC 中 ICE、TURN、SDP 协商的过程，以及媒体协商失败时如何排查。

参考答案：

ICE 过程：

两端各自收集候选地址：host（本机）、srflx（STUN 反射）、relay（TURN 中继）。
通过信令交换候选地址。
双方按优先级尝试连接，通常优先直连，失败后走 TURN。
选择可用路径建立连接。

SDP 协商：

一方创建 Offer（包含媒体类型、编解码、带宽等）。
另一方回复 Answer。
双方通过 setLocalDescription / setRemoteDescription 设置。

TURN 作用：

当双方 NAT 类型不兼容或防火墙限制时，TURN 作为中继转发媒体流。
增加延迟和带宽成本，但提高连通率。

排查媒体协商失败：

检查信令是否成功交换 Offer/Answer/ICE candidate。
查看 SDP 中是否有共同支持的编解码。
检查 STUN/TURN 服务器是否可达。
查看浏览器 console 和网络日志中的 ICE 状态。
确认摄像头/麦克风权限。

评分维度：

ICE/TURN 理解（40%）：候选、优先级、中继
SDP 协商（30%）：Offer/Answer、本地/远端描述
排查能力（30%）：信令、编解码、ICE 状态、权限

常见错误：

认为 TURN 是首选路径，实际上它是最后选择。
SDP 设置顺序错误导致协商失败。

延伸追问：

如何降低 TURN 中继带来的延迟？
SDP 中 BUNDLE 和 RTCP-mux 的作用是什么？

相关题目：

FB-32-CO-B-002 WebRTC 核心概念
FB-32-CO-A-003 WebRTC 信令服务器设计

参考资源：

WebRTC ICE

口头回答版：

WebRTC 中 ICE 收集 host、STUN、TURN 候选地址并选择最优路径；SDP 通过 Offer/Answer 协商媒体能力；TURN 在 P2P 不通时中继。排查协商失败要检查信令交换、共同编解码、STUN/TURN 可达性、ICE 状态和权限。

FB-32-SE-P-001：实时协同中的安全与权限如何设计？

题型：安全题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：32 实时与协同标签：实时协同、权限、鉴权、加密、操作审计 出现频率：中频 预计回答时长：7-10 分钟

题目描述：请设计实时协同系统（如文档、白板）中的安全与权限控制方案。

参考答案：

安全设计要点：

接入鉴权：
- 用户加入房间前校验 Token/Session，确认身份。
- WebSocket 连接建立时也需鉴权，不能仅靠 HTTP Cookie。
房间权限：
- 角色：所有者、编辑者、评论者、查看者。
- 不同角色可执行操作不同（编辑、评论、导出、邀请）。
操作鉴权：
- 每个操作（插入、删除、移动）到达服务端后校验权限。
- 前端仅做 UI 隐藏，不能作为安全防线。
数据隔离：
- 用户只能订阅自己有权访问的房间/频道。
- 服务端按房间路由，禁止跨房间消息泄露。
传输加密：WSS/HTTPS，敏感协同数据可端到端加密。
内容审计：
- 记录操作日志（who/when/what），便于审计和恢复。
- 防刷屏、恶意内容过滤。
分享链接：
- 设置有效期、密码、只读/可编辑。
- 分享 Token 权限降级。

评分维度：

鉴权设计（30%）：连接鉴权、房间权限、操作鉴权
数据隔离（20%）：房间路由、订阅控制
安全传输与审计（30%）：WSS、日志、审计
分享控制（20%）：链接权限、过期、密码

常见错误：

仅在加入房间时鉴权，后续操作不校验。
用前端角色隐藏按钮代替后端鉴权。

延伸追问：

如何实现“只读用户可看到实时更新但不能编辑”？
协同编辑内容的版本历史如何保护？

相关题目：

FB-31-SD-R-002 微前端场景下安全隔离
FB-32-SD-R-001 设计实时协同文档

参考资源：

OWASP Access Control Cheat Sheet

口头回答版：

实时协同安全要在连接、房间、操作三层鉴权；前端只隐藏 UI，后端必须校验每个操作。数据按房间隔离，用 WSS 传输，记录操作日志。分享链接要设角色、过期和密码。不能只鉴权一次。

FB-32-PE-P-002：实时数据流中的背压（Backpressure）如何处理？

题型：性能优化题难度：🟣 深入 岗位层级：资深 / 架构 面试知识域：32 实时与协同标签：背压、流控、反压、实时数据、队列 出现频率：低频 预计回答时长：7-10 分钟

题目描述：请解释实时数据流中的背压问题，并给出前端的处理策略。

参考答案：

背压：生产者速度大于消费者处理能力，导致缓冲区无限增长、内存溢出或延迟飙升。

场景：

服务端高频推送行情/日志，前端渲染跟不上。
多人协同中大量操作同时到达。

处理策略：

服务端限流：按客户端消费能力推送，如令牌桶、漏桶。
采样与聚合：服务端先聚合或采样，减少消息量。
客户端缓冲 + 丢弃：
- 设置缓冲区上限，超过后丢弃非关键消息或只保留最新值。
- 对连续数值使用最新值覆盖（如股票价格）。
流控信号：
- 客户端向服务端发送 pause/resume。
- WebSocket 内置 TCP 流控，但应用层也需主动反馈。
批量处理：
- 把一段时间内的消息合并处理，避免每消息触发渲染。
Web Worker：把数据解析放 Worker，主线程只负责渲染。

指标监控：

缓冲区大小、处理延迟、丢包率、渲染帧率。

评分维度：

背压理解（30%）：生产者/消费者速度不匹配
服务端策略（30%）：限流、采样、聚合
客户端策略（30%）：缓冲、丢弃、批量、Worker
监控（10%）：延迟、帧率

常见错误：

无限制缓存所有消息，导致内存溢出。
对关键业务消息也丢弃，造成数据丢失。

延伸追问：

RxJS 中的 backpressure 操作符有哪些？
看板场景下哪些消息可以丢弃，哪些不能？

相关题目：

FB-32-CO-B-007 实时应用性能优化
FB-32-CD-A-001 设计实时数据看板

参考资源：

Reactive Streams Backpressure

口头回答版：

背压是生产速度大于消费速度。处理办法包括服务端限流、采样聚合，客户端设缓冲上限并丢弃非关键消息、批量处理、用 Worker。还可以发 pause/resume 信号。要监控缓冲、延迟和帧率。

架构题（42 道）

FB-32-SD-R-001：如何设计一个实时协同文档系统？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：32 实时与协同标签：协同文档、CRDT、OT、版本历史、权限 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请设计一个类似 Google Docs/Notion 的实时协同文档系统，覆盖数据模型、同步协议、冲突解决、权限和版本历史。

参考答案：

整体架构：

客户端：富文本编辑器 + CRDT/OT 运行时 + 本地缓存。
网关：WebSocket 连接管理、房间路由。
协同服务：操作转换或 CRDT 合并、持久化快照、版本历史。
存储：文档操作日志（CRDT updates 或 OT ops）、快照、元数据。
搜索/索引：异步构建文档索引。

数据模型：

文档由 Block/段落组成，每个 Block 有唯一 ID 和 CRDT 状态。
操作日志按文档 ID 分片存储，便于回放和审计。

同步协议：

客户端本地先应用操作，再发送给服务端。
服务端广播给其他客户端。
使用 CRDT 时无需中央变换，服务端只做路由和持久化。
使用 OT 时需要服务端做操作变换。

冲突解决：

采用 CRDT（如 Yjs、Automerge）实现最终一致。
对结构化属性（标题、权限）使用 LWW 或用户介入。

权限：

文档级/Block 级权限，角色包括查看、评论、编辑、所有者。
服务端对每个操作校验权限。

版本历史：

定期保存快照，操作日志可回滚到任意版本。
展示时间轴和版本对比。

扩展性：

按文档 ID 分片，大文档可拆分为 Block 级 CRDT。
客户端离线编辑后联网合并。

评分维度：

架构完整（30%）：客户端、网关、服务、存储
同步与冲突（30%）：CRDT/OT、广播、合并
权限与版本（20%）：角色、操作校验、快照
可扩展性（20%）：分片、离线、大文档

常见错误：

服务端对每个字符都落盘，导致写入压力过大。
忽略版本历史带来的存储成本。

延伸追问：

如何实现文档的离线编辑和在线合并？
如果文档非常大，如何优化首次加载？

相关题目：

FB-32-CO-A-002 OT 与 CRDT 区别
FB-32-CO-P-001 CRDT 原理与分类

参考资源：

Yjs Architecture

口头回答版：

实时协同文档系统前端用 CRDT 运行时，WebSocket 网关管连接，协同服务做路由和持久化。数据模型按 Block 组织，操作日志分片存储。冲突用 CRDT 最终一致，权限在服务端校验，版本历史用快照加日志回放。大文档按 Block 分片，支持离线编辑。

FB-32-SD-R-002：如何设计一个实时聊天系统？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：32 实时与协同标签：实时聊天、IM、消息队列、离线消息、已读回执 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请设计一个支持单聊、群聊、离线消息的实时聊天系统。

参考答案：

架构：

客户端：消息 UI + 本地数据库（IndexedDB/SQLite）+ WebSocket 连接。
接入网关：WebSocket 网关，维护用户-连接映射。
消息服务：处理发送、路由、存储、推送。
消息队列：Kafka/RocketMQ 做异步解耦和削峰。
存储：
- 消息表：按会话分片，存储消息内容、时间、状态。
- 会话列表表：存储最近会话、未读数、置顶。
- 离线消息队列/未读信箱。

核心流程：

发送消息：客户端 -> 网关 -> 消息服务 -> 持久化 -> 推送给在线接收方/写入离线信箱。
已读回执：接收方读消息后发送 ack，服务端更新已读状态并通知发送方。
离线补推：用户上线后拉取未读消息。

设计要点：

消息全局唯一 ID，保证顺序与去重。
单聊可优化为双写（给双方各写一份）。
群聊按群 ID 分片，大群使用扩散写或读扩散权衡。
富媒体消息先上传对象存储，消息体存 URL。

扩展性：

网关无状态，连接状态存 Redis。
消息服务水平扩展，按会话 ID 路由。
热群单独分片。

评分维度：

架构完整（30%）：客户端、网关、服务、队列、存储
消息流程（30%）：发送、推送、离线、已读
扩展性（20%）：无状态、分片、热群处理
体验（20%）：顺序、去重、富媒体

常见错误：

所有消息都实时推送，未考虑离线存储。
大群消息直接广播给所有在线成员，单节点负载过高。

延伸追问：

如何实现消息撤回和删除？
群聊人数达到 10 万时如何设计？

相关题目：

FB-32-CO-A-005 实时消息队列设计
FB-32-CO-B-008 用户离线消息处理

参考资源：

Designing WhatsApp

口头回答版：

实时聊天系统前端连 WebSocket 网关，消息服务处理路由和存储，消息队列削峰。消息全局唯一 ID 保证顺序去重，单聊双写，群聊按群 ID 分片，大群要扩散写或读扩散。离线消息写未读信箱，上线补推。已读回执异步更新。

FB-32-SD-R-003：如何设计一个实时视频会议系统？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：32 实时与协同标签：视频会议、WebRTC、MCU、SFU、媒体路由 出现频率：高频 预计回答时长：10-15 分钟

题目描述：请设计一个支持多人音视频会议的系统，说明媒体路由方案、信令、屏幕共享和录制。

参考答案：

架构：

客户端：音视频采集 + WebRTC + UI。
信令服务器：房间管理、SDP/ICE 交换。
媒体服务器：MCU（混音合屏）或 SFU（选择性转发）。
TURN 服务器：NAT 中继。
录制/直播服务：接收媒体流后录制或转推 CDN。

媒体路由方案：

Mesh：每个端与其他端直接 P2P，适合 3-4 人。
MCU：服务端合成一路音视频，客户端只订阅合流，CPU 消耗大，延迟略高。
SFU：服务端只转发，不混音，客户端按需订阅，支持 Simulcast/SVC，适合大规模会议。

现代方案通常采用 SFU：

上行一路或多路（Simulcast）。
下行按需订阅，带宽自适应。

屏幕共享：

作为独立视频轨道发送。
通常优先保证清晰度和帧率，可牺牲延迟。

录制：

服务端录制：稳定，适合合规。
客户端录制：简单但依赖本地性能。

其他要点：

噪声抑制、回声消除（AEC/NS/AGC）。
弱网降码率、丢包重传（NACK/FEC）。

评分维度：

架构完整（30%）：客户端、信令、媒体、TURN、录制
路由方案（30%）：Mesh/MCU/SFU 选型
高级特性（20%）：屏幕共享、Simulcast、弱网优化
录制合规（20%）：服务端录制、存储

常见错误：

多人会议仍用 Mesh，导致客户端上行带宽爆炸。
忽视弱网场景下的音视频体验。

延伸追问：

SFU 如何支持千人会议？
视频会议中的端到端加密如何实现？

相关题目：

FB-32-CO-A-003 WebRTC 信令服务器设计
FB-32-CO-P-004 WebRTC TURN 与媒体协商

参考资源：

WebRTC SFU Architecture

口头回答版：

视频会议系统客户端用 WebRTC，信令服务器管理房间和交换 SDP/ICE，媒体服务器用 SFU 转发。3-4 人可用 Mesh，多人用 SFU 加 Simulcast。TURN 处理 NAT 不通。屏幕共享单独轨道，服务端录制满足合规。还要做回声消除、弱网降码。

FB-32-SD-R-004：实时系统与离线同步如何结合？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：32 实时与协同标签：离线优先、本地优先、同步、CRDT、冲突解决 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个既支持实时协同又支持离线编辑的系统，说明本地存储、同步协议和冲突解决策略。

参考答案：

设计原则：

本地优先：用户操作先写本地，再异步同步到服务端。
乐观更新：本地立即反馈，失败时回滚或提示。
最终一致：联网后合并本地与服务端状态。

本地存储：

使用 IndexedDB/SQLite 保存操作日志和快照。
定期压缩日志，生成快照减少回放时间。

同步协议：

操作日志同步：本地记录所有操作，联网后按因果顺序发送。
状态同步：基于版本向量或 lastSyncId，只拉取差异。
双向合并：服务端把本地操作广播给其他客户端，并把其他客户端操作推给本地。

冲突解决：

文本/列表使用 CRDT（如 Yjs）。
结构化数据使用 LWW、版本向量或用户介入。
对不能自动合并的冲突提供 diff 视图。

边界处理：

多设备登录时的同步顺序。
长时间离线导致操作日志过大，需要快照截断。
敏感操作需联网确认后才能生效。

评分维度：

本地优先（30%）：先本地、乐观更新
同步协议（30%）：操作日志、差异同步、版本向量
冲突解决（30%）：CRDT、LWW、用户介入
边界处理（10%）：多设备、日志截断

常见错误：

离线编辑后直接用服务端覆盖本地，丢失用户数据。
不处理离线期间其他端产生的大量操作。

延伸追问：

本地数据被用户清除后如何恢复？
离线编辑内容涉及权限变更怎么办？

相关题目：

FB-32-CO-A-007 网络分区处理
FB-32-SD-R-001 设计实时协同文档

参考资源：

Local-First Software

口头回答版：

离线优先系统要先写本地再异步同步，用 IndexedDB 存操作日志和快照。同步时按版本向量拉差异，双向合并。冲突用 CRDT 或 LWW，无法自动合并时让用户选。要处理多设备、日志过大、敏感操作需联网确认等问题。

FB-32-SD-R-005：如何设计一个实时协同白板？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：32 实时与协同标签：协同白板、图形同步、CRDT、Canvas、Presence 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计一个支持多人同时绘制、拖拽、缩放的实时协同白板系统。

参考答案：

数据模型：

每个图形元素有唯一 ID、类型、坐标、样式、CRDT 属性。
页面/画布由元素集合组成，使用 CRDT Map/Set 管理。

同步策略：

元素级 CRDT：每个元素的属性（位置、大小、颜色）使用 LWW-Register 或 MV-Register。
操作广播：新增、删除、移动、缩放作为操作广播。
差异同步：首次加载拉取快照，后续同步操作日志。

渲染优化：

使用 Canvas 或 WebGL 渲染大量元素。
仅重绘变化区域（脏矩形）。
对可视区域外元素做裁剪或分层。

交互协同：

光标/选区同步：节流 + 插值。
锁定机制：用户选中元素时临时锁定，防止同时编辑同一元素。
撤销/重做：基于操作日志回放。

扩展性：

大画布按空间区域分片，客户端只订阅可视区域。
使用空间索引（R-tree/四叉树）加速碰撞检测。

评分维度：

数据模型（30%）：元素 CRDT、集合管理
同步策略（30%）：操作广播、差异同步
渲染优化（20%）：Canvas、脏矩形、裁剪
协同体验（20%）：光标、锁定、撤销

常见错误：

把整个画布作为位图同步，导致冲突无法合并。
不处理元素同时被多人移动的竞争。

延伸追问：

白板无限缩放时坐标精度如何保证？
如何实现白板内容的搜索？

相关题目：

FB-32-CO-A-006 实时白板光标同步
FB-32-CO-P-002 光标/选区同步难点

参考资源：

Figma Engineering Blog

口头回答版：

协同白板每个元素有唯一 ID 和 CRDT 属性，操作广播同步。渲染用 Canvas 或 WebGL，脏矩形重绘，按可视区域分片。光标节流插值，选中元素可临时锁定，撤销基于操作日志。大画布用空间索引加速。

FB-32-SD-R-006：实时系统的监控与降级策略如何设计？

题型：系统设计题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：32 实时与协同标签：实时系统、监控、降级、熔断、可观测性 出现频率：中频 预计回答时长：10-15 分钟

题目描述：请设计实时系统的监控体系和降级预案，确保高可用。

参考答案：

监控体系：

连接层：在线连接数、连接/断开速率、重连率、心跳超时率。
消息层：QPS、延迟 P99、丢包率、消息堆积、ACK 延迟。
业务层：房间数、人均消息量、错误率、异常操作。
资源层：CPU、内存、带宽、文件描述符、GC。
用户体验：首屏加载时间、操作到同步的延迟、卡顿率。

告警：

P0：大量连接断开、消息服务不可用。
P1：消息延迟突增、丢包率超过阈值。
P2：资源使用率高、异常重连。

降级策略：

限流：对单用户/单房间消息限流，防止刷屏。
熔断：下游服务异常时停止非关键推送。
功能降级：
- 关闭光标同步，只保留内容同步。
- 大房间禁用实时聊天，改为轮询。
- 关闭历史消息加载，只提供最新数据。
扩容：连接数达到阈值自动扩容网关。
隔离：把异常房间/用户迁移到独立节点。

预案演练：

定期模拟机房故障、网络分区、消息队列阻塞。
明确 SOP 和 on-call 流程。

评分维度：

监控覆盖（30%）：连接、消息、业务、资源、体验
告警分级（20%）：P0/P1/P2
降级策略（40%）：限流、熔断、功能降级、扩容
演练机制（10%）：预案、SOP

常见错误：

只监控服务器资源，不监控端到端消息延迟。
降级方案影响核心功能，导致业务不可用。

延伸追问：

如何评估降级对用户体验的影响？
消息队列阻塞时如何快速恢复？

相关题目：

FB-30-SD-R-001 可观测性体系设计
FB-32-PE-P-001 实时系统水平扩展

参考资源：

Google SRE Book

口头回答版：

实时系统要监控连接、消息、业务、资源和用户体验，按 P0/P1/P2 告警。降级包括限流、熔断、关闭光标等非核心功能、轮询替代、自动扩容和隔离异常房间。还要定期演练预案。

FB-32-CP-R-001：多端实时状态一致性如何保证？

题型：综合开放题难度：🔴 架构 岗位层级：架构 / 专家 面试知识域：32 实时与协同标签：多端同步、状态一致性、CRDT、乐观更新、最终一致 出现频率：中频 预计回答时长：10-15 分钟

题目描述：用户可能在 Web、App、小程序等多端同时使用同一账号。请设计多端实时状态一致方案。

参考答案：

核心挑战：

多端同时在线，操作可能并发。
网络状态不同，有的在线有的离线。
不同端能力差异（推送、存储、渲染）。

方案：

统一状态源：
- 服务端作为权威状态源，所有变更最终同步到服务端。
操作同步：
- 本地操作即时生效，并发送给服务端。
- 服务端广播给其他端。
冲突合并：
- 使用 CRDT 或版本向量处理并发操作。
- 对结构化状态使用 LWW 或业务规则合并。
推送通道：
- 在线端用 WebSocket/长连接同步。
- 不在线端用 APNS/FCM/厂商推送触发拉取。
本地存储：
- 每端本地缓存状态和操作日志，支持离线使用。
会话管理：
- 同一账号多端登录时，维护会话列表，支持互踢/同步登录态。

一致性级别：

同一端内：强一致（本地立即生效）。
多端之间：最终一致，允许短暂差异。

评分维度：

统一状态源（20%）：服务端权威
同步机制（30%）：操作广播、推送、拉取
冲突合并（30%）：CRDT、版本向量、LWW
多端适配（20%）：离线、推送、能力差异

常见错误：

各端各自维护状态，不统一合并规则。
离线端上线后直接覆盖服务端状态。

延伸追问：

同一用户多端同时编辑同一文档，如何显示冲突？
小程序和 Web 的推送能力差异如何补齐？

相关题目：

FB-32-SD-R-004 实时与离线同步结合
FB-29-SD-R-001 多端状态一致性

参考资源：

CRDT.tech

口头回答版：

多端一致性要以服务端为权威源，本地操作先生效再同步，服务端广播给其他端。并发用 CRDT 或版本向量合并，在线用 WebSocket，不在线用推送触发拉取。每端本地缓存支持离线。同一端强一致，多端最终一致。

FB-32-SC-B-001：WebSocket 和 SSE 有什么区别？分别适用什么场景？

题型：场景设计题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：CRDT、WebSocket、WebRTC、实时通信、心跳 出现频率：中频 预计回答时长：3-5 分钟

题目描述： WebSocket 和 SSE 有什么区别？分别适用什么场景。

参考答案：

特性	WebSocket	SSE
方向	双向	服务端 → 客户端
协议	ws/wss	HTTP
自动重连	需手动实现	浏览器原生支持
适用	聊天、游戏、协同编辑	推送、行情、通知

补充说明：

在实际落地 WebSocket 和 SSE 有什么区别分别适用什么场景时，建议结合 CRDT、WebSocket、WebRTC 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

方向区别（30%）
协议区别（20%）
场景举例（40%）
重连机制（10%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

| 特性 | WebSocket | SSE | |------|-----------|-----| | 方向 | 双向 | 服务端 → 客户端 | | 协议 | ws/wss | HTTP | | 自动重连 | 需手动实现 | 浏览器原生支持 | | 适用 | 聊天、游戏、协同编辑 | 推送、行情、通知 |

FB-32-SD-B-001：如何设计 WebSocket 重连机制？

题型：系统设计题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：CRDT、WebSocket、WebRTC、实时通信、心跳 出现频率：中频 预计回答时长：3-5 分钟

题目描述：如何设计 WebSocket 重连机制。

参考答案：

监听 onclose/onerror 触发重连。
使用指数退避控制重连频率。
设置最大重试次数或无限重试。
断线期间缓存待发送消息。
重连后恢复房间状态、补发未确认消息。

补充说明：

在实际落地设计 WebSocket 重连机制时，建议结合 CRDT、WebSocket、WebRTC 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 补充说明：

在实际落地设计 WebSocket 重连机制时，建议结合 CRDT、WebSocket、WebRTC 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

触发条件（20%）
退避策略（30%）
消息缓存（25%）
状态恢复（25%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

监听 onclose/onerror 触发重连。 - 使用指数退避控制重连频率。 - 设置最大重试次数或无限重试。 - 断线期间缓存待发送消息。

FB-32-CP-B-001：什么是 CRDT？与 OT 有什么区别？

题型：综合开放题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时与协同标签：CRDT、WebSocket、WebRTC、实时通信、心跳 出现频率：中频 预计回答时长：3-5 分钟

题目描述：什么是 CRDT？与 OT 有什么区别。

参考答案：

CRDT 是具有数学特性的数据结构，允许多个副本独立修改并最终一致。OT 需要中央服务器对操作进行变换。

CRDT 更适合离线优先、去中心化场景；OT 适合强一致、中心化场景。

补充说明：

在实际落地 CRDT与 OT 有什么区别时，建议结合 CRDT、WebSocket、WebRTC 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

解释 CRDT（40%）
解释 OT（30%）
选型对比（30%）

二、进阶题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

CRDT 是具有数学特性的数据结构，允许多个副本独立修改并最终一致。 OT 需要中央服务器对操作进行变换。 CRDT 更适合离线优先、去中心化场景；OT 适合强一致、中心化场景。

FB-32-CO-A-008：WebSocket 集群如何实现跨节点广播？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 资深 面试知识域：32 实时与协同标签：CRDT、WebSocket、WebRTC、实时通信、心跳 出现频率：中频 预计回答时长：5-8 分钟

题目描述： WebSocket 集群如何实现跨节点广播。

参考答案：

使用 Redis Pub/Sub、RabbitMQ 等消息中间件。
每个 WebSocket 节点订阅房间频道。
消息发送到中间件，所有订阅节点转发给本地连接。
或使用 sticky session 将同一房间用户路由到同一节点。

补充说明：

在实际落地 WebSocket 集群如何实现跨节点广播时，建议结合 CRDT、WebSocket、WebRTC 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

中间件方案（40%）
订阅机制（30%）
扩展性考虑（30%）

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

使用 Redis Pub/Sub、RabbitMQ 等消息中间件。 - 每个 WebSocket 节点订阅房间频道。 - 消息发送到中间件，所有订阅节点转发给本地连接。 - 或使用 sticky session 将同一房间用户路由到同一节点。

FB-32-CO-A-009：实时系统的可观测性应关注哪些指标？

题目描述：实时系统的可观测性应关注哪些指标。

参考答案：

连接数、在线用户数。
消息延迟（端到端）。
断线率、重连成功率。
消息丢失率/重复率。
服务端资源使用（CPU、内存、带宽）。

补充说明：

在实际落地实时系统的可观测性应关注哪些指标时，建议结合 CRDT、WebSocket、WebRTC 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

连接相关指标（30%）
消息质量指标（40%）
资源指标（20%）
告警机制（10%）

三、高级题

常见错误：

回答停留在定义复述，缺少真实项目中的取舍与折中。
只讲正常路径，不提超时、降级、兼容等边界情况。
对关键指标和取舍缺乏量化意识。

口头回答版：

连接数、在线用户数。 - 消息延迟（端到端）。 - 断线率、重连成功率。 - 消息丢失率/重复率。

FB-32-CO-B-009：WebSocket 与 HTTP 长轮询的区别

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时系统标签：WebSocket、长轮询、实时、SSE、通信 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请比较 WebSocket、SSE 和长轮询的特点和适用场景。

参考答案：

核心思路如下：

WebSocket：全双工、低延迟、适合高频双向通信
SSE：服务器单向推送，基于 HTTP，自动重连
长轮询：兼容性好，但实时性差、开销大
WebSocket 适合聊天、游戏、协作
SSE 适合股票行情、日志流、通知

需要避免的典型误区：

所有实时场景都用 WebSocket
忽略 WebSocket 代理和防火墙
长轮询不设置超时

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：WebSocket、SSE 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有实时场景都用 WebSocket
忽略 WebSocket 代理和防火墙
长轮询不设置超时

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

WebSocket；SSE；长轮询；WebSocket 适合聊天、游戏、协作；SSE 适合股票行情、日志流、通知。同时要避免所有实时场景都用 WebSocket。

FB-32-CO-A-010：WebSocket 连接管理要点

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：WebSocket、重连、心跳、状态、管理 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明生产环境使用 WebSocket 需要管理的连接问题。

参考答案：

核心思路如下：

连接建立、断开、重连机制
心跳检测：防止中间件超时断开
重连策略：指数退避、最大重试次数
消息队列：断线期间消息暂存
连接状态暴露给 UI
多标签页避免重复连接

需要避免的典型误区：

断线不重连
无心跳导致假死
重连风暴

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：连接建立、断开、重连机制、心跳检测等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

断线不重连
无心跳导致假死
重连风暴

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

连接建立、断开、重连机制；心跳检测；重连策略；消息队列；连接状态暴露给 UI；多标签页避免重复连接。同时要避免断线不重连。

FB-32-SC-A-001：设计一个实时消息推送系统

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：实时、推送、WebSocket、SSE、消息队列 出现频率：高频 预计回答时长：8-15 分钟

题目描述：请设计一个支持百万在线用户的实时消息推送系统前端架构。

参考答案：

核心思路如下：

连接层：WebSocket 网关负责长连接管理
接入层：按用户/房间分组，支持广播、组播、单播
消息协议：JSON/Protobuf，包含 id、type、timestamp、seq
客户端：连接管理、消息去重、顺序保证、离线缓存
降级：WebSocket 不可用降级到 SSE/长轮询
监控：连接数、消息延迟、丢包率

需要避免的典型误区：

每个用户一条独立连接但无网关
消息无序号导致乱序
无降级策略

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：连接层、接入层等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

每个用户一条独立连接但无网关
消息无序号导致乱序
无降级策略

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

连接层；接入层；消息协议；客户端；降级；监控。同时要避免每个用户一条独立连接但无网关。

FB-32-CO-P-005：实时系统中的消息顺序与一致性

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：32 实时系统标签：顺序、一致性、seq、CRDT、OT、实时 出现频率：中频 预计回答时长：8-15 分钟

题目描述：请说明实时系统中如何保证消息顺序和最终一致性。

参考答案：

核心思路如下：

服务端生成单调递增 seq 或时间戳
客户端按 seq 排序，缺号时补拉
版本向量处理并发冲突
CRDT/OT 用于协作编辑等强一致性场景
容忍短暂不一致，关键操作二次确认

需要避免的典型误区：

依赖客户端时间戳排序
不处理消息丢失
对最终一致场景追求强一致

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：服务端生成单调递增 seq 或时间戳、客户端按 seq 排序，缺号时补拉等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

依赖客户端时间戳排序
不处理消息丢失
对最终一致场景追求强一致

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

服务端生成单调递增 seq 或时间戳；客户端按 seq 排序，缺号时补拉；版本向量处理并发冲突；CRDT/OT 用于协作编辑等强一致性场景；容忍短暂不一致，关键操作二次确认。同时要避免依赖客户端时间戳排序。

FB-32-SC-P-001：网络分区对实时系统的影响

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：32 实时系统标签：网络分区、离线、重连、消息队列、一致性 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请分析网络分区时实时应用前端应如何处理。

参考答案：

核心思路如下：

检测：心跳超时、发送失败
本地缓存未发送消息
重连后同步离线期间的操作
冲突解决：LWW、业务合并、用户选择
UI 提示用户当前连接状态

需要避免的典型误区：

断线时直接报错
重连后消息重复
忽略本地操作丢失

补充说明：

在实际落地网络分区对实时系统的影响时，建议结合网络分区、离线、重连的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：检测、本地缓存未发送消息等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

断线时直接报错
重连后消息重复
忽略本地操作丢失

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

检测；本地缓存未发送消息；重连后同步离线期间的操作；冲突解决；UI 提示用户当前连接状态。同时要避免断线时直接报错。

FB-32-SD-R-007：设计一个实时协作白板

题型：系统设计题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：32 实时系统标签：实时协作、白板、CRDT、WebSocket、性能 出现频率：中频 预计回答时长：15-30 分钟

题目描述：请设计一个多人实时协作白板的前端架构。

参考答案：

核心思路如下：

数据模型：图元对象、图层、操作历史
同步协议：基于 CRDT 或 OT 的操作转换
传输：WebSocket 广播操作，本地先执行再同步
渲染：Canvas 或 SVG，增量更新
冲突处理：CRDT 天然合并，OT 需服务端协调
presence：光标、选区、用户头像
历史与撤销：操作日志 + 版本向量

需要避免的典型误区：

直接传输完整状态
不做操作去重
忽略离线编辑

补充说明：

在实际落地设计一个实时协作白板时，建议结合实时协作、白板、CRDT 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据模型、同步协议等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

直接传输完整状态
不做操作去重
忽略离线编辑

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据模型；同步协议；传输；渲染；冲突处理； presence；历史与撤销。同时要避免直接传输完整状态。

FB-32-CO-A-011：SSE 的优缺点与使用限制

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：SSE、服务器推送、HTTP、单向、限制 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 SSE 的适用场景和限制。

参考答案：

核心思路如下：

优点：基于 HTTP、自动重连、支持事件 ID
缺点：只能服务器向客户端推送，浏览器连接数限制
适合：通知、日志、股票、监控数据流
限制：每个源连接数受限，HTTP/2 可缓解
需要设置正确的 MIME 类型和事件格式

需要避免的典型误区：

需要双向通信却用 SSE
不处理重连后事件 ID
忽略浏览器连接数限制

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：优点、缺点等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

需要双向通信却用 SSE
不处理重连后事件 ID
忽略浏览器连接数限制

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

优点；缺点；适合；限制；需要设置正确的 MIME 类型和事件格式。同时要避免需要双向通信却用 SSE。

FB-32-SC-A-002：实时系统中的心跳设计

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：心跳、WebSocket、超时、重连、保活 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计 WebSocket 心跳机制。

参考答案：

核心思路如下：

客户端定时发送 ping，服务端回复 pong
超过一定时间未收到响应判定断线
心跳间隔应小于代理/网关超时时间
断线后按指数退避重连
后台标签页可降低心跳频率省电

需要避免的典型误区：

心跳间隔过长被代理断开
没有 pong 确认机制
重连过于频繁

补充说明：

在实际落地实时系统中的心跳设计时，建议结合心跳、WebSocket、超时的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：客户端定时发送 ping，服务端回复 pong、超过一定时间未收到响应判定断线等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

心跳间隔过长被代理断开
没有 pong 确认机制
重连过于频繁

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

客户端定时发送 ping，服务端回复 pong；超过一定时间未收到响应判定断线；心跳间隔应小于代理/网关超时时间；断线后按指数退避重连；后台标签页可降低心跳频率省电。同时要避免心跳间隔过长被代理断开。

FB-32-PE-A-001：实时系统前端性能优化

题型：性能优化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：实时、性能、节流、批量、渲染 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明高频率实时数据更新的前端性能优化手段。

参考答案：

核心思路如下：

节流/防抖：高频数据批量更新
批量 DOM 更新，避免每帧 setState
使用 requestAnimationFrame 对齐渲染
虚拟化长列表
数据采样：可视区外降低精度
Web Worker 处理数据解析

需要避免的典型误区：

每条消息都触发渲染
UI 线程被数据更新占满
不区分可见区域

补充说明：

在实际落地实时系统前端性能优化时，建议结合实时、性能、节流的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：节流/防抖、批量 DOM 更新，避免每帧 setState 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

每条消息都触发渲染
UI 线程被数据更新占满
不区分可见区域

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

节流/防抖；批量 DOM 更新，避免每帧 setState；使用 requestAnimationFrame 对齐渲染；虚拟化长列表；数据采样；Web Worker 处理数据解析。同时要避免每条消息都触发渲染。

FB-32-CO-P-006：什么是操作转换 OT 与 CRDT

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：32 实时系统标签：OT、CRDT、协作、并发、一致性 出现频率：中频 预计回答时长：8-15 分钟

题目描述：请比较 OT 和 CRDT 在实时协作中的应用。

参考答案：

核心思路如下：

OT：操作在服务端转换，保证一致性，依赖中心服务器
CRDT：无中心，本地合并，适合点对点
OT 实现复杂但成熟，如 Google Docs
CRDT 更适合去中心化、离线优先
选型：强中心用 OT，多端离线用 CRDT

需要避免的典型误区：

CRDT 数据模型设计不当导致冲突
OT 无服务器协调
忽略两者存储开销

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：OT、CRDT 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

CRDT 数据模型设计不当导致冲突
OT 无服务器协调
忽略两者存储开销

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

OT；CRDT；OT 实现复杂但成熟，如 Google Docs；CRDT 更适合去中心化、离线优先；选型。同时要避免CRDT 数据模型设计不当导致冲突。

FB-32-SC-A-003：实时聊天前端架构设计

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：聊天、WebSocket、消息、历史、未读 出现频率：高频 预计回答时长：8-15 分钟

题目描述：请设计一个实时聊天应用的前端架构。

参考答案：

核心思路如下：

消息分层：本地消息、历史消息、实时消息
WebSocket 维护连接，接收/发送消息
消息状态：发送中、已发送、已送达、已读
历史分页加载，本地缓存最近消息
未读计数、消息提醒、多设备同步
富文本与图片安全过滤

需要避免的典型误区：

所有消息都重新拉取
消息状态不一致
断线后消息丢失

补充说明：

在实际落地实时聊天前端架构设计时，建议结合聊天、WebSocket、消息的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：消息分层、WebSocket 维护连接，接收/发送消息等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有消息都重新拉取
消息状态不一致
断线后消息丢失

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

消息分层；WebSocket 维护连接，接收/发送消息；消息状态；历史分页加载，本地缓存最近消息；未读计数、消息提醒、多设备同步；富文本与图片安全过滤。同时要避免所有消息都重新拉取。

FB-32-FS-A-001：实时消息延迟高如何排查

题型：故障排查题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：实时、延迟、排查、网络、服务端 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请给出实时消息延迟高的排查思路。

参考答案：

核心思路如下：

区分客户端渲染延迟与网络传输延迟
测量各阶段耗时：发送 -> 服务端 -> 广播 -> 接收
检查 WebSocket 是否被降级为轮询
查看网络质量、丢包、重连
服务端检查消息队列和广播延迟
前端检查是否有批量渲染阻塞

需要避免的典型误区：

只看端到端总延迟
忽略服务端广播延迟
未记录消息时间戳

补充说明：

在实际落地实时消息延迟高如何排查时，建议结合实时、延迟、排查的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：区分客户端渲染延迟与网络传输延迟、测量各阶段耗时等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

只看端到端总延迟
忽略服务端广播延迟
未记录消息时间戳

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

区分客户端渲染延迟与网络传输延迟；测量各阶段耗时；检查 WebSocket 是否被降级为轮询；查看网络质量、丢包、重连；服务端检查消息队列和广播延迟；前端检查是否有批量渲染阻塞。同时要避免只看端到端总延迟。

FB-32-SC-P-002：实时系统中如何做消息去重

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：32 实时系统标签：去重、消息 ID、幂等、顺序、实时 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计实时消息去重机制。

参考答案：

核心思路如下：

每条消息带全局唯一 id 或 seq
客户端维护已接收 id 集合
重连后根据 lastSeq 拉取缺失消息
幂等处理：同一消息多次处理结果一致
清理过期 id 防止内存无限增长

需要避免的典型误区：

用时间戳做唯一标识
不重连补漏直接丢弃
去重集合无上限

补充说明：

在实际落地实时系统中如何做消息去重时，建议结合去重、消息 ID、幂等的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：每条消息带全局唯一 id 或 seq、客户端维护已接收 id 集合等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

用时间戳做唯一标识
不重连补漏直接丢弃
去重集合无上限

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

每条消息带全局唯一 id 或 seq；客户端维护已接收 id 集合；重连后根据 lastSeq 拉取缺失消息；幂等处理；清理过期 id 防止内存无限增长。同时要避免用时间戳做唯一标识。

FB-32-CO-A-012：实时系统中如何处理 Presence

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：Presence、在线状态、心跳、WebSocket、用户 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明实时应用中的在线状态（Presence）设计。

参考答案：

核心思路如下：

服务端维护用户在线状态
心跳机制检测在线/离线
延迟上线/下线避免频繁抖动
多设备登录状态合并
隐私：不在线用户不暴露详细状态

需要避免的典型误区：

仅依赖 WebSocket 连接状态
上线下线过于敏感频繁变化
多设备状态不一致

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：服务端维护用户在线状态、心跳机制检测在线/离线等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

仅依赖 WebSocket 连接状态
上线下线过于敏感频繁变化
多设备状态不一致

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

服务端维护用户在线状态；心跳机制检测在线/离线；延迟上线/下线避免频繁抖动；多设备登录状态合并；隐私。同时要避免仅依赖 WebSocket 连接状态。

FB-32-SD-R-008：设计一个实时数据可视化大屏

题型：系统设计题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：32 实时系统标签：实时、数据可视化、WebSocket、性能、Canvas 出现频率：中频 预计回答时长：8-15 分钟

题目描述：请设计一个高频实时数据的可视化大屏。

参考答案：

核心思路如下：

数据接入层通过 WebSocket 或 SSE 与后端建立长连接，按业务主题订阅；断线时自动重连并补录缺失窗口数据。
在客户端设置环形缓冲区和时间窗口聚合器，对高频原始数据做降采样、滑动平均或最大值保留，避免每帧都渲染全量点。
渲染层根据数据规模选择 Canvas 2D、OffscreenCanvas 或 WebGL；对静态背景分层缓存，仅更新变化区域，使用 requestAnimationFrame 批量绘制。
视图更新策略采用增量更新 + 脏矩形检测，合并同一帧内的多次数据变更；对趋势图、热力图等使用合适的可视编码。
交互与告警：支持阈值告警、异常高亮、下钻联动；通过 Web Worker 做数据预处理，防止阻塞主线程。
稳定性保障：心跳检测、断线提示、降级为轮询、历史数据回放；配合监控埋点观察帧率、内存与延迟。

需要避免的典型误区：

每帧都全量重绘
数据不采样导致卡顿
断线后数据空洞

补充说明：

在实际落地设计一个实时数据可视化大屏时，建议结合实时、数据可视化、WebSocket 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：数据接入、数据缓冲与采样等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

每帧都全量重绘
数据不采样导致卡顿
断线后数据空洞

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

数据接入；数据缓冲与采样；渲染；更新策略；断线重连与历史补录；告警阈值与异常高亮。同时要避免每帧都全量重绘。

FB-32-CO-P-007：WebRTC 在前端实时系统中的应用

题型：概念题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：32 实时系统标签：WebRTC、P2P、音视频、数据通道、实时 出现频率：低频 预计回答时长：5-8 分钟

题目描述：请说明 WebRTC 的适用场景及前端需要处理的问题。

参考答案：

核心思路如下：

适用：音视频通话、P2P 数据传输、低延迟直播
需要信令服务器建立连接
处理 NAT 穿透、ICE、STUN/TURN
前端处理权限、设备选择、码率适配
信令与媒体分离设计

需要避免的典型误区：

认为 WebRTC 完全无服务端
忽略网络穿透
不做音视频降级

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：适用、需要信令服务器建立连接等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

认为 WebRTC 完全无服务端
忽略网络穿透
不做音视频降级

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

适用；需要信令服务器建立连接；处理 NAT 穿透、ICE、STUN/TURN；前端处理权限、设备选择、码率适配；信令与媒体分离设计。同时要避免认为 WebRTC 完全无服务端。

FB-32-SC-A-004：实时系统中如何做限流与降级

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：限流、降级、实时、消息、频率 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计实时系统的客户端限流与服务端降级策略。

参考答案：

核心思路如下：

客户端限流：发送频率限制、合并操作
服务端限流：按用户/房间限速
降级：高负载时降低消息频率或采样率
非关键消息延迟发送
通知用户当前处于降级模式

需要避免的典型误区：

无限制发送消息
服务端过载不降级
限流导致用户体验极差

补充说明：

在实际落地实时系统中如何做限流与降级时，建议结合限流、降级、实时的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：客户端限流、服务端限流等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

无限制发送消息
服务端过载不降级
限流导致用户体验极差

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

客户端限流；服务端限流；降级；非关键消息延迟发送；通知用户当前处于降级模式。同时要避免无限制发送消息。

FB-32-CO-A-013：长连接服务端的推送策略

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：推送、长连接、广播、房间、分组 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明服务端如何高效向客户端推送消息。

参考答案：

核心思路如下：

按用户/房间/ topic 分组管理连接
广播时只发给相关连接
消息合并：同一房间多条更新合并推送
优先级：重要消息优先发送
失败重试与离线补偿

需要避免的典型误区：

全量广播所有连接
每条消息都单独推送
不考虑离线用户

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：按用户/房间/ topic 分组管理连接、广播时只发给相关连接等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

全量广播所有连接
每条消息都单独推送
不考虑离线用户

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

按用户/房间/ topic 分组管理连接；广播时只发给相关连接；消息合并；优先级；失败重试与离线补偿。同时要避免全量广播所有连接。

FB-32-PE-P-003：实时列表的渲染优化

题型：性能优化题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：32 实时系统标签：实时列表、虚拟化、DOM、渲染、性能 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明实时消息列表的渲染优化方案。

参考答案：

核心思路如下：

虚拟滚动只渲染可视区
批量插入新消息
新消息动画不阻塞列表滚动
历史消息分页懒加载
高亮@自己的消息不频繁重排

需要避免的典型误区：

上万条消息全部渲染
每条新消息都插入动画
频繁滚动到底部

补充说明：

在实际落地实时列表的渲染优化时，建议结合实时列表、虚拟化、DOM 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：虚拟滚动只渲染可视区、批量插入新消息等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

上万条消息全部渲染
每条新消息都插入动画
频繁滚动到底部

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

虚拟滚动只渲染可视区；批量插入新消息；新消息动画不阻塞列表滚动；历史消息分页懒加载；高亮@自己的消息不频繁重排。同时要避免上万条消息全部渲染。

FB-32-SC-P-003：实时系统中的断线补偿策略

题型：场景设计题难度：🟣 深入 岗位层级：高级 / 资深 面试知识域：32 实时系统标签：断线、补偿、重连、消息队列、同步 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计断线重连后的数据补偿机制。

参考答案：

核心思路如下：

记录最后接收的消息 seq/ID
重连后发送 lastSeq 请求补漏
服务端返回缺失消息
本地操作队列在重连后批量同步
冲突时按业务规则合并或提示用户

需要避免的典型误区：

重连后直接丢弃历史消息
不记录 lastSeq
补偿消息与本地操作冲突未处理

补充说明：

在实际落地实时系统中的断线补偿策略时，建议结合断线、补偿、重连的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：记录最后接收的消息 seq/ID、重连后发送 lastSeq 请求补漏等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

重连后直接丢弃历史消息
不记录 lastSeq
补偿消息与本地操作冲突未处理

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

记录最后接收的消息 seq/ID；重连后发送 lastSeq 请求补漏；服务端返回缺失消息；本地操作队列在重连后批量同步；冲突时按业务规则合并或提示用户。同时要避免重连后直接丢弃历史消息。

FB-32-CP-R-002：实时系统的架构演进路径

题型：综合开放题难度：🔴 架构 岗位层级：架构师 / 专家 面试知识域：32 实时系统标签：实时、演进、长轮询、WebSocket、CRDT 出现频率：低频 预计回答时长：8-15 分钟

题目描述：请说明一个实时系统从简单到复杂的演进路径。

参考答案：

核心思路如下：

阶段一：长轮询满足基本实时性
阶段二：SSE 单向推送
阶段三：WebSocket 双向低延迟
阶段四：引入消息队列、房间、Presence
阶段五：CRDT/OT 支持协作编辑
阶段六：多活、边缘节点、全球加速

需要避免的典型误区：

一开始就上最复杂方案
忽视用户规模和场景
演进无数据支撑

补充说明：

在实际落地实时系统的架构演进路径时，建议结合实时、演进、长轮询的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：阶段一、阶段二等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

一开始就上最复杂方案
忽视用户规模和场景
演进无数据支撑

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

阶段一；阶段二；阶段三；阶段四；阶段五；阶段六。同时要避免一开始就上最复杂方案。

FB-32-CO-B-010：什么是 Socket.IO，它解决了什么问题

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时系统标签：Socket.IO、WebSocket、降级、实时、 rooms 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 Socket.IO 的核心能力。

参考答案：

核心思路如下：

Socket.IO 是基于事件的实时通信库
自动降级：WebSocket -> 长轮询
内置命名空间、房间、广播、重连
跨浏览器兼容性好
适合快速开发实时应用

需要避免的典型误区：

认为 Socket.IO 就是 WebSocket
忽略 rooms 与命名空间设计
过度依赖自动降级

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：Socket.IO 是基于事件的实时通信库、自动降级等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

认为 Socket.IO 就是 WebSocket
忽略 rooms 与命名空间设计
过度依赖自动降级

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

Socket.IO 是基于事件的实时通信库；自动降级；内置命名空间、房间、广播、重连；跨浏览器兼容性好；适合快速开发实时应用。同时要避免认为 Socket.IO 就是 WebSocket。

FB-32-SE-A-001：实时系统中的鉴权与安全

题型：安全题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：实时、鉴权、Token、WebSocket、安全 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明 WebSocket/SSE 连接的鉴权方案。

参考答案：

核心思路如下：

连接建立时通过 URL 参数或 Cookie 传递 Token
优先使用短期 token 或 ticket
连接后定期校验 token 有效期
防止未授权用户加入房间
敏感消息端到端加密

需要避免的典型误区：

Token 长期有效
鉴权逻辑只在 HTTP 握手
房间号可猜测导致越权

补充说明：

在实际落地实时系统中的鉴权与安全时，建议结合实时、鉴权、Token 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：连接建立时通过 URL 参数或 Cookie 传递 Token、优先使用短期 token 或 ticket 等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

Token 长期有效
鉴权逻辑只在 HTTP 握手
房间号可猜测导致越权

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

连接建立时通过 URL 参数或 Cookie 传递 Token；优先使用短期 token 或 ticket；连接后定期校验 token 有效期；防止未授权用户加入房间；敏感消息端到端加密。同时要避免Token 长期有效。

FB-32-SC-A-005：实时系统中的多端一致性

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：多端、一致性、消息同步、未读、状态 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计同一用户在多设备上的实时状态同步方案。

参考答案：

核心思路如下：

服务端维护用户级消息状态
消息已读、未读多端同步
同步协议：拉取增量 + 推送变更
设备间状态以服务端为准
处理设备离线后的状态合并

需要避免的典型误区：

各设备独立维护未读
状态不同步导致消息重复提醒
离线设备上线状态缺失

补充说明：

在实际落地实时系统中的多端一致性时，建议结合多端、一致性、消息同步的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：服务端维护用户级消息状态、消息已读、未读多端同步等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

各设备独立维护未读
状态不同步导致消息重复提醒
离线设备上线状态缺失

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

服务端维护用户级消息状态；消息已读、未读多端同步；同步协议；设备间状态以服务端为准；处理设备离线后的状态合并。同时要避免各设备独立维护未读。

FB-32-CO-B-011：什么是长连接

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：32 实时系统标签：长连接、WebSocket、TCP、HTTP、实时 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释长连接的概念及与短连接的区别。

参考答案：

核心思路如下：

长连接建立后保持，可多次通信
WebSocket 是全双工长连接
HTTP keep-alive 也是长连接但半双工
长连接适合实时、推送场景
需要心跳保活和重连机制

需要避免的典型误区：

认为 HTTP 就是长连接
长连接不管理导致资源泄漏
忽略网络断开

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：长连接建立后保持，可多次通信、WebSocket 是全双工长连接等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

认为 HTTP 就是长连接
长连接不管理导致资源泄漏
忽略网络断开

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

长连接建立后保持，可多次通信；WebSocket 是全双工长连接；HTTP keep-alive 也是长连接但半双工；长连接适合实时、推送场景；需要心跳保活和重连机制。同时要避免认为 HTTP 就是长连接。

FB-32-SC-A-006：实时消息队列前端处理

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：实时、消息队列、WebSocket、消费、ack 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请设计前端消费实时消息队列的方案。

参考答案：

核心思路如下：

维护本地消息队列缓冲
按顺序处理消息，避免乱序
消费确认 ack
失败重试与死信处理
UI 展示处理状态

需要避免的典型误区：

消息处理无队列直接渲染
不确认导致重复
乱序不处理

补充说明：

在实际落地实时消息队列前端处理时，建议结合实时、消息队列、WebSocket 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：维护本地消息队列缓冲、按顺序处理消息，避免乱序等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

消息处理无队列直接渲染
不确认导致重复
乱序不处理

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

维护本地消息队列缓冲；按顺序处理消息，避免乱序；消费确认 ack；失败重试与死信处理；UI 展示处理状态。同时要避免消息处理无队列直接渲染。

FB-32-CO-A-014：WebSocket 心跳机制

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：WebSocket、心跳、ping、pong、超时 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明 WebSocket 心跳的作用。

参考答案：

核心思路如下：

检测连接是否存活
防止中间件超时断开
客户端定时发送 ping，服务端回复 pong
超时未响应触发重连
后台标签页可降低频率

需要避免的典型误区：

无心跳导致假死
心跳过频耗电
只有 ping 无 pong

补充说明：

在实际落地 WebSocket 心跳机制时，建议结合 WebSocket、心跳、ping 的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：检测连接是否存活、防止中间件超时断开等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

无心跳导致假死
心跳过频耗电
只有 ping 无 pong

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

检测连接是否存活；防止中间件超时断开；客户端定时发送 ping，服务端回复 pong；超时未响应触发重连；后台标签页可降低频率。同时要避免无心跳导致假死。

FB-32-PE-A-002：实时数据前端采样

题型：性能优化题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：实时、采样、数据、性能、可视化 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明实时数据流在前端的采样策略。

参考答案：

核心思路如下：

按时间窗口聚合
按可视区域精度采样
丢弃超出显示范围的数据
保留异常点
在缩放时下钻加载细节

需要避免的典型误区：

所有数据点都渲染
采样丢失关键波动
不区分采样层级

补充说明：

在实际落地实时数据前端采样时，建议结合实时、采样、数据的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：按时间窗口聚合、按可视区域精度采样等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

所有数据点都渲染
采样丢失关键波动
不区分采样层级

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

按时间窗口聚合；按可视区域精度采样；丢弃超出显示范围的数据；保留异常点；在缩放时下钻加载细节。同时要避免所有数据点都渲染。

FB-32-SC-A-007：实时白板冲突处理

题型：场景设计题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：白板、实时、冲突、CRDT、OT 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请说明多人协作白板如何合并冲突操作。

参考答案：

核心思路如下：

使用 CRDT 或 OT 算法
本地先执行再同步
操作带唯一 ID 和时间戳
冲突时按业务规则合并
提供用户感知和撤销

需要避免的典型误区：

直接用 LWW
无操作 ID
离线操作丢失

补充说明：

在实际落地实时白板冲突处理时，建议结合白板、实时、冲突的真实场景做验证。重点关注可观测性埋点、异常降级路径和性能基线回归；同时通过灰度发布、指标看板和复盘机制持续迭代，确保方案从“能跑”演进为“可维护、可扩展”。 评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：使用 CRDT 或 OT 算法、本地先执行再同步等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

直接用 LWW
无操作 ID
离线操作丢失

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

使用 CRDT 或 OT 算法；本地先执行再同步；操作带唯一 ID 和时间戳；冲突时按业务规则合并；提供用户感知和撤销。同时要避免直接用 LWW。

FB-32-CO-A-015：SSE 与自动重连

题型：概念题难度：🔵 进阶 岗位层级：中级 / 高级 面试知识域：32 实时系统标签：SSE、自动重连、EventSource、断线 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请说明 SSE 的自动重连机制和如何控制。

参考答案：

核心思路如下：

EventSource 自动在断线后重连
服务端通过 id 字段标记事件
客户端发送 Last-Event-ID 恢复
可自定义重连时间 retry
适合服务器单向推送

需要避免的典型误区：

不处理 id 导致消息重复
重连风暴
需要双向通信却用 SSE

评分维度：

问题理解与分析（35%）：是否抓住核心矛盾
方案设计（45%）：EventSource 自动在断线后重连、服务端通过 id 字段标记事件等关键点
落地与优化（20%）：是否考虑监控、回滚、演进

常见错误：

不处理 id 导致消息重复
重连风暴
需要双向通信却用 SSE

延伸追问：

如果候选人答对了，可追问：能否举一个你实际项目中遇到的具体例子，并说明当时的取舍？
如果候选人答错了，可引导：如果从“稳定性、可维护性、性能”三个维度再看，你还会补充哪些点？

相关题目：

暂无

参考资源：

口头回答版：

EventSource 自动在断线后重连；服务端通过 id 字段标记事件；客户端发送 Last-Event-ID 恢复；可自定义重连时间 retry；适合服务器单向推送。同时要避免不处理 id 导致消息重复。

实时与协同面试题 ​

目录 ​

基础题（8 道） ​

FB-32-CO-B-001：WebSocket、SSE、长轮询分别适用于什么场景？ ​

FB-32-CO-B-002：WebRTC 的核心概念是什么？ ​

FB-32-CO-B-003：实时系统中为什么要做心跳和重连？ ​

FB-32-CO-B-004：如何保证实时消息的顺序和可靠性？ ​

FB-32-CO-B-005：实时系统中的房间/频道模型如何设计？ ​

FB-32-CO-B-006：Presence（在线状态）在实时系统中如何实现？ ​

FB-32-CO-B-007：实时应用有哪些常见的性能优化手段？ ​

FB-32-CO-B-008：实时系统中如何处理用户离线？ ​

进阶题（8 道） ​

FB-32-CO-A-001：WebSocket 心跳与重连机制如何设计？ ​

FB-32-CO-A-002：OT 与 CRDT 有什么区别？协同编辑如何选型？ ​

FB-32-CO-A-003：WebRTC 信令服务器如何设计？ ​

FB-32-CO-A-004：实时系统中的冲突解决有哪些策略？ ​

FB-32-CO-A-005：实时消息队列/发布订阅如何设计？ ​

FB-32-CO-A-006：实时白板中光标/选区同步如何优化？ ​

FB-32-CO-A-007：网络分区对实时系统有什么影响？如何处理？ ​

FB-32-CD-A-001：如何设计一个实时数据看板？ ​

深入题（7 道） ​

FB-32-CO-P-001：CRDT 的原理与分类是什么？ ​

FB-32-CO-P-002：协同编辑中的光标/选区同步有什么难点？ ​

FB-32-PE-P-001：实时系统如何实现水平扩展？ ​

FB-32-CO-P-003：消息去重与幂等如何保证？ ​

FB-32-CO-P-004：WebRTC 中 TURN 和媒体协商的作用是什么？ ​

FB-32-SE-P-001：实时协同中的安全与权限如何设计？ ​

FB-32-PE-P-002：实时数据流中的背压（Backpressure）如何处理？ ​

架构题（42 道） ​

FB-32-SD-R-001：如何设计一个实时协同文档系统？ ​

FB-32-SD-R-002：如何设计一个实时聊天系统？ ​

FB-32-SD-R-003：如何设计一个实时视频会议系统？ ​

FB-32-SD-R-004：实时系统与离线同步如何结合？ ​

FB-32-SD-R-005：如何设计一个实时协同白板？ ​

FB-32-SD-R-006：实时系统的监控与降级策略如何设计？ ​

FB-32-CP-R-001：多端实时状态一致性如何保证？ ​

FB-32-SC-B-001：WebSocket 和 SSE 有什么区别？分别适用什么场景？ ​

FB-32-SD-B-001：如何设计 WebSocket 重连机制？ ​

FB-32-CP-B-001：什么是 CRDT？与 OT 有什么区别？ ​

二、进阶题 ​

FB-32-CO-A-008：WebSocket 集群如何实现跨节点广播？ ​

FB-32-CO-A-009：实时系统的可观测性应关注哪些指标？ ​

三、高级题 ​

FB-32-CO-B-009：WebSocket 与 HTTP 长轮询的区别 ​

FB-32-CO-A-010：WebSocket 连接管理要点 ​

FB-32-SC-A-001：设计一个实时消息推送系统 ​

FB-32-CO-P-005：实时系统中的消息顺序与一致性 ​

FB-32-SC-P-001：网络分区对实时系统的影响 ​

FB-32-SD-R-007：设计一个实时协作白板 ​

FB-32-CO-A-011：SSE 的优缺点与使用限制 ​

FB-32-SC-A-002：实时系统中的心跳设计 ​

FB-32-PE-A-001：实时系统前端性能优化 ​

FB-32-CO-P-006：什么是操作转换 OT 与 CRDT ​

FB-32-SC-A-003：实时聊天前端架构设计 ​

FB-32-FS-A-001：实时消息延迟高如何排查 ​

FB-32-SC-P-002：实时系统中如何做消息去重 ​

FB-32-CO-A-012：实时系统中如何处理 Presence ​

FB-32-SD-R-008：设计一个实时数据可视化大屏 ​

FB-32-CO-P-007：WebRTC 在前端实时系统中的应用 ​

FB-32-SC-A-004：实时系统中如何做限流与降级 ​

FB-32-CO-A-013：长连接服务端的推送策略 ​

FB-32-PE-P-003：实时列表的渲染优化 ​

FB-32-SC-P-003：实时系统中的断线补偿策略 ​

FB-32-CP-R-002：实时系统的架构演进路径 ​

FB-32-CO-B-010：什么是 Socket.IO，它解决了什么问题 ​

FB-32-SE-A-001：实时系统中的鉴权与安全 ​

FB-32-SC-A-005：实时系统中的多端一致性 ​

FB-32-CO-B-011：什么是长连接 ​

FB-32-SC-A-006：实时消息队列前端处理 ​

FB-32-CO-A-014：WebSocket 心跳机制 ​

FB-32-PE-A-002：实时数据前端采样 ​

FB-32-SC-A-007：实时白板冲突处理 ​

FB-32-CO-A-015：SSE 与自动重连 ​

实时与协同面试题

目录

基础题（8 道）

FB-32-CO-B-001：WebSocket、SSE、长轮询分别适用于什么场景？

FB-32-CO-B-002：WebRTC 的核心概念是什么？

FB-32-CO-B-003：实时系统中为什么要做心跳和重连？

FB-32-CO-B-004：如何保证实时消息的顺序和可靠性？

FB-32-CO-B-005：实时系统中的房间/频道模型如何设计？

FB-32-CO-B-006：Presence（在线状态）在实时系统中如何实现？

FB-32-CO-B-007：实时应用有哪些常见的性能优化手段？

FB-32-CO-B-008：实时系统中如何处理用户离线？

进阶题（8 道）

FB-32-CO-A-001：WebSocket 心跳与重连机制如何设计？

FB-32-CO-A-002：OT 与 CRDT 有什么区别？协同编辑如何选型？

FB-32-CO-A-003：WebRTC 信令服务器如何设计？

FB-32-CO-A-004：实时系统中的冲突解决有哪些策略？

FB-32-CO-A-005：实时消息队列/发布订阅如何设计？

FB-32-CO-A-006：实时白板中光标/选区同步如何优化？

FB-32-CO-A-007：网络分区对实时系统有什么影响？如何处理？

FB-32-CD-A-001：如何设计一个实时数据看板？

深入题（7 道）

FB-32-CO-P-001：CRDT 的原理与分类是什么？

FB-32-CO-P-002：协同编辑中的光标/选区同步有什么难点？

FB-32-PE-P-001：实时系统如何实现水平扩展？

FB-32-CO-P-003：消息去重与幂等如何保证？

FB-32-CO-P-004：WebRTC 中 TURN 和媒体协商的作用是什么？

FB-32-SE-P-001：实时协同中的安全与权限如何设计？

FB-32-PE-P-002：实时数据流中的背压（Backpressure）如何处理？

架构题（42 道）

FB-32-SD-R-001：如何设计一个实时协同文档系统？

FB-32-SD-R-002：如何设计一个实时聊天系统？

FB-32-SD-R-003：如何设计一个实时视频会议系统？

FB-32-SD-R-004：实时系统与离线同步如何结合？

FB-32-SD-R-005：如何设计一个实时协同白板？

FB-32-SD-R-006：实时系统的监控与降级策略如何设计？

FB-32-CP-R-001：多端实时状态一致性如何保证？

FB-32-SC-B-001：WebSocket 和 SSE 有什么区别？分别适用什么场景？

FB-32-SD-B-001：如何设计 WebSocket 重连机制？

FB-32-CP-B-001：什么是 CRDT？与 OT 有什么区别？

二、进阶题

FB-32-CO-A-008：WebSocket 集群如何实现跨节点广播？

FB-32-CO-A-009：实时系统的可观测性应关注哪些指标？

三、高级题

FB-32-CO-B-009：WebSocket 与 HTTP 长轮询的区别

FB-32-CO-A-010：WebSocket 连接管理要点

FB-32-SC-A-001：设计一个实时消息推送系统

FB-32-CO-P-005：实时系统中的消息顺序与一致性

FB-32-SC-P-001：网络分区对实时系统的影响

FB-32-SD-R-007：设计一个实时协作白板

FB-32-CO-A-011：SSE 的优缺点与使用限制

FB-32-SC-A-002：实时系统中的心跳设计

FB-32-PE-A-001：实时系统前端性能优化

FB-32-CO-P-006：什么是操作转换 OT 与 CRDT

FB-32-SC-A-003：实时聊天前端架构设计

FB-32-FS-A-001：实时消息延迟高如何排查

FB-32-SC-P-002：实时系统中如何做消息去重

FB-32-CO-A-012：实时系统中如何处理 Presence

FB-32-SD-R-008：设计一个实时数据可视化大屏

FB-32-CO-P-007：WebRTC 在前端实时系统中的应用

FB-32-SC-A-004：实时系统中如何做限流与降级

FB-32-CO-A-013：长连接服务端的推送策略

FB-32-PE-P-003：实时列表的渲染优化

FB-32-SC-P-003：实时系统中的断线补偿策略

FB-32-CP-R-002：实时系统的架构演进路径

FB-32-CO-B-010：什么是 Socket.IO，它解决了什么问题

FB-32-SE-A-001：实时系统中的鉴权与安全

FB-32-SC-A-005：实时系统中的多端一致性

FB-32-CO-B-011：什么是长连接

FB-32-SC-A-006：实时消息队列前端处理

FB-32-CO-A-014：WebSocket 心跳机制

FB-32-PE-A-002：实时数据前端采样

FB-32-SC-A-007：实时白板冲突处理

FB-32-CO-A-015：SSE 与自动重连