小白科普：分布式和集群
1分布式
小明的公司有3个系统： 系统A、系统B和系统C ，这三个系统所做的业务不同，被部署在3个独立的机器上运行， 他们之间互相调用（当然是跨域网络的）， 通力合作完成公司的业务流程。
将不同的业务分布在不同的地方， 这就构成了一个分布式的系统，现在问题来了， 系统A是整个分布式系统的“脸面”， 用户直接访问，用户量访问大的时候要么是速度巨慢，要么直接挂掉， 怎么办？
由于系统A只有一份， 所以会引起单点失败。
2集群（Cluster）
小明的公司不差钱，就多买几台机器吧， 小明把系统A一下子部署了好几份（例如下图的3个服务器），每一份都是系统A的一个实例， 对外提供同样的服务，这样能睡个安稳觉了，不怕其中一个坏掉了，我还有另外2个呢。
这3个服务器上的系统就组成了一个集群。
可是对用户来说，一下子出现这么系统A ，每个系统的IP地址都不一样， 到底访问哪一个？
如果所有人都访问服务器1.1 ，那服务器1.1 会被累死， 剩下的三个闲死，成了浪费钱的摆设。
3负载均衡（Load Balancer）
小明要尽可能的让3个机器上的系统A 工作均衡一些， 比如有3万个请求，那就让3个服务器各处理1万个（当然，这是理想状况）， 这叫负载均衡。
很明显，这个负载均衡的工作最好独立出来， 放到独立的服务器上 （例如Ngnix）：
后来小明发现， 这个负载均衡的服务器虽然工作内容很简单，就是拿到请求，分发请求，但是它还是有可能挂掉啊， 单点失败还是会出现。
没办法，只好把负载均衡也搞成一个集群， 不过和系统A的集群有两点不同：
1. 这个新的集群中虽然有两个机器，但我们可以用某种办法，让这个集群对外只提供一个IP地址， 也就是说用户看到的好像只有一个机器。
2. 同一时刻，我们只让一个负载均衡的机器工作， 另外一个原地待命。 如果工作的那个挂掉了，待命的那个就顶上去。
4弹性
如果这3个系统A的实例还是满足不了大量的请求，那就再加服务器！
双11来了，用户量是平时的10倍， 小明向领导申请费用又买了几十台服务器，一下子把系统A部署了几十份。 可是双11过后， 流量一下子降下来了，那几十个服务器用不上了，也变成了摆设！
被领导批评以后，小明决定尝试一下云计算， 在云端可以轻松的创建、删除虚拟的服务器， 那样就可以轻松地随着用户的请求动态的增减服务器了。 双11来了就创建虚拟服务器，等到双11过去了就把不用的关掉， 省得浪费钱。
于是小明的系统具备了一定的弹性。
5失效转移
上面的系统看起来很美好，但是做了一个不切实际的假设： 所有的服务都是无状态的。 换句话说，假设用户的两次请求直接是没有关联的。
但是现实是，大部分服务都是有状态的， 例如购物车。
用户访问系统，在服务器1.1上创建了一个购物车，并向其中加入了几个商品， 然后 服务器1.1 挂掉了， 用户的后续访问就找不到服务器1.1了，这时候就要做失效转移，让另外几个服务器去接管、去处理用户的请求。
可是问题来了，在服务器1.2，1.3上有用户的购物车吗？ 如果没有， 用户就会抱怨，我刚创建的购物车哪里去了？
还有更严重的，假设用户是在服务器1.1上登录的， 用户登录过的信息保存到了该服务器的session中， 现在这个服务器挂掉了， 用户的session自然也不见了，当用户被失效转移到其他服务器上的时候，其他服务器发现用户没有登录， 就把用户踢到了登录界面， 让用户再次登录！
状态， 状态，状态！ 用户的登录信息，购物车等都是状态信息， 处理不好状态的问题，集群的威力就大打折扣，无法完成真正的失效转移， 甚至无法使用。
怎么办？
一种办法是把状态信息在集群的各个服务器之间复制，让集群的各个服务器达成一致， 谁来干这个事情？ 只能是像Websphere, Weblogic这样的应用服务器了。
还有一种办法， 就是把状态信息集中存储在一个地方， 让集群的各个服务器都能访问到：
小明听说Redis 不错， 那就用Redis来保存吧 ！
（完）
张大胖和CAP定理
计算机界有很多高大上又难于理解的术语，CAP就是其中之一， 什么一致性（Consistency）， 可用性（Availability）， 分区容错性（Partition tolerance） 就很难理解了， 再加上CAP定理更是让人云里雾里， 今天咱们试图通俗的演绎一下。
张大胖在公司奋发图强，经过多年的努力，终于做到了架构师的位置。
架构师的椅子还没坐热，很快就来了一个项目要做架构设计。
老板把大胖叫来，谆谆教导说： 大胖啊， 数据是我们的宝贵资产，你设计的系统可千万要保证数据不能丢失啊！
大胖说老板放心， 这方面我有经验， 一般来讲我们要做数据的冗余处理， 简单的来讲就是给数据做多个副本来保存。 我会设计一个分布式系统， 把数据备份到多个机器节点去。
几天后， 大胖给发了一张图， 展示了这个分布式系统是怎么工作的：
数据副本在不同的机器上做冗余， 中间有数据的复制， 保证数据的同步。
虽然只是两台机器， 但是也构成了一个简单的分布式环境。
老板虽然不懂技术， 但是看到数据在不同的机器之间有备份，也就放心了。
经过几个月的开发和测试，系统顺利上线， 但是大家很快就发现： 分布式系统不像单机系统那么简单， 由于网络的原因， 或者某个机器的原因很容易导致通讯失败，或者节点不可用。
有一天， 用户先访问了左边的机器A , 写入了一条数据， 然后机器A很不幸， 网线被悲催的网管给踢掉了， 这直接导致了两个严重的后果：
1. 负载均衡找不着机器A，认为它死翘翘了， 就要把用户的下一次访问转到机器B去。
2. 数据复制也找不着机器A , 只好罢工。 用户刚写入的数据没法复制到机器B，机器B上还是老数据
怎么办？ 虽然这是一次偶然， 把网管臭骂一顿， 插上网线就可以了， 但是谁能保证以后两个机器的通信是一致畅通的呢？
组里的小王说： 我们的机器B 还活着呢， 还能提供服务， 数据复制不到机器B， 不就是少看几条数据嘛， 无伤大雅，不影响大局， 勉强可用， 插上网线后数据复制就会工作， 一切就会恢复正常。
小王无意中选择了系统的可用性(Availability，简称A)， 系统能提供服务就好， 数据不一致可以忍受。
张大胖说: 不行， 老板说了，我们系统的数据极为重要， 数据如果不一致会带来严重后果，所以机器B上的和这些关键数据相关的功能也必须停掉， 必须等到机器A插上网线，数据同步以后才能开工
很明显， 张大胖遵循老板指示， 把一致性（Consistency, 简称C ）放到了首位。
所以问题就很明显了， 在网络节点之间无法通信的情况下, 和数据复制相关的功能， 要么选择可用性(A) , 要么选择一致性(C)， 不能同时选择两者。
大胖仔细思考了一下， 其实这两种选择的背后其实隐藏着另外一个事实， 那就是网络节点之间无法通信的情况下， 节点被隔离，产生了网络分区， 整个系统仍然是可以工作的， 大胖给它起了个名： 分区容错性（Partition tolerance， 简称P）。
如果选择了可用性(A) + 分区容错性(P) , 就要放弃一致性(C)。
如果选在一致性(C) + 分区容错性(P) , 就得放弃可用性(A) ， 对了， 这种情况下，虽然系统的有些功能是不能使用的， 因为需要等待数据的同步， 但是那些和数据同步无关的功能还是可以访问的 ， 相当于系统做了功能的降级。
既然有AP和CP, 会不会出现仅仅是CA（一致性+可用性）这种组合呢？ 就是没有分区容错性， 只保留可用性和一致性？ 仔细想想， 这种情况其实就退化成了单机应用， 没有意义了。
大胖觉得自己似乎发现了一个规律： 在一个分布式计算机系统中，一致性(C)，可用性(A)和分区容错性(P) 这三种保证无法同时得到满足，最多满足两个。
他决定把找个规律叫做CAP定理， 听起来比较高大上， 显得自己高深莫测。
如果你实在是搞不懂这CAP, 张大胖会告诉你一个更容易理解的版本： 在一个分布式系统中， 在出现节点之间无法通信（网络分区产生）， 你只能选择 可用性 或者 一致性， 没法同时选择他们。
（完）
认识分布式架构
认识分布式架构
随着计算机系统规模变得越来越大，将所有的业务单元集中部署在一个或若干个大型机上的体系结构，已经越来越不能满足当今计算机系统，尤其是大型互联网系统的快速发展，各种灵活多变的系统架构模型层出不穷。分布式的处理方式越来越受到业界的青睐——计算机系统正在经历一场前所未有的从集中式向分布式架构的变革。
集中式与分布式
集中式系统
所谓的集中式系统就是指由一台或多台主计算机组成中心节点，数据集中存储于这个中心节点中，并且整个系统的所有业务单元都集中部署在这个中心节点上，系统的所有功能均由其集中处理。
集中式系统的最大的特点就是部署结构非常简单，底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署，也就不用考虑各节点之间的分布式协作问题。但是，由于采用单机部署，很可能带来系统大而复杂、难于维护、发生单点故障（单个点发生故障的时候会波及到整个系统或者网络，从而导致整个系统或者网络的瘫痪）、扩展性差等问题。
分布式系统
分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。简单来说就是一群独立计算机集合共同对外提供服务，但是对于系统的用户来说，就像是一台计算机在提供服务一样。分布式意味着可以采用更多的普通计算机（相对于昂贵的大型机）组成分布式集群对外提供服务。计算机越多，CPU、内存、存储资源等也就越多，能够处理的并发访问量也就越大。
从分布式系统的概念中我们知道，各个主机之间通信和协调主要通过网络进行，所以分布式系统中的计算机在空间上几乎没有任何限制，这些计算机可能被放在不同的机柜上，也可能被部署在不同的机房中，还可能在不同的城市中，对于大型的网站甚至可能分布在不同的国家和地区。但是，无论空间上如何分布，一个标准的分布式系统应该具有以下几个主要特征：
分布性
分布式系统中的多台计算机之间在空间位置上可以随意分布，同时，机器的分布情况也会随时变动。
对等性
分布式系统中的计算机没有主／从之分，即没有控制整个系统的主机，也没有被控制的从机，组成分布式系统的所有计算机节点都是对等的。副本（Replica）是分布式系统最常见的概念之一，指的是分布式系统对数据和服务提供的一种冗余方式。在常见的分布式系统中，为了对外提供高可用的服务，我们往往会对数据和服务进行副本处理。数据副本是指在不同节点上持久化同一份数据，当某一个节点上存储的数据丢失时，可以从副本上读取该数据，这是解决分布式系统数据丢失问题最为有效的手段。另一类副本是服务副本，指多个节点提供同样的服务，每个节点都有能力接收来自外部的请求并进行相应的处理。
并发性
在一个计算机网络中，程序运行过程的并发性操作是非常常见的行为。例如同一个分布式系统中的多个节点，可能会并发地操作一些共享的资源，如何准确并高效地协调分布式并发操作也成为了分布式系统架构与设计中最大的挑战之一。
缺乏全局时钟
在分布式系统中，很难定义两个事件究竟谁先谁后，原因就是因为分布式系统缺乏一个全局的时钟序列控制。
故障总是会发生
组成分布式系统的所有计算机，都有可能发生任何形式的故障。除非需求指标允许，在系统设计时不能放过任何异常情况。
分布式系统面临的问题
通信异常
分布式系统需要在各个节点之间进行网络通信，因此网络通信都会伴随着网络不可用的风险或是系统不可用都会导致最终分布式系统无法顺利完成一次网络通信。另外，即使分布式系统各节点之间的网络通信能够正常进行，其延时也会远大于单机操作，会影响消息的收发的过程，因此消息丢失和消息延迟变得非常普遍。
网络分区
当网络由于发生异常情况，导致分布式系统中部分节点之间的网络延时不断增大，最终导致组成分布式系统的所有节点中，只有部分节点之间能够进行正常通信，而另一些节点则不能——我们将这个现象称为网络分区，就是俗称的“脑裂”。当网络分区出现时，分布式系统会出现局部小集群，在极端情况下，这些局部小集群会独立完成原本需要整个分布式才能完成的功能，这就对分布式一致性提出类非常大的挑战。
三态
分布式系统的每一次请求与响应，存在特有的“三态”概念，即成功、失败与超时。当出现超时现象时，网络通信的发起方是无法确定当前请求是否被成功处理的。
节点故障
节点故障则是分布式环境下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或“僵死”现象。
分布式事务
在单机数据库中，我们很容易能够实现一套满足ACID特性的事务处理系统，但在分布式数据库中，数据分散在不同的机器上，如何对这些数据进行分布式的事务处理具有非常大的挑战。但是在分布式计算领域，为了保证分布式应用程序的可靠性，分布式事务是无法回避的。
分布式事务是指事务的参与者、支持的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点之上。通常一个分布式事务中会涉及对多个数据源或业务系统的操作。一个最典型的分布式事务场景：一个跨银行的转账操作涉及调用两个异地的银行服务，其中一个是本地银行提供的取款服务，另一个则是目标银行提供的存款服务，这两个服务本身是无状态并且是互相独立的，共同构成了一个完整的分布式事务。
对于一个高访问量、高并发的互联网分布式系统来说，如果我们期望实现一套严格满足ACID特性的分布式事务，很可能出现的情况就是在系统的可用性和严格一致性之间出现冲突——因为当我们要求分布式系统具有严格一致性时，很可能就需要牺牲掉系统的可用性。但毋庸置疑的一点是，可用性又是一个所有消费者不允许我们讨价还价的系统属性，比如淘宝网这样在线网站就要求能够7*24小时不间断地对外提供服务，而对于一致性，则更加是所有消费者对于一个软件系统的刚需。因此，在可用性和一致性之间永远无法存在一个两全其美的方案，于是如何构建一个兼顾可用性和一致性的分布式系统成为了无数工程师探讨的难题，出现了诸如CAP和BASE这样的分布式系统经典理论。
CAP定理
CAP理论告诉我们，一个分布式系统不可能同时满足一致性（C：Consistency）、可用性（A：Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的两项。
一致性
在分布式环境中，一致性是指数据在多个副本之间是否能够保持一致性的特性。在一致性的需求下，当一个系统在数据一致性的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。在分布式系统中，如果能够做到针对一个数据项的更新操作执行成功后，所有的用户都可以读取到其最新的值，那么这样的系统被认为具有强一致性（或严格的一致性）。
可用性
可用性是指系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容错性
分区容错性约束了一个分布式系统需要具有如下特性：分布式系统遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性的可用性的服务，除非是整个网络环境环境都发生了故障。需要注意的是，组成一个分布式系统的每个节点的加入与退出都可以看作是一个特殊的网络分区。
在进行对CAP定理的应用时，我们就需要抛弃其中的一项，下表是抛弃CAP定理中任意一项特性的场景说明。
| 放弃CAP定理 | 说明 |
|---|---|
| 放弃P | 如果希望能够避免系统出现分区容错性问题，一种较为简单的做法是将所有的数据都放在一个分布式节点上。这样的做法虽然无法100%地保证系统不会出错，但至少不会碰到由于网络分区带来的负面影响。但同时需要注意的是，放弃P的同时也就意味着放弃类系统的可扩展性 |
| 放弃A | 放弃可用性，一旦系统遇到网络分区或其他故障时，那么受到影响的服务需要等待一定的时间，因此在等待期间系统无法对外提供正常的服务，即不可用 |
| 放弃C | 事实上，放弃一致性指的是放弃数据的强一致性，而保留数据的最终一致性。这样的系统无法保证数据保持实时的一致性，但是能够承诺的是，数据最终会达到一个一致的状态。这就引入了一个时间窗口的概念，具体多久能够达到数据一致取决于系统的设计，主要包括数据副本在不同节点之间的复制时间长短 |
对于一个分布式系统，分区容错性可以说是一个最基本的要求。既然是分布式系统，那么分布式系统中的组件必然需要被部署到不同的节点，否则也就无所谓分布式系统了，因此必然出现子网络。而对于分布式系统而言，网络问题又是一个必定会出现的异常情况，因此分区容错性也就称为了一个分布式系统必然需要面对和解决的问题。因此系统架构设计师往往需要把精力花在如何根据业务特点在C（一致性）和A（可用性）之间寻求平衡。
BASE理论
BASE是Basically Available（基本可用）、Soft state（软状态）和Eventually consistent（最终一致性）三个短语的简写，是由eBay的架构师提出的。BASE是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，其核心思想是即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身的业务特点，采用适当的方式来使系统达到最终一致性（Eventual consistency）。
基本可用
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。“基本可用”的典型例子：
1、响应时间上损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应 时间增加到了1-2秒。
2、功能上的损失：正常情况下，在一个电子商务网站上进行购物，消费者几乎能够顺利地完成每一笔订单，但是在大促购物高峰的时候，由于消费 者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能被引导到一个降级页面。
弱状态
弱状态也称为软状态，和硬状态相对，是指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
最终一致性
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
参考资料
从Paxos到Zookeeper分布式一致性原理与实践
分布式核心组件：什么是Zookeeper?
张大胖所在的公司这几年发展得相当不错，业务激增，人员也迅速扩展，转眼之间，张大胖已经成为公司的“资深”员工了，更重要的是，经过这些年的不懈努力，他终于坐上了架构师的宝座。
但是大胖很快发现，这架构师真不是好当的，技术选型、架构设计，尤其是大家搞不定的技术难点，最终都得自己扛起来。沟通、说服、妥协、甚至争吵都是家常便饭，比自己之前单纯做开发的时候难多了。
公司的IT系统早已经从单机转向了分布式，分布式系统带来了巨大的挑战。这周一刚上班，张大胖的邮箱里已经塞满了紧急邮件。
1小梁的邮件小梁的邮件里说了一个RPC调用的问题，本来公司的架构组开发了一个RPC框架让各个组去使用，但是各开发小组纷纷抱怨：这个RPC框架不支持动态的服务注册和发现。
张大胖一看这个图就明白怎么回事了，为了支持高并发，OrderService被部署了4份，每个客户端都保存了一份服务提供者的列表，但是这个列表是静态的（在配置文件中写死的），如果服务的提供者发生了变化，例如有些机器down了，或者又新增了OrderService的实例，客户端根本不知道，可能还在傻乎乎地尝试那些已经坏掉的实例呢！
想要得到最新的服务提供者的URL列表，必须得手工更新配置文件才行，确实很不方便。
对于这样的问题，大胖马上就意识到，这就是客户端和服务提供者的紧耦合啊。
想解除这个耦合，非得增加一个中间层不可！
张大胖想到，应该有个注册中心，首先给这些服务命名（例如orderService），其次那些OrderService 都可以在这里注册一下，客户端就到这里来查询，只需要给出名称orderService，注册中心就可以给出一个可以使用的url， 再也不怕服务提供者的动态增减了。
不知道是不是下意识的行为，张大胖把这个注册中心的数据结构设计成为了一个树形结构：
/orderService 表达了一个服务的概念， 下面的每个节点表示了一个服务的实例。 例如/orderService/node2表示的order service 的第二个实例， 每个节点上可以记录下该实例的url , 这样就可以查询了。
当然这个注册中心必须得能和各个服务实例通信，如果某个服务实例不幸down掉了，那它在树结构中对于的节点也必须删除， 这样客户端就查询不到了。
嗯，可以在注册中心和各个服务实例直接建立Session, 让各个服务实例定期地发送心跳，如果过了特定时间收不到心跳，就认为这个服务实例挂掉了，Session 过期， 把它从树形结构中删除。
张大胖把自己的想法回复了小梁，接着看小王的邮件。
2小王的Master选举小王邮件中说的是三个Batch Job的协调问题，这三个Batch Job 部署在三台机器上，但是这三个Batch Job同一个时刻只能有一个运行，如果其中某个不幸down掉，剩下的两个就需要做个选举，选出来的那个Batch Job 需要“继承遗志”，继续工作。
其实这就是一个Master的选举问题，张大胖一眼就看出了本质。
只是为了选举出Master， 这三个Batch Job 需要互通有无，互相协调才行，这就麻烦了！
要不弄个数据库表？ 利用数据库表主键不能冲突的特性，让这三个Batch Job 都向同一个表中插入同样的数据，谁先成功谁就是Master ！
可是如果抢到Master的那个Batch Job挂掉了，别人永远就抢不到了！ 因为记录已经存在了， 别的Batch Job 没法插入数据了！
嗯，还得加上定期更新的机制，如果一段时间内没有更新就认为Master死掉了，别的Batch Job可以继续抢..... 不过这么做好麻烦！
换个思路，让他们也去一个注册中心去大吼一声：“我是master!”， 谁的声音大谁是Master 。
其实不是吼一声，三个Batch Job启动以后，都去注册中心争抢着去创建一个树的节点（例如/master ），谁创建成功谁就是Master （当然注册中心必须保证只能创建成功一次，其他请求就失败了），其他两个Batch Job就对这个节点虎视眈眈地监控，如果这个节点被删除，就开始新一轮争抢，去创建那个/master节点。
什么时候节点会被删除呢？ 对，就是当前Master的机器down掉了 ！ 很明显，注册中心也需要和各个机器通信，看看他们是否活着。
等等，这里还有一个复杂的情况， 如果机器1并没有死掉，只是和注册中心长时间连接不上，注册中心会发现Session超时，会把机器1创建的/master删除。 让机器2和机器3去抢，如果机器3成为了master, 开始运行Batch Job, 但是机器1并不知道自己被解除了Master的职务， 还在努力的运行Batch Job，这就冲突了！
看来机器1必须得能感知到和注册中心的连接断开了，需要停止Batch Job才行，等到和注册中心再次连接上以后，才知道自己已经不是master了，老老实实地等下一次机会吧。
无论哪种方案，实现起来都很麻烦，这该死的分布式！
先把思路给小王回复一下吧。接着看小蔡的邮件。
3小蔡的分布式锁小蔡的邮件里说的问题更加麻烦，有多个不同的系统（当然是分布在不同的机器上！），要对同一个资源操作。
这要是在一个机器上，使用某个语言内置的锁就可以搞定，例如Java的synchronized ， 但是现在是分布式啊，程序都跑在不同机器的不同进程中， synchcronized一点用都没有了！
这是个分布式锁的问题啊！
能不能考虑下Master选举问题中的方式，让大家去抢？ 谁能抢先在注册中心创建一个/distribute_lock的节点就表示抢到这个锁了，然后读写资源，读写完以后就把/distribute_lock节点删除，大家再来抢。
可是这样的话某个系统可能会多次抢到，不太公平。
如果让这些系统在注册中心的/distribute_lock下都创建子节点， 然后给每个系统一个编号，会是这个样子：
然后各个系统去检查自己的编号，谁的编号小就认为谁持有了锁， 例如系统1。
系统1持有了锁，就可以对共享资源进行操作了， 操作完成以后process_01这个节点删除， 再创建一个新的节点（编号变成process_04了）：
其他系统一看，编号为01的删除了，再看看谁是最小的吧，是process_02，那就认为系统2持有了锁，可以对共享资源操作了。 操作完成以后也要把process_02节点删除，创建新的节点。这时候process_03就是最小的了，可以持有锁了。
这样循环往复下去...... 分布式锁就可以实现了！
看看，我设计的这个集中式的树形结构很不错吧，能解决各种各样的问题！ 张大胖不由得意起来。
好，先把这个想法告诉小蔡，实现细节下午开个会讨论。
4Zookeeper正准备回复小蔡的时候，大胖突然意识到，自己漏了一个重要的点，那就是注册中心的高可用性，如果注册中心只有那么一台机器，一旦挂掉，整个系统就玩完了。
这个注册中心也得有多台机器来保证高可用性，那个自己颇为得意的树形结构也需要在多个机器之间同步啊，要是有机器挂掉怎么办？ 通信超时怎么办？ 树形结构的数据怎么在各个机器之间保证强一致性？
小王、小梁、小蔡的原始问题没有解决，单单是这个注册中心就要了命了。 以自己公司的技术实力，搞出一套这样的注册中心简直是Mission Impossible !
大胖赶紧上网搜索，看看有没有类似的解决方案，让大胖感到万分幸运的是，果然有一个，叫做Zookeeper ！
Zookeeper 所使用的树形结构和自己想象的非常类似，更重要的是，人家实现了树形结构数据在多台机器之间的可靠复制，达到了数据在多台机器之间的一致性。并且这多台机器中如果有部分挂掉了/或者由于网络原因无法连接上了， 整个系统还可以工作。
大胖赶快去看Zookeeper的关键概念和API：
1. Session ： 表示某个客户系统（例如Batch Job）和ZooKeeper之间的连接会话, Batch Job连上ZooKeeper以后会周期性地发送心跳信息， 如果Zookeepr在特定时间内收不到心跳，就会认为这个Batch Job已经死掉了, Session 就会结束。
2. znode : 树形结构中的每个节点叫做znode， 按类型可以分为永久的znode（除非主动删除，否则一直存在），临时的znode（Session结束就会删除）和 顺序znode（就是小蔡的分布式锁中的process_01,process_02.....）。
3. Watch ： 某个客户系统（例如Batch Job）可以监控znode， znode节点的变化（删除，修改数据等）都可以通知Batch Job， 这样Batch Job可以采取相应的动作，例如争抢着去创建节点。
嗯，这些概念和接口应该可以满足我们的要求了， 就是它了，下午召集大家开会开始学习Zookeeper吧。
后记：本文从使用者的角度描述了Zookeeper有什么用处，至于它内部是如何工作，那是另外一个Big topic了，我们以后再讲。