zookeeper中几个相关实体和它们之间的交互

      zookeeper是一个开源的分布式协调服务,其独特的"leader-follower"集群模式,"过半成功"的写策略,很好的解决了分布式单点问题.zookeeper包含leader,follower,znode三个重要实体.

 leader:
      zookeeper集群中所有机器通过一个选择过程来选定一台被称为"leader"的机器,leader提供读,写,选举操作

  follower
       zookeeper集群中除leader外的其他机器,follower提供读,选举操作

 znode:
       zookeeper维护着一个树形层次结构,树中的节点被称为znode,znode可以用于存储数据,并且有一个与之相关联的ACL.zookeeper被设计用来实现协调服务(通常使用小数据文件),而不是用于大容量的数据存储,一般一个znode能存储的数据被限制在1MB以内
  
       znode的数据访问具有原子性.客户端在读取一个znode的数据时,要么读到所有的数据,要么读操作失败,不会只读到部分数据.同样,写操作将替换znode存储的所有数据,zookeeper保证写操作不成功就失败,不会出现部分写之类的情况
   
      znode有两种类型:短暂的和持久的.znode的类型在创建时确定并且之后不能再修改.在创建短暂znode的客户端回话结束时,zookeeper会将该短暂znode删除.相比之下,持久znode不依赖于客户端会话,只有当客户端明确要删除该持久znode时才会被删除.短暂znode不可以有子节点,即便是短暂子节点.虽然每个短暂的znode都绑定到一个客户端会话,但它们对所有的客户端还是可见的

       znode以某种方式发生变化时,"观察"机制可以让客户端得到通知.可以针对zookeeper服务的操作来设置观察,该服务的其他操作可以触发观察.观察只被触发一次,为了多次受到通知,客户端需要重新注册观察

    

      当一个写请求到达zookeeper集群时都会被转发给领导者,再由领导者将更新广播给跟随者,当半数以上的跟随者已经将修改持久化后,领导者才会提交这个更新,然后客户端才会收到一个更新成功的响应,这个用来达成共识的协议被设计成具有原子性,类似于数据库的两阶段提交协议.
      如果领导者发生故障,其余的机器会选出另外一个领导者,并和新的追随者一起继续提供服务.领导者选择过程是非常快的,一般只需要200毫秒,因此领导者选举过程中不会出现性能的明显降低.
     

       在更新内存中的znode树之前,集体中的所有机器都会将更新写入磁盘,任何一台机器都可以为读提供服务,由于读只涉及内存操作,因此非常快
     
      每个zookeeper客户端启动时都会尝试连接到列表中的一台服务器,如果连接失败,它会尝试连接到另一台服务器,以此类推,直到成功连接到一台服务器或者因为所有zookeeper服务器都不可用而失败

      一旦客户端与一台服务器建立连接,这台服务器就会为该客户端创建一个新的会话.每个会话都有一个超时设置,如果在超时时间段内没有收到任何请求,则相应的会话就会过期,该连接也无法重新打开,与会话相关联的短暂znode都会丢失.一般一个会话空闲超过一定时间,都可以通过客户端发送心跳请求保存会话不过期,这个时间的设置应该足够低,一般能检测出服务器故障,并且能够在会话超时时间内连接到另外一台机器.

      zookeeper客户端可以自动地进行故障切换,切换至另一台zookeeper服务器.关键一点是在另一台服务器接替故障服务器之后,所有的会话(和相关的短暂znode)仍然是有效的.当客户端断开连接时,观察通知无法发送.但是当客户端恢复连接后,这些通知会被发送.当然当客户端重新连接到另一台服务器的过程中,如果应用程序试图执行一个操作,这个操作将会失败.