by shihang.mai

zookeeper用作分布式协调服务

1. zk节点

zk节点

• zk是目录树结构

• node大小只能为1m，这是为了减少网络传输的数据，服务协调快。

• 节点有临时节点和持久节点两类型,它们都可以作为序列化节点。

• 临时节点可配合session使用做分布式锁

1.1 节点属性详解

当执行命令

get /ooxx

结果

"hello";(二进制安全的)
cZxid = 0x20000002;(增加的事务id.事务id单调递增，c代表create。低32位代表事务id，高32位代表第几个leader,leader切换高32位增加1)
cTime = 时间;(创建时间)
mZxid = 0x20000004;(修改的事务id。)
mTime = 时间;(修改时间)
pZxid = 0x20000003;(当前节点下，最后创建节点的事务id)
ephemeralOwner = 0x0;(临时持有者,即创建临时节点的sessionid)

连接和消除session都要增加事务id

下面命令解决多线程下同一节点命名，zk会自动在节点后加上id

create -s /abc/xxx "ssss"

结果

/abc/xxx00000000

2. zk的特性

• Sequential Consistency:顺序性。
  因为所有写操作都在leader,leader单节点，保证顺序.
• Atomicity:原子性。
  因为所有写操作都在leader，leader和follower主从模式，要不成功要不失败，没中间状态.
• Single System Image:统一视图.
  因为是主从模型，客户端无论连接那个zk都一样。
• Reliability:可靠性/持久性。
• Timeliness:及时性/最终一致性。

zk的特点	zk特性
node可存放1m数据,并且所有客户端无论连接那个zk，都读取到一样的数据	统一配置管理
path结构	分组管理
sequential(create -s /abc/xxx "ssss")	统一命名
临时节点	同步

3. zk集群状态

zk集群状态

• zk集群中只有一个leader，其他是follower和Observer（主从）,只有follower参与选举。

• leader会存在单点故障。

但是zk是高可用的，证明有一种方式就算故障了也可以让其快速恢复。就是ZAB协议

如果连接的zk突然down了，在设置的timeout时间内恢复zk集群，那么连接会切换到另外一个zk上，session还是同一个

4. zk配置说明

zk并没有像redis一样的发布订阅，所以下面的配置需要配置这个集群所有zk。

如集群下有4个zk

#3888:在leader down了或者在刚启动时还没leader时用这个端口通信。选leader投票用的。
#2888:leader启动端口,leader接受write请求的端口。
#4台,过半(3台)就可以根据id谁大谁是leader了。例如启动1 2 3，3已经是leader
server.1=ip地址:2888:3888
server.2=ip地址:2888:3888
server.3=ip地址:2888:3888
server.4=ip地址:2888:3888:observer

5. zk的脑裂

假死：由于心跳超时（网络原因导致的）认为leader死了，但其实leader还存活着。
脑裂：由于假死会发起新的leader选举，选举出一个新的leader，但旧的leader网络又通了,导致有两个leader

5.1 zk脑裂解决

zookeeper采用过半策略+zab协议来解决脑裂

1. 假设某个leader假死，其余的followers选举出了一个新的leader。这时，旧的leader复活并且仍然认为自己是leader
2. 这个时候旧leader向其他followers发出写请求也是会被拒绝的。因为每当新leader产生时，会生成一个epoch标号(标识当前属于那个leader的统治时期)，这个epoch是递增的，followers如果确认了新的leader存在，知道其epoch，就会拒绝epoch小于现任leader epoch的所有请求。
3. 那有没有follower不知道新的leader存在呢，有可能，但肯定不是大多数，否则新leader无法产生。旧leader即使各种认为自己是leader，然并卵