TechNomads

开发人员主要使用zk的客户端，所以我们先来了解zk客户端的创建过程原理。 1. 概述 zk客户端的核心组件如下： ZooKeeper实例 ：客户端入口 ClientWatcherManager ：客户端Watcher管理器 HostProvider：客户端地址列表管理器 ClientCnxn：客户端核心线程。包含两个线程，即SendThread和EventThread。前者是一个I/O线程，主要负责ZooKeeper客户端和服务端之间的网络I/O通信，后者是一个事件线程，主要负责对服务端事件进行处理。 类图说明: ZooKeeper客户端的初始化与启动环节，实际上就是ZooKeeper对象的实例化过程，分析一个zk客户端的构造方法： public ZooKeeper(String connectString, int sessionTimeout, Watcher watcher, long sessionId, byte[] sessionPasswd, boolean canBeReadOnly, HostProvider aHostProvider, ZKClientConfi....

业界存在不少消息中间件产品，实现各不相同。这篇文章主要介绍基于ZooKeeper实现的分布式队列。分布式队列，简单来说分为两大类，一种是常规的先入先出队列，另一种是要等到所有元素集聚之后才能统一安排执行的Barrier模型。 1. FIFO：先入先出 FIFO队列是一种非常典型的按序执行的队列模型：先进入队列的请求操作完成后，才会开始处理后面的请求。 使用zk实现FIFO队列，和zk对于共享锁的实现类似。FIFO队列就类似于一个全局的共享锁模型。所有客户端都会到一个节点（比如queue_fifo）下创建一个临时顺序节点。 创建完节点，根据如下四个步骤确定执行顺序。 1.通过调用getChildren() 接口来获取 /queue_fifo节点下的所有子节点，即获取队列中的所有元素。 2.确定自己的节点序号在所有子节点中的顺序 3.如果自己不是序号最小的子节点，那么就需要进入等待，同时向比自己序号小的最后一个节点注册Watcher监听 4.接收到Watcher通知后，重复步骤1 整个通过流程如下图所示： 2. Barrier：分布式屏障 Barrier在分布式系统中特指系统之间的一个协....

本文章先概述一下zk的主要应用场景，然后重点讲述其分布式锁的实现。 1.应用场景概述 1.1.数据发布/订阅 数据发布/订阅系统，即所谓的配置中心。意思就是发布者将数据发布到zk的n个节点上，供订阅者进行数据订阅，进而达到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。 1.2.负载均衡 zk作为路由，client从zk那里拿到可用的server地址（最好做个缓存），通过自己的负载均衡算法得到要连接的地址，client去连接指定server。server要做的是，当server启动后去zk注册自己（创建临时文件），子节点变化时（比如当某台server宕机），server与zk的链接会断掉，zk会自动删除该临时文件。 1.3.命名服务 命名服务是分布式系统中最基本的公共服务之一。要命名的对象包括集群中的机器列表，服务名称等。zk实现命名服务的方式：通过调用zk节点创建的API接口创建一个顺序节点，并且在API返回值中返回这个节点的完整名字。 1.4.分布式协调/通知 zk中特有的Watcher注册与异步通知机制，能够很好的实现分布式环境下不同机器，甚至是不同系统之间的协调与....

1. 协议概述 ZAB协议是为分布式协调服务zk专门设计的一种支持崩溃恢复的原子广播协议，在协议设计之初并没有要求其具有很好的扩展性，最初只是为雅虎公司内部哪些高吞吐量、低延迟、健壮、简单的分布式系统场景设计的。zk文档中也指出，ZAB协议并不像Paxos算法那样，是一种通用的分布式一致性算法，它是一种特别为zk设计的崩溃可恢复的原子消息广播算法 zk中，主要依赖ZAB协议来实现分布式数据一致性，基于该协议，zk实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。具体实现是： zk使用一个单一的主进程来接收并处理客户端的所有事务请求，并采用ZAB的原子广播协议，将服务器数据的状态变更以事务的形式广播到所有的副本进程上去。ZAB协议的这个主备模型架构保证了同一时刻集群中只能有一个主进程来广播服务器的状态变更，因此能够很好地处理客户端的大量的并发请求。另外，考虑到在分布式环境中，顺序执行的一些状态变更其前后存在一定的依赖关系，有些状态变更必须依赖于比它早生成的那些状态变更，例如变更C需要依赖变更A和变更B。这样的依赖关系也对ZAB协议提出了一个要求：ZAB协议必须能够保证一个全....

1. 来源 Apache ZooKeeper由Apache Hadoop的子项目发展而来，为分布式应用提供了高效且可靠的分布式协调服务，提供了诸如统一命名服务，配置管理和分布式锁等分布式的基础服务。由雅虎创建，是Google Chubby的开源实现。在解决分布式数据一致性方面，并没有采用Paxos算法，而是采用了ZAB（ZooKeeper Atomic Broadcase）的一致性协议 2. 特性 顺序一致性 从同一客户端发起的请求，之中将会严格的按照其发起的顺序被应用到ZooKeeper中去 原子性 所有事务请求的处理结果在整个集群中所有机器上的应用情况是一致的。 单一视图 无论客户端连接的是哪个ZooKeeper服务器，其看到的服务端数据模型都是一致的 可靠性 一旦服务端成功的应用了一个事务，并完成了对客户端的响应，那么该事务所引起的服务端状态变更将会被一直保留下来，除非有另一个事务又对其进行了变更 实时性 ZooKeeper能保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态，并不能保证实时的 3. 设计目标 ZooKeeper致力于提供一个高性能、高可用，且....

paxos算法是莱利斯·兰伯特于1990年提出的一种基于消息传递且具有高度容错特性的一致性算法。是目前公认的解决分布式一致性问题最有效的算法之一。在常见的分布式系统中，总会发生机器宕机或者网络异常等情况。paxos算法就是要解决就是如果在一个会发生上述异常的分布式系统中，快速且正确的在集群内部对某个数据的值达成一致，并且保证不论发生以上任何异常，都不会破坏整个系统的一致性。 1. 历史故事 1982年，lamport与另外两人共同发表了论文The Byzantine Generals Problem，提出了一种计算机容错理论。在理论描述过程中，为了能更加形象的表达，lamport设想了下面一种场景： 拜占庭帝国有多支军队，不同军队的将军之间要指定统一的行动计划，从而选择做出进攻或者撤退的决定，同时，各个将军在地理上都是被隔离开来的，只能依靠军队的通讯员进行通信。然而在所有的通讯员中可能会存在叛徒，这些叛徒可以任意篡改消息，从而达到欺骗将军的目的。 这就是著名的拜占庭将军问题，从理论上来说，在分布式计算领域，试图在异步系统和不可靠的信道上达成一致状态是不可能的，所以在研究的过程中，往往假....

随着计算机系统规模越来越大，将所有业务单元部署在一个或者若干个大型主机上的体系结构，已经越来越不满足当今计算机系统，尤其是大型互联网系统的发展，各种灵活多变的系统架构模型层出不穷。同时，随着微型计算机的发展，越来越多廉价的PC机成为了各大企业IT架构的首选，分布式的处理方式越来越受到业界的青睐，计算机系统经历着一场从集中式到分布式架构的转变。 1. 从集中式到分布式 自20世纪60年代大型主机被发明出来以后，凭借其超强的计算和I/O处理能力以及在安全性和稳定性方面的卓越表现，在很长一段时间，大型主机引领了计算机行业以及商业计算领域的发展。最知名的企业当属IBM，其发明的 System/360系列大型主机，是计算机发展史上的一个里程碑，与波音707，福特T型车齐名，并称为20世纪最重要的三大商业成就，并一度成为大型主机的代名词，从那时起，IT界进入了大型主机时代。 随着大型主机的到来，计算机系统架构也进入集中式处理的时代。大型主机由于卓越的性能、良好的稳定性，其在单机处理能力方面的优势非常明显。使得IT系统快速进入了集中式处理阶段。但是20世纪80年代后，计算机向微型化和网络化的发展趋势....