粗粒度 Kafka Topic

不同类型的事件是放入同一个 Kafka Topic，还是分开放入不同 Topic？可以通过下面这几条经验法则来选择。

 

1、最重要的规则是，任何需要保持固定顺序的事件都必须进入相同的Topic（而且它们还必须使用相同的分区键）。最常见的情况是，如果事件与相同的实体有关，那么它们的顺序就很重要。因此，根据经验，我们可以说，关于同一实体的所有事件都需要进入同一个 Topic。

如果您正在使用 event sourcing 方法进行数据建模，那么事件的顺序是特别重要的。在这里，聚合对象的状态是通过按照特定的顺序重放事件派生的。因此，即使可能有许多不同的事件类型，定义聚合的所有事件都必须位于同一个 Topic 中。

 

2、当你有关于不同实体的事件时，他们是否应该在同一 Topic 或不同的 Topic？我想说的是，如果一个实体依赖于另一个实体(例如，一个地址属于一个客户)，或者如果经常需要它们在一起，那么它们也可以进入相同的 Topic。另一方面，如果他们是不相关的，并且由不同的团队管理，他们最好把他们放在不同的 Topic 中。

当然，也要考虑吞吐量：如果一个实体类型的事件发生率远高于另一个实体类型，那么最好将它们分割成单独的 Topic，以避免淹没那些只想要低发生率事件的消费者(参见第4点)。但是，可以很容易地合并所有事件发生率较低的几个实体。

 

3、如果一个事件涉及多个实体，该怎么办？例如，购买涉及产品和客户，从一个帐户转移到另一个帐户至少涉及到这两个帐户。

我建议：最初将事件记录为单个原子消息，不要将其分解为多个 Topic 中的多个消息。最好按照接收到的方式记录事件，以尽可能原始的形式记录。您可以稍后使用流处理器对复合事件进行分割——但是如果您过早地分割原始事件，那么重构原始事件就会困难得多。更好的是，您可以给初始事件一个唯一的ID（例如UUID）；这样，当您将原始事件分裂为多个事件（一个事件对应一个实体）时，您就可以将带上那个 ID，从而使每个事件的起源是可追溯的。

 

4、注意消费者需要订阅的 Topic 的数量。如果几个消费者都消费一组特定的 topic，这就意味着这些 topic 应该合并起来。

如果您将细粒度的 topic 合并为粗粒度的 topic，一些消费者可能会收到他们不想要的事件。这并不是什么大问题：消费 Kafka 消息的开销非常低，因此，即使消费者最终忽略了一半的事件，这种过度消费的代价可能并不大。只有当使用者需要忽略绝大多数消息（例如99.9%是不需要的）时，我才建议将低容量事件流从大容量流中分离出来。

 

5、Kafka Streams 状态存储（KTable）的 changelog topic 应该与所有其他 topic 分开。在这种情况下，topic 是由Kafka Streams 管理的，不应该与其他任何内容共享。

 

6、最后，如果上面的规则都没有告诉您是将一些事件放在同一个 topic 中还是放在不同的 topic 中呢？那么，将同一类型的事件放在同一个 topic 中，通过事件类型将它们分组。然而，我认为这条规则是最不重要的。