zookeeper

会话（Session） Session是指客户端会话，在讲解客户端会话之前，我们先来了解下客户端连接。在ZooKeeper中，一个客户端连接是指客户端和ZooKeeper服务器之间的TCP长连接。ZooKeeper对外的服务端口默认是2181，客户端启动时，首先会与服务器建立一个TCP连接，从第一次连接建立开始，客户端会话的生命周期也开始了，通过这个连接，客户端能够通过心跳检测和服务器保持有效的会话，也能够向ZooKeeper服务器发送请求并接受响应，同时还能通过该连接接收来自服务器的Watch事件通知。Session的SessionTimeout值用来设置一个客户端会话的超时时间。当由于服务器压力太大、网络故障或是客户端主动断开连接等各种原因导致客户端连接断开时，只要在SessionTimeout规定的时间内能够重新连接上集群中任意一台服务器，那么之前创建的会话仍然有效。 版本 ZooKeeper的每个ZNode上都会存储数据，对应于每个ZNode，ZooKeeper都会为其维护一个叫作Stat的数据结构，Stat中记录了这个ZNode的三个数据版本，分别是version（当前ZNode的版本）、cversion（当前ZNode子节点的版本）和aversion（当前ZNode的ACL版本）。

leader 选举 和 follower 信息同步 如上图所示，kafaka集群的 broker，和 Consumer 都需要连接 Zookeeper。 Producer 直接连接 Broker。

https://github.com/knightliao/disconf Distributed Configuration Management Platform(分布式配置管理平台) zookeeper 五个功能点

1. master的管理，如amq 集群，kafka集群。
2. 分布式锁（悲观、乐观）
3. 分布式配置中心。
4. 集群的监管。
5. 发布与订阅（队列）。

znode数据结构有如下特点： 1> 每个znode都有唯一路径标识，最顶层的znode为/，比如p_2这个znode的路径标识为/app1/p_2，znode只支持绝对路径，不支持相对路径，也不支持“.”和“..” 2> znode可以有子节点，并且每个znode可以存储数据。但zk是被设计用来协调管理服务的，因此znode里存储的都是一些小数据，而不是大容量的数据，数据容量一般在1M范围内。 3> znode的数据有版本号，可以用在并发访问场景中，用乐观锁机制实现数据的一致性 4> znode分为临时节点和永久节点，zk的客户端和服务器通信采用长连接的方式，每个客户端和服务器通过心跳来保持连接，这个连接状态称为session，如果znode是临时节点，当session失效（即客户端与服务器断开连接），znode会被服务器自动删除。 5> znode的节点名称可以自动编号，如果app1已经存在，再创建的话，将会自动命名为app2，这种节点称为序列节点。 6> znode可以被监控，包括这个节点中存储的数据被修改、子节点列表变化（删除或新增子节点）等，一旦变化，zk服务器会通过所有监控该节点的客户端，这是zk的核心特性，zk很多的功能都是基于这个特性实现的。

