数据存储：大数据存储系统（5）--- ZooKeeper

本文转载自：https://blog.csdn.net/u013710265/article/details/72818735

Distrubuted Coordination：ZooKeeper

1、概念
用于分布式系统中， 多个节点协调。

• Leadership election：选举一个代表负责节点
• Group membership：哪些节点还活着？发现崩溃等故障
• Consensus：对一个决策达成一致

Zookeeper：Yahoo研发的开源分布式协调系统。是Hadoop/Hbase环境的一部分。

目前广泛应用于分布式系统对于master节点的容错。

• 使用多台机器运行master节点，一台为主，其余为备份
• 当主master出现故障，某台备份可以成为主master

2、数据模型和API

（1）数据模型：Data Tree

共同维护一个数据状态

 

（2）Client API

Watch机制：Client的读操作可注册watch，ZooKeeper数据改变，通知Client一次（仅一次，继续关注需继续注册watch）

create（path，data，flags(regular/ephemeral)）返回Znode的name

delete（path，version）version与现在Znode一致才删除

exists（path，watch）返回T/F

getData（path，watch）返回data和version

setData（path，data，version）version与现在Znode一致才修改

getChildren（path，watch）返回所有孩子Znode

sync（）等待前面的写操作完成create、delete、setdata

支持同步与异步方式

• Synchronous 同步：Client发请求，阻塞等待响应，当请求多时慢
• Asynchronous 异步：允许Client发送多请求，不需要阻塞等待请求完成；提供Callback函数，当请求完成时调用

（3）保证

写操作可串行化 Linearizable writes；

client的读写操作按照FIFO顺序发生 FIFOclient order；

不同client之间的读写顺序没有保证，读可能得到旧数据，so读最新数据要sync！

3、基本原理

（1）ZooKeeper系统结构

（2）ZooKeeper节点内部结构

读请求直接由本地的Replicated database回答。

写请求Atomic Broadcast发给leader统一处理（写操作全局串行化，使用ZAB协议，2PC变型）。

leader将写请求包装为Idempotent Transaction（每个Txn可赤执行多次来恢复，Txn有唯一递增ID）。

Atomic Broadcast后，写操作修改本地Replicated database。

（3）ZAB：两个主要工作模式

• 正常Broadcast：Leader向Follower广播新的写操作。

  如果Leader未收到f个Ack(timeout了)或Follower长时间未收到Leader的消息，那么就发现了故障，需要进入Recovery。

• 异常Recovery：竞争新Leader，新Leader恢复。

  竞争Leader： 最大限度保护Client写操作。 新Leader：把所有正确执行的Txn都确保正确执行（idempotent，再广播一次），
  其他已经提交但未执行的Client操作丢弃（Client会重试）。TxnID：64位（高32 epoch + 低32 in­epoch id）