实时网络同步核心要点：时间同步、状态同步与一致性方案

1. 实时网络同步的第一课：先分清“同步”到底同步什么

这几年做过的实时类项目不少，从多人协作白板、在线文档，到工业设备的遥测数据回传、直播间的实时榜单，几乎每个项目都会碰到同一个词：实时网络同步。

但说实话，这个词被用得太泛了。很多人一上来就聊 WebSocket、聊 MQTT、聊长连接，好像把通道建起来、消息能推出去，同步就完成了。真正动手之后才发现，通道只是最表层的一环。实时同步这个领域，至少包含两个完全不同的维度：一个是时间层面的同步，一个是状态层面的同步。

时间层面的同步，说的是让网络中不同设备对“当前时刻”有一致的认识。状态层面的同步，说的是让网络中不同节点对“业务数据”有一致的认识。这两者经常被混为一谈，但它们在原理、工具链、衡量指标上几乎不重叠。

我用一个生活中很常见的场景来解释。假设你和几个朋友分别坐在不同的房间里，各自手持一个计时器，想要同时按下按钮开始一场比赛。如果每个房间里的钟走得不一样快，或者大家按下按钮的瞬间根本不一致，这场比赛从一开始就是不公平的。这就是时间同步要解决的问题。但比赛开始之后，裁判需要实时掌握每个选手跑到哪里了、谁犯规了、当前排名是什么，这些信息要不断从各个比赛场地传到裁判中心，再分发到所有观众的屏幕上。这又是状态同步要解决的问题。

放到技术系统里，时间同步的典型场景是分布式数据库的事务时间戳、日志的时序排序、音视频流的同步播放。状态同步的典型场景是多人游戏中的角色位置、在线文档中的文字内容、协同工具中的任务状态。

明白了这两条线之后，后面所有技术选型都不会乱。所以这篇我就按这两条主线展开，把实时网络同步里最常用的方案、最该避开的坑、以及真正落地的工程经验一次讲透。适合正在做实时通信、分布式系统、协同编辑相关项目，或者准备从零搭建一套实时同步方案的读者。

2. 时钟对齐：NTP 到 PTP，为什么“几点几分”在分布式系统里这么重要

2.1 NTP 的工作原理：多级时钟源校准

先看时间层面的同步。大多数普通业务系统用的都是 NTP（Network Time Protocol），也就是网络时间协议。它解决的核心问题是：一台服务器说现在是 14:30:00，另一台服务器说现在是 14:30:01，到底谁对？这两台机器上的日志时间相差一秒，在做故障排查、事件排序的时候就会产生非常痛苦的干扰。

NTP 的基本思路是层级校准。整个网络里的时钟源分层次，最顶层是 Stratum 0，通常是原子钟、GPS 授时模块这类高精度的时间源。Stratum 1 是直接连接 Stratum 0 的时间服务器，Stratum 2 从 Stratum 1 同步，以此类推。层级越低，离权威时间源越远，精度也逐步下降。

客户端向服务器发起时间同步请求时，会记录四个时间戳：

• T1：客户端发出请求的时刻
• T2：服务器收到请求的时刻
• T3：服务器发出响应的时刻
• T4：客户端收到响应的时刻

有了这四个时间戳，就能算出网络往返延迟 (T4 - T1) - (T3 - T2)，以及客户端与服务器之间的时钟偏移量。这个偏移量的计算有个前提假设：网络在请求方向上的延迟和响应方向上的延迟大致相等。这在实际互联网环境中并不总是成立，所以 NTP 的精度通常只能到毫秒级，而且它会通过多次采样、过滤异常值、平滑调整频率来逐步逼近更准确的时间，而不是一次性粗暴地改变系统时间。

这里有个很实用的细节：NTP 客户端一般不会直接“跳变”系统时间，而是通过调整系统时钟的频率，让本地时间慢慢“漂移”到正确值。直接跳变会引发一系列问题，比如日志时间出现断层、定时任务突然触发异常、分布式系统里的单调时钟判断出错。所以如果你在排查一个时间同步问题，发现系统时间突然跳了几百毫秒，先想想是不是有人手动改了时间，而不是 NTP 在正常工作。

