Node.js实时协作项目复盘OT与CRDT的选型决策与实际工程挑战一、实时协作的技术十字路口2025年初开发一个在线文档协作工具核心需求多人同时编辑同一份文档实时同步。技术选择面临两个阵营OTOperational Transformation和CRDTConflict-free Replicated Data Types。两者都能解决多人编辑冲突问题但实现路径完全不同。Google Docs用的是OTFigma和Notion偏向CRDT。选择哪个需要理解技术原理后才能做出决策。二、OT vs CRDT的技术原理对比OT操作转换的核心思想当两个用户同时编辑时操作需要根据并发操作进行变换初始文档: hello 操作A: insert( world, at 5) → hello world 操作B: delete(0, 3) → lo 在服务器端如果先收到A再收到B B transform(B, A) → B变成 delete(0, 3) (不变) 但如果先收到B再收到A A transform(A, B) → A变成 insert( world, at 2) (位置变了!)OT的核心问题是transform函数需要保证transform(transform(op1, op2), op3) transform(transform(op1, op3), transform(op2, op3))——这在数学上是NP-hard问题。Google做了十几年才把OT做稳定。CRDT的核心思想给每个字符分配一个全局唯一的、可排序的ID。两个用户同时在不同位置插入字符时通过ID排序自动确定最终顺序// CRDT字符的唯一ID [逻辑时钟, 用户ID] // 例如: [5, userA] 表示userA的第5次操作 // 用户A插入x在字符[3,B]和[4,B]之间 // 用户B同时在[3,B]和[4,B]之间插入y // 最终结果: [3,B],[5,A],[6,B],[4,B] → Bx...y...B // 因为 [5,A] [6,B] → x 排在 y 前面CRDT不需要中央服务器协调操作顺序天然支持离线编辑和P2P同步。三、最终选择CRDT及其实践选择CRDT基于三点考虑离线编辑支持。目标应用场景包括移动端网络不稳定。OT在离线场景下需要复杂的操作缓冲重连同步逻辑。实现复杂度。OT的正确transform函数极其难写。CRDT的核心数据结构RGA/List CRDT虽然有学习成本但一旦理解后实现逻辑清晰。社区趋势。YjsCRDT的Star数和活跃度超过ShareDBOT表明CRDT正在成为主流选择。基于YjsWebSocket的实现import * as Y from yjs; import { WebsocketProvider } from y-websocket; // 服务端 const ydoc new Y.Doc(); // 客户端A const docA new Y.Doc(); const wsProviderA new WebsocketProvider( wss://collab.example.com, document-123, docA ); const ytext docA.getText(content); // 插入文本——CRDT自动处理冲突 ytext.insert(0, Hello); // 监听远程变更 ytext.observe((event) { event.changes.delta.forEach((delta) { if (delta.insert) { console.log(远程插入了: ${delta.insert}); } if (delta.delete) { console.log(远程删除了 ${delta.delete} 个字符); } }); }); // Undo/Redo支持Yjs内置 const undoManager new Y.UndoManager(ytext); undoManager.undo(); undoManager.redo(); // 离线编辑——Yjs自动处理 // 用户断线后继续编辑重连后自动同步 wsProviderA.on(status, (event: { status: string }) { if (event.status connected) { console.log(已同步离线编辑内容); } }); // 感知其他用户光标位置、选择范围 const awareness wsProviderA.awareness; awareness.setLocalState({ name: User A, color: #ff0000, cursor: { index: 5, length: 0 }, }); awareness.on(change, () { awareness.getStates().forEach((state, clientId) { if (clientId ! docA.clientID) { // 渲染其他用户的光标 renderRemoteCursor(state.cursor, state.color, state.name); } }); });四、实际挑战与解决方案挑战一文档大小增长CRDT的每个操作都保留历史用于冲突解决文档越长元数据越大。一篇1000字文档的CRDT元数据约50KB。解决方案定期做垃圾回收——将已删除的内容真正移除而非仅标记deleted将连续插入的操作合并。Yjs的gc选项默认为true。挑战二WebSocket连接管理1000个用户同时编辑一份文档时每个变更都要广播到999个其他用户——O(n²)的复杂度。解决方案分片Sharding。将文档按段落分片每个分片最多100个用户。同一段落内广播跨段落不广播。挑战三大文本粘贴用户粘贴一篇5000字的文章到协作文档中——这在CRDT中产生5000个插入操作需要在1秒内同步到所有协作者。解决方案使用Yjs的transact批量操作——所有变更在一次事务中完成只产生一个更新事件ydoc.transact(() { // 批量插入只触发一次同步 pastedText.split(\n).forEach((line, idx) { ytext.insert(cursorPos idx, line \n); }); });五、总结OT vs CRDT的选型决策核心需要强一致性 中心化架构 → OT如Google Docs需要离线支持 去中心化 → CRDT如Notion、Figma不想处理OT的数学复杂性 → CRDT已有大量OT基础设施 → 继续OT当前选择的CRDT方案Yjs运行6个月的表现支持最多200人同时编辑一份文档同步延迟P99约300ms离线编辑重连后5秒内完成同步。唯一的运维痛点是Yjs的文档体积会随时间增长需要定期做服务端持久化垃圾回收。如果重来一次仍然会选择CRDTYjs——不是因为CRDT一定优于OT而是在实现正确性和实现简单性之间CRDT的简单性为团队省去了大量调试OT transform函数的痛苦。