ZooKeeper源码分析-目录

    • 背景
    • 目录
    • 思考
    • 总结
    • 参考

背景

ZooKeeper是一款开源的分布式应用的分布式协调服务。它包含一个简单的原语集,分布式应用程序可以基于它实现同步服务,配置维护和命名服务等。

其特点如下:

  1. 虽然是内存数据库,但提供持久化功能,通过快照事务日志将数据持久化到磁盘,即使服务器关闭,依然可以恢复本地数据
  2. ZooKeeper提供的数据类型单一,且每个ZNode最多存放1MB数据,但提供了顺序结点临时结点
  3. ZooKeeper提供了强大的监听功能,客户端可以作为观察者获取数据更改的通知
  4. ZooKeeper是一个分布式的产品,在少于半数的服务器宕机的情况下依然可以对外提供服务,并且在保持高可用性的同时通过leader选举,数据同步原子广播保证了强一致性
  5. ZooKeeper中只有leader可以处理写操作,保证了客户端的写请求顺序执行
  6. 可以根据ZooKeeper提供的功能进行扩展,完成如分布式锁,分布式队列,leader选举等功能(如集群中每个服务器在同一路径下创建一个临时顺序子结点,创建的最小顺序的结点成为leader,同时在最小结点上注册监听事件,则可实现leader选举,并且旧leader宕机时可重新选举新leader).详见curator官网Recipes

目录

  1. Zookeeper源码分析(一) —– 源码运行环境搭建
  2. Zookeeper-服务器端启动流程(单机模式)
  3. Zookeeper-持久化

思考

个人觉得如果单单将某个类的源码单独拿出来分析,对于读者而言,虽然可以较为清楚的了解该功能是如何实现的,但不知何时回调用该方法,也即不知道各个类之间是如何协调工作的.而且由于我功夫未到,在输出知识的过程中,恐怕连将功能的实现介绍清楚都很困难;但是如果深度优先介绍的话(即跟着函数调用栈学习运行流程),则很难把握重点.这次写ZooKeeper的博客也是我第一次尝试写一系列的博客,介绍一个比较大的功能,我平时学习的风格是深度优先学习,但是这次就行不通了,因为ZooKeeper各个组件之间交互太复杂,由于最初没有将ZooKeeper各个组件分离开来,在刚开始写作此类博客时,实在是太痛苦了,往往写着写着发现这个功能不知道怎么实现的,还要继续去看源码,边看编写.
还是在看介绍rocketmq的一篇博客时给了我启发,那篇博客中将rocketmq的技术难点做了思维导图,于是我也将ZooKeeper主要功能做了思维导图,先梳理出大概的层级关系,再写博客,虽然思维导图也会更改,但是比直接写博客思维更清晰一些.
另外,”写着写着发现这个功能不知道怎么实现的”这个问题我觉得是没法避免的,看源码一遍就是只能知道个大概,只有在写博客完成知识输出的过程中才能知道哪些地方是没有掌握的,再去重复看源码,输出知识.这是个只能花时间去解决的事情,因此要坚持多看几遍代码,勉励自己!

总结

我fork了一份apache/zookeeper的源码,在学习的过程中填加了很多注释,供大家参考pfjia/zookeeper

参考

  • Zookeeper总览(翻译自Zookeeper官方网站Release 3.4.11版本)
  • ZooKeeper官网介绍
  • 从Paxos到Zookeeper:分布式一致性原理与实践 (书中介绍Paxos算法的部分是根据Paxos的论文直接翻译而来,且有些术语翻译不准确,如将proposal和value都翻译为”提案”,导致我第一次看该书无法理解Paxos算法,也没有坚持下去.后来第二次再看该书时,由于看了Paxos算法的论文,对Paxos有了大致了解,最后将该书全部看完,书中后面部分介绍的非常清楚,如Zookeeper技术内幕.建议看该书时一定要参考Paxos算法的论文)
  • 【Zookeeper】源码分析目录
  • Zookeeper源码与思考

你可能感兴趣的:(ZooKeeper)