Skip to content

四火的唠叨

一个纯正程序员的啰嗦

Menu
  • 所有文章
  • About Me
  • 关于四火
  • 旅行映像
  • 独立游戏
  • 资源链接
Menu

常见分布式应用系统设计图解(九):协同编辑系统

Posted on 11/12/202008/14/2022 by 四火

这里讲的 “协同编辑”,指的是 “Collaborative Editing”,多个人同时一起编辑同一个文件,比如说 Google Docs,国内的有有道云协作、石墨文档之类的。这样的系统倒不如我们前面提到的那些应用系统那么 “火”,但是,依然具备相当的典型性。

第一印象,这样的一个系统,我们可以简单做出如下归类:

  • 这是一个文件编辑系统,这是最最基础的一个功能性需求,它就好像是 Windows 下的记事本,只不过它是在线的。
  • 这是一个分布式系统,客户端/浏览器可以在不同的地方,通过网络和服务端联结,用户的编辑行为转化为请求发送给服务端。
  • 这是一个异步系统,编辑编辑过程中,事件都是由不同用户的浏览器/客户端上对文件的来触发的。

因此,根据上面的三条,我们可以 “没什么新意” 地归纳出一些相应的需求和限制,不过,这个系统里面还隐含了这么几个特殊的要求:

  • 自动保存:所见即所得,所见即所存。因此文件的变更需要自动同步到服务端保存,并且显然一般情况下,这是一个增量同步。这个增量同步是双向的,既有客户端到服务器,也有服务器到客户端。
  • 冲突处理:在多数情况下,系统要能够自动处理合并多人对于同一个文件在同一时间的修改,这个文件多数是文本文件,或者至少是内容结构化了的文件。
  • 版本管理:要能够追溯修改历史,回退版本,甚至单独剔除或合并特定用户的修改等等。
  • 权限管理:不同的人可以具备不同的权限,比如有的人只可以读,有的人可以写。
  • 图中虚线表示控制流,也包括协同编辑文件的创建,但是实际的文件内容数据流动,是通过实线完成的。
  • 上半部分表示的是一个文件创建的过程,Application Server 接受请求,通过 Metadata Service 把文件创建出来。文件赋予不同的权限组,Auth Service 管理权限记录。
  • 下半部分,用户把编辑内容增量写入 Channel Service,这样的事件经过鉴权和简单处理后放入待处理队列。Collaboration Service 从队列中取出事件并处理,它在完成编辑操作以后,把 merge 完的变更事件写到另一个队列中去,并通过 Channel Service 把更新推送给另一个用户。
  • 一般的系统,在服务端推送的时候建立长连接的比较多,但是这类系统在客户端推送和服务端推送两头都要建立长连接。 客户端每发生一次变更,就要把事件通知到 Channel Service,反之亦然 。之所以这样做,有两个原因,
    • 一是因为数据要尽可能实时地同步;
    • 二是这样的数据包一般都比较小,长连接可以减少开销。
  • 所谓增量变更,常见的包括三种:insert、delete 和 retain,前两个用于对当前光标位置的字符增删操作,后者用于移动光标。
  • 对于文件修改的冲突自动解决和合并,有一个这类系统使用的特定的技术,叫做 Operational Transformation(OT)。基本上就是把根据用户编辑文档的版本和字符所在位置,以及编辑行为(增加或/和删除),转换并合并编辑到实际文档中位置的一种技术。
  • 对于修改历史记录的存储,肯定要存放一个基础版本加上每个变更。每个变更都很小,且按照时间序列排好,这样的变更数据使用支持索引的 KV 数据库或者列数据库都可以实现。
    • 但是,如果只使用这个机制,在变更非常多的情况下,读出所有数据才能得到最新版本,效率很低,其中一个改进的办法是一定变更数量以后进行 archive,或者说对一系列变更做一个 snapshot。
    • 因此,整体看来,这就是一个 Snapshot + WAL(Write Ahead Log)的典型实现。

这是《常见分布式系统设计图解》系列文章中的一篇,如果你感兴趣,请参阅汇总(目录)寻找你其它感兴趣的内容。

文章未经特殊标明皆为本人原创,未经许可不得用于任何商业用途,转载请保持完整性并注明来源链接 《四火的唠叨》

×Scan to share with WeChat