2.2 硬件时间戳与 PTP：要在微秒级工作，NTP 就不够了

NTP 对绝大多数业务系统够用，但涉及实时工业控制、音视频同步采集、高频交易这类场景，毫秒级就不够了。这时需要用到 PTP（Precision Time Protocol），也就是 IEEE 1588 标准。PTP 可以把同步精度做到微秒甚至亚微秒级别。

PTP 和 NTP 的核心差异不只是协议不同，更关键的是时间戳的获取位置。NTP 的时间戳通常由软件在操作系统网络协议栈中打点，这中间有中断处理、协议栈调度、系统调度的不确定性，误差很容易到上百微秒。PTP 则支持用支持硬件时间戳的网卡，在物理层收发报文的瞬间自动打上时间戳，彻底绕开操作系统的调度延迟。

工业现场执行 PTP 同步时，通常需要一台主时钟（Grandmaster Clock），它可以是 GPS 授时设备，也可以是精确原子钟。网络中的交换机、终端设备作为从时钟，通过交换 PTP 报文计算出与主时钟的偏差和报文传输延迟。为了让精度更高，整个网络中所有网络设备最好都支持 PTP 的边界时钟或透明时钟功能。边界时钟会对所经过的 PTP 报文进行重新计时，透明时钟则直接修正报文携带的时间戳字段。如果中间串了一台不支持 PTP 的普通交换机，精度会急剧下降。

我早年做过一个多路摄像头同步采集项目，四台工业相机通过网络连接，要求每个摄像头拍到的画面帧必须在同一时刻启动。因为帧采样是以 TCP 接收时间作为触发基准的，如果四台机器的本地时间相差超过一毫秒，就会出现明显的画面对齐误差。最初我们用 NTP 同步，时间偏差在 5 到 10 毫秒之间波动，怎么调都压不下去。后来换了几台支持 IEEE 1588 的网卡和交换机，把系统切到 PTP 模式，时间偏差直接降到微秒级，问题彻底解决。

这里有个判断原则可以分享：如果应用层对时间精度的要求是毫秒级，认真调优 NTP 就够；如果是几十微秒甚至更低，一定得上 PTP 和硬件时间戳，不要指望软件层能突破物理层的不确定性。

2.3 单调时钟和墙上时钟：分布式系统里最容易混淆的两个概念

做实时同步的系统设计，还有一个比 NTP 更基础的概念经常被人忽略：单调时钟（Monotonic Clock）和墙上时钟（Wall Clock）的区别。

墙上时钟是挂钟上的时间，对应操作系统里的 clock_gettime(CLOCK_REALTIME)。它表示的是当前日期和时间，可能因为 NTP 校准、手动调整而向前或向后跳变。分布式系统里做事件排序，如果直接依赖墙上时钟的先后顺序，一旦某台机器的时间被回拨，它产生的时间戳就可能小于之前已经生成的时间戳，导致整个事件序列疑似倒退。

单调时钟则不同，它只保证在同一台机器内单调递增，比如 clock_gettime(CLOCK_MONOTONIC)。它不表示具体几点几分，只用来计算相对时间间隔。同一台机器上测量一段操作的耗时、判断心跳是否超时，都应该用单调时钟，而不是墙上时钟。跨机器的先后顺序问题，则不能靠时钟，要靠逻辑时钟或者分布式共识来解决。

实时网络同步领域遇到的大部分“时间混乱”问题，其实都出在这个地方。比如一个项目里有两个服务实例在互相推送数据，每次推送都会带上本机时间戳，接收方按时间戳来判定谁的数据更“新”。某天运维同事为了修正机器时间，把其中一台服务器的时间往后调了一小时，这期间产生的数据全部排序错乱。这种问题从根本上是设计缺陷，因为跨进程的时间比较本身就不应该依赖墙上时钟。

3. 状态如何对齐：全量同步、增量同步与操作日志

3.1 先传“当前长什么样”，还是先传“发生了什么事”？

