Kafka——消费者偏移量存储问题

目录

引入—— 存储在哪

为啥最开始是存储在zookeeper中的？

为啥不继续用zookeeper存储了?

 回顾*分区副本机制

---

 

每个消费者在一个消费者组中都有自己的偏移量，用于记录消费到的消息位置。消费者可以通过提交偏移量来告知 Kafka 服务器它已经处理了哪些消息，下次消费时可以从哪里开始。

 

引入—— 存储在哪

• 在较早的 Kafka 版本（0.8.x 及之前），消费者的偏移量是存储在 Zookeeper 中的。这种方式在新的 Kafka 版本中已经被弃用，因为将偏移量存储在 Kafka 自身可以提高性能并简化管理。
• 从 Kafka 0.9.0.0 版本开始，默认情况下，消费者组的偏移量会被存储在一个特殊的内部主题 `__consumer_offsets` 中。这个主题是由 Kafka 自动管理的，存储了所有消费者组的偏移量信息。
     - `__consumer_offsets` 主题使用与普通主题相同的*分区和副本机制，以保证偏移量存储的高可用性和可靠性。每个消费者组在每个分区中的偏移量都会被存储在这个主题的相应分区中。
• 如何查看偏移量信息？
   Kafka 提供的命令行工具 kafka-consumer-groups.sh来查看和管理消费者组的偏移量。例如：
   
   

   kafka-consumer-groups.sh --bootstrap-server <kafka-broker> --describe --group <consumer-group-id>

为啥最开始是存储在zookeeper中的？

1.   Zookeeper 能确保每个消费者组中的偏移量信息一致且可靠。也避免了并发问题。

为啥zookeeper能确保每个消费者组的偏移量信息一致并且可靠？

s持久化存储数据不会丢失，原子性操作，保证了顺序性处理与应用，watch监视机制及时去通知

持久化存储：Zookeeper 将数据存储在磁盘上，即使发生服务器崩溃或重启，存储的偏移量信息也不会丢失。这种持久化存储保证了即使发生故障，也能够恢复正确的偏移量状态。

原子性操作：Zookeeper 支持原子性操作，这意味着针对单个 znode 的更新是原子的。

Watch 机制：Zookeeper 提供了一种监视机制，消费者可以通过注册 Watch 来监听偏移量信息的变化。一旦偏移量信息发生变化，Zookeeper 将通知订阅了该 Watch 的消费者，使得消费者能够及时更新自己的状态。

顺序一致性：确保了在多个操作同时发生时，每个操作都按照确定的顺序被处理和应用，避免了并发更新导致的数据不一致性问题。

只有leader进行写操作。follower进行读操作，这意味着，Zookeeper 都只会接受并传播来自 Leader 节点的更新，从而确保所有节点的数据视图是一致的。

 2. 

在 Kafka 早期版本中，架构设计简单，Zookeeper 被广泛用于集群的元数据管理，包括主题、分区、领导者选举等各种关键配置和状态。将消费者的偏移量存储在 Zookeeper 中是一个自然的选择。
3. 简单性

初期，使用 Zookeeper 来管理偏移量相对简单，开发和维护成本较低。Zookeeper 提供的 API 已经能够满足偏移量存储的基本需求。

为啥不继续用zookeeper存储了?

• 1. 性能瓶颈

随着 Kafka 集群和消费者组规模的扩展，偏移量存储在 Zookeeper 中带来了性能瓶颈。频繁的读写操作增加了 Zookeeper 的负担，影响了整个系统的性能和可扩展性。

• 2. 复杂性增加：

 管理依赖于 Zookeeper 的偏移量变得越来越复杂，特别是在大规模集群中。需要额外的运维和监控工作来确保 Zookeeper 的高可用性和性能。

• 3. 延迟问题：

 Zookeeper 的一致性保证虽然强，但也会带来一定的延迟，特别是在网络不稳定或负载高的情况下。这对于需要快速响应的消费者来说，可能会影响实时性。

鉴于这些问题，Kafka 社区在 0.9.0.0 版本引入了将偏移量存储在 Kafka 自身的内部主题 `__consumer_offsets` 中的新机制。这种方式充分利用了 Kafka 的日志系统，解决了上述问题，带来了更好的性能、一致性和简化的管理方式。

总结来说，最开始将偏移量存储在 Zookeeper 中是基于当时的技术背景和架构设计考量，但随着 Kafka 的演进和应用场景的扩大，转向使用 Kafka 内部主题来存储偏移量是一个自然且必要的发展方向。

 回顾*分区副本机制

__consumer_offsets 主题，它存储了消费者组的偏移量信息，其分区和副本机制与普通主题类似，但有一些特殊性：

• 分区数量：__consumer_offsets 主题的分区数量通常等于 Kafka 集群中的 broker 数量，这样可以确保每个 broker 上都有该主题的分区副本。
• 副本分布：与普通主题一样，__consumer_offsets 主题的每个分区会有多个副本分布在不同的 broker 上，确保数据的可靠性和容错性。
• 选举和同步：如果某个副本不可用，Kafka 会通过副本的同步机制保证副本的数据与领导者副本保持同步，确保数据的完整性和一致性。