1.master挂机传统做法备份必然是以前數据，该如何保证挂机数据与备份数据一致2.分布式系统如何实现对同一资源的访问，保证数据的强一致性3.集群中的worker挂了，传统做法是什么zookeeper又是如何做的？

分布式系统的运行是很复杂的因为涉及到了网络通信还有节点失效等不可控的情况。下面介绍在最传统的master-workers模型主要可以会遇到什么问题，传统方法是怎么如何解决问题以及怎么用zookeeper如何解决问题

Backup会定期向Master获取Meta信息并且检测Master的存活性，一旦Master挂了Backup立馬启动，接替Master的工作自己成为Master分布式的情况多种多样，因为涉及到了网络通信的抖动针对下面的情况:

• Backup检测Master存活性传统的就是定期发包，一旦一定时间段内没有收到响应就判定Master Down了于是Backup就启动，如果Master其实是没有downBackup收不到响应或者收到响应延迟的原因是因为网络阻塞的问题呢？Backup也启动了这时候集群里就有了两个Master，很有可能部分workers汇报给Master另一部分workers汇报给后来启动的Backup，这下子服务就全乱了
• Backup是定期同步Master中的meta信息，所以总是滞后的一旦Master挂了，Backup的信息必然是老的很有可能会影响集群运行状态。
  
• Master节点高可用并且保证唯一。
• Meta信息的及时同步
  
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挂了是很可能的一旦workerA挂了，如果存在其余的workers互相之间需要通信那么workers必须尽快更新自己的hosts列表，把挂了的worker剔除从而不在和它通信，而Master要做的是把挂了worker上的作业调度到其怹的worker上同样的，这台worker重新恢复正常了要通知其他的workers更新hosts列表。传统的作法都是有专门的监控系统通过不断去发心跳包(比如ping)来发现worker是否alive，缺陷就是及时性问题不能应用于在线率要求较高的场景

zookeeper监控集群利用zookeeper建立znode的强一致性，可以用于那种对集群中机器状态机器在线率有较高要求的场景，能够快速对集群中机器变化作出响应