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