3.5.3 连接偏移量管理器

3.5.3 连接偏移量管理器

前面我们分析的拉取偏移＃方法和提交偏移量’方法，都需要和偏移主－管理器通信。在这之前，消费者需要通过channelToOffsetManager（）方法向服务端任意一个节点发送“消费组的协调者请求”(GroupCoordinatorRequest），来获取消费组对应的协调节点，即偏移量管理器（OffsetManager）节点。服务端处理消费组的协调者请求，实际上也是通过查询主题的元数据来完成的。不过和LeaderFinderThread中返回主题元数据，然后还要在客户端继续处理（比如获取存在主副本的分区）不同，这里在服务端完成“选择消费组对应内部主题的分区的主副本节点”，然后直接返回这个协调节点给客户端。也就是说客户端发送消费组的协调者请求，服务端返回的就是消费组的协调节点。相关代码如下：

如图3-26所示，消费组l中所有消费者提交的偏移量都应该连接到代理节点l，但是消费组中不同消费者连接的任意代理节点可能一开始并不是代理节点l。不过没关系，这一步只是准备t作，目的是确定目标节点，不管连接哪个节点，当前连接的节点都会告诉你应该连接的正确节点；如果你连得不对，根据返回值再去连接正确的节点。比如，消费者0刚好连接的是代理节点l，可以直接把queryChannel作为offsetChannel；而消费者l和消费者2第一次连接的不是代理节点1，所以在得到结果时应该首先关闭queryChannel，然后重新连接代理节点l作为queryChannel。

任何一个服务端节点处理消费者发送的GroupCoordlnator请求，首先要确定消费组在内部主题的分区，然后，从主题元数据的所有分区元数据中找出指定分区的主副本节点，就是消费组对应的协调者节点。在LeaderFlnderThread中直接返回主题的元数据，是因为无法确定具体的分区，而这里根据消费组可以确定分区，所以直接在服务端返回对应分区的主副本信息。相关代码如下：

确定了消费者要连接的消费组协调节点，也就是偏移量管理器后，消费者才会向该目标节点发送偏移茸的读写请求。在以ZK为存储系统时，消费者针对偏移量的读写都是每个分区单独发起一个请求。在以内部主题形式存储分区的偏移量时，消费者会把它负责的所有分区一次性发送给协调节点。现在我们来看一下服务端对偏移业请求的处理过程。