Zookeeper05——内部原理（会话，事务，选举，Zab）

1.会话

• 简介
  • 客户端与服务端之间的任何操作都依赖于会话。
  • Zookeeper的连接与会话就是客户端通过实例化Zookeeper对象来实现客户端与服务端之间 创建并保持TCP连接的过程。
  • 会话是Zookeeper的一个重要抽象。保证请求有序，临时节点，监视点都与会话密切相关。
• 会话状态
  • 
    • 步骤1:会话从NOT_CONNECTED开始，当Zookeeper客户端初始化后转换到CONNECTING状态。
    • 步骤2:客户端成功与Zookeeper服务器建立连接后，会话转到CONNECTED。
    • 步骤3:当客户端无法收到服务器响应或与服务器连接断开时，进行此步骤，连接状态变化为CONNECTING状态并尝试发现其他的Zookeeper服务器，如果重新连接成功，即步骤2。
    • 步骤5:步骤3中，重新连接失败后，客户端将会声明会话过期，状态转换到CLOSED。
    • 步骤4:客户端显式的关闭会话。
• 客户端与服务端对会话的维护
  • 创建会话时设置一个重要参数——会话超时时间sessionTimeout，这个参数设置了会话允许被声明为超时之前存在的时间。
  • 服务端：在经过sessionTimeout时间后，未接受到该会话的任何消息，服务就会声明会话过期。
  • 客户端：在经过1/3 sessionTimeout的时间未收到任何消息，客户端将会向服务器发送心跳消息，在经过2/3.sessionTimeout时间后，客户端开始寻找其他的服务器，剩余1/3的时间寻找。
• 服务器与会话
  • Zookeeper的服务器一个重要任务就是跟踪并维护这些会话。
  • 独立模式下，单个服务器会跟踪所有的会话，在集群模式下由群首服务器来跟踪维护。两者都是运行相同的会话跟踪器（SessionTracker类和SessionTrackerImpl类）。
  • 为保证会话的存活，服务器需要接收会话的心跳信息。
    • 心跳的形式可以是一个新的请求或者显式的ping消息。
    • 以上两种形式触发一种，服务器会更新会话的过期时间。
    • 集群模式下，群首服务器会发送一个PING消息给他的追随者们，追随者返回最新一次PING消息之后的一个Session列表。群首每半个tick发送一个PING消息给追随者们。
  • 会话的过期管理主要通过一个过期队列（expire queue）的数据结构，来维护会话的过期。
    • 这个数据结构使用bucket来维护会话，每一个bucket对应某一个时间范围内过期的会话。
• 集群模式下，客户端的会话转移
  • 客户端尝试连接到不同的服务器时，通过客户端记录的 事务标识符（zxid） 来与服务端的事务标识符比较，不能连接小于客户端的事务标识符号的服务器。这样保证了客户端不会连接到状态滞后的服务端。

2.事务

• 对于事务我们知道事务的基本要素是具备ACID（原子性，一致性，隔离性，持久性）特性。对于事务在应用中的体现，是建立在应用对数据进行请求的时候，所以在谈Zookeeper的事务的时候，我们先谈下Zookeepe的请求，分为读请求与写请求。
• Zookeeper客户端请求（集群模式下）
  • 读请求
    • 对于读请求，Zookeeper服务器只会在本地处理（exists，getData和getChildren）。因此Zookeeper在处理只读请求为主要负载的时候，性能会很高。
  • 写请求
    • 对于写请求，会被接收请求的服务端转发给群首，群首执行相应的请求，并形成状态的更新，称之为事务（transaction） 。其中请求来源于客户端发起的操作，而事务则包含了对应请求处理而改变Zookeeper状态需要执行的步骤。
    • 例子：假设客户端提交了一个对/z节点的setData请求，setData将会改变znode 节点数据 信息，并会增加该 节点的版本号，那么对于这个请求的事务来说，此事务中包含两个重要字段：节点中新的数据字段值和该节点新的版本号。当处理该事务时，服务端将会用事务中的数据信息替换原来的/z节点的数据信息，并以事务中的版本号替换节点版本号，不是增加版本号的值。
