3.5.2 提交偏移量到内部主题

3.5.2 提交偏移量到内部主题

消费者提交偏移量到Kafka的内部主题，首先要确定连接哪个或者哪些服务端节点。回顾一下，生产者发送消息时会根据分区的主副本分组，和多个节点者rs建立连接；消费者分配多个分区，也要根据分区的主副本分组，和多个节点建立连接。而消费者提交所有分区的偏移量时，实际上只和－个服务端节点建立连接。同样要处理多个分区，为什么普通消息需要多个连接，而偏移量只需要一个连接？如图3-24所示，目标节点指的是分区的主副本节点，我们给出了偏移聋的多种连接方案。

(1)如果不同分区的偏移盐写到了不同的节点，消费者分配了多个分区，当要读取不同分区的偏移盘时，就得连接不同的节点才可以获得完整的数据。
(2)如果能让所有分区的偏移草’数据只保存在一个节点，消费者就只需要同一个节点通信。但因为消费者和分区的关系是变化的，即使保证这一次分区在一个节点上，也无法保证下一次仍然在同一个节点。
(3)如果消费组所有消费者所有分区的偏移量都保存在一个节点，就可以解决第二种方式的问题。
(4)实际上，消费者的分区偏移盏’要保存在哪个节点，跟消费者所属的消费组有关系。只要保证消费组级别的偏移i量在一个节点上，即使消费者和分区的关系发生变化，也能够保证消费者访问新分配的分区时，只需要访问一个节点。

同一个消费组的所有消费者，以内部主题形式提交所有分区的偏移盘到一个目标节点，这个内部主题和普通消息的主题一样也会有多个分区。如果只有一个分区，所有消费组都只能提交到唯一的节点，就又退化到和ZK面临的将所有读写请求都压到一个节点的相同问题。而如果有多个分区，并且以悄费组作为分区的分布条件，不同消费组提交到的偏移量有可能是不同的节点，就可以分散偏移盘读写的压力。

实际上，消费者提交偏移量如果存储在ZK中，也是用消费组级别来表示。存储在ZK巾天生就具有共享存储的优势，所有的消费者只需要连接ZK即可。而以主题方式存储偏移革命时，就得考虑是杏需要连接多个服务端节点。每个消费组只连接一个节点是最好的，这个节点负宽管理一个消费组所有消费者所有分区的偏移量，叫作偏移量管理器（OffsetManager）。和采用ZK方式将偏移蓝数据写到ZK不同，消费者将偏移量数据封装成偏移量提交请求（OffsetCommitRequest）发送给偏移量管理器。就像生产者的生产请求、消费者的拉取请求一样，偏移量提交请求和偏移拉获取请求都是发送给Kafka服务端节点的。相关代码如下：

如图3-25所示，总结r下目前为止客户端需要确定服务端节点的几个场景。

• 生产者发送消息时，直接在客户端决定消息要发送给哪个分区，这一步不向服务端发送请求。
• 消费者拉取管理器的LeaderFinderThread线程向服务端发送主题元数据请求，获取包含了主副本等信息的所有分区元数据，消费者拉取线程才能确定要连接哪些服务端节点。
• 提交偏移茸虽然有点像生产者的发送消息，都是写数据，但也需要和l消费者的LeaderFinderThread一样，获取分区的主副本作为偏移ill:管理器，才能确定提交到哪个节点。
  

注意：消费者提交普通主题“分区”的消费偏移量，和偏移量存储在内部主题的“分区”，这两个分区概念上相同，但数据是不同的，前者是普通主题的分区，后者是内部主题的分区。服务端把客户端提交的分区偏移量当作消息，消息键由消费组编号、主题、分区编号组成，消息值是分区的偏移量。比如消费者l属于消费纽I(GroupI），它订阅了主题I(Topicl),分配给它的分区消费进度分别是：（P0:100,P1:120,P2:130］。服务祸内部主题有3条消息：(Group1-Topic1-P0,100),(Group1-Topic1-P1,120),(Group1-Topic1-P2,130）。