OT算法的协同文档制作的底层基础架构记录

关于OT算法的协同的核心算法部分已经写完了。 再简单谈一下关于协同文档底层架构的问题,因为目前我的方案还没有最终落地所以并不清楚实际情况中会出现哪些问题, 说一下传输层,传输层是用的MQTT,得益于RabbitMQ的插件MQTT,实现了消息队列,当然了MQ和Redis是老搭档了,少不了Redis的入场,Redis基本上只负责服务器缓冲层的作用,因为大量的JSON数据会传输到后端存储起来,用Redis最好不过了,这里使用的是Redis的有序set,这样咱们的数据进来的时候可以根据时间戳进行排序,等到新用户进来的时候,可以快速从缓冲区拿出数据,并且很快的编译出完整的文档来,目前Mysql的作用

OT算法-前端锁的解决方案

(operational-transformations) 此篇文章写给一同在进行ot算法实践中的朋友们,希望抛砖引玉,有对ot算法感兴趣的小伙伴可以联系我一下,目前关于此算法的一些细节处理上我还有一点点的疑惑部分,希望能讨论解决 巨人的肩膀 我们可以先看一下其他人是如何解决的: 前端状态图 Purpose 目的 OT算法解决协同编辑问题在在落地中客户端设计可以简化为三种状态和三个方法 如何解决 数据结构设计如下: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 client { version //记录当前版本 state

OT算法-关于版本冲突相差过大的解决方案

(operational-transformations) 此篇文章写给一同在进行ot算法实践中的朋友们,希望抛砖引玉,有对ot算法感兴趣的小伙伴可以联系我一下,目前关于此算法的一些细节处理上我还有一点点的疑惑部分,希望能讨论解决 Purpose 目的 如果A客户端对文档进行了多次编辑,B客户端因为网络原因没有及时同步到A客户端的OP操作,继续在老版本编辑并向服务端发送OP操作会出现什么情况呢? 如何解决 OT算法通过链式反应法则解决对老版本OP操作的问题 前边说过:transform算法的解决方案,这次也借助这个核心算法解决 基础操作分为三种: R = Retain,保持操作 I =

OT算法-transform代码解析

(operational-transformations) 此篇文章写给一同在进行ot算法实践中的朋友们,希望抛砖引玉,有对ot算法感兴趣的小伙伴可以联系我一下,目前关于此算法的一些细节处理上我还有一点点的疑惑部分,希望能讨论解决 Purpose 目的 在目前的ot算法中,对我们来说就是一个黑盒,我们知道给一定的输入,它会有正确的输出,但是它是如何做到的呢? 在介绍它的实现之前,我们需要抽象一下我们的操作行为,在之前我们的描述都是 第3个字符行后面插入了一个‘d’ 这里怎么转换成程序识别或者能用代码表达的呢?其实这也是OT的关键。 这里我直接揭晓答案: 所有对文本的操作都可以抽象成三个原

ot算法两个字符串如何生成ot操作转换的工具

(operational-transformations) 此篇文章写给一同在进行ot算法实践中的朋友们,希望抛砖引玉,有对ot算法感兴趣的小伙伴可以联系我一下,目前关于此算法的一些细节处理上我还有一点点的疑惑部分,希望能讨论解决 Purpose 目的 在目前的ot算法中,您并不知道两个字符串是如何将一个字符串转换为第二个字符串的,在使用操作转换(operational-transformations,OT)时,您必须知道文本块何时被插入、删除或替换。您只处理字符串中的连续更改(连续意味着所有更改都在一起)。从来没有超过一组的变化) 即可。 Here’s an example: 下面是一