• 事务（transaction）：
  • 事务的特性：
    • 一个事务为一个原子执行单位。即不会存在更新了节点的数据但没有更新节点版本号的情况。
    • 在Zookeeper中不存在关系型数据库的回滚机制，而是确保每一步的操作都互不干扰。
    • Zookeeper事务具备幂等性，即同一个事务执行两次及以上，会得到相同的结果（建立在每个事务顺序每次都是一致的）。
  • 事务标识符
    • 当群首产生一个事务，就会为该事务分配一个标识符，称之为Zookeeper的会话id（zxid），通过Zxid对事务进行标识，这样保证了可以按照群首指定的顺序在各个服务器（follower）中按顺序执行。（服务器之间进行新的群首选举时也会交换zxid信息，这样可以知道那个无故障服务器接收了更多的事务，并可以同步他们之间的状态信息）
    • zxid：long型，64位整数，分为两部分：时间戳（epoch）和计数器（counter），每部分32位数。

3.群首选举

• 简介
  • 群首为集群中的服务器选择出来的一个服务器，用来对客户端所发起的Zookeeper 状态变更请求进行排序。
  • 群首将每一个更新请求转换为一个事务，自己执行完成后，并将这些事务发送给追随者。
• 集群选举
  • 成为群首条件：超过集群中半数的服务器选你。
  • 每个服务器启动后进入LOOKING状态，开始选举一个新的群首或查找已经存在的群首。如果群首存在，其他服务器就会通知这个新启动的服务器，告知哪个服务器是群首，于此同时，新的服务器会与群首建立连接，以确保自己的状态与群首一致。
  • 群首不存在，即所有的服务器都处于LOOKING的状态，那么这些服务器之间就会通过通信来选举一个群首，通过 信息交换（投票） 来达成对群首选举的共识。
  • 群首选举信息称之为群首选举通知信息。通信协议很简单，当一个服务器进入LOOKING状态，发现没有群首存在，就会向集群中的每个服务器服务器发送一个通知消息，该消息中包含服务器的投票（vote）信息，投票中包含 服务器标识符（sid，即服务器配置的myid）和服务器最近执行的 事务的zxid 信息。然后各个服务将接收到的信息和自己本地的数据比较，然后修改投票信息。一个服务器的投票流程如下：
    • 将接收到其他服务器投票信息中的sid，zxid和自己的 mysid，myzxid比较。
    • 如果 myzxid>zxid 或者 **(myzxid=zxid && mysid>sid)**的时候，保留自己的投票信息，否则将自己的投票信息修改为接收到的投票信息。
  • 在如上的整个投票流程，即优先最新事务的服务器成为群首。
  • 在一个服务器成为群首，就会行使群首的权力，同时其他的服务器成为追随者之后尝试连接群首服务器，并同步群首的状态。
  • 群首选举过程如下图，参照前面介绍的群首选举说明进行理解：

4.Zab(Zookeeper的原子广播协议)

• 原子广播是对集群中事务的提交引入的。对此需要先说明Zookeeper服务集群中的事务的提交流程。
  • 应用在接收到一个写请求操作之后，追随者会将请求转发给群首， 群首将探索性的执行该请求，并将执行的结果以事务的方式对˙状态更新进行广播。一个事务中包含服务器需要执行变更的确切操作，当事务提交时，服务器就会将这些变更反馈到数据树上，其中数据树为Zookeeper保存状态信息的数据结构（org.apache.zookeeper.server.DataTree）。
  • 然而集群如何确认一个事务已经提交，这里就是通过Zab协议来保证的。
  • Zookeeper事务提交流程按步骤如下：
    • 群首向所有追随者发送一个PROPOSAL(提案)消息p。
    • 当一个追随者接收到消息p后，会响应群首一个ACK消息，通知群首其已接收该提案（PROPOSAL）。
    • 当收到仲裁数量的服务器发送确认信息后（仲裁数量包括群首自己），群首发送消息通知追随者进行提交（COMMIT）操作。
  • 在上面群首与追随者之间交互的过程之中，Zab协议保证了执行顺序的正确。Zab保障如下：
    • 如果群首按顺序广播了事务T1和T2，那么每个服务器在提交事务T2的时候，保证事务T1已经执行。
      • 此特性保证了事务在服务器之间的传送顺序的一致。
    • 如果某个服务器按照事务T1和T2的顺序提交事务，那么其他服务器也必然会按照此顺序提交事务。
      • 此特性保证了服务器不会跳过任何事务。
    • 一个被选举的群首在提交完成所有之前的时间戳内需要提交的事务之后，才开始广播新的事务。
    • 在任何时间点，都不会出现两个被仲裁支持的群首。