zookeeper适用场景：zookeeper解决了哪些问题
问题导读：1.master挂机，传统做法备份必然是以前数据，该如何保证挂机数据与备份数据一致？
2.分布式系统如何实现对同一资源的访问，保证数据的强一致性？
3.集群中的worker挂了，传统做法是什么？zookeeper又是如何做的？
static/image/hrline/4.gif
分布式系统的运行是很复杂的，因为涉及到了网络通信还有节点失效等不可控的情况。下面介绍在最传统的master-workers模型，主要可以会遇到什么问题，传统方法是怎么解决以及怎么用zookeeper解决。
Master节点管理
集群当中最重要的是Master，所以一般都会设置一台Master的Backup。
Backup会定期向Master获取Meta信息并且检测Master的存活性，一旦Master挂了，Backup立马启动，接替Master的工作自己成为Master，分布式的情况多种多样，因为涉及到了网络通信的抖动，针对下面的情况:
[*]Backup检测Master存活性传统的就是定期发包，一旦一定时间段内没有收到响应就判定Master Down了，于是Backup就启动，如果Master其实是没有down，Backup收不到响应或者收到响应延迟的原因是因为网络阻塞的问题呢？Backup也启动了，这时候集群里就有了两个Master，很有可能部分workers汇报给Master，另一部分workers汇报给后来启动的Backup，这下子服务就全乱了。
[*]Backup是定期同步Master中的meta信息，所以总是滞后的，一旦Master挂了，Backup的信息必然是老的，很有可能会影响集群运行状态。
解决问题:
[*]Master节点高可用，并且保证唯一。
[*]Meta信息的及时同步
zookeeper Master选举
zookeeper会分配给注册到它上面的客户端一个编号，并且zk自己会保证这个编号的唯一性和递增性，N多机器中只需选出编号最小的Client作为Master就行，并且保证这些机器的都维护一个一样的meta信息视图，一旦Master挂了，那么这N机器中编号最小的胜任Master，Meta信息是一致的。
配置文件管理
集群中配置文件的更新和同步是很频繁的，传统的配置文件分发都是需要把配置文件数据分发到每台worker上，然后进行worker的reload，这种方式是最笨的方式，结构很难维护，因为如果集群当中有可能很多种应用的配置文件要同步，而且效率很低，集群规模一大负载很高。还有一种就是每次更新把配置文件单独保存到一个数据库里面，然后worker端定期pull数据，这种方式就是数据及时性得不到同步。
解决问题:
[*]统一配置文件分发并且及时让worker生效
zookeeper发布与订阅模型
发布与订阅模型，即所谓的配置中心，顾名思义就是发布者将数据发布到ZK节点上，供订阅者动态获取数据，实现配置信息的集中式管理和动态更新。例如全局的配置信息，服务式服务框架的服务地址列表等就非常适合使用。
分布式锁
在一台机器上要多个进程或者多个线程操作同一资源比较简单，因为可以有大量的状态信息或者日志信息提供保证，比如两个A和B进程同时写一个文件，加锁就可以实现。但是分布式系统怎么办？需要一个三方的分配锁的机制，几百台worker都对同一个网络中的文件写操作，怎么协同？还有怎么保证高效的运行？
解决问题:
[*]高效分布式的分布式锁
zookeeper分布式锁
分布式锁主要得益于ZooKeeper为我们保证了数据的强一致性，zookeeper的znode节点创建的唯一性和递增性能保证所有来抢锁的worker的原子性。
集群worker管理
集群中的worker挂了是很可能的，一旦workerA挂了，如果存在其余的workers互相之间需要通信，那么workers必须尽快更新自己的hosts列表，把挂了的worker剔除，从而不在和它通信，而Master要做的是把挂了worker上的作业调度到其他的worker上。同样的，这台worker重新恢复正常了，要通知其他的workers更新hosts列表。传统的作法都是有专门的监控系统，通过不断去发心跳包(比如ping)来发现worker是否alive，缺陷就是及时性问题，不能应用于在线率要求较高的场景
解决问题:
[*]集群worker监控
zookeeper监控集群
利用zookeeper建立znode的强一致性，可以用于那种对集群中机器状态，机器在线率有较高要求的场景，能够快速对集群中机器变化作出响应。
相关文章：
zookeeper原理
zookeeper中Watcher和Notifications
zookeeper适用场景：如何竞选Master及代码实现
zookeeper适用场景：配置文件同步
zookeeper适用场景：分布式锁实现
zookeeper适用场景：zookeeper解决了哪些问题
好帖，凌乱中找到了方向 留着，好好学习！ 版主，问你个问题，当我的Storm在ZK上注册了信息后，Storm的Master会向ZK里面发送任务信息，提供给Storm每台Node读取并执行，假设一台node节点挂机了，哪个ZK会自动获取到信息，并自动通过广播方式告诉每天Node吗？并将挂机Node的任务分配到其他机器上，以便完成任务 Joker 发表于 2014-12-10 21:33
版主，问你个问题，当我的Storm在ZK上注册了信息后，Storm的Master会向ZK里面发送任务信息，提供给Storm每 ...
Storm在ZK上注册了信息后，Storm的nimbus会向ZK里面发送任务信息，提供给Storm的supervisor，task读取并执行，supervisor, task也会定义发送心跳信息到zookeeper，一旦task挂掉，可以重启一些挂掉的task。
这里重心是任务，并非每一台，如果在这台机器上task挂掉了，那么他会重启这个task，如果机器挂掉了，它还会重启task，当然可能会使用其它机器。对于挂掉的task，没有必要告诉每一个task或则每一台机器，这样做没有意义。
pig2 发表于 2014-12-11 12:13
Storm在ZK上注册了信息后，Storm的nimbus会向ZK里面发送任务信息，提供给Storm的supervisor，task读取并 ...
恩，了解，版主还有一小点疑问就是，之前Storm在ZK里面注册的任务信息，Storm如果全部执行完毕之后，是进入历史还是说直接清空了？
假设ZK中途全部挂机了，重启后ZK是否还保存没有完成的Storm任务？
学习学习 首先感谢楼主辛苦发帖 看了好几个楼主的帖子 都是 以问题来引导主题言简意赅一针见血很喜欢这种风格 望楼主发扬
但有两个问题还不是很清楚
1.在 Master选举小节中说的client 应该是集群中提供服务的server吧。
2.别的地方提到master的选举 是依照paxos算法 进行投票 得票大于一半的才是master，请问是我理解有误 还是这是另外一种选取master的方法？
学习了(*^__^*) 嘻嘻…… 学习了，感谢无私分享。
页:
[1]
2