你可能也喜欢看:

  1. 常见分布式应用系统设计图解(十):电商秒杀系统
  2. 常见分布式应用系统设计图解(一):即时消息系统
  3. 常见分布式应用系统设计图解(八):文件同步分享系统
  4. 常见分布式应用系统设计图解(十四):日志系统
  5. 常见分布式应用系统设计图解(四):输入建议系统

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

订阅·联系

四火,啰嗦的程序员一枚,现居西雅图

Amazon Google Groovy Hadoop Haskell Java JavaScript LeetCode Oracle Spark 互联网 亚马逊 前端 华为 历史 同步 团队 图解笔记 基础设施 工作 工作流 工具 工程师 应用系统 异步 微博 思考 技术 数据库 曼联 测试 生活 眼界 程序员 管理 系统设计 缓存 编程范型 美股 英语 西雅图 设计 问题 面向对象 面试

分类

  • Algorithm and Data Structure (30)
  • Concurrency and Asynchronization (6)
  • System Architecture and Design (43)
  • Distributed System (18)
  • Tools Frameworks and Libs (13)
  • Storage and Data Access (8)
  • Front-end Development (33)
  • Programming Languages and Paradigms (55)
  • Testing and Quality Assurance (4)
  • Network and Communication (6)
  • Authentication and Authorization (6)
  • Automation and Operation Excellence (13)
  • Machine Learning and Artificial Intelligence (6)
  • Product Design (7)
  • Hiring and Interviews (14)
  • Project and Team Management (14)
  • Engineering Culture (17)
  • Critical Thinking (25)
  • Career Growth (57)
  • Life Experience and Thoughts (45)

推荐文章

  • 谈谈分布式锁
  • 常见分布式系统设计图解(汇总)
  • 系统设计中的快速估算技巧
  • 从链表存在环的问题说起
  • 技术面试中,什么样的问题才是好问题?
  • 从物理时钟到逻辑时钟
  • 近期面试观摩的一些思考
  • RSA 背后的算法
  • 谈谈 Ops(汇总 + 最终篇):工具和实践
  • 不要让业务牵着鼻子走
  • 倔强的程序员
  • 谈谈微信的信息流
  • 评审的艺术——谈谈现实中的代码评审
  • Blog 安全问题小记
  • 求第 K 个数的问题
  • 一些前端框架的比较(下)——Ember.js 和 React
  • 一些前端框架的比较(上)——GWT、AngularJS 和 Backbone.js
  • 工作流系统的设计
  • Spark 的性能调优
  • “残酷” 的事实
  • 七年工作,几个故事
  • 从 Java 和 JavaScript 来学习 Haskell 和 Groovy(汇总)
  • 一道随机数题目的求解
  • 层次
  • Dynamo 的实现技术和去中心化
  • 也谈谈全栈工程师
  • 多重继承的演变
  • 编程范型:工具的选择
  • GWT 初体验
  • java.util.concurrent 并发包诸类概览
  • 从 DCL 的对象安全发布谈起
  • 不同团队的困惑
  • 不适合 Hadoop 解决的问题
  • 留心那些潜在的系统设计问题
  • 再谈大楼扔鸡蛋的问题
  • 几种华丽无比的开发方式
  • 我眼中的工程师文化
  • 观点的碰撞
  • 谈谈盗版软件问题
  • 对几个软件开发传统观点的质疑和反驳
  • MVC 框架的映射和解耦
  • 编程的未来
  • DAO 的演进
  • 致那些自嘲码农的苦逼程序员
  • Java 多线程发展简史
  • 珍爱生命,远离微博
  • 网站性能优化的三重境界
  • OSCache 框架源码解析
  • “ 你不适合做程序员”
  • 画圆画方的故事

近期评论

  • panshenlian.com on 初涉 ML Workflow 系统:Kubeflow Pipelines、Flyte 和 Metaflow
  • panzhixiang on 关于近期求职的近况和思考
  • Anonymous on 闲聊投资:亲自体验和护城河
  • 四火 on 关于近期求职的近况和思考
  • YC on 关于近期求职的近况和思考
  • mafulong on 常见分布式基础设施系统设计图解(四):分布式工作流系统
  • 四火 on 常见分布式基础设施系统设计图解(八):分布式键值存储系统
  • Anonymous on 我裸辞了
  • https://umlcn.com on 资源链接
  • Anonymous on 我裸辞了
© 2025 四火的唠叨 | Powered by Minimalist Blog WordPress Theme