事件中心是否应在消息类型上拆分？

Question

我正在考虑将Azure事件Hub用于我目前正在进行的项目.我们今天使用Service Bus Queues作为命令,这里我们每个消息类型使用一个队列.

有几个事件中心是否有意义,或者更好地将一个集线器用于多种消息类型？

Answer 1

这是一个充满权衡的问题,并对您希望现在和将来构建的系统以及它们如何使用不同的事件类型进行判断.

以下是Jay Kreps为在Apache Kafka上设计系统提供的一些指导的摘录,这些指南也适用于事件中心(除了短暂保留期限和消费者群体数量限制的主要例外) .

让我们从纯粹的事件数据开始 - 公司内部发生的活动.在网络公司中,这些可能是点击次数,展示次数和各种用户操作.联邦快递可能有包裹递送,包裹提取,司机位置,通知,转移等.

这些类型的事件可以用每个操作类型的单个逻辑流表示.为简单起见,我建议将Avro架构和主题命名为相同的东西,例如PageViewEvent.如果事件具有自然主键,您可以使用它来分区Kafka中的数据,否则Kafka客户端将自动为您平衡数据.

...

我们在不同时间通过在单个主题中混合多个事件进行实验,发现这通常会导致过度的复杂性.相反,为每个事件提供自己的主题,消费者可以随时订阅多个此类主题,以便在需要时获得混合Feed.

我通常同意这个建议(如果你在Event Hubs/Kafka/Kinesis上设计一个系统,你应该阅读整篇博文).需要忽略他们不感​​兴趣的消息的订户不仅烦人,如果其中一个事件类型开始支配组合流,则后来成为问题.

但是拥有多个流并将它们组合在一起确实会产生成本,并且需要在做出决策时权衡它们.我已经列出了一些想到的东西.

1. 除非您花费精力将其添加回来,否则您将丢失来自同一来源的不同类型的事件之间的排序.

2. 如果您想将进度提交到不同的主题,那么您需要管理它们.

3. 如果要在主题之间共享的主键上对事件流进行分区,并希望每个主题中的分区一起传输,则不能使用像EventProcessorHost这样的高级客户端,因为分区最终可以自动平衡到不同的进程.

4. 每个分区具有一个线程的消费者最终将所需线程数乘以主题数.除非您拥有无法共享的昂贵结构,否则可能不是问题.

在我自己的部署中,我们为不同的事件类型使用不同的事件中心,即使我们当前使用相同的代码来处理它们.这只是因为我希望添加仅关注某些事件类型的新组件.我希望这会有所帮助,最糟糕的是我已经告诉过你去看看Kafka的指导,因为原理是一样的,并且它已经存在了很长时间.