分布式协调系统

chubby锁服务

系统架构

Chubby保证了可靠性与高可用性，且在语义上易于理解（易于编程？）
使用5台服务器，一台为主4台作为备份，保证有一台主服务器且主服务器不可用时，能够选举出一台备用服务器作为主服务器

数据模型

以树形结构保存与管理目录
提供查询与加锁服务

会话

客户端通过租期与续约来保持服务器的keepalive，服务器通过term保证一致性

客户端缓存

客户端可缓存部分数据信息，以减轻服务器压力
服务器修改数据需保证所有缓存数据的客户端都接受到数据已过期的通知

zookeeper

zookeeper任意一台服务器均可响应客户端的读操作（写操作同样只能主服务器进行？），这样相比于Chubby获得了更高的性能。

一致性

虽然主从服务器通过ZAB协议来保证更新操作的一致性与顺序写，但是由于传播时间的问题，客户端任有可能获得非最新的数据（即该数据在主从服务器中不一致）
1.提供sync()API，该操作使得从属服务器从主控服务器同步状态信息。因此，当客户端在读数据前调用该API则一定会获得最新的数据。
2.（若客户端没有调用sync（））客户端与服务器通信时，附带一个zxid，服务器会比对zxid与自身的zxid，确保客户端一定不会获取比自己目前还早的数据。

API

zookeeper提供一系列API

应用场景

核心通过，当 当前节点发生更改，则向所有watch节点发送消息的功能（消息订阅发布？）
1.领导者选举
2.配置管理
3.成员管理
4.任务分配
5.锁（在锁节点拉链，在自己前面一个node设置watch。所以知道拿到锁只会被唤醒一次）
6.双向路障同步