实时协作应用程序如何保存数据？

Question

我以前使用套接字的帮助完成了一些非常基本的实时应用程序，并且出于好奇而一直在阅读有关它的更多信息。我读到的一篇非常有趣的文章是关于 Operational Transformation 的，我学到了一些新东西。读完之后，我一直在想，如果我要保留这些数据，何时或如何真正将其保存到数据库中。我对可能发生的事情有两个假设/理论，但我不确定它们是否正确和/或解决此问题的最佳解决方案。它们如下：

（对于这个例子，我们假设它是一个实时协作白板：）

1. 对于发生的每一次编辑（例如画一条线），套接字都会向所有协作的人发送一条消息。但同时，我会将数据存储在我的数据库中。 我看到这个解决方案的问题是我需要访问数据库的时间量。对于用户绘制的每一行，我都需要访问数据库来存储它。
2. 使用轮询。对于这个理论，我想将每个数据保存在服务器的临时存储中，然后在“x”时间后，它将从临时存储中获取所有数据并将它们保存在数据库中。 这个理论的问题是暂时存储失败的可能性（例如电气故障）。如果临时存储在保存到数据库之前丢失了数据，那么我将永远无法再次恢复它们。

Google Doc、Slides 等类似的实时协作应用程序如何将数据存储在其数据库中？他们是否遵循我提到的一种理论，或者他们有完全不同的数据存储方式？

Answer 1

他们依赖于更改日志 + 最新文档版本 + 定期快照（如果他们允许时间遍历文档历史）。

• 它类似于大多数数据库的事务系统的工作方式。在验证更改是合法的之后，数据库以非常快速的数据结构将更改写入磁盘上。仅附加更改值的日志。此日志使用专用数据结构在内存中复制以加快读取速度。

• 当读取进入时，数据库将检查内存中的数据结构并将更改与存储在缓存或磁盘上的内容合并。

• 内存和日志中存在的更改会定期与磁盘上的数据结构合并。

总结一下，就你而言：

• 当操作转换进入服务器时，会发生两件事：

1. 按原样存储在数据库中，避免丢失（相当于日志）
2. 它会更新内存中的数据结构，以便在用户请求最新版本（相当于内存数据结构）时能够快速重放更改

• 当用户请求最新的文档时，服务器会检查内存中的数据结构并根据最后存储的合并文档重放更改，因为以下几点可能会滞后

• 定期将日志应用于“最后存储的合并文档”，以减少必须重放以生成最新文档的 OT 数量。

无论如何，获得明确答案的最佳方法是查看能够满足您需求的开源代码，例如以太垫。