zookeeper学习笔记

server.id=host:port1:port2

全局有序：如果消息 a 在消息 b 之前被投递，那么在任何一台服务器，消息 a都会在消息 b 之前被投递

因果有序：如果消息 a 在消息 b 之前发生（a 导致了 b），并被一起发送，则 a 始终在 b 之前被执行。

有 2f+1 台服务器，只要有大于等于 f+1 台的服务器正常工作，就能完全正常工作。

3/4 -> 2; 5/6->3, 7/8->4

广播（boardcast）：Zab 协议中，所有的写请求都由 leader 来处理。正常工作状态下，leader 接收请求并通过广播协议来处理。

恢复（recovery）：当服务初次启动，或者 leader 节点挂了，系统就会进入恢复模式，直到选出了有合法数量 follower 的新 leader，然后新 leader 负责将整个系统同步到最新状态。

简化的二阶段提交

过程

和二阶段提交比较

Zab 协议的广播部分不能处理 leader 挂掉的情况，Zab 协议引入了恢复模式来处理这一问题

目的

场景

选举策略

已经处理的消息不能丢

被丢弃的消息不能再次出现

重启时

同一个客户端无论连接到集群中的哪台机器上，都将会看到服务的同一视图。即：同一客户端无论什么时候连接到哪个服务器上，都不会看到比自己之前看到的数据更早版本的数据。

如何保证

网络延迟或者其他因素可能导致不同的客户端在不同的时刻感知某一监视事件，但是不同的客户端所看到的一切具有一致的顺序

顺序一致性：来自客户端的更新将按照发送的顺序被写入到zk

原子性：更新操作要么成功要么失败，没有中间状态

可靠性：一旦应用更新，数据将被持久化，直到数据被再次更新，对于该保证有两个推论：1、如果客户端得到了成功的返回码，说明写入成功，数据被持久化，如果出现了通信错误，超时等一些故障，客户端将不知道更新是否已应用。我们采取措施尽量减少失败，但唯一的保证是只有成功的返回码。 （这在Paxos中称为单调性条件。）2、如果客户端已经读取到了数据或者写入成功了数据，都不会因为zk的失败而导致回滚；

及时性：任何客户端所看到的系统视图的滞后都是有限的，不会超过几十秒。如果一个服务器数据很陈旧就会关闭，并强迫客户端连接到新的服务器。

4.等待无关（wait-free）：慢的或者失效的client不得干预快速的client的请求，使得每个client都能有效的等待。

分为follower 和 leader脑裂. 当脑裂发生时, 如果 follower和 leader 及其他节点通信延迟到某个值, 会导致 follower不可用.

leader 脑裂会自动选举 leader

网络分区后, 小于等于n/2的节点的集群都是不可用的,例如 5 个节点,其中 2/3分区, 2 节点的分区不可用

Master选举的容灾措施是，可以随时进行手动指定master，就是说应用在zk在无法获取master信息时，可以通过比如http方式，向一个地方获取master。

CONNECTING、CONNECTED、RECONNECTING、RECONNECTED 和 CLOSE

当设置监视的数据发生改变时，该监视事件会被发送到客户端，例如，如果客户端调用了getData("/znode1", true) 并且稍后 /znode1 节点上的数据发生了改变或者被删除了，客户端将会获取到 /znode1 发生变化的监视事件，而如果 /znode1 再一次发生了变化，除非客户端再次对/znode1 设置监视，否则客户端不会收到事件通知。

此时无法判断请求处理是成功还是失败,只能业务自己判断, 但是 zookeeper一定是成功或失败,不存在中间状态

在Zookeeper中，服务器和客户端之间维持一个长连接，CONNECTION_LOSS意味着这个连接断开了。客户端API返回CONNECTION_LOSS时，不能确定请求是成功还是失败（视连接断开发生在请求发送之前还是之后，遗憾的是无法区分这两种情况），应用需要自己的逻辑来确认操作是否成功

Session超时由服务端管理。客户端在初始化连接时会指定该Session的超时时间（下面用T表示），相当于服务端给客户端的一个Lease。客户端的每次请求到达服务端后，服务端会刷新该Session的Lease（续约），如果客户端在T/3时间内都无请求，则内部会发送一个PING来续约。正常情况下，客户端与服务端的Session将一直保持，当出现网络闪断或者连上的那台服务器断电等情况，