讲完时钟，进入更核心的部分：状态同步。这是网络同步里信息密度最高、也最容易出问题的一块。

状态同步有两条基本思路，一条叫状态迁移（State Transfer），一条叫操作日志（Operation Log）。

状态迁移比较直接：A 节点把当前的完整状态发给 B 节点，B 节点收到后直接覆盖本地状态。这种方式的优点是实现简单、不容易出错；缺点是每次都要传完整数据，数据量大时带宽消耗非常严重。早期的多人游戏帧同步、部分群控系统就喜欢用全量状态推送。

操作日志则聪明一些：A 节点不传状态本身，只传“刚才发生了什么”，比如“用户在坐标 10, 20 处插入了一个字符”“玩家从 A 点移动到了 B 点”。B 节点拿到这批操作，在自己本地按顺序执行一遍，最终得到与 A 节点一致的状态。这种方式在数据量大、但单次变更小的场景下非常高效，在线文档、协同白板基本都是这个思路。

实际系统里通常是两种方式混着用的。我做过的一个协作白板项目，初始连接时先做一次全量状态同步，让新加入的客户端快速拿到当前画面；之后所有用户的画线操作都以操作日志的形式增量广播。为了防丢失，服务端还会把操作日志持久化一段时间，客户端如果中途掉线重连，先拉取这段时间内未收到的增量操作，再补一次全量对账。

3.2 增量同步的版本号机制：为什么必须用版本号而不是时间戳

增量同步要能成立，核心前提是每个节点能判断自己哪些数据已经收到、哪些还没收到。最常用的办法就是给数据打版本号。

版本号可以是简单的单调递增整数，也可以是版本向量。单机场景下，用整数版本号就够了：每产生一次变更，版本号加一，接收方发现版本号跳跃，就知道中间丢了一批更新，需要重新请求缺失区间。但多机并发场景下，整数版本号有一个致命问题：两个节点同时各自生成了版本号 5，但内容不同，你没有办法区分谁先谁后、谁覆盖谁。

这就是 Lamport 时钟和向量时钟（Vector Clock）的用武之地。

Lamport 时钟的思路是：每个节点维护一个计数器，节点内每次事件加一；节点之间通信时，把当前计数器值附在消息里，接收方取“本地计数器和消息计数器中的较大值再加一”。这样就能保证所有节点上的事件之间存在一个合理的偏序关系：如果事件 A 发生时间早于事件 B，那么 A 的 Lamport 时钟值一定小于 B。

向量时钟更进一步。每个节点维护一个向量，记录“我所知道的每个节点各自的计数器值”。比较两个事件的因果关系时，只要逐项比较向量里对应维度的值，就能判断两个事件是因果相关的，还是并发发生的。如果向量 A 的每一个分量都小于等于向量 B，那么 A 导致 B；否则两者是并发事件，需要额外的冲突处理机制。

我见过不少项目组在实现多端数据同步时，拿着普通整数版本号去处理并发写，最后发现数据反复互相覆盖、用户抱怨“我改的怎么不见了”。其实问题不出在存储，而在于版本号根本表达不了并发关系。如果你做的实时同步系统允许两个节点同时修改同一个数据项，请老老实实用版本向量或者至少引入节点 ID + 自增序列的结构化版本号。

3.3 分布式共识：多副本一致性不是靠同步，而是靠“谁有话语权”

状态同步还有一个绕不开的话题：当多个节点都认为自己手里的状态是最新的时候，听谁的？

这个问题单独用“同步”解决不了，必须有第三方裁判，或者一套选举机制来决定谁在冲突时拥有话语权。常见的方案有三种：

第一种是主从模式。所有写操作都发给唯一的主节点，主节点负责把状态变更广播给所有从节点。从节点只读，或者接受读写但最终以主节点为准。这种方式最简单可靠，也是绝大多数系统的默认选择，缺点是主节点故障时会有一段不可用时间，直到重新选出新主。

