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

Question

我之前用套接字做过一些非常基础的实时应用程序，并出于好奇而阅读了更多相关内容。我读到了一篇非常有趣的操作转换文章，学到了一些新东西。在阅读完后，我一直在思考如果我要保存这些数据，它们是如何真正保存到数据库中的。我有两个假设/理论，但我不确定它们是否正确和/或解决此问题的最佳方案。它们如下所示：

（以实时协作白板为例：）

1. 每次发生编辑行为（例如画一条线），套接字都会向所有协作者发送消息。但是同时，我也将数据存储在我的数据库中。我看到这种解决方案的问题在于我需要访问数据库的时间。对于用户画的每一条线，我都需要访问数据库进行存储。
2. 使用轮询。对于这个理论，我考虑将每个数据保存在服务器的临时存储中，然后在“x”时间之后，它将从临时存储中获取所有数据并将它们保存在数据库中。这个理论的问题是可能会出现临时存储的故障（例如电力故障）。如果临时存储在保存到数据库之前丢失其数据，则我将永远无法恢复它们。

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

- elco45

Answer 1

他们可能依赖变更日志、最新文档版本和定期快照（如果允许时间旅行文档历史记录）。

类似于大多数数据库事务系统的运作方式。经过验证更改是合法的后，数据库会将更改写入非常快速的磁盘数据结构，即仅追加更改值的日志。这个日志与专用数据结构在内存中复制以加快读取速度。当读取请求到来时，数据库会检查内存中的数据结构并将更改与缓存或磁盘上存储的内容合并。

周期性地，存在于内存和日志中的更改会与磁盘上的数据结构合并。因此，总结起来，在您的情况下：

当操作转换到达服务器时，会发生两件事情：

1.将其存储在数据库中，以避免任何损失（相当于日志）

2.更新内存数据结构，以便能够快速重演更改，以防用户请求最新版本（相当于内存数据结构）

当用户请求最新文档时，服务器会检查内存数据结构并对最后存储的已合并文档重新播放更改，这可能滞后于以下点的原因：

定期应用日志到“最后存储的已合并文档”中，以减少必须重演以生成最新文档的操作转换数量。

无论如何，获得确定性答案的最佳方法是查看执行您要寻找的功能的开放源代码，例如etherpad。

- amirouche