从多个节点订阅事件流

Question

我们正在评估使用事件作为源来构建报告，并增加了许多不同的选项。

我们目前正在服务结构集群中运行我们的系统(意图在将来的某个时候转移到kubernetes )，这意味着各种事件流的订阅者在默认情况下将在多个节点上运行。我们已经研究了各种事件流实现(kafka、SqlStreamStore和EventStoreDb)，并遇到了一个共同的问题，即多节点订阅者都将尝试处理新消息并并行构建共享投影，这意味着我们需要根据以前处理过的消息表或主键约束进行检查。

可能的解决方案是，我们坚持单节点订户，但我不能看到随着事件开始堆积，这种扩展，或者我们直接从事件流建立投影。是否有人遇到或找到了解决这个问题的方法？

Answer 1

要运行并行投影，我建议考虑分区/切分策略。最明显的方法是确保单个投影类型将由特定的订阅者处理(这可以通过侦听该投影类型或每个流类型处理的事件来完成)。有了这一点，您就可以分配负载，而不会以竞争的消费者问题告终。

如果您的消费者争夺共享资源--例如您要写入的读取模型--那么很难保证处理顺序。理论上，您可以将流版本写入投影，然后验证它是否高于处理事件的版本。但是，您可能最终会遇到这样的情况：

• first处理程序-获取事件1和2
• 第二处理程序-获取事件3

如果第一个处理程序滞后，则第二个处理程序将写入投影，将版本设置为3。如果根据版本执行检查，则事件1和事件2将被忽略。

此外，与竞争的消费者，事件会失去秩序(例如，因为重试)，那么您可能会以版本号空白结束，而不是验证是否可以编写或不容易编写。

这很难从一条小溪中投射出来。对于来自多个流的投影，它变得更加棘手。您可能最终需要为同一读取模型中的其他流维护不同的版本。从长远来看是难以控制的。

如果您的事件是典型的传输事件，这就可以工作--所以“上层服务”。但是，如果您有业务事件，那么丢失一个事件可能很关键。

另一种情况是，您不关心排序，可以在可能出现错误的状态下处理一段时间的数据(例如，首先从"update事件“中应用可能的内容，然后填充来自"create event”的数据)。然而，这通常需要在投影业务逻辑上付出更多的努力，并确保无序情况得到充分处理。

我建议从一个作家开始。如果您看到性能问题，请定义分区/切分策略，并确保没有竞争订阅者使用相同的目标读取模型。这也是至关重要的，使你的预测幂等(所以，如果你得到相同的事件两次，它将有一个单一的效果)。