对于MongoDB变更流读取器，什么是好的横向扩展策略？

Question

我正在考虑实现MongoDB变更流读取器，并且我想确保自己做的正确。关于如何实现实际阅读器代码，有很多简单的示例，包括官方文档，我对此不太担心。

但是，我有点担心读者会落在变更流之后而无法跟上变化，我想确保读者能够处理变更流。

mongo服务器是一个群集，为了便于讨论，我们假设它每天都非常忙。鉴于更改流API必须迭代流结果而不是像队列一样对其进行操作，因此更改流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]/

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

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

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