mjunz的博客

没有创建临时节点成功的客户端也就没能获得锁，需要到"/exclusive_lock"节点上，注册一个子节点变更的Watcher监听，以便可以实时监听lock节点的变更情况。如果有大量的客户端在等待锁的释放，那么不仅会出现大量的Watcher通知，还会出现大量的获取"/shared_lock"的子节点列表的请求，但最后大部分客户端都会判断出自己并非是序号最小的节点。当控制台进行一些操作时，便会触发修改这些节点的数据，而zk会将这些节点数据的变更以事件通知的形式发送给监听的客户端。

轮询法是最为简单的负载均衡算法。加权轮询法的方式与轮询法的方式很相似，唯一的不同在于选择机器时，不只是单纯按照顺序的方式去选择，还要根据机器的配置和性能高低有所侧重，让配置性能好的机器优先分配。TDDL通过分批获取ID编码的方式，减少了客户端访问服务器的频率，避免了网络波动所造成的影响，并减轻了服务器的内存压力。首先负载均衡服务器在接收到客户端的请求后，通过getData()方法获取已成功注册的业务服务器列表，也就是"/Servers"节点下的各个临时节点，这些临时节点都存储了当前服务器的连接数。

CREATE、READ、WRITE、DELETE、ADMIN，也就是增、删、改、查、管理权限，这5种权限简写为crwda(即：每个单词的首字符缩写)。zk支持某些特定的四字命令字母结合nc与其的交互，这样可以用来获取zk服务的当前状态及相关信息，也就是通过telnet或nc向zk提交相应的命令。创建顺序节点使用-s，可以重复创建"同名"的顺序节点(命令行看起来同名而已，但实际不是同名的)。不管是持久节点还是临时节点，一旦创建完一个节点后，再重复创建同名节点都是不成功的。

zk重启时就可以把包含1000个事务的快照直接加载到内存里，然后把1000之后的32个事务，在内存里回放一遍，即可恢复重启前的数据。一般来说，在启动zk集群之前，首先需要在zoo.cfg配置文件里设置好参数，比如设置zk集群server.1、server.2的信息，设置dataDir、dataLogDir的目录，开启自动清理数据文件等。zk在不停的运行，事务日志会越来越多，但不可能是无限多的，所以zk会切割出多个事务日志文件。即使Follower宕机，也只丢失内存里的数据，磁盘上的事务日志是存在的。

同理，如果Leader收到过半Follower的ACK响应后，在发送Commit消息的过程中，出现Leader宕机或者Leader和Follower的网络问题。那么Follower只要与它能找到的Leader(新选举的ZXID最大的Follower或者原来的Leader)进行数据同步，就可以保证新数据在该Follower中完成Commit。某个客户端连接到某个Follower时可以读取到刚刚Commit的数据，但有的客户端连接到另一个Follower时却没法读取到还没有Commit的数据。

集群启动后会自动选举一个Leader出来，只有Leader可以写，Follower只能同步数据和提供数据的读取。zk封装了分布式架构中很多核心和主流的需求功能，比如很多分布式系统都需要分布式锁、集中式存储分布式集群的元数据、Master选举、分布式协调，这些功能需求都可以使用zk来实现。Kafka里使用zk进行元数据管理、Master选举、分布式协调，Canal也一样使用zk进行元数据管理、Master选举(HA主备切换)，HDFS的HA也是基于zk来做的。假设现在有3台机器，要进行元数据的存储。

大纲1.分布式系统特点2.分布式系统的理论3.两阶段提交Two-Phase Commit(2PC)4.三阶段提交Three-Phase Commit(3PC)5.Paxos岛的故事来对应ZooKeeper6.Paxos算法推导过程7.Paxos协议的核心思想8.ZAB算法简述6.Paxos算法推导过程(1)Paxos的概念(2)问题描述(3)推导过程(4)Proposer生成提案(5)Acceptor批准提案(6)Paxos算法描述(7)Learner学习被选定的value(8)如何保证Paxos算法的活性

紧接着他又收到了S2的提议，结果他一查记事本，发现这个提议的编号小于等于我的当前编号1，于是拒绝了这个提议：对不起，这个提议先前提过了。因此S2的提议被拒绝，S1的提议被S1和S3同意。每个议员(zk的Server)只会同意大于当前编号(zk的ZXID)的提议(Proposal)，包括已生效和未生效的(分布式节点要排除由于网络延迟而晚收到的消息)。Chubby和ZooKeeper都是基于Paxos的理论来实现的，Paxos还被认为是到目前为止唯一的分布式一致性算法，其它的算法都是Paxos的改进或简化。