第九章：zookeeper内部原理

zookeeper集群中的服务器分为三种角色：群首leader、跟随者follower、观察者observer。

群首作为中心点处理所有对zookeeper系统变更的请求，包括create、setData、delete；

追随者角色接收群首所发出的更新操作请求，并对这些请求进行处理，以此来保障状态更新操作不会发生碰撞。

观察者角色的设计只是为了系统的可扩展性。

群首与跟随者角色会参与集群群首的选举。

其中群首与跟随者服务器组成了保障状态变化有序的核心实体。

 

请求、事务、标识符

1、zookeeper服务器会在本地处理只读请求，包括exist、getData、getChildren操作。例如一个服务器接收到客户端的getData请求，服务器读取状态信息，并将这些信息返回给客户端。

因此服务器在处理只读请求时性能很高，同时可以通过扩张更多的服务器的方式，处理更多的只读请求，提升整体的处理性能。

2、zookeeper对那些可以更改状态的请求，包括create、setData、delete操作，会被转发给群首leader，群首执行相应的请求，并形成状态更新，可以把这个过程称为事务。

其中请求表示客户端发起的操作 ，而事务则包含了对应请求处理而改变zookeeper状态所需要执行的步骤。

注意：一个客户端提交了一个对/z节点的setData请求，setData将会改变node节点的数据信息， 并增加该节点的版本号，因此对这个请求的事务包含了两个重要字段：节点中新的数据字段和该节点新的版本号。当处理该事务时，服务端将会用事务中的数据信息替换/z节点的数据，同时使用事务中的版本号替换/z节点的版本号，而不是增加版本号的值。

zookeeper集群以事务方式运行，并保证所有变更操作以原子方式被执行，同时不会被其他事务所干扰。

zookeeper使用多线程的方式，以便提高事务处理的速度。

zookeeper的事务具有幂等性，我们可以对一个事务执行两次。得到的结果还是一样的。还可以对多个事务执行多次，只要保证多个事务执行的顺讯都是一样的。

事务的幂等性可以让我们进行恢复处理时更简单。

群首对产生的每个事务都会分配一个标识符，可以成为zxid，zxid由两部分组成：时间戳和计数器，这两个字段都是32位的。

 

群首选举

群首为zookeeper集群中选举出的一个服务器，群首可以保证对zookeeper集群的变更操作请求进行排序。

群首必须被法定数据量的服务器所认可，法定数量必须在集群数量是能够交叉的，以避免出现脑裂问题。

使用仲裁来表示属于一个进程的子集（包括群首与跟随者服务器），仲裁模式要求服务器之间两两相交。

每个服务器在启动后都会进入looking状态，开始选举一个新的群首或者查找已经存在的群首。

如果已经存在群首，其他服务器就会通知这个新启动的服务器，告知哪个服务器时群首，同时新的服务器需要与群首建立连接，以确保自己的状态与群首一致。

如果集群中的所有服务器都处于looking状态，这些服务器之间就行通讯来选举一个群首。在本次选举中胜出的服务器将进入leading状态，其他服务器将会进入following状态。

群选举的消息称为群选举通知消息，或者称为通知，该协议很简单，当一个服务器进入looking状态时就会向集群中的每个服务器发送一个通知消息，该消息中包括服务器的投票信息，投票信息中包含了服务器标识符sid，与最近执行的事务的zxid信息，比如一个投票信息（1,5），1为服务器sid，5为zxid。

当一个服务器接收到投票信息，该服务器会根据以下规则修改自己的投票信息：

如果voteZxid>myZxid或者（voteZxid=myZxid 且voteId>myId），保留当前的投票信息

否则，修改自己的投票信息，将voteZxid赋值给myZxid，将voteId赋值给mySid

简而言之，只有最新的服务器将赢得选举，因为其拥有最近一次的zxid。

当一个服务器接收到的仲裁数量的服务器发送的投票信息都一样时，就表示群首选举成功。

注意：并没有要求追随者一定成功连接上被选举的群首服务器。

 

快速群首选举的快速指的是什么？这是相对于之前的群首选举来说的，最初的群首选举采用的是拉取的模型，一个服务器拉取投票值的间隔大概为妙，该方法增加了恢复的延迟时间，相比较现在的实现方式，我们可以成为快速的进行群首选举，

 

ZAB：状态更新的广播协议

在接收到一个写请求后，追随者会将请求转发给群首，群首将尝试执行该请求，并讲请求结果以事务的方式对状态进行广播。一个事务包含服务器需要执行变更的确切操作，当时误提交时，服务器就会将这些变更反馈到数据树上，其中数据树为zookeeper用于保存状态信息的数据结构。

Zab全称为zookeeper atomic broadcast protocol （zookeeper原子广播协议），该协议类似两步提交过程。

1、群首向所有追随者发送一个proposal消息

2、当一个追随者接收到消息p时，会响应群首一个ack信息，通知群首其已经接收该提案。

3、当收到仲裁数量的服务器发送的确认消息后（该仲裁数包含群首自己），群首就发送消息通知追随者进行提交操作。

 

Zab协议保障了以下几个重要的属性：

1、如果群首按照顺序广播了事务T和事务T1，那么每个服务器在提交T1事务前保证事务T已经提交完成。

2、如果某个服务器按照事务T、事务T1的顺序提交事务，所有其他服务器也必然会在事务T提1提交前提交事务T。

第一个属性保证事务在服务器间的传送顺序的一致。

第二个属性竖向的保证服务器不会跳过任何事务。

两阶段提交保证了事务的顺序。Zab在仲裁数量服务器中记录了事务，集群中仲裁数量的服务器需要在群首提交事务前对事务达成一致，而且追随者也会在硬盘中记录事务的确认信息。