之前的解决方案

单人编辑加锁——>多人编辑缓存到本地，选择最新的副本，数据丢失

在线

架构：传统的C/S架构，主要解决数据同步问题，即用户输入准确到达服务器端，同时考虑网络传输问题与性能，前端使用的PouchDB开源方案

多人

问题最大，即分布式系统中的Multiple Leader Duplication，多个用户也就是多个Leader，同步数据必然会遇到冲突。
解决方法：

• 避免直接冲突，不让多个用户编辑同一处，简单易实现
• 用户自己解决，适用于大部分用户
• 利用时间戳。但是同步出现问题，会丢失很多输入，《设计数据密集型应用》
• 冲突解决需要选主，现成解决方案zookeeper，权限管理注意session传递。

文档编辑

文档编辑就是传统的界面开发，常用的解决方案就是Vue这样的类Flux架构，编辑器选择Quill（数据模型为Delta）—（Slate -> 数据模型为JSON，缺少开源方案）
整个应用的状态，即model一共有三大块：

• 文档的状态，即文档自身的内容，包括样式；
• 编辑器的状态，比如编辑器的光标位置、选中状态、编辑器菜单等等（前端）；
• 应用自身的状态，比如登录状态、用户数据、权限管理等等。

多人协作冲突解决：OT 与CRDT

数据一致性算法，OT操作转换，CTRD无冲突复制
基于OT的协同编辑框架 shardDB
基于 CRDT 的协同编辑框架 Yjs
OT：当编辑器接收到协同操作时，需要对 Undo栈、Redo栈中的所有操作循环执行操作转换逻辑，undo 或者 redo 时最终执行的是转换后的操作。 OT 算法的实现依赖于编辑器数据模型的设计，不同的数据模型需要实现不同的操作转换算法。