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

Question

我以前使用套接字做过一些非常基本的实时应用程序，只是出于好奇，我一直在阅读更多关于它的文章。我读到的一篇非常有趣的文章是关于操作变换的，我学到了一些新东西。读完之后，我一直在想，如果要保存这些数据，什么时候或者如何才能真正保存到数据库中。对于可能发生的事情，我有两个假设/理论，但我不确定它们是否正确和/或解决这个问题的最佳解决方案。它们如下：

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

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

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

Answer 1

它们依赖于更改日志+最新文档版本+定期快照(如果允许时间遍历文档历史记录的话)。

• 它类似于大多数数据库事务系统的工作方式。经过验证，更改是合法的，数据库在磁盘上以非常快的数据结构写入更改。只附加已更改的值的日志。此日志是在内存中复制的，具有专用的数据结构，以加快读取速度。
• 当读取进来时，数据库将检查内存中的数据结构，并将更改与缓存或磁盘中存储的内容合并。
• 定期将内存和日志中的更改与磁盘上的数据结构合并。

因此，总结一下，在你的例子中：

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

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

• 当用户请求最新的文档时，服务器检查内存中的数据结构，并根据上次存储的统一文档重放更改，这些更改可能会因为以下原因而滞后
• 定期将日志应用于“最后存储的合并文档”，以减少生成最新文档所必须重放的OT数量。

无论如何，获得明确答案的最佳方法是查看实现所需内容的开源代码，例如etherpad。