第二种是分布式共识算法，比如 Raft、Paxos。它们本质上是一套“大多数同意才执行”的机制，通过日志复制、选举、提交判定来保证即使部分节点宕机，整个系统仍然能对状态达成一致。做实时同步系统时，如果后端需要多个副本同时提供高可用服务，通常会把共识算法封装在底层存储层，而不是在上层业务逻辑里自己实现。

第三种是定序服务。单独部署一个序列生成器，所有写操作先到这里拿一个全局递增的序号，再根据这个序号决定执行顺序。这种方式比满键 Raft 轻量很多，适合顺序要求严格但并发量又不到苛刻级别的业务。

有个很现实的建议：不要在业务代码里重复造轮子去实现共识算法。 曾经有个项目团队坚持自己实现了一个类似 Raft 的选主逻辑，跑了半年都挺正常，直到一次网络抖动，两个节点同时认为自己是主节点，数据开始双向写入，最后恢复时花了很长时间手工修复。成熟的实现如 etcd、Consul、ZooKeeper，都经历过极端条件下的验证，直接用它们，省心得多。

4. 实时通道怎么选：WebSocket、WebRTC、MQTT、SSE 的适用边界

4.1 四种主流实时通道的对比

同步的内容和策略定好之后，接下来要解决的是数据怎么从 A 传到 B。目前实时网络同步领域最常用的传输方案是下面这四个：

• WebSocket：基于 TCP 的全双工长连接，适合浏览器端、移动端与服务器之间双向通信。优点是浏览器原生支持，不需要额外协议栈；缺点是 TCP 保证可靠但延迟上会有队头阻塞问题。
• WebRTC：基于 UDP 的实时通信协议栈，核心场景是音视频通话、低延迟多人互动。传输效率高、延迟低，但信令握手复杂，浏览器端需要信令服务器配合建立连接。
• MQTT：基于 Broker 的发布/订阅消息协议，适合物联网数据上报、设备控制。支持 QOS 分级，对弱网环境有专门优化。传统 MQTT 基于 TCP，也有一版 MQTT over QUIC 的探索。
• SSE（Server-Sent Events）：服务端单向推送的轻量协议，基于 HTTP，自带自动重连和事件 ID。适合服务端往客户端单向推送消息，比如行情推送、通知中心。

面对这么多选项，我的选型判断很简单：

如果你的业务是浏览器页面与服务端双向交互，且交互频率高，直接选 WebSocket。如果主要是服务端往浏览器单向推送，SSE 就够，而且更简单。如果是大规模低功耗设备上报数据，MQTT 更合适。如果涉及音视频或超低延迟多人互动，WebRTC 是唯一现实的选择。

不同方案的对比，可以参考下面这个表格：

4.2 选 WebSocket 之后，一定会遇到的心跳、重连与消息去重

WebSocket 看起来很简洁，但真正做实时业务时，有几个细节必须提前设计好，否则线上必踩坑。

第一个是心跳机制。WebSocket 连接长时间没有任何数据时，中间可能被防火墙或 NAT 网关静默断开，但客户端和服务端都感知不到。常规做法是客户端每隔 30 秒到 1 分钟发送一次 ping 帧，服务端收到后立即回 pong。如果连续几次 ping 都没有 pong，就认为连接已经断开，主动进入重连流程。这里值得注意：用系统层的 ping/pong 帧和自己在应用层发心跳包是两回事。有些代理服务器对 TCP 层的控制帧支持不好，应用层心跳更可靠。我习惯两种都做，但应用层心跳作为主要依据。

第二个是重连策略。断线后立刻重连是最差的策略，因为网络抖动时服务端还在恢复，拼命重连反而会加重服务端压力。更好的做法是带退避的指数重连：第一次重连延迟 1 秒，第二次 2 秒，第三次 4 秒，到最大值比如 30 秒后封顶。同时要在重连成功后做一次增量状态对齐，保证断线期间丢失的消息能补回来。

第三个是消息去重。TCP 保证消息不丢失不错序，但应用层的重试机制可能会把同一条消息发送两次。比如客户端发了一条同步指令，服务端处理成功回复 ACK 时网络断了，客户端超时重发，服务端就会收到两条一模一样的指令，产生重复执行。解决办法是给每条消息一个全局唯一的消息 ID，服务端记录最近处理过的消息 ID，重复消息直接丢弃。