Raft Paxos偏向于理论、对如何应用到工程实践提及较少。理解的难度加上现实的骨感，在生产环境中基于Paxos实现一个正确的分布式系统非常难[1]： There are significant gaps between the description of the Paxos algorithm and the needs of a real-world system. In order to build a real-world system, an expert needs to use numerous ideas scattered in the literature and make several relatively small protocol extensions. The cumulative effort will be substantial and the final system will be based on an unproven protocol. Raft[2][3]在2013年提出，提出的时间虽然不长，但已经有很多系统基于Raft实现。相比Paxos，Raft的买点就是更利于理解、更易于实行。 为达到更容易理解和实行的目的，Raft将问题分解和具体化：Leader统一处理变更操作请求，一致性协议的作用具化为保证节点间操作日志副本(log replication)一致，以term作为逻辑时钟(logical clock)保证时序，节点运行相同状态机(state machine)[4]得到一致结果。Raft协议具体过程如下： Client发起请求，每一条请求包含操作指令 请求交由Leader处理，Leader将操作指令(entry)追加(append)至操作日志，紧接着对Follower发起AppendEntries请求、尝试让操作日志副本在Follower落地 如果Follower多数派(quorum)同意AppendEntries请求，Leader进行commit操作、把指令交由状态机处理 状态机处理完成后将结果返回给Client 指令通过log index(指令id)和term number保证时序，正常情况下Leader、Follower状态机按相同顺序执行指令，得出相同结果、状态一致。 宕机、网络分化等情况可引起Leader重新选举(每次选举产生新Leader的同时，产生新的term)、Leader/Follower间状态不一致。Raft中Leader为自己和所有Follower各维护一个nextIndex值，其表示Leader紧接下来要处理的指令id以及将要发给Follower的指令id，LnextIndex不等于FnextIndex时代表Leader操作日志和Follower操作日志存在不一致，这时将从Follower操作日志中最初不一致的地方开始，由Leader操作日志覆盖Follower，直到LnextIndex、FnextIndex相等。 Paxos中Leader的存在是为了提升决议效率，Leader的有无和数目并不影响决议一致性，Raft要求具备唯一Leader，并把一致性问题具体化为保持日志副本的一致性，以此实现相较Paxos而言更容易理解、更容易实现的目标。 Zab Zab[5][6]的全称是Zookeeper atomic broadcast protocol，是Zookeeper内部用到的一致性协议。相比Paxos，Zab最大的特点是保证强一致性(strong consistency，或叫线性一致性linearizable consistency)。 和Raft一样，Zab要求唯一Leader参与决议，Zab可以分解成discovery、sync、broadcast三个阶段： discovery: 选举产生PL(prospective leader)，PL收集Follower epoch(cepoch)，根据Follower的反馈PL产生newepoch(每次选举产生新Leader的同时产生新epoch，类似Raft的term) sync: PL补齐相比Follower多数派缺失的状态、之后各Follower再补齐相比PL缺失的状态，PL和Follower完成状态同步后PL变为正式Leader(established leader) broadcast: Leader处理Client的写操作，并将状态变更广播至Follower，Follower多数派通过之后Leader发起将状态变更落地(deliver/commit) Leader和Follower之间通过心跳判别健康状态，正常情况下Zab处在broadcast阶段，出现Leader宕机、网络隔离等异常情况时Zab重新回到discovery阶段。 了解完Zab的基本原理，我们再来看Zab怎样保证强一致性，Zab通过约束事务先后顺序达到强一致性，先广播的事务先commit、FIFO，Zab称之为primary order(以下简称PO)。实现PO的核心是zxid。 Zab中每个事务对应一个zxid，它由两部分组成：<e, c>，e即Leader选举时生成的epoch，c表示当次epoch内事务的编号、依次递增。假设有两个事务的zxid分别是z、z’，当满足 z.e < z’.e 或者 z.e = z’.e && z.c < z’.c 时，定义z先于z’发生(z < z’)。 为实现PO，Zab对Follower、Leader有以下约束： 有事务z和z’，如果Leader先广播z，则Follower需保证先commit z对应的事务 有事务z和z’，z由Leader p广播，z’由Leader q广播，Leader p先于Leader q，则Follower需保证先commit z对应的事务 有事务z和z’，z由Leader p广播，z’由Leader q广播，Leader p先于Leader q，如果Follower已经commit z，则q需保证已commit z才能广播z’ 第1、2点保证事务FIFO，第3点保证Leader上具备所有已commit的事务。 相比Paxos，Zab约束了事务顺序、适用于有强一致性需求的场景。 Paxos、Raft、Zab再比较 除Paxos、Raft和Zab外，Viewstamped Replication(简称VR)[7][8]也是讨论比较多的一致性协议。这些协议包含很多共同的内容(Leader、quorum、state machine等)，因而我们不禁要问：Paxos、Raft、Zab和VR等分布式一致性协议区别到底在哪，还是根本就是一回事？[9]

在分布式系统中有个CAP理论，对于P（分区容忍性）而言，是实际存在 从而无法避免的。因为，分布系统中的处理不是在本机，而是网络中的许多机器相互通信，故网络分区、网络通信故障问题无法避免。因此，只能尽量地在C 和 A 之间寻求平衡。对于数据存储而言，为了提高可用性（Availability），采用了副本备份，比如对于HDFS，默认每块数据存三份。某数据块所在的机器宕机了，就去该数据块副本所在的机器上读取（从这可以看出，数据分布方式是按“数据块”为单位分布的）

