协同编辑系统架构设计与冲突解决

一、问题定性：先对齐边界，再谈方案

面对”设计一个协同编辑系统”这类题目，成熟的工程师不会一上来就画架构图，而是先花一两分钟明确需求边界。这不是拖延，而是在为后续所有设计决策定基调。

一句话定性：这是一个”高频小写入 + 强实时广播 + 强收敛一致性”的系统。

难点不在增删改查，也不在存储容量，而在于——如何让多个用户同时编辑同一篇文档时，不互相覆盖、不产生分歧、最终所有端看到的内容完全一致。

协同编辑的本质，是把并发的用户操作转换成所有端最终一致的操作序列。后续所有设计——无论是通信协议、冲突解决算法还是存储策略——都是为这个目标服务的。

需要澄清的关键边界包括：

• 并发规模：同一文档同时编辑的人数是多少？10人、100人还是1000人？
• 一致性要求：是强一致性（所有端实时同步）还是最终一致性（允许短暂分歧但最终收敛）？
• 离线支持：用户断网后能否继续编辑？断网时长上限是多少？
• 历史版本：是否需要版本回放、任意时间点还原？
• 文档规模：单文档的操作序列有多长？是否需要定期压缩？

这些问题的答案会显著影响架构选型。例如，如果并发人数很少且不需要离线支持，简单的锁机制可能就够了；但如果要支持大规模并发和离线编辑，就必须引入OT或CRDT。

二、分层架构：客户端乐观更新 + 服务端集中定序

系统采用分层解耦设计，核心思路是”客户端乐观更新 + 服务端集中定序”。整体分为以下几层：

接入层（无状态）：负责WebSocket连接管理、鉴权、心跳保活、消息编解码。这一层无状态，可以水平扩展，通过负载均衡分发连接。

协同层（有状态）：负责操作定序、冲突解决、版本管理。同一文档的所有操作通过一致性哈希路由到同一个节点的同一条线程串行处理，从根上消除并发乱序。

存储层：负责操作日志持久化、快照存储、文档元数据管理。写入走消息队列异步落库，读取走缓存加速。

广播层：负责将定序后的操作实时推送给所有在线客户端。

各层职责一句话说清：

层级	职责	状态
接入层	连接管理、鉴权、编解码	无状态
协同层	定序、冲突解决、版本管理	有状态
存储层	操作日志、快照、元数据	持久化
广播层	实时推送定序结果	无状态

关键设计权衡

接入层无状态、协同层有状态——同一docId的所有操作通过一致性哈希路由到同一个节点的同一条线程串行处理。这相当于用空间换正确性，把分布式一致性问题降级成单机内存问题。协同层节点故障时，通过操作日志回放恢复状态。

实时链路和落库链路分离——广播走WebSocket即时推送，持久化走消息队列异步落库。写库抖动不影响编辑体验，同时消息队列的削峰填谷能力可以应对突发写入。

有状态下沉、无状态上浮——扩展性靠无状态的网关扛，一致性靠有状态的协同服务守。网关可以随意增减实例，协同层则通过一致性哈希保证同一文档始终路由到同一节点。

三、冲突解决：OT与CRDT的取舍

冲突解决是协同编辑的核心算法问题。业界主流方案有两种：OT（Operational Transformation，操作变换）和CRDT（Conflict-free Replicated Data Type，无冲突复制数据类型）。

OT的核心思想

OT的基本思路是：当两个操作并发产生时，通过变换函数调整其中一个操作，使其在另一个操作已经应用的基础上仍然正确。

举例说明：假设文档内容为”AB”，用户1在位置1插入”X”，用户2在位置1插入”Y”。

• 用户1的操作：insert(1, “X”)，期望结果”AXB”
• 用户2的操作：insert(1, “Y”)，期望结果”AYB”

服务端先收到用户1的操作，文档变为”AXB”。此时收到用户2的操作insert(1, “Y”)，需要将其变换为insert(2, “Y”)，应用后得到”AXYB”。这个变换过程就是OT的核心。

OT的关键在于变换函数的正确性。对于插入、删除、保留三种基本操作，两两组合需要定义变换规则。实际操作类型更多（如富文本格式变更），变换矩阵会更复杂。

public class Operation {
    enum Type { INSERT, DELETE, RETAIN }
    Type type;
    int position;
    String content;
    int length;
}
public class OTTransformer {
    public static Operation[] transform(Operation a, Operation b) {
        if (a.type == Operation.Type.INSERT && b.type == Operation.Type.INSERT) {
            if (a.position < b.position || 
                (a.position == b.position && a.clientId < b.clientId)) {
                return new Operation[]{a, new Operation(b.type, b.position + a.content.length(), b.content, b.length)};
            } else {
                return new Operation[]{new Operation(a.type, a.position + b.content.length(), a.content, a.length), b};
            }
        }
        // 其他组合的变换规则...
        return new Operation[]{a, b};
    }
}

CRDT的核心思想

CRDT的思路不同：它设计特殊的数据结构，使得并发操作天生可交换、可结合，无论以什么顺序应用，最终结果都相同。

常见的CRDT实现包括：

• G-Counter（增长计数器）：每个节点维护自己的计数，合并时取各节点最大值之和。
• PN-Counter（正负计数器）：用两个G-Counter分别记录增和减。
• LWW-Register（最后写入胜出寄存器）：用时间戳决定哪个写入生效。
• RGA（Replicated Growable Array）：用于序列化文本编辑，每个字符有唯一ID，插入时指定前驱字符。

