5.2.3 协调者处理请求前的条件检查

曾经终败给现在 2023-01-13 15:57 82阅读 0赞

#### 5.2.3 协调者处理请求前的条件检查 ####

协调者在处理“加入组请求”和“同步组请求”之前都需要优先做下吨的一些条件检查。

*  协调者不可用，通常是协调者被关闭了。
 *  消费者客户端传递的消费组编号无效，比如没有设置消费组编号。
 *  消费者连接错了协调者，这个协调者不是消费组的协调者。
 *  协调者正在加载，通常是协调者自身在进行迁移。
 *  消费者客户端设置的会话超时时间无效。
 *  协调者还没有消费组，但消费者的成员编号却不是“未知编号”。
 *  协调者有消费组，消费者的成员编号不是“未知编号”，但是不在消费组中。

协调者针对上面几种异常情况都有特定的错误码，并且会立即调用定义好的回调方法，把错误信息及时地返回给消费者客户端。消费者客户端在响应处理器的回调方法巾，针对每种错误码都有不同的处理。比如，如果是“未知编号”错误码，就会重置客户端的成员编号为“未知编号”，然后重新发送“加入组请求”；如果是GROUP\_COORDINATOR\_I、!OT\_AVAILABLE或NOT\_COORDINATOR\_FOR\_GROUP，消费者就会连接新的协调者节点，并重新发送“加入组请求”。

上面的条件检查过后，handleJoinGroup()方法最终会调用doJoinGroup()方法来允许消费者加入消  
费组，有下面两种情况。

*  消费组为空井且成员编号为“未知编号”，允许加入。第一个消费者第一次加入组会执行一次。
 *  消费组不为空，如果成员编号是“未知编号”，允许加入；如果成员变量不是“未知编号”，必须保证已经在消费组中才允许加入。

下面列举了几个消费者以不同的顺序和方式第一次加入或重新加入消费组，协调者处理的不同  
方式。

(1)Cl以“未知编号”加入组，组不存在，允许加入。创建组，分配Cl的成员编号为［1］。
    (2)C2以“未知编号”力II入组，组已经存在，允许加入。分配C2的成员编号为［2］。
    (3)Cl以编号川加入组，组已经存在，成员也在组中，允许加入。
    (4)C3以编号［3］加入组，组已经存在，但成员不在组中，编号［3］不是“未知编号”，拒绝加入。
    (5)C4以“未知编号”加入组，组已经存在，允许加入。分配C4的成员编号为［3］。
    (6)C3以“未知编号”加入组，组已经存在，允许加入。分配C3的成员编号为［4］。

注意：第一个消费者用Cl表示，以此类推。消费者友送加入纽请求和分配的编号没有必然的关联关系。

协调者处理消费者发送的“同步组请求”同样需要执行条件检查。客户端发送“加入组请求”后才会发送“同步组请求”，服务端处理“同步组请求”也一定在处理“加入组请求”之后。因为协调者在正常处理“加入组请求”时一定会创建消费组，所以它的handleSyncGroup()方法在处理“同步组”请求时必须保证消费组不为空，才可以调用doSyncGroup()方法。

消费组发送“加入组请求”和“同步组请求”一定是发送到同一个协调者节点。假设Cl发送“加入组请求”给协调节点A，协调节点A会创建Cl对应的消费组。但Cl发送“同步组请求”时发给了协调节点B，而协调节点B并没有消费组，所以消费组为空。实际上协调者在判断没有消费组之前，会首先判断它是不是消费组的协调者，如果不是，直接返回NOT\_COORDINATOR\_FOR\_GROUP错误码。

协调者处理“加入组请求”和“同步组请求”时，涉及比较复杂的状态机转换操作。这里先抛开状态机，协调者处理两种情况的最终目的是：返回“加入组响应”和“同步组响应”给消费者客户端。其中，“加入组响应”要能够返回所有的消费者成员信息，“同步组响应”要能返回消费者的分配信息。