最近跟着大佬学习的项目因为涉及到多人协同，所以有了解到一点 OT 算法的概念
下面主要是我的一些笔记内容，只是大概的简介，后面会随着学习进度慢慢的更新，maybe…
什么是 OT 算法
即是 Operation Transform 的缩写，是一种处理协同编辑的算法。主要作用于多人同时编辑的逻辑处理，不会因为并发修改而导致冲突，很好解决了用户数据丢失，版本维护等问题
OT 算法的核心原则
场景：OT 算法中是靠版本号来区分提交版本的，服务端只会保存最新的一个版本号，假设 A 和 B 的初始版本都是 1 ，那么 A 提交一次的版本号就为 2，服务端就会保存版本号为 2 的版本，同时把版本 2 更新给 B ，B 再次更新就会以版本 2 修改更新版本 3 提交，如果两端都同时操作了一个地方提交，那就需要 OT 算法来处理冲突了「其中主要分为 操作冲突 和 版本冲突 」，主要涉及到 OT 算法中的几大原则如下
操作冲突：指的是同时编辑修改了同一个位置而引发的冲突
版本冲突：指的是同一个地方 A 和 B 的版本操作不一样，比如 删除 和 修改
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 那么就不需要再去关心单元格存不存在了