关于后端:常见面试题-如何设计Google-Docs

常见面试题 – 如何设计 Google Docs？

一图胜千言。明天咱们来看看设计 Google Docs 的几个次要模块。

首先咱们来看看 功能性需要：

• 在线编辑
• 合作编辑 – 容许多人同时编辑同一个文档。

• 文件存储 – 反对文件系统，容许查看文档、增加文档、批改文档、删除文档。

咱们先简化一下问题。如果是一个单机版的在线文档，没有多人合作的要求，那其实只有将本地的文档同步到远端就能够了。如下图所示，设计中的难点在于 放弃本地文档和远端文档的数据同步。如果发送到文件服务的过程中丢了数据，那么就有点难堪了。所以不论是给各种文件操作定序，还是给文档内容设置 CRC 校验，都能够保证数据一致性。

那么如果退出 多人合作编辑 呢？

下图先将各个组件串联在一起以便与咱们剖析问题：

1. 客户端编辑器和 WebSocket 服务器建设长连贯，以便及时向 WebSocket 服务器发送文档编辑操作。
2. WebSocket 服务器会解决文档编辑操作，并将它们发送到音讯队列中。
3. 文档操作服务器会从音讯队列耗费客户端的操作事件，并应用合作算法生成转换后的操作。这个过程叫做操作转换（Operational Transformation），就是依据多人对文档的批改状况来失去最终的后果，并更新每个人的操作。
4. 为了给用户更好的实时编辑体验，最近的操作会先应用缓存来存储。
5. 文档最终会存储在数据库或其余文件系统中。存储的数据分为三个局部：文件元数据，文件内容和文件编辑操作。

退出多人合作后，最大的挑战之一是须要 实时解决编辑抵触。解决抵触的常见的合作算法包含：

1. 操作转换 (OT, Operational transformation)
2. 差分同步 (DS, Differential Synchronization)
3. 无抵触复制数据类型 (CRDT, Conflict-free replicated data type)

依据维基百科，Google Docs 应用的是 OT，而 CRDT 是实时并发编辑的一个沉闷钻研畛域。

OT 的根本思维和 Git 相似。服务器晓得每个用户的批改是基于哪一个版本的，会尝试把各人的操作合并。

如果你对这些算法感兴趣，能够在后盾通知我。

【关注公众号 ByteByteGo 获取高清图】