CRDT的优点是天然支持离线编辑和P2P同步，不需要中心服务器定序。缺点是元数据开销大（每个字符需要额外ID和位置信息），且垃圾回收复杂。

选型建议

维度	OT	CRDT
中心化要求	需要中心服务器定序	可去中心化
元数据开销	低	高
离线支持	较弱	强
实现复杂度	变换函数复杂	数据结构复杂
适用场景	实时协同为主	离线优先、P2P

实际工程中，如果以实时协同为主、离线为辅，OT是更成熟的选择；如果离线编辑是核心需求，CRDT更有优势。也可以混合使用：在线时走OT，离线时走CRDT，重连后合并。

四、断线重连与历史版本回放

断线重连

用户断网后重新连接，需要补齐断网期间错过的所有操作。核心机制是版本向量（Version Vector）：

• 服务端为每个操作分配递增版本号。
• 客户端记录自己已应用的最新版本号。
• 重连时，客户端发送自己的版本号，服务端返回该版本之后的所有操作。

但有一个关键细节：落后补偿靠主动拉，不靠傻等广播。客户端发现自己版本落后，走pullOpLog(fromVersion)增量补齐；如果落后的操作太多（比如超过500条或超过阈值），就不逐条变换了，直接拉全量快照重置。

public class ReconnectHandler {
    private static final int MAX_INCREMENTAL_OPS = 500;
    public void onReconnect(String docId, long clientVersion) {
        long latestVersion = versionStore.getLatestVersion(docId);
        long gap = latestVersion - clientVersion;
        if (gap <= MAX_INCREMENTAL_OPS) {
            // 增量补齐：拉取从clientVersion到latestVersion的所有操作
            List<Operation> ops = opLogStore.getOps(docId, clientVersion, latestVersion);
            for (Operation op : ops) {
                client.apply(op);
            }
        } else {
            // 差距过大：直接拉全量快照
            Snapshot snapshot = snapshotStore.getLatestSnapshot(docId);
            client.reset(snapshot);
            // 再补齐快照之后的操作
            List<Operation> ops = opLogStore.getOps(docId, snapshot.getVersion(), latestVersion);
            for (Operation op : ops) {
                client.apply(op);
            }
        }
    }
}

快照与回放

操作日志会无限增长，必须定期压缩。快照机制是：每隔N个操作或每隔T分钟，将当前文档状态序列化为快照存储，同时截断之前的操作日志。

历史版本回放则依赖快照 + 操作日志的组合：

1. 找到目标时间点之前最近的快照。
2. 从该快照开始，依次应用操作日志中的操作，直到目标时间点。
3. 得到目标时间点的文档状态。

public class HistoryPlayer {
    public Document replay(String docId, long targetVersion) {
        // 找到目标版本之前最近的快照
        Snapshot snapshot = snapshotStore.getNearestSnapshot(docId, targetVersion);
        Document doc = snapshot.getDocument();
        // 应用快照之后、目标版本之前的操作
        List<Operation> ops = opLogStore.getOps(docId, snapshot.getVersion(), targetVersion);
        for (Operation op : ops) {
            doc = applyOperation(doc, op);
        }
        return doc;
    }
}

快照策略的权衡

• 快照频率高：回放快、恢复快，但存储开销大、写入频繁。
• 快照频率低：存储省，但回放慢、恢复时间长。

工程上通常采用自适应策略：操作密集时提高快照频率，操作稀疏时降低频率。同时，快照可以异步生成，不阻塞主流程。

五、大规模连接与性能优化

当系统需要支撑30万甚至更多长连接时，需要从多个维度优化：

连接层优化：

• 使用轻量级协议（如WebSocket over TCP），减少握手开销。
• 心跳间隔自适应调整，避免大量心跳同时触发。
• 连接复用：同一用户多设备共享底层连接。

协同层优化：

• 一致性哈希路由，保证同一文档始终由同一节点处理。
• 操作批量处理：将短时间内的多个操作合并为一个批次，减少广播次数。
• 内存优化：文档状态常驻内存，操作日志分页加载。

存储层优化：

• 操作日志追加写入，避免随机写。
• 快照冷热分离：近期快照存高速存储，历史快照存低成本存储。
• 异步落库 + 消息队列削峰。

广播层优化：

• 增量广播：只推送变更部分，而非全量文档。
• 二进制协议：减少序列化开销和网络带宽。
• 多级缓存：热点文档的操作结果缓存在网关层。

六、总结

协同编辑系统的设计可以归纳为几个核心决策：

1. 需求边界先行：明确并发规模、一致性要求、离线支持和历史版本需求。
2. 分层解耦：接入层无状态、协同层有状态、存储异步化、广播实时化。
3. 冲突解决选型：实时协同为主选OT，离线优先选CRDT，也可混合使用。
4. 断线重连策略：增量补齐为主，差距过大时全量快照重置。
5. 快照与回放：定期快照 + 操作日志，支撑历史版本回放和故障恢复。
6. 规模化优化：连接复用、批量处理、增量广播、异步落库。

这套设计不仅适用于面试场景，也可以作为实际项目的设计文档基础。真正的工程落地还需要考虑更多细节——权限控制、协作光标、评论批注、多端同步等——但核心骨架不变：让并发操作在所有端最终一致地收敛。