为什么需要Paxos或Quorum算法？分布式系统实现数据存储，是通过多份数据副本来保证可靠，假设部分节点访问数据失败，还有其他节点提供一致的数据返回给用户。对数据存储而言，怎样保证副本数据的一致性当属分布式存储最重要的问题。 一致性是分布式理论中的根本性问题，近半个世纪以来，科学家们围绕着一致性问题提出了很多理论模型，依据这些理论模型，业界也出现了很多工程实践投影。何为一致性问题？简而言之，一致性问题就是相互独立的节点之间，在可控的时间范围内如何达成一项决议的问题。

JNDI是 Java 命名与目录接口（Java Naming and Directory Interface），在J2EE规范中是重要的规范之一，不少专家认为，没有透彻理解JNDI的意义和作用，就没有真正掌握J2EE特别是EJB的知识。

Guava是一种基于开源的Java库，其中包含谷歌正在由他们很多项目使用的很多核心库。这个库是为了方便编码，并减少编码错误。这个库提供用于集合，缓存，支持原语，并发性，常见注解，字符串处理，I/O和验证的实用方法。 Guava的好处 标准化 - Guava库是由谷歌托管。 高效 - 可靠，快速和有效的扩展JAVA标准库 优化 -Guava库经过高度的优化。 函数式编程 -增加JAVA功能和处理能力。 实用程序 - 提供了经常需要在应用程序开发的许多实用程序类。 验证 -提供标准的故障安全验证机制。 最佳实践 - 强调最佳的做法。 Guava工程包含了若干被Google的 Java项目广泛依赖 的核心库，例如：集合 [collections] 、缓存 [caching] 、原生类型支持 [primitives support] 、并发库 [concurrency libraries] 、通用注解 [common annotations] 、字符串处理 [string processing] 、I/O 等等。

使用Fluent Interface：Fluent Interface可以使代码更短，更容易编写。

Curator是Netflix公司一个开源的zookeeper客户端，在原生API接口上进行了包装，解决了很多ZooKeeper客户端非常底层的细节开发。同时内部实现了诸如Session超时重连，Watcher反复注册等功能，实现了Fluent风格的API接口，是使用最广泛的zookeeper客户端之一。 使用Curator需要依赖包： guava-17.0.jar zookeeper-3.4.6.jar curator-framework-3.2.1.jar zookeeper提供的原生API操作过于烦琐，curator框架是对zookeeper提供的原生API进行了封装，提供了更高级的API接口，使客户端程序员使用zookeeper更加容易及高效。 注意事项： 1、Curator只是封装了原生Zookeeper的监听事件，使客户端程序员无序重复注册Watcher，但是Wathcer的一次性还是存在的，只是由curator完成。因此对于某些场景使用依然需要慎重。因为curator需要重复注册，因此，第一次触发Wathcer与再次注册Watcher即使是异常操作，但是中间还是存在时延，假使对于Zookeeper瞬时触发几个事件，则该监听器并不能保证监听到所有状态的改变，至于可以监听到多少取决于服务器的处理速度。 2、只要curator的cache启动成功，监听器注册成功，理论上只要没有1的情况下，监听器是可以很完美的处理需要监听到的事件。但是如果在cache.start()的时候，与Zookeeper的连接是中断的，则后续连接恢复，也无法让客户端感知到需要监听的变动。我当时想到的一个解决方案是在Zookeeper启动的时候设置一个连接状态的监听器（连接状态监听器看第7节），如果Zookeeper客户端连接状态是连接失败，则添加这个监听器，恢复连接的时候，调用cache.clearAndRefresh()，然后移除连接状态监听器即可。 但是，这个接口只针对PathChildrenCache，因为该监听器监听节点删除的时候，再次创建也不会再有重新监听的效果，调用该接口即可恢复。另外两种监听器可以不用考虑这种情况，原因取决于监听器的内部实现。 Curator n ˈkyoor͝ˌātər:，展品或者其它收藏品的看守者，管理员，ZooKeeper的Keeper。它由3个相关的项目组成：