---
title: 多人实时协作编辑系统的高层架构设计与核心技术实现：从实时同步到冲突处理及可扩展性探讨
created: 2026-03-02
updated: 2026-03-02
type: summary
tags: ["collaboration", "notes", "realtime", "system", "telegram"]
external: http://go/ui/posts/2101/
status: inbox
---

```
I am preparing a senior software engineer system design questions, one of the question is: `Create a Google Docs like collaborative text editing system, so multiple users can edit the same text, handle potential conflict issues` 

please help me design this system, draw the architecture diagram, and highlight how to allow multiple people editing the same doc. The design should just enough for the inerview questions and possible extension requirements, but maybe don't make it too complicated to explain 
```

为了设计一个类似 Google Docs 的多人实时协作编辑系统，我们需要解决几个核心问题：**实时同步、冲突处理、数据一致性和可扩展性**。下面我会先给出一个高层架构图（用文字描述），然后详细解释各个组件以及协作流程，最后讨论冲突解决方案和可能的扩展。

## 1. 系统架构图（文字描述）

```
+----------------+     +------------------+     +-----------------+
|  客户端 A (Web) | <-> |  负载均衡器       | <-> |  WebSocket 服务 |
+----------------+     +------------------+     |  (集群)         |
                                                  +----------------+
                                                           |
+----------------+     +------------------+                |
|  客户端 B (Web) | <-> |  负载均衡器       | <-> | 应用服务器     | <-> 数据库 (PostgreSQL + Redis)
+----------------+     +------------------+     | (业务逻辑/OT)  |
                                                  +----------------+
                                                           |
                                                  +----------------+
                                                  | 对象存储 (S3)   |
                                                  | (文档历史/快照) |
                                                  +----------------+
```

**说明**：
- **客户端**：浏览器或移动端，通过 WebSocket 与服务器保持长连接，实时收发操作。
- **负载均衡器**：分发 WebSocket 连接和 HTTP 请求，保证高可用。
- **WebSocket 服务集群**：负责维护与客户端的连接，广播操作消息，可独立扩展。
- **应用服务器**：处理文档业务逻辑，包括操作转换（OT）、权限校验、持久化等。
- **数据库**：存储文档元数据、用户信息、操作日志（可选）。使用关系型数据库保证事务性。
- **Redis**：用作临时存储文档当前状态（如操作队列），加速读写。
- **对象存储**：定期保存文档快照，用于恢复和历史版本回溯。

## 2. 核心协作流程

### 2.1 编辑操作发送
1. 用户 A 在文档中输入一个字符 `'x'`。
2. 客户端将此次操作封装为一个 **操作（Operation）**，例如 `{type: 'insert', position: 5, char: 'x', version: 10}`。
3. 通过 WebSocket 连接发送到服务器。

### 2.2 服务器处理与广播
- 服务器接收到操作后，先进行**操作转换（Operational Transformation）**，确保该操作与服务器上其他并发操作合并后得到一致结果。
- 转换后的操作被应用到服务器端的主文档副本，并更新版本号。
- 服务器将该操作广播给所有正在编辑该文档的其他客户端（包括操作发起者，用于确认）。
- 同时，服务器将操作记录到数据库（或先记日志，异步落盘）。

### 2.3 客户端接收与更新
- 其他客户端收到广播的操作后，应用该操作到本地文档，保持与服务器一致。

### 2.4 冲突解决
当两个用户同时编辑同一位置时，例如：
- 用户 A 在位置 5 插入 `'a'`
- 用户 B 在位置 5 插入 `'b'`

服务器通过 OT 算法将两个操作转换，使得最终结果既不是 `'ab'` 也不是 `'ba'`，而是根据某种规则（如用户 ID 排序）确定顺序，但保证两个用户最终看到相同结果。常用的 OT 算法如 **Jupiter** 或 **Google Wave OT**。

另一种现代方案是使用 **CRDT（无冲突复制数据类型）**，如 **Automerge** 或 **Yjs**，它们去中心化，不需要中心服务器做转换，但服务器仍作为协调者和持久化节点。

## 3. 数据存储设计

- **文档内容**：通常不直接存储整个文本，而是存储操作的日志（operation log），通过回放日志重建文档。但为了提高读取性能，会定期生成快照（snapshot）并保存到对象存储。
- **元数据**：文档 ID、所有者、创建时间、权限列表等，存在关系型数据库中。
- **用户连接信息**：用户与文档的映射关系，存在 Redis 中以便快速广播。

## 4. 扩展性考虑

- **WebSocket 服务水平扩展**：通过负载均衡器（如 Nginx 或 HAProxy）支持 sticky session，保证同一文档的连接尽量集中在同一台服务器，减少跨节点通信。
- **文档分片**：如果单个文档特别大，可以按段落分片，每个片独立处理操作，但复杂度较高。
- **离线编辑**：客户端缓存操作，重连后发送到服务器，服务器需处理这些操作的合并。
- **版本历史**：用户可以回溯到任意历史版本，通过快照 + 操作日志实现。

## 5. 可能的冲突处理细节

在面试中，可以简要说明 OT 的核心思想：
- 每个操作都带有一个版本号（或状态向量）。
- 服务器维护文档的当前版本，收到操作后检查版本是否落后，若落后则先进行转换，使操作基于最新状态。
- 转换函数 `transform(op1, op2)` 返回两个操作，使得它们在应用后结果一致且可交换。

或者选择 CRDT 方案，更简单：每个字符有唯一 ID，插入时带上前驱/后继信息，合并时按 ID 排序，天然解决冲突。Yjs 就是基于 CRDT 的成熟库。

## 6. 回答时的要点（中文）

在面试中，你可以这样组织回答：

1. **概述**：这是一个实时协作编辑系统，核心是低延迟同步和无冲突合并。
2. **架构**：展示分层架构图，解释每一层的作用。
3. **数据流**：从用户输入到服务器广播的完整流程。
4. **冲突解决**：选择 OT 或 CRDT，简要说明原理（比如 OT 通过操作转换保证顺序，CRDT 通过唯一标识合并）。
5. **扩展性**：如何应对大量文档和用户（WebSocket 集群、负载均衡、Redis 缓存、数据库分片）。
6. **附加功能**：离线支持、版本历史、权限管理等。

这样既覆盖了核心问题，又不会陷入过于复杂的细节，适合面试中的系统设计题。
