performance - RethinkDB 更改提要性能 : architectural advice?

Question

我正在使用 RethinkDB 构建一个应用程序，我即将切换到使用 changefeeds。但我面临着一个架构选择，我想得到一些建议。

我的应用程序当前在用户登录时从几个表中加载所有用户数据(将所有数据发送到前端)，然后处理来自前端的请求，更改数据库，准备并向用户发送更改的项目。我想把它切换到changefeeds。在我看来，我有两个选择:

为每个表设置一个更改源。按登录到特定服务器的用户进行过滤，并手动将更改分发给用户。这些更改源永远不会关闭，例如他们有我的服务器的生命周期。

当用户登录时，为该用户设置单独的更改源，仅用于该用户的数据(使用带有二级索引的 getAll)。维护与当前登录用户一样多的更改源。当用户注销时关闭它们。

解决方案#1 有一个很大的缺点:RethinkDB changefeeds 没有时间(或版本号)的概念，就像 Kafka 那样。这意味着无法 a) 加载初始数据，以及 b) 获取自初始加载以来发生的更改。有一个时间窗口可以丢失更改:在初始数据加载 (a) 和设置更改源的时刻 (b) 之间。我觉得这令人担忧。

解决方案#2 似乎更好，因为 includeInitial可用于获取初始数据，然后不间断地获取后续更改。我必须处理初始加载性能(加载所有数据的单个转储比处理数千个更新更快)，但它似乎更“正确”。但是缩放呢？我计划每台服务器最多处理 1k 个用户——RethinkDB 是否准备好处理数千个更改源，每个更改源本质上都是一个 getAll询问？这些 changefeeds 中的实际事件将非常低，这只是我担心的数字。

RethinkDB 手册关于 changefeed 缩放有点简洁，说:

Changefeeds perform well as they scale, although they create extra intracluster messages in proportion to the number of servers with open feed connections on each write.

解决方案#2 创建了更多的提要，但是对于这两种解决方案，具有开放提要连接的服务器数量实际上是相同的。并且“changefeeds 在扩展时表现良好”还不够继续:-)

我也很想知道处理服务器重启/升级和断开连接的推荐做法是什么。在我看来，如果 RethinkDB 发生任何事情，客户端必须在重新连接后执行完整的数据加载(使用 includeInitial)，因为无法知道停机期间丢失了哪些更改。人就是这样吗？

Answer 1

如果 RethinkDB 在合理的硬件上，它应该能够很好地处理数千个 changefeeds。在这种情况下，有些人要降低网络负载的一件事是，他们将代理节点与他们的应用程序服务器放在同一台机器上，并连接到该机器上，因为代理节点知道的足以消除通过网络传入的 changefeed 消息的重复数据，并且因为它从他们的主集群中减少了大量的 CPU/内存负载。

目前从崩溃中恢复的唯一方法是使用 includeInitial 重新启动 changefeed .有计划在 future 添加写入时间戳，但在这种情况下处理删除很复杂。