有一种很典型的线上事故就是这样引发的：某个实时排行榜服务，客户端每收到一条消息就刷新页面，重连后服务端重放了断线期间的所有消息，旧消息和新消息重叠，排行榜瞬时跳变。后来加了消息 ID 去重 + 状态快照恢复才稳定下来。

4.3 推拉结合的兜底设计

再健壮的实时通道也有不可用的时候。网络断连、运营商限流、客户端长时间切后台，这些场景下如果整个系统只靠实时推送一条路，数据必然出现缺口。

我现在的习惯是：实时通道负责“推”，定时通道负责“拉”，两个口子互相兜底。 客户端通过 WebSocket 接收实时增量，同时每隔一段时间（比如 30 秒）调用一次 REST 接口获取一次最新状态快照。两边的数据做一次比对，发现快照比实时推送的状态更新，就以快照为准，强制刷新本地状态。

这个设计增加的开发量不多，但能大大降低长时间运行下“静默数据不一致”的概率。尤其是移动端 App，后台进程经常以分钟级为单位被系统暂停，等恢复前台时，积压下来的推送消息已经不够用了，直接拉一次快照最省事。

5. 并发冲突处理：LWW、OT、CRDT，以及我在项目里的取舍

5.1 最后写入获胜的代价

当两个客户端同时修改同一个数据项时，实时同步系统必须在“数据一致”和“允许并发”之间做取舍。最简单粗暴的策略是 LWW（Last Write Wins）：谁的时间戳大（或者谁的版本号大），谁的数据生效。

LWW 实现成本极低，绝大多数实时数据库的默认同步语义就是它。但它有一个非常隐蔽的问题：如果比较依据是客户端本地时钟，一旦某个客户端的时间不准，它产生的时间戳可能会把其他所有客户端的新数据都覆盖掉。我见过一个表单协同工具，用户的时区设置错误，导致他本地时间比服务器快了一小时，他每次编辑都会把其他人刚保存的内容覆盖掉。后来我们把时间来源全部改成了服务器下发的时钟基准，才从根本上解决。

所以即便你用 LWW，也一定要确保参与比较的时钟来源是同一个可信基准，而不是各节点自己的本地时间。

5.2 OT 和 CRDT：面向文本编辑与结构化数据的强一致方案

在线文档、多人白板这一类场景，用户需要在同一份内容上并发修改且最终一致，LWW 明显不够用。这就要上 OT（Operational Transformation）或者 CRDT（Conflict-Free Replicated Data Type）。

OT 的核心思想是：每个操作都通过一个转换函数，把“并发的两个操作”转换成一个“可顺序执行的等价操作”，保证不同节点即使以不同顺序收到操作，最终状态也是一致的。Google Wave 最早把 OT 带入大众视野，后来的 Google Docs 也用类似机制。OT 的难点在于转换函数随数据结构复杂度的增加会急剧膨胀，实现一个满足所有交换律、结合律的 OT 引擎非常考验功力。

CRDT 则是另一种思路：通过设计特殊的数据结构，使得并发操作天然满足交换律、结合律、幂等性，无论操作以什么顺序到达，最终收敛到同一个状态。CRDT 的实现在代码层面相对 OT 要直观一些，常见的有 G-Counter（增长计数器）、PN-Counter（可增减计数器）、G-Set、OR-Set（允许增删的集合）、LWW-Register（带时间戳的寄存器）。

做过一个团队便签应用，多个成员可以同时编辑同一个清单列表，我们用的是基于有序列表的 CRDT，把每个列表项挂在一个唯一 ID 和前后项指针构成的链上，插入操作共享同一套合并逻辑，即使断网离线编辑，恢复网络后也能自动收敛。实现过程中最大的体会是：CRDT 的特点是写代码容易、理解代价高。 如果团队里没有人对 CRDT 原理有充分的把握，宁可后台加一个定序服务把所有操作统一排序，也不要在客户端直接放飞并发。