只要客户端在Lease时间内重连上Cluster中某台机器，Session将仍然有效。

如果服务端在时间T内未收到一个Session的任何信息时，Zookeeper认为该Session已经超时了，之后由集群的Leader来下发Session超时的命令，该Session的相关信息（Session本身、其创建的临时节点及添加的Watch）将被Zookeeper清除。在Session超时这一过程中，客户端通常会先看到连接断开，只有与Zookeeper重新建立连接后，客户端才能收到Session超时事件（也就是说SESSION_EXPIRE事件一定是服务端告诉客户端的，客户端本身没有相关的计时逻辑）。

收到SESSION_EXPIRE后，客户端要做的事情视应用的场景而定。一般情况，需要重新与Zookeeper建立建立（注意一定要关闭之前的连接），重新建立临时节点，重新添加的Watch。

处理连接断开事件中，应用开发者必须清楚处于闪断附近的那个请求是什么（这常常难以判断），该请求是否是幂等的，对于业务请求在Server端服务处理上对于”仅处理一次” “最多处理一次” “最少处理一次”语义要有选择和预期

例如

重连发生在两种情况，其一是socket连接发生异常，其二是socket连接正常，但是2T/3时间内未收到服务端的响应。

不支持永久Watch的原因是Zookeeper无法保证性能。永久Watch意味着数据的每一次修改都要通知到所有的观察者，这是无法接受的。在大多数情况下，客户端并不需要追踪节点的每一次变化。

在Zookeeper最初始的版本中，事件通知带上了具体的变更内容，比如/a的值变成了v2，但这很难被正确使用。Watch的目的是用来追踪节点最近的变化，直接通知内容会有如下问题：比如Client A首先获取/a的内容为v1，并设置了Watch，之后Client B将/a的值依次设置为v2，v3，这样Client A将只能获取到/a的内容变成了v2，无法得知其已经变为v3。

收到通知与重新添加Watch不是原子的，如果在之间节点的内容被修改多次，这中间的修改将不被感知。

如果一定需要追踪节点每次的变化，需要仔细的设计观察者与写者之间的协议，可参考ZKC一致性cache的做法。

a. Watch的通知是一次性的；

b. 客户端在CONNECTIONLOSS之后有重新连上Zookeeper（未发生SESSION超时），那么这个连接注册的Watch依然在。内部会重新发送添加过的Watch，并且如果Watch的节点在CONNECTIONLOSS阶段发生了改变，重连上之后会收到对应的事件（不会因为与Zookeeper的连接断开而丢失事件）；

c. 需要注意的一种情况是：对一个不存在的节点添加exists的Watch，之后该Session与Zookeeper断开连接，在重新连上之前，这个节点被创建了，又被删除了，该Session重新连上之后，将不会收到通知。

d. 变化指节点的版本号，即使已相同的值set该节点，将触发CHANGED事件；

e. 对同一个节点多次注册Watch，只会收到一次事件，如执行zoo_wexists(“/a”)两次，当/a被创建或者被删除时，该Session只会收到一次通知；

f. 切忌在回调函数中抛出异常

CONNECTED 第一次连接

SUSPENDED 对应原生的Disconnected

LOST 对应原生的Expired

SyncConnected 连接成功和重连成功时触发

Disconnected 连接断开时触发

Expired session过期时触发

异步调用和观察者回调的所有完成将按顺序进行，一次一个。调用者可以进行他们希望的任何处理，但在此期间不会处理任何其他回调。

回调不会阻止IO线程的处理或同步调用的处理。

同步调用可能无法按正确顺序返回。例如，假设客户端执行以下处理：发出节点/ a的异步读取，并将 watch设置为true，然后在读取的完成回调中执行/ a的同步读取。（也许不是很好的做法，但也不是非法的，这只是一个简单的例子。）请注意，如果异步读取和同步读取之间存在/ a更改，则客户端库将在同步读取的响应之前接收监视事件/更改，但由于完成回调阻止了事件队列，在 处理监视事件之前，同步读取将返回新值/ a

所有的zk事件都在EventThread中按顺序执行，如果一个事件长时间执行会导致其他事件无法及时响应。

如果在事件 process过程中堵塞，其他事件即使发生了，也只会放到本地队列中，暂时不会执行。

判断是否存在该节点,如果存在是否需要删除重建.

每个节点都会存在 sessionId,需要判断是否相同