多人协同的核心就是OT算法「 Operation Transform 」
- 相关一般使用的第三方库 ot.js / shareDB
OT 算法核心原则
-
last victory 最后胜利原则,最粗暴的方式也是最后兜底的原则,是OT 算法最基础的原则,谁后来就听谁的
- 比如在 Node 单线程的环境下,两端就算同时更新,因为网速的影响,一定会有一个先后请求顺序,OT算法会以每次客户端提交的版本号来进行广播更新,比如 A 的这次更改就会在原来1的版本加1,作为版本2提交
-
Priority 优先级原则,主要判断只是版本冲突,不是操作冲突,如果是操作冲突的话,优先级原则就不好使了
- 比如 A 先是修改,B 是删除,那么就会就直接应用了删除操作
- 如果是先删除 后修改的冲突,一般会有两种方案,要么就是返回给修改提示已删除然后根据修改后续操作打包成一个新的版本发布。要么就是不给提示直接作为不同的版本存在
-
Position 位置原则,假设都是操作冲突的话,就会做追加处理
- 比如 A 修改为 ‘hello world’ B 修改为 ‘hello banana’ ,那么就会追加为 ‘hello world banana’ 的版本
-
low cost 最小代价原则,涉及到一个版本有n 个操作的时候,会把其中没有冲突的地方先更新,然后把有冲突的地方按照客户端的需求更新成不同版本,看采用谁的,类似 git meger ,其中也触及到 撤销 和 回退
OT 算法的实现
OT 规定需要有一套完整的版本控制机制和操作描述符来作为基架
- 设计的时候一定要有版本的概念,和操作描述符(也就是crud操作),其中除了创建、删除,OT 不需要更新操作,因为用 delete + create 比 update 在后续的操作和版本回退中更简单方便,如果追加了一个 update 操作,那么服务端需要时时刻刻去验证这个单元格是不是存在的,如果将一个 update 操作拆分成了 delete + create 那么就不需要再去关心单元格存不存在了
- 代码实现 OT 算法的各个原则逻辑