ZooKeeper-9.3 Zab:状态更新的广播协议- 高飞网

9.3 Zab:状态更新的广播协议

2018-06-07 10:32:51.0

    在接收到一个写请求操作后,追随者会将请求转发给群首,群首将探索性的地执行该请求,并将执行结果以事务的方式对状态更新进行广播。当事务提交时,服务器会将这些变更反馈到数据树上,其中数据树为ZooKeeper用于保存状态信息的数据结构。

    服务器如何确认一个事务已经提交,采用的就是Zab协议:ZooKeeper原子广播协议(ZooKeeper Atomic Broadcast protocal),一个事务的提交过程如下,类似于一个两阶段提交。

  1. 群首向所有追随者发送一个PROPOSAL消息p
  2. 当一个追随者接收到消息p后,会响应群首一个ACK消息,通知群首其已接受该提案(proposal)
  3. 当收到仲裁数量的服务器发送确认消息后,群首就会发送消息通知追随者进行操作操作。

    Zab保障了以下几个重要属性:

  1. 如果群首按顺序广播了事务T和事务T',那么每个服务器在提交T'事务前保证事务T已提交完成,保证了事务在服务器之间传送顺序的一致
  2. 如果某个服务器按照事务T、事务T'的顺序提交事务,所有其他服务器也必须会在提交事务T前提交事务T。保证服务器不会跳过任何事务。

    事务在某些服务器上可能会终结,而其他服务器上却不会,因为在写入事务到存储中时,服务器也可能发生崩溃。无论何时,只要仲裁条件达成并选举了一个新的群首,ZooKeeper可以将所有服务器的状态更新到最新。

    ZooKeeper自始至终并不总是有一个活动的群首,因为群首服务器也可能崩溃,或短时间失去连接,此时其他服务器需要选举一个新的群首以保证系统整体仍可用。zxid有两部分组成,一部分是时间戳epoch,代表了管理权随时间的变化情况,一个时间戳表示了某个服务器行使管理权的这段时间,在一个时间戳内,群首会广播提案消息,并根据计数器counter识别每一个消息。

    时间戳在的值在每次新群首选举发生时便会增加。

    一个被选举的群首确保在提交完所有之前的时间戳内需要提交的事务,之后才开始广播新的事务。
    在任何时间点,都不会出现两个被仲裁支持的群首。

    在时间戳发生转换时,ZooKeeper使用两种不同的方式来更新追随者来优化这个过程。如果追随者滞后于群首不多,群首只需要发送缺失的事务点。因为追随者按照严格的顺序接收事务点,这些缺失的事务点永远是最近的。这种更新在代码中被为DIFF。如果追随者滞后很久,ZooKeeper将发送称为SNAP的完整快照。因为发送完整快照会增大系统恢复的延时,发送缺点的事务点是更优的选择。可是当追随者滞后太远的情况下,我们只能选择发送完整快照。



上一篇:9.2 群首选举
下一篇:9.4 观察者