5.3 冲突处理的工程兜底：永远留一个“手动纠错”的后门

不管选哪种一致性策略，真实业务里一定会有规则覆盖不到的场景。比如两人同时把同一个字段改成完全不同的值，而业务上哪个都算有效，系统无法自动判断谁对。这种情况系统能做的最优解是：选择一边收敛，同时把被覆盖的另一边保留为“冲突记录”，让用户后续可以手动恢复。

这个原则我在多个项目里反复验证过。自动冲突处理做得再漂亮，也不如给用户一个“撤销”“查看历史版本”的入口来得安心。实时同步系统里加一个轻量级的历史版本表，每次冲突发生时自动记录冲突双方的快照，成本极低，可回溯性极高，值得所有做实时协作的项目借鉴。

6. 实时系统的可观测性与故障排查链路

6.1 从日志时间到链路追踪，先统一你的时间底数

实时同步系统是典型的分布式系统，排查问题最主要的手段就是日志。但如果你只有应用日志、没有统一的时间底数，排查几乎无从下手。

我到一个新项目组做的第一件事，永远是确认所有服务器是否都配置了同一组 NTP 时间源。别笑，很多系统崩溃的根因不是代码逻辑，而是日志时间乱序导致的分析误判。等 NTP 确认无误之后，再看日志格式里是否有请求 ID、消息 ID、客户端会话 ID 这些关联字段。没有这些，就算日志时间完全一致，你也没办法把同一条链路的多段日志串起来。

6.2 实时通道的指标监控：连接数、延迟、心跳成功率，一个都不能少

做了多年实时系统，我建议至少监控四个指标：

• 当前活跃连接数及连接建立速率：连接数飙升或骤降往往意味着服务异常或被攻击。
• 端到端消息延迟：从客户端发送到服务端再推送给目标客户端的整链路耗时，这个指标最能反映用户体验。
• 心跳超时率：一段时间内心跳丢失的占比。超时率突然升高，可能是网络链路问题，也可能是服务端口处理不过来。
• 消息积压量：服务端等待推送给客户端的消息队列长度。积压持续增加说明消费速度跟不上了，需要扩容或优化。

监控数据的采集本身也要注意，不要在主链路上做太重的埋点，否则会影响延迟本身。我用得比较多的是在服务端把指标汇总成直方图，按百分位（p50、p99）来观察延迟分布，而不是只盯着平均值。平均值容易被极端值拉高，p99 能让人看到大多数情况下的真实体验。

6.3 一个典型的实时同步故障排查案例

之前有一个在线协作项目，某天运营反馈部分用户的文档长时间无法同步，改动内容经常在刷新后丢失。我接手排查时，先看了一组监控面板，发现 WebSocket 连接数和心跳超时率都是正常的，消息延迟也维持在几十毫秒。

既然通道没问题，怀疑方向转向业务逻辑。我拉出一台出现问题的用户的设备日志，对照发现：用户 A 的文档版本号停留在 100，但服务器的文档版本号已经到 105。按系统设计，客户端断线重连后应该做增量同步，但客户端上报的起始版本号和请求参数里附带的时间戳发生了偏差，导致服务端认为客户端根本没有缺失区间，直接返回空结果。

根因出在客户端构造增量同步请求时，用了本地缓存里的时间戳作为“最后同步时间”，而这个时间戳是在用户上一次修改时间之后、但文档数据还没来得及推送的时候写入的。客户端以此时间为基准发起的增量拉取，从服务端视角看确实没有“新数据”。修复办法很简单，把增量拉取的版本基准改成服务端确认过的最新版本号，而不是本地时间。

这个案例给我的核心教训是：实时同步系统的故障，一半出在通道，一半出在版本基准没对齐。排查时先确认通道健康，再检查各端对“当前版本”的认知是否一致。

7. 大型实时系统还要考虑的三个瓶颈：带宽、状态爆炸与弱网

7.1 带宽优化：增量压缩、条件推送与合并通知

