实时协同编辑-它是如何工作的？

我正在编写一个应用程序，我希望在其中有接近实时的文档协同编辑功能(非常类似于谷歌文档样式编辑)。

我知道如何跟踪光标的位置，这很简单。只需用当前用户 id、文件名、行号和行号轮询服务器，即可将其存储在数据库中，该轮询请求的返回值就是其他用户的游标位置。

我不知道如何做的是更新文档的方式，它不会抛出您的光标，并强制完全重新加载，因为这将是远远慢于我的目的。

这真的只需要在谷歌浏览器上运行，最好是在火狐浏览器上。我不需要支持任何其他浏览器。

35042 次浏览
小开
最佳答案

幕后用于合并来自多个对等点的协作编辑的算法称为 操作转换。但是实现它并不是微不足道的。

有用的链接请参见 这个问题。

小开

Google Docs 团队做了一些关于实时协作如何工作的案例研究，但我找不到博客条目。

不过，维基百科页面上还是有一些不错的东西: Http://en.wikipedia.org/wiki/collaborative_real-time_editor

小开

正如金陶塔斯所指出的，这是操作转换造成的。据我所知，这个功能的大部分研究和开发是作为现在已经停止的 Google Wave 项目的一部分完成的，也就是众所周知的 Wave 协议。幸运的是，GoogleWave 是开源的，因此您可以在 http://code.google.com/p/wave-protocol/上获得一些好的代码示例

小开

对于这一点，不一定需要 xmpp 或 wave。大部分称为无限的开源实现的工作已经用 j∞(https://github.com/sveith/jinfinote)完成了。Jinfinote 最近还被移植到 python (https://github.com/phrearch/py-infinote) ，以集中处理并发和文档状态。我目前在 hwios 项目(https://github.com/phrearch/hwios)中使用这两种方法，它依赖于 websockets 和 json 传输。您不会希望在这类应用程序中使用轮询。另外，xmpp 似乎使事情变得不必要地复杂。

小开

在遇到这个问题并进行了更仔细的搜索之后，我认为最好的绿色软体应该是 以太板，它作为一个 JS 浏览器应用程序运行，在服务器端使用 Node.JS。这背后的技术被称为 操作转换。

Etherpad 最初是一个相当重量级的应用程序，后来被 Google 收购并合并到 Google Wave 中，但失败了。代码以开源的形式发布，该技术被用 JavaScript 为 Etherpad Lite 重写，现在更名为“ Etherpad”。一些 Etherpad 技术可能也被整合到 Google Docs 中。

自从 Etherpad 以来，这项技术已经有了各种版本，特别是一些允许将其直接集成到 Web 应用程序中的 Javascript 库:

我是 陨石共享软件包的维护者，用于将实时编辑器直接添加到 流星应用程序中，恕我直言，这是两个世界中最好的:)

小开

实时协同编辑需要几样东西才能有效。这里的大多数其他答案只关注问题的一个方面: 即分布式状态(又称共享-可变-状态)。操作转换(OT)、无冲突复制数据类型(CRDT)、差分同步以及其他相关技术都是实现近实时分布式状态的方法。大多数关注的是最终一致性，它允许每个参与者的状态暂时发生分歧，但保证每个参与者的状态最终在编辑停止时会收敛。其他答案提到了这些技术的几个实现。

但是，一旦共享了可变状态，就需要其他一些特性来提供合理的用户体验。这些额外概念的例子包括:

  • 身份 : 与你合作的人是谁。
  • 现场 : 现在谁在“这里”和你一起编辑。
  • 沟通 : 聊天、音频、视频等，允许用户协调行动
  • 协作提示 : 提示其他参与者正在做什么和/或将要做什么的特性。

共享游标和选择是协作提示(又称为协作意识)的例子。它们帮助用户理解其他参与者的意图和可能的下一步行动。最初的海报在一定程度上是在询问共享可变状态和协作暗示之间的相互作用。这一点很重要，因为光标或选定内容在文档中的位置通常是通过文档中的位置来描述的。问题是游标的位置(例如)取决于文档的上下文。当我说我的光标位于索引37时，这意味着我正在查看的文档中的字符37。由于您或其他用户的编辑，您现在拥有的文档可能与我的不同，因此您文档中的索引37可能不正确。

因此，您用来分发光标位置的机制必须以某种方式集成到系统中，或者至少知道系统中为共享可变状态提供并发控制的机制。今天的挑战之一是，尽管有许多 OT/CRDT、双向消息传递、聊天和其他库，但它们都是没有集成的孤立解决方案。这使得构建一个提供良好用户体验的最终用户系统变得很困难，并且经常导致技术挑战留给开发人员去解决。

最后，为了实现一个有效的实时协同编辑系统，你需要考虑所有这些方面，我们甚至还没有讨论历史、授权、应用程序级冲突解决和许多其他方面。您必须构建或找到支持这些概念的技术，其方式必须对您的用例有意义。那你必须把它们融合起来。

好消息是，支持协同编辑的应用程序正变得越来越流行。支持建造它们的技术正在成熟，每个月都有新的技术出现。火力点是第一批试图将这些概念包装成易于使用的 API 的解决方案之一。新近推出的 汇聚(完全公开，我是 Converence 实验室的创始人)提供了一个一体化的 API，支持大多数协同编辑方面，可以大大减少开发实时协同编辑应用程序的时间、成本和复杂性。

小开

我最近发布了一个知识库，其中包含一个工作示例，展示了您似乎正在努力实现的目标:

Https://quill-sharedb-cursors.herokuapp.com

它基于 ShareDB(OT)作为后端，奎尔作为前端的富文本编辑器。

基本上就是把这些东西和 更多的代码来绘制游标连接起来。代码应该相当简单，以便理解和复制到任何特定的解决方案。

希望对你的努力有帮助。


提交答案