主题信息（必填）
主题描述（最多限制在50个字符）
申请人信息（必填）
申请信息已提交审核，请注意查收邮件，我们会尽快给您反馈。
如有疑问，请联系
CSDN &《程序员》研发主编，投稿&纠错等事宜请致邮
你只管努力，剩下的交给时光！
如今的编程是一场程序员和上帝的竞赛，程序员要开发出更大更好、傻瓜都会用到软件。而上帝在努力创造出更大更傻的傻瓜。目前为止，上帝是赢的。个人网站：www.xttblog.com。个人QQ群：、
个人大数据技术博客：http://www.iteblog.com
zookeeper是一个用来管理大量主机的分布式协调服务。具有可靠性、可扩展性、透明性等优点，提供命名服务、配置管理、集群管理、节点领导者选举、锁定和同步服务、数据注册表等服务！他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)体验分布式协调服务ZooKeeper的一些尝试
一、简单介绍
先来简单说明下ZooKeeper原理，再来谈谈在产品中的具体使用。ZooKeeper是一个开放源码的分布式应用程序协调服务，由知名互联网公司雅虎创建，是Google
Chubby的开源实现。设计目标是为分布式提供一致性服务，其没有直接采用Paxos算法，而是采用了被称为ZAB的一致性协议。ZooKeeper具有以下几个特征：
1、数据模型
ZooKeeper使用一个共享的、树形结构的名字空间-数据模型，其由一系列被称为ZNode的的数据节点组成，其层级关系，如文件系统的目录结构一样，结构如下图所示：
每个Znode上都会保存自己的数据内容以及属性信息，节点分为持久节点和临时节点，持久节点除非进行删除操作，否则将会一直保存在ZooKeeper上；而临时节点，他的生命周期和客户端会话绑定，一旦会话失效，这个客户端所创建的所有临时节点都会被删除。另外，可以给节点加上一个属性：sequential，节点创建的时候，会自动在节点后面追加一个由父节点维护的自增数字。
2、构建集群
一个ZooKeeper集群通常由一组机器组成，一般3-5台机器就可以组成一个可用的集群，其结构和工作原理如下图所示：
只要集群中存在超过一半的机器能够正常工作，集群就能够正常对外服务。&
ZooKeeper具有以下三种角色：
Leader： 为客户端提供读写服务&
Follower：为客户端提供读服务，参与Leader选举过程&
Observer：为客户端提供读服务，不参与Leader选举过程
3、顺序访问
对于客户端的每个更新请求，ZooKeeper都会分配一个全局唯一的递增编号，反映了所有事务操作的先后顺序，通过这个特点来实现更高层次的同步原语。
由于ZooKeeper将全局数据存储在内存中，并直接服务于客户端的所有非事物请求，因此他特别适用于以读写操作为主的应用场景。
二、核心处理
在学习、调研和实际产品使用的过程中，总结了两种ZooKeeper的处理方式，以应对各种使用场景的实现。分别为：阻塞式和自杀式。
所有实例会向ZooKeeper的指定路径下把实例ip:port注册上去，注意，这里注册的节点类型是一个临时顺序节点。完成注册后，每个实例都可以获取到所有的节点列表，再通过对比判断自己是否是所有节点中序号最小的，如果是最小的则作为Leader，来执行定时任务或者数据库同步。当Leader机器发生故障，会再次按“小序号优先”策略选出Leader继续执行任务。具体的做法是，所有实例在指定路径下注册临时顺序子节点，并得到子节点列表，通过排序判断自己是否是最小子节点，如果是即为Leader，否则对前一个比自己序号小的节点，注册一个“节点存在”的watcher监听，来监控节点存在情况，一旦客户端断开连接或者会话失效，对应节点会被自动删除，对它进行监控的实例会受到事件通知，以此类推，从而选出最小节点，即Leader。其流程图如下：
与等待式最大的区别在于，当实例发现自己不是最小节点时，会自主删除。具体的做法是，注册“最小节点存在”的watcher监听，来监控最小节点存在情况，一旦Leader机器与ZooKeeper断开连接，会话失效，对应的节点会被自动删除，则其他实例会接收到变更通知，再向指定路径下注册节点，并判断自己是否是最小节点，如果是最小节点则为Leader，不是，则自杀删除自己注册的节点。其流程如下：
这里需要特别声明下，所有的watcher都是一次性的，如果需要再次监控变化，需要再次注册watcher监听。
三、应用场景
接下来，我们谈谈ZooKeeper在产品中的具体实现和开发，以保证产品的分布式运行。
1、服务注册中心
随着分布式的发展和微服务的增多，需要一个管理这些服务的控制中心，即服务注册中心，其主要提供所有服务注册信息的中心存储，同时负责将服务注册信息的更新实时通知给服务消费者，主要通过ZooKeeper的Watcher机制实现。
服务启动，注册临时节点，格式：/{project}/services/{module}/{ip:port},例如在192.168.1.200服务器上启动某服务模块，服务端口为1234，则其注册节点为：/zk_project/services/zk_module/192.168.1.200:1234，并开始初始化服务缓存，把服务模块所有节点信息保存在缓存中，且通过watcher监控路径为/{project}/services/{module}/下的节点变化，若发生变化，获取节点信息更新缓存，保证缓存和ZooKeeper的信息保持一致，其他模块亦是如此。当需要访问其他模块时，通过算法，得到相应的模块ip:port信息，再通过Http访问其他模块，当然安全认证的过程是不可少的。架构设计如下如所示：
2、集群管理
随着分布式系统规模的日益扩大，集群中的机器规模也随之变大，因此，如何更好地进行集群管理也显得越来越重要了，否则则是一盘散沙。
例如，在日常开发和运维的过程中，平台需要知道当前有多少在线的服务器，以及对机器进行上下线的操作。为了实现自动化的线上运维，我们对机器的上下线情况有一个全局的监控。首先将指定的agent部署到这些机器上并启动，向ZooKeeper指定路径下注册临时节点，完成后，对当前路径watcher的监控就会接受到节点变更事件，即上线通知，同样机器下线时，监控同样会接收到下线通知，这样便实现了对服务器上下线的检测，最后同步数据库，保证数据库准确性以及和真实场景的一致性。其结构流程如下：
注明：这里的同步数据库操作，是由服务实例集群的Leader执行，接下来的Leader选举会详细说明
3、Leader选举
Leader选举，它是用来保证集群运行的过程中任务执行的唯一性和准确性，如果每个节点服务器都能执行Leader才能执行任务，会导致服务混乱以及数据的不准确性。
分布式都是多实例多点运行，一个服务对应一个多实例服务集群，这些实例运行着相同的程序，对外提供相同的服务。但某些任务只能由Leader执行，当Leader服务器down机或者发生故障时，需要从其他的实例中选举一个Leader来继续执行任务。Leader选举就是通过上述自杀式处理方式实现的，因为需要选出网络性能最好的机器来当Leader。结构图如下：
4、分布式锁
分布式锁是控制分布式系统之间同步访问共享资源的一种方式。如果不同的系统或者同一个系统的不同主机之间共享一个或一组资源，那么访问这些资源的时候，会需要通过一些手段来防止彼此之间的干扰，以保证一致性，这个情况下，就需要使用分布式锁了。
产品中分布式锁的实现是通过上述阻塞式，如果是最小节点则获取锁，进行事务处理，不是则大序号临时节点会watcher监听前一个小序号节点存在情况，如果小序号节点消失，大序号节点的实例会受到事件通知，再通过判断，如果是最小，则获取锁，否则继续监听前一个小序号节点，以此类推循环，直到拿到锁为止。结构图如下：
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。他的最新文章
他的热门文章
您举报文章：
举报原因：
原文地址：
原因补充：
(最多只允许输入30个字)《分布式协调服务――ZooKeeper(原理与最佳实践)》倪超_图文_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
《分布式协调服务――ZooKeeper(原理与最佳实践)》倪超
&&分布式协调服务――ZooKeeper(原理与最佳实践)
阅读已结束，下载文档到电脑
想免费下载本文？
定制HR最喜欢的简历
下载文档到电脑，方便使用
还剩24页未读，继续阅读
定制HR最喜欢的简历
你可能喜欢}