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

关于OT算法的协同的核心算法部分已经写完了。

再简单谈一下关于协同文档底层架构的问题，因为目前我的方案还没有最终落地所以并不清楚实际情况中会出现哪些问题，

说一下传输层，传输层是用的MQTT，得益于RabbitMQ的插件MQTT，实现了消息队列，当然了MQ和Redis是老搭档了，少不了Redis的入场，Redis基本上只负责服务器缓冲层的作用，因为大量的JSON数据会传输到后端存储起来，用Redis最好不过了，这里使用的是Redis的有序set，这样咱们的数据进来的时候可以根据时间戳进行排序，等到新用户进来的时候，可以快速从缓冲区拿出数据，并且很快的编译出完整的文档来，目前Mysql的作用也是很大的，使用Mysql主要是考虑有以下2点问题：

Redis缓冲区如果数据过多一定会出现新用户进入前端处理太多的逻辑导致页面卡死
Redis配合Mysql也是市面上常见的解决方案
Mysql作为持久层，框架更多，方便理解，对于大数据存储更加得心应手

基本逻辑很简单，当用户离开时候，会通过Mqtt拿到离开指令并给与当前页面的文本（这里的操作是同步的，程序备份的时候，所有用户的改动都将存在本身的缓存区中，等待缓冲区结束），程序将Redis的缓存区数据拿出，备份到mysql缓冲区历史中，并将Redi缓冲区清空，mysql存储一版本的成型文档，当新用户进入的时候，首先会从mysql拿到成型文档，接下来会从该版本之后的缓存区版本实现ot整合操作，形成最终文档。

我这里的方案完全依赖于前端，Ot算法在前端实现，在前端进行，后端只做存储，和消息传递，这样的好处不用多说，将算法的压力分摊到各个用户浏览器，后台的压力极小，缺点也很明显，没办法在后台处理各种逻辑，全都由用户动作处理。

（完）