apache-kafka - 为微服务扩展 Kafka

Question

问题
我想了解如何设计使微服务保持静止的消息传递
弹性和可扩展性。
目标

微服务允许弹性数量的实例根据当前负载自动伸缩。这个特性不应该被Kafka限制。

我们需要保证至少一次交货

我们需要保证同一实体事件的传递顺序

运行示例

简单地说，假设有 2 个微服务 A 和 B；

A1、A2为微服务A的实例；微服务B的B1和B2实例

A1 和 A2 发布描述 A 实体上的 CRUD 操作的事件，例如实体被创建、更新、删除。

设计一

A1 在主题下发布事件 a.entity.created包括 id 等信息在消息正文中创建的实体。

A1 必须指定将有多少个分区 (p) 以允许消费者并行消费。这将允许可扩展性。

B1和B2订阅主题a.entity.created作为消费群体b-consumers .这会导致 B 实例之间的负载分布。

问题 :

a) 涉及同一实体的事件可能会被并行处理并且可能会出现乱序，对吗？

b) 这将导致 B 的实例并行处理请求。限制因素是生产者如何定义 p(分区数量)。如果有 5 个分区，但我需要 8 个消费者来应对负载，那么它将无法工作，因为 3 个消费者不会收到事件。我理解正确吗？这将 IMO 无法用于可能想要进一步扩展的弹性微服务。

设计二

A1 在主题下发布事件 a.entity.created.{entityId}导致很多不同的话题。

每个分区大小设置为 1。

B1 和 B2 订阅主题 a.entity.created.*使用通配符作为消费组 b-consumers .这导致 B 实例之间的负载分布。

问题 :

c) 同一实体的事件应该保证按顺序传递，因为只有一个分区，对吗？

d) 这里是如何处理可扩展性的？分区的数量不应该限制消费者的数量，或者是吗？

e) 是否有更好的方法来保证上述目标？

设计 III(感谢 StuartLC)

A1 在主题下发布事件 a.entity.created和 分区键 基于entityId。

每个分区大小设置为 10。

B1和B2订阅主题a.entity.created作为消费群体b-consumers .这导致 B 实例之间的负载分布。由于分区键，关于同一实体的事件将按顺序传递。

问题 :

f) 当 p=10 时，我最多可以有 10 个消费者。这意味着如果使用环境变量，我必须在设计时/部署时估计消费者的数量。我可以将它移动到运行时以便动态调整吗？

Answer 1

您不需要每个实体单独的主题来确保消息的传递顺序。
相反，分配一个 partition key在基于您的实体 ID(或实体的其他不可变标识符)的每条消息上，以确保有关同一实体的事件始终传递到每个主题的同一分区。
即使多个生产者实例为同一实体发布消息，分区上消息的时间顺序通常也会保留(例如，如果 A1 和 A2 都发布实体 E1 的消息，则 E1 的分区键将确保所有 E1 消息都得到传递到相同的分区，P1。)。有一些边缘情况不会保留排序(例如，生产者的连接丢失)，在这种情况下，您可以查看 enabling idempotence .
你是对的，在任何时候，一个消费者组中最多有一个消费者将订阅一个主题分区，尽管一个消费者可以被分配到多个分区。所以例如消费者 B2 可能会处理来自分区 P1(按顺序)以及来自另一个分区的所有消息。如果一个消费者死亡，那么另一个消费者将被分配到该分区(转换可能需要几秒钟)。
当在消息上提供分区键时，默认情况下，分区分配的消息是基于分区键的散列完成的。在极少数情况下(例如，实体分区键很少)，这可能会导致消息在分区上分布不均，在这种情况下，您可以提供自己的 partitioning strategy ，如果您发现吞吐量受到不平衡的影响。
基于以上，经过configuring an appropriate number of partitions对于您的场景，您应该能够使用一致的分区键来满足您的设计目标，而根本不需要对 Kafka 进行过多的自定义。