mongodb - 什么是 MongoDB 更改流读取器的良好水平扩展策略？

Question

我正在考虑实现一个 MongoDB 变更流读取器，我想确保我做的是正确的。有很多关于如何实现实际阅读器代码的简单示例，包括 official documentation ，我不太担心这方面的问题。

不过，我有点担心读者落后于变化流，无法 catch 变化流，我想确保读者能够处理变化流。

mongo 服务器是一个集群，为了便于论证，我们假设它在一天中的所有时间都非常繁忙。更改流 API 似乎只与执行工作的单个实例兼容，因为它必须如何迭代流结果而不是像队列一样对其进行操作。因此，我担心迭代结果的单个实例可能比将新项目推送到流中花费更长的时间来完成它的工作。

我的直觉是让读者简单地读取流，批处理更改，然后将其推送到队列中，其他工作人员可以在队列中横向扩展以完成工作。但是，我仍然有一个作为读取器的实例，理论上它仍然有可能落后于流，即使只做了将更改推送到队列中的最低限度的工作。

所以我的问题是，这种担心有多现实？是否有任何方法可以创建读取器，即使它只是将更改流式传输到工作队列中，它也可以水平扩展？我还应该考虑哪些其他注意事项？

Answer 1

最有可能的是，只需将所有工作委派给水平缩放的队列，单个阅读器就足够了。

如果事实证明这还不够，并且您的读者仍然需要水平缩放，那么您可以通过使用匹配过滤器来实现这一点，这种方式允许多个读者分担工作。

例如，如果您有一个包含十六进制字符的 ID，您可以通过在每个服务器上使用匹配运算符将工作拆分到两个服务器上，其中每个服务器匹配整个范围内的一半字符:

// Change Stream Reader 1
const params = [
  { $match: { _id: /^[0-7]/ } }
];
const collection = db.collection('inventory');
const changeStream = collection.watch(params);

在第二台机器上:

// Change Stream Reader 2
const params = [
  { $match: { _id: /^[8-9a-f]/ } }
];
const collection = db.collection('inventory');
const changeStream = collection.watch(params);

如果您需要超过 16 台服务器，那么您可以使范围更加具体:

// Server 0  matches on /^0[0-7]/
// Server 1  matches on /^1/
// ...
// Server 15 matches on /^f/
// Server 16 matches on /^0[8-9a-f]/

这将允许每台机器观看消息的子集并处理它们，而其他机器正在处理其他消息而不会重复。

以稳健的方式协调哪个服务器正在监视哪个范围变得有些复杂，因为您需要确保崩溃或挂起的机器恢复，如果您需要动态地水平扩展，那么您需要能够向服务器提供新的范围并调整大小。此解决方案还会导致消息被乱序处理，因此如果顺序很重要，那么您需要想出一个解决方案来重新排序消息或处理乱序问题。

但是这些都是与这个问题不同的主题，所以我现在将省略细节。