RethinkDB changefeeds 性能：架构建议？

Question

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

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

1. 为每个表设置一个单一的更改提要。按登录到特定服务器的用户过滤，并手动将更改分发给用户。这些变更提要永远不会关闭，例如他们拥有我的服务器的生命周期。
2. 当用户登录时，为该用户设置一个单独的更改源，仅用于该用户的数据（使用带有二级索引的getAll）。维护与当前登录用户一样多的变更提要。当用户注销时关闭它们。

解决方案 #1 有一个很大的缺点：RethinkDB 变更提要没有时间（或版本号）的概念，例如 Kafka。这意味着没有办法 a) 加载初始数据，b) 获取自初始加载以来发生的更改。有一个时间窗口可能会丢失更改：在初始数据加载 (a) 和设置更改源的时刻 (b) 之间。我觉得这很令人担忧。

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

RethinkDB 手册对 changefeed 扩展有点简洁，说：

Changefeeds 在扩展时表现良好，尽管它们会创建额外的集群内消息，与每次写入时打开 feed 连接的服务器数量成正比。

解决方案 #2 会创建更多的订阅源，但对于两种解决方案来说，打开订阅源连接的服务器数量实际上是相同的。并且“changefeeds 在扩展时表现良好”还不足以继续下去:-)

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

Answer 1

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

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