Go 协作文档冲突解决：OT 算法和 CRDT 的并发编辑实现

Go 协作文档冲突解决OT 算法和 CRDT 的并发编辑实现一、两个人同时改同一行保存后其中一个人的修改丢了协作文档类似 Google Docs/飞书文档的核心技术挑战是并发编辑冲突。当用户 A 在第 5 行插入项目延期了用户 B 正在第 5 行删除进度正常两个操作几乎同时到达服务器。如果简单按到达顺序处理必然有一个人的操作被覆盖。解决这个问题的经典方案有两种OTOperational Transformation操作变换和 CRDTConflict-free Replicated Data Type无冲突复制数据类型。OT 通过变换操作保证一致性CRDT 通过数据结构设计保证操作可交换。两者在工程上有不同的取舍。二、OT 算法的核心原理OT 的核心想法是当两个并发操作冲突时不是拒绝其中一个而是变换其中一个操作使其在另一个操作之后执行仍能产生正确的结果。OT 的核心是transform(op1, op2)函数它对操作做位置偏移变换。这个算法在 Google Docs 中使用多年成熟稳定。三、Go 实现简化的 OT 引擎package ot import ( fmt sync time ) // OpType 操作类型 type OpType int const ( OpInsert OpType iota OpDelete ) // Operation 编辑操作 type Operation struct { Type OpType json:type Position int json:position // 操作位置 Content string json:content // 插入的文本Delete 时为空 Length int json:length // 删除的长度Insert 时为0 UserID string json:user_id Timestamp int64 json:timestamp Revision int json:revision // 基于的版本号 } // Document 协作文档 type Document struct { mu sync.RWMutex content string revision int history []*Operation } // NewDocument 创建文档 func NewDocument(content string) *Document { return Document{ content: content, revision: 0, history: make([]*Operation, 0), } } // Apply 应用一个操作到文档 func (d *Document) Apply(op *Operation) error { d.mu.Lock() defer d.mu.Unlock() // 版本检查 if op.Revision ! d.revision { return fmt.Errorf( 版本冲突: 期望 %d, 当前 %d, op.Revision, d.revision, ) } switch op.Type { case OpInsert: if op.Position 0 || op.Position len(d.content) { return fmt.Errorf(插入位置越界: %d, op.Position) } d.content d.content[:op.Position] op.Content d.content[op.Position:] case OpDelete: if op.Position 0 || op.Positionop.Length len(d.content) { return fmt.Errorf(删除范围越界) } d.content d.content[:op.Position] d.content[op.Positionop.Length:] } d.revision d.history append(d.history, op) return nil } // Transform 变换两个并发操作 // 返回变换后的 op2使 op2 在 op1 之后仍正确 func Transform(op1, op2 *Operation) (*Operation, error) { if op1.Position op2.Position { // op1 在 op2 之后不影响 op2 的位置 return op2, nil } transformed : Operation{ Type: op2.Type, UserID: op2.UserID, Timestamp: op2.Timestamp, Revision: op2.Revision, } switch op1.Type { case OpInsert: // op1 在 op2 前面插入op2 的位置需要后移 transformed.Position op2.Position len([]rune(op1.Content)) transformed.Content op2.Content transformed.Length op2.Length case OpDelete: if op1.Positionop1.Length op2.Position { // op1 删除的内容完全在 op2 前面 transformed.Position op2.Position - op1.Length } else if op1.Position op2.Positionop2.Length { // op1 删除的内容完全在 op2 后面不影响 transformed.Position op2.Position } else { return nil, fmt.Errorf( 操作冲突: op1删除范围与op2重叠, ) } transformed.Content op2.Content transformed.Length op2.Length } return transformed, nil } // OTEngine OT 引擎服务端 type OTEngine struct { documents sync.Map // docID - *Document } // NewOTEngine 创建 OT 引擎 func NewOTEngine() *OTEngine { return OTEngine{} } // HandleOperation 处理客户端发来的操作 func (e *OTEngine) HandleOperation( docID string, op *Operation, ) (*Operation, bool, error) { docInterface, _ : e.documents.LoadOrStore( docID, NewDocument(), ) doc : docInterface.(*Document) doc.mu.Lock() // 检查是否需要变换 if op.Revision doc.revision { // 客户端的版本落后需要对操作做变换 pendingOps : doc.history[op.Revision:] for _, pendingOp : range pendingOps { var err error op, err Transform(pendingOp, op) if err ! nil { doc.mu.Unlock() return nil, false, fmt.Errorf( 操作变换失败: %w, err, ) } } op.Revision doc.revision } // 应用操作 if err : doc.Apply(op); err ! nil { doc.mu.Unlock() return nil, false, err } doc.mu.Unlock() // 返回变换后的操作用于同步给其他客户端 return op, true, nil } // GetContent 获取文档内容 func (e *OTEngine) GetContent(docID string) string { docInterface, ok : e.documents.Load(docID) if !ok { return } doc : docInterface.(*Document) doc.mu.RLock() defer doc.mu.RUnlock() return doc.content }四、边界分析与 Trade-offsOT vs CRDT 的选择OT 需要中心服务器Google Docs 模式适合对一致性要求极高的文档协作。CRDT 支持离线编辑后再同步Figma 模式适合需要离线能力的场景。但 CRDT 的存储开销大需要保留所有历史操作且某些复杂操作如富文本格式的 CRDT 实现极其复杂。企业文档协作场景下 OT 是更务实的选择。操作粒度的影响按字符做 OT 变换会导致操作极多一次粘贴可能产生几百个 Insert 操作。实际使用中通常按词或块做操作合并——客户端将连续插入合并为一个操作后再发给服务端。但这可能导致变量——如果两个用户在不同位置修改同一个词块仍然需要 OT 处理。版本管理的存储增长OT 的历史操作列表会无限增长。可以定期如每天做快照——将当前文档内容保存为新的基线版本清理之前的操作历史。下一个版本从快照开始重新计数。网络延迟下的用户体验OT 要求操作要先过服务端才能看到效果这在网络延迟大时体验很差。优化客户端本地先套用操作乐观更新服务端确认后再修正。如果服务端变换后的结果和客户端不同再做本地修正——这就是 Google Docs 的用户体验设计。五、总结OT 算法的核心是transform(op1, op2)函数它的作用是如果两个操作同时发生变换其中一个使两者都能正确执行。代码实现上要注意位置偏移的计算Insert 导致位置增加Delete 导致位置减少以及对重叠删除的冲突处理。Go 语言实现 OT 的优势是并发安全sync.Mutex 保护好文档的临界区和性能不需要处理复杂的异步回调。如果要从零实现协作文档建议从纯文本 OT 开始跑通后再扩展到富文本——那是另一个维度的复杂度。