全量推送永远是最省事但最浪费的方案。我在一个监控大屏项目里做过一次优化，原始方案是每个设备数据变化后直接把 JSON 全量发送给前端，高峰期每秒产生好几 MB 的数据，前端渲染也扛不住。后来切成增量协议，把数据包拆成“元数据头 + 变化字段”两部分，再用 JSON 序列化 + gzip 压缩，带宽消耗直接降到原来的十分之一以下。

另一个更符合业务直觉的优化是条件推送。如果服务端有实时计算能力，可以先在服务端判断一次“这次变化是否值得推给客户端”，不值得就不推。比如某个统计指标从 100 变成 101，如果业务上用户只关心十位变化，就完全没必要推送。这种业务前置过滤，能省下的带宽比任何压缩算法都多。

还有一个合并通知的技巧，适用于高频小数据量的场景。客户端 A 在一秒内连续发送了 100 次状态变更，全部即时推送出去，对端会收到 100 个包；如果服务端做一个抖动窗口，把同一毫秒级窗口内的更新合并成一条批量消息，推送次数可以降一个数量级，对端处理压力也小很多。

7.2 状态爆炸：能不发全量就不发全量，能少存就少存

实时同步系统运行久了，累积的状态数据会快速增长。客户端每次同步都把全量状态拉去和本地对比，很快会变成灾难。有一个实用思路是引入数据分区：把业务数据按维度切成多块，客户端只订阅自己关心的分区，减少同步的数据量。比如多人在线文档，可以按段落分块，光标远程位置同步只推属于自己所在段落的数据，其他段落的变化只在滚动到附近时才去拉取。

服务端的会话状态也是一样。WebSocket 长连接本身会占用内存，每个连接还要维护会话上下文、消息队列、同步游标。连接数上万之后，内存压力非常明显。对长时间不活跃的连接主动断连，把会话状态持久化到 Redis 或数据库，等客户端重连时再从持久化层恢复，可以显著降低常驻内存压力。

7.3 弱网场景下的优雅降级：实时性让位给保底一致性

实时网络同步有个不得不接受的现实：网络条件差，实时性必然受影响。项目里对弱网的处理，核心是定义“最低可用体验”。以在线文档为例，弱网下可以做三件事：

• 本地先把用户的编辑暂存，以操作草稿的形式存在本地队列中，等网络恢复后自动同步。
• 同步策略动态降级，实时长连接扛不住时，自动降低推送频率，改为批量拉取模式。
• 给用户明确的状态提示，弱网时显示“正在同步”而不是假装已经同步成功。

这三件事做到了，实时系统在弱网下的可用性会有质的提升。用户能接受延迟，但不能接受静默丢数据。

8. 踩过多次坑之后，我的三个核心经验

实时网络同步不是“把消息推过去”这么简单，它是时间同步、状态同步、一致性协议、传输通道、异常处理等多层技术叠加在一起的结果。踩过多次坑之后，我总结出三条最想传达的经验。

第一，先定义“同步成功”是什么，再动手写代码。 很多项目做实时同步做崩了，问题不在技术方案，而在需求方和开发方对“成功”的定义不一致。方案设计的第一步，就是明确：两个节点达到什么状态算同步成功？新加入节点初始状态是什么？断线重连后多久恢复？这几件事定了，后续每一条代码都清晰。

第二，通道和协议是两回事，做好分工。 WebSocket 管的是消息能送达，版本号和冲突处理管的是消息到达后如何正确落地。很多人把这两层混在一堆代码里，写起来痛快，维护起来痛苦。我在性能优先的地方会严格分层：传输层只负责可靠收发，同步层负责版本管理、冲突检测、状态合并。两层各干各的，互相不渗透。

第三，永远给问题留一个“重新对齐”的后门。 实时系统会累积误差，不管是时钟偏移、版本号漂移、还是连接断开导致的局部状态缺失，都需要有一种手段把两端的整体状态重新拉到一致。这个后门可以是定时全量对账，可以是一个“重新同步”API，也可以是一个强制刷新按钮。它的存在不会影响正常同步的效率，却能在大规模故障发生时省下救命的几小时。