存储机制的谷歌文档，如实时编辑器

Question

我已经把一个文本编辑器(所见即所得)放在一起，我能够以这样的结构来回发送delta:

{
    "action": "insert",
    "position": 25,
    "content": "some text"
}

和我已经实现了一种方法，将这些发送到所有参与的客户端，并在目的地应用增量。

存储

我现在正试图弄清楚如何处理服务器端的存储机制。我使用MongoDB作为主数据库，由于这些delta经常出现，我想在它们出现时将它们全部写入数据库，可能会使数据库非常紧张。

可能的解决方案

我正在考虑在内存中组装文档并每隔10秒将文档刷新回数据库(但是如果我在将更改写入数据库之前丢失了怎么办?而且，记忆是非常宝贵的)

假设我已经成功地将这些更改的100 000存储在一起形成一个文档，那么当有人加载文档时(操作DOM似乎是资源密集型的)，将它们全部拉出来并呈现到编辑器上是明智的吗?还是在它们到达服务器时将它们应用到文档中，并在文档被请求时返回已经组装好的文档?

使用上面建议的解决方案，我将只获得一个文档，而不是要处理的增量数组。但是我想避免向客户端发送HTML内容。

像Google Docs这样的服务如何处理这个问题?欢迎对实现提供任何建议。

感谢

---

目前资源:

• 并发变更应用过程

Answer 1

我不知道Google Docs是怎么做到的，但这类事情就是像Redis和Memcached这样的数据库设计的目的。它们主要在内存中，但会定期刷新磁盘以进行持久化。没有完美的原子性，但一般来说，你不可能在同一个解决方案中同时拥有完美的事务完整性和完美的可伸缩性;这通常涉及到某种权衡。