如何实现多人协作的在线文档

网络
由于业务需要,在工作中接触到了在线文档、在线Excel。但是在调研阶段发现国内相关文章比较匮乏,所以结合工作实践和自己的一些思考,写几篇文章剖析实现在线文档和在线Excel的一些技术方案。

由于业务需要,在工作中接触到了在线文档、在线Excel。但是在调研阶段发现国内相关文章比较匮乏,所以结合工作实践和自己的一些思考,写几篇文章剖析实现在线文档和在线Excel的一些技术方案。为了避免涉及到公司隐私,所以文章中一些数据结构的设计和非关键场景都写的比较简略。我们主要从需求分析、方案设计、技术选型等几个方面介绍如何实现多人协作的在线文档。

需求分析

我们借鉴领域驱动模型的思路进行需求分析。需求中包含「人」「文档」两个实体。「人」的主要属性有:用户ID、用户名。「文档」的主要属性有:文档ID、文档内容、创建者、创建时间。人和文档的关系非常简单:一个人可以有多个文档,一个文档只归属某一个人,属于一对多的关系。

因为文档内容不能被随便阅读和修改,所以还要有权限管理,「权限」是一种值对象。权限的值有:阅读、编辑。人对文档可以有阅读权限或编辑权限。

还有一个最关键的问题就是「协作」。协作是多个「人」,对一篇文档同时操作。协作的过程中需要把多个人编辑的内容,经过合并转换为最终保存的文档内容。协作的过程中需要让文档编辑人员看到当前「一起协作的对象」和协作对象「实时编辑的内容」

为了实现以上功能我们把系统拆分成五大模块:人员管理、文档管理、权限管理、协作和前端文档编辑器。

方案设计

人员管理

因为人员管理不是本文的重点,所以我们只做一个简要的设计,主要是为了辅助说明后面的设计。

表结构主要字段有:

下面介绍下该模块的主要逻辑。

用户注册

  1. 前端把用户填写的用户名、密码、手机号等信息加密后发送给服务端。
  2. 服务端拿到数据,再和生成的唯一用户ID一起,存入表中。

用户登录

  1. 前端要求用户输入用户名+密码并发送给服务端,服务端校验用户名和密码的正确性。
  2. 校验通过后,根据「用户名+密码+密钥+时间戳」生成有时效性的Token,返回给客户端。
  3. 登录之后前端所有请求都带着Token信息。服务端根据Token获取当前登录用户信息并判断请求是否合法。

文档管理

文档的表结构设计:

下面介绍下该模块的主要逻辑。

创建文档

  1. 前端发送文档名称、文档内容给服务端
  2. 服务端生成唯一的文档ID,从Token中获取到用户ID,获取服务器时间然后把数据一起存入数据库中
  3. 服务端返回文档ID给前端

修改文档

这里的修改是指修改文档的内容。我们为了及时保存用户编辑的内容,需要在用户编辑过程中实时把数据传递给服务端。如果每次都发送全部文档内容给服务端,虽然服务端的处理逻辑会比较简单,但是每次请求都有很多冗余数据,浪费大量的带宽。所以我们最好只发送变化的内容给服务端,让服务端根据当前文档内容和变化内容合并生成最新的文档内容。

如何发送变化的内容呢?我们可以把用户对文档内容的操作分成三类:「新增、修改、删除」。新增就是给文档添加内容,修改就是修改文档的某一段内容,删除就是删除了文档的某一段内容。对这三类操作我们可以使用Json形式来表示:

  1. {  
  2.   op:""// 操作 add:新增,update:修改, delete:删除     
  3.   start:""// 开始位置下标     
  4.   end: ""// 结束位置下标     
  5.   text:""// 修改内容 

这样修改文档的流程就是

  1. 前端生成修改数据发送给服务端
  2. 服务端从数据库中获取文档内容,然后根据用户的行为合并操作,最后保存到数据库中。

用户在编辑一篇文章时,往往需要很多次数据传输。Json的数据格式虽然能很好的表达语意,但是每次传输也需要发送较多的字节,浪费带宽;而且Json的序列化和反序列化过程也相对低效。我们可以采用Google的Protobuf协议来代替,它是基于二进制的传输协议,在传输内容大小和解析速度上都强于Json。

  1. message Doc {     
  2.   enum Op{         
  3.     add:0;         
  4.     update:1;         
  5.     delete:2;     
  6.   }     
  7.   required Op op = 0;     
  8.   required int32 start = 1;        
  9.   required int32 end = 5;     
  10.   string text = "修改内容"     

这里协议比较简单,自己按照规则拼接字符串也是可以的。考虑到后续功能的可扩展性,还是建议采用Protobuf协议。

修改文档的流程还有顺序问题,我们假设用户的操作是这样的:

  1. 用户先删除了5个字“12345”
  2. 添加了5个字“一二三四五”
  3. 又修改了其中的前两个字是“你好”

正常顺序下最后的结果是:「你好三四五」。但是如果服务端的执行顺序变成了3、1、2,那最后的结果变成了:「一二三四五」。这显然是不符合预期的。所以我们要保证服务端顺序处理前端发过来的请求。

保证顺序执行有几个方案:

  1. 前端请求由异步变成同步
  2. 前端每次请求都生成连续递增的ID,服务端判断如果递增ID不连续了,就短暂的等待
  3. 把对同一个文档的操作代理到同一个服务器,服务端单进程接收请求,并把数据存入有序队列。队列的消费端正常消费就可以了。

方案一在请求多的时候,处理效率太低会影响用户体验,可以直接排除掉。方案二主要依赖客户端生成递增ID,是比较不错的方案。方案三依赖单进程和有序队列保证顺序。虽然单进程在并发量高的情况下很难抗压,但是如果根据文档ID去做负载均衡也可以比较好的控制流量,毕竟对一个文档的修改QPS也高不到哪去。
当然也可以把方案二和方案三结合使用。

查看文档

  1. 前端发送要查看的文档ID给服务端
  2. 服务端根据文档ID返回文档内容

删除文档

  1. 前端发送要删除的文档ID给服务端
  2. 服务端根据文档ID删除对应文档

权限管理

当前需求的权限场景特别适合「ABAC」的权限模型。
用户属性:只要是正常登录用户即可
环境属性:普通的文档内容
操作属性:文档的读和写
对象属性:文档

所以,我们存储权限信息的表结构主要字段有:

下面介绍下该模块的主要逻辑。

开通权限

  1. 前端发送文档ID和权限类型(读/写)给服务端
  2. 服务端根据文档ID和Token中的用户ID,在权限表中添加记录,并返回成功

删除权限

  1. 前端发送文档ID和权限类型(读/写)给服务端
  2. 服务端根据文档ID和Token中的用户ID,在权限表中删除记录,并返回成功

校验权限

我们可以实现一个中间键,当用户请求某文档内容时,判断其是否为创建者。如果不是再从权限表中查询用户是否有权限查看或者编辑权限。修改文档内容时也是同样的逻辑,就不再赘述了。

协作

合并冲突

当多个人同时修改一个文档时,处理内容冲突的几种方式:

  1. 文档加锁:当有人修改文档时,对整个文档加写锁,别人都只能看不可编辑。虽然实现简单,不过协作的体验会特别差。
  2. diff+patch的合并算法:diff+patch是常用的文档内容比较和合并算法,Linux本身就提供了diff和patch命令支持文件的比较和合并。git也使用了diff+patch方法来合并文件,当无法解决冲突时,会把冲突抛给用户手动合并。
  3. OT算法:相比diff+patch来讲OT算法往往能带来更好的合并结果。不过OT算法的实现也更复杂一些。目前Google文档、腾讯文档、石墨文档等都是采用了OT算法。我们后面单独写文章来聊一聊diff+patch和OT算法。

协作通知

为了更好的协作,文档编辑者需要看到同时编辑文档的人,还需要看到别人修改的内容,来减少冲突,达到协作的目的。

大家打开文档编辑页面的时间是不同步的,为了让大家「互相看到」,而且互相看到对方「修改的内容」,就需要服务端主动给客户端推送消息。此场景下采用长链接的方案是比较合适的。

前文也提到过,文档修改频繁的时候,发送数据的频次会很高,如果是HTTP请求会导致每次请求都携带头信息,建立连接等开销,所以修改文档内容的数据上报也可以采用长链接。同时,服务端维护一个「协作列表」来存放所有正在被编辑的文档和每个文档的在线用户,可以类比为一个聊天室。

文档修改者加入

  1. 前端打开一个文档时,发送请求给服务端,服务端检查协作列表中是否有当前文档。
  2. 如果有则把当前用户加入此文档修改者列表;如果没有就把当前文档加入协作列表,同时把当前用户ID写入其中。
  3. 服务端通过长链接给文档列表中的所有其他用户推送消息,告知大家有用户加入协作。

文档修改者退出逻辑和加入基本相同就不再赘述了。

「修改内容」

  1. 前端把修改数据发送给服务端
  2. 服务端暂存多个用户的操作,并根据OT算法把用户操作合并,最后和数据库存储的文档内容合并
  3. 把合并完的文档内容保存到数据库中
  4. 服务端根据文档ID,读取协作列表中的用户,给所有用户发送合并结果
  5. 客户端把合并结果与本地文档内容合并

文档编辑器

「编辑功能」

文档编辑器需要支持,文档内容编辑、文字样式调整、插入图片、插入链接等一系列功能。 实现内容可编辑的方案有textarea标签和contenteditable属性可以选择。但是textarea标签对其他需求的实现很难支持,而且不方便控制。所以我们选用contenteditable=true来实现文档内容的编辑。

「上报功能」

文档修改时,内容的上报,需要文档编辑器处理好。不能用户每输入一个字符就上报一次,这样频繁的发送数据会给服务端带来很大压力,也是没有必要的。所以客户端的上报需要做防抖处理。上报的过程中有可能会因为网络闪断等原因导致上报失败,此时需要重试。

服务可能因为长时间的网络中断或者服务器异常导致数据上报失败。此时前端可以先把用户修改存储在浏览器本地的LocalStorage中,不过需要注意浏览器本地缓存通常有5M的大小限制。本地存储除了在网络异常时发挥作用,在实现Ctrl+Z操作时,也可以起到记录之前操作的作用。

「长链接」

需要有一个单独的模块管理长链接,统一处理上报的接口和服务端下发的数据,做好数据的封装和解析;并及时的反馈给用户连接成功、数据保存成功、连接异常等信息。

「大文档的加载」

对于大文档的加载,我们需要做异步处理。根据滚动条滚动的位置,在服务端异步的获取更多数据。

「其他功能」

前端编辑器的其他模块我们可以根据其功能范围拆分:比如控制文字大小、颜色的功能模块;控制文字对齐方式的模块;控制插入内容的模块;支持Ctrl+C、Ctrl+V、Ctrl+Z的模块等等。拆分好之后根据功能实现就可以了,这里就不一一分析了。

技术选型

「存储」

存储方面,当前场景使用关系型数据库比较合适。我们可以根据文档和用户的数量级选择合适的数据库。通常千万级别的数据量选择MySQL就可以了,如果数据更多的话我们可以选择TIDB或者MySQL分库分表的方案。
当然采用MongoDB和PG也都可以满足需求,我们可以结合公司的DBA运维能力自行选择。

补充一下,如果考虑文档内容的搜索,只选择一种存储结构是不够的。需要单独为文档建立索引,可以选择使用ES集群为文档创建全文索引。而且索引的创建和MySQL的增删改比起来是比较耗时的操作,所以创建索引往往放在异步流程中。而且用户创建一个文档也很少立马就对它搜索。

「长链接」

当前常用的长链接方案主要有“HTTP/2 + SSE”和WebSocket两种,WebSocket更成熟一些,优先选择。

「消息队列」

建议采用RocketMQ,因为

  1. RocketMQ支持同步/异步刷盘,支持同步/异步写副本,消息的可靠性更有保障。
  2. RocketMQ支持顺序消息。

当然写入性能方面要比Kafka弱一些。但是在线文档的场景里,消息的可靠性和顺序更加重要。

架构设计

基于上面的分析,我们设计的部署架构图如下

其中,接入层负责用户的鉴权和长链接保持;其他各模块负责各自的功能。文档修改的队列我们采用MQ发送,文档管理模块消费。Redis我们用来存放多人协作时的文档和用户对应关系。当然数据量不大时MQ也可以使用Redis临时代替。

总结

以上就是我对多人协作在线文档的分析和设计方案,其中包含了前后端交互流程、文档的存储和服务的部署方案。为了突出主要问题和逻辑,文中很多设计和技术点都是点到为止,给大家造成困扰的地方大家可以自行搜索下关键字或者留言交流。

责任编辑:梁菲 来源: 一行舟
相关推荐

2021-09-08 15:43:03

在线写作协作文档办公软件

2011-11-30 16:37:58

sync

2021-03-28 17:21:15

Git分支策略

2011-11-30 16:08:14

YC新锐Stypi

2021-08-30 17:35:17

开发在线文档多人协作

2022-03-04 09:02:01

StoryBoard工具git

2012-06-12 09:51:43

在线思维

2021-08-30 14:41:16

在线文档协同办公腾讯文档

2011-11-30 15:57:18

2016-11-10 07:50:55

群晖云端Office

2011-11-30 16:06:16

20个实用的在线协作

2011-11-30 15:57:18

谈企业协同应用

2009-07-14 08:26:46

微软网络版Office网络版Office功能Office 2010

2011-11-30 16:20:56

20款免费或廉价的在线

2021-08-30 16:48:24

在线文档

2021-08-30 14:28:56

在线写作协作文档办公软件

2011-11-30 15:28:32

在线协作系统

2011-11-30 16:21:32

5款在线协作数字白板

2020-02-05 18:24:24

飞书
点赞
收藏

51CTO技术栈公众号