$ 《ZooKeeper分布式过程协同技术详解》笔记
$ 第一章
$ 1.1 ZooKeeper的使命
它可以在分布式系统 中协作多个任务。一个协作任务是指一个包含多个进程的任务，这个任务可以是为了协作或者是为了竞争。
ZooKeeper客户端功能包括：
- 保障强一致性、有序性和持久性
- 实现通用的同步原语的能力
- 提供了一种简单的并发处理机制
ZooKeeper不适用于海量数据存储。
$ 1.2 示例：主-从应用
主-从架构：一个在分布式系统中得到广泛应用的架构。主节点进程负责跟踪从节点状态和任务的有效性，并分配任务到从节点。对于ZooKeeper来说，这个架构风格具有代表性，阐述了大多数流行的任务，如：
- 选举主节点
- 跟踪有效的从节点
- 维护应用元数据
要实现主从模式的系统，必须解决以下三个关键问题：
- 主节点崩溃（备份主节点故障转移，避免脑裂）
- 从节点崩溃（主节点检测从节点崩溃的能力，消除崩溃副作用）
- 通信故障（从节点适应多个从节点执行相同任务的可能性）
主从架构需求：
- 主节点选举
- 崩溃检测
- 组成员关系管理
- 元数据管理
$ 第2章
$ 2.1 ZooKeeper基础
ZooKeeper并不直接暴露原语，它暴露了由一小部分调用方法组成的类似文件系统的API，以便允许应用实现自己的原语。
$ API概述
- create /path data
- delete /path
- exists /path
- setData /path data
- getData /path
- getChildren /path
ZooKeeper不允许局部写入或读取znode的数据。
$ znode类型
- persistent
- ephemeral
- persistent_sequential
- ephemeral_sequential
$ 监视与通知
为了替换客户端的轮询，选择了基于通知的机制。
客户端必须在每次通知后设置一个新的监视点。
通知机制的一个重要保障是，对同一个znode的操作，先向客户端传送通知，然后再对该节点进行变更。保证客户端以全局的顺序观察zookeeper的状态。
$ 版本
使用版本来阻止并行操作的不一致性。
每个znode都有一个版本号，它随着每次数据变化而自增。
两个API setData和delete调用以版本号为传入参数，只有当传入参数的版本号与服务器上的版本号一致时调用才会成功。
$ zookeeper仲裁
$ 会话
客户端提交给zookeeper的所有操作均关联在一个会话上，会话终止=>会话期间创建的临时节点消失。
会话提供了顺序保证。
会话的状态：
NOT_CONNECTED => CONNECTING <=> CONNECTED => CLOSED
|_________________________↑
客户端尝试连接到一个不同的服务器时，这个服务器的状态要与最后连接的服务器的zookeeper状态保持最新。
$ 主从模式例子的实现
主从模式的模型包括三个角色：
- 主节点
- 从节点
- 客户端
实现过程：
创建主节点：
create -e /master "master2.example.com:223"
创建一些必要节点：
create /workers ""
create /tasks ""
create /assign ""
主节点监视/workers, /tasks子节点变化：
ls /workers true
ls /tasks true
从节点创建：
create -e /workers/worker1.example.com "worker1.example.com:2224"
从节点准备接收任务：
create /assign/worker1.example.com ""
从节点等待任务分配：
ls /assign/worker1.example.com true
客户端提交任务，并监视新建的/tasks/task-0000000000子字节：
create -s /tasks/task- "cmd"
从节点执行完毕，更新任务状态：
setData /tasks/task-0000000000/status "done"
客户端检查结果：
get /tasks/task-0000000000
$ 第三章
一个对象的构造函数没有返回前不要调用其他函数。