如果我使用 Kafka 作为简单消息。真的值得吗

Question

=== 从消费者的角度假设一切 ===

1. 我正在阅读几篇 Kafka 文章，我看到分区的数量与微服务实例的数量相关......例如：如果我为我的 serviceA 说 1topic 1partition.. Producer 将消息推送到 topicT1，partitionP1 ，并且从 consumerSide(ServiceA1) 我可以从 t1,p1 读取。如果我将新 pod(ServiceA2) 旋转为具有高吞吐量，那么第二个实例将永远不会收到任何消息，因为 Kafka/ZooKeeper 将 id 分配给每个消费者，并且 partition1 已经被 serviceA1 占用。所以 serviceA2++ 保持空闲......为了避免这样的麻烦，Kafka 建议添加更多分区，以便可以根据需要增加/减少消费者的数量。
2. 我还可以通过命令行进行测试，并且 service2 从未使用过任何消息。如果我关闭 service1，那么 service2 就能够选择新消息...因此，如果我旋转更多 pod，那么 FailSafe/Availability 会增加，但吞吐量始终相同...
3. 我的假设是否正确。我有什么遗漏吗。现在我觉得任何标准的消息传递都会有同样的问题......如何扩展面向消息的系统本身。

Answer 1

每个主题都有一个分区，如果您不定义分区计数值，默认情况下它只有一个分区。在您的情况下，您有一个由两个消费者组成的消费者组。每个消费者都从分区中读取日志。在您的情况下，第一个消费者从第一个分区（我们有唯一的分区）读取日志，而对于第二个消费者，消费者将没有数据分区，因此它变得空闲。一旦第一个消费者下线，那么只有第二个消费者从最后提交的偏移量开始从第一个分区读取数据。

请查看以下博客和视频。解释了kafka中的topic、consumer、consumer group。

https://www.javatpoint.com/apache-kafka-consumer-and-consumer-groups http://cloudurable.com/blog/kafka-architecture-consumers/index.html https://docs.confluent.io/platform/current/clients/consumer.html https://www.youtube.com/watch?v=lAdG16KaHLs

我希望这能让您了解消费者和消费者群体。

Answer 2

对此的广泛解决方案是将消息的消费（即从 Kafka 接收消息并可能反序列化并验证它是否符合模式）和处理它（解释消息）解耦。如果消耗足够简单，则无需限制消耗的实例数不超过分区数。

实现此目的的一种方法是使用 Kafka 消费服务，该服务将 HTTP 请求（可能通过负载均衡器或其他）发送到具有任意多个成员的处理服务。

请注意，根据您使用 Kafka 的目的，可能会要求某些消息始终彼此位于同一分区中，以确保以确定的顺序处理它们（因为跨分区排序是不保证）。一个典型的例子是消息是特定记录的更改事件。如果您通过消息键的某些哈希（或者如果使用自定义分区器，则为键的一部分）来完成此操作，那么简单地更改分区数可能不可行（您需要引入某种迁移或有生产者知道哪些记录必须路由到旧分区，并且只有在以前从未见过记录时才路由到新分区。

Answer 3

1. 我们刚刚开始用 Kafka 代替消息传递。

2. 在传统的 MQ 中会有一个集群，里面会有 1orMQ。

3. 因此 MQ 集群/协调器服务会将消息传递给客户端。

4. 现在可以有 10 个服务/客户端可以使用来自单个 MQ 的消息。

5. 所以如果 MQ 中有 10 条消息，那么每个服务/消费者/客户端可以读取/处理 1 条消息

6. 现在这种情况在 Kafka 中是不可能的，我现在按照设计理解

7. 为了在 Kafka 中实现类似的功能，我添加了相同或更多数量的分区作为客户端/消费者/pod。