最近研究了一下zookeeper（后续以zk简称），对于一个自认为泡在服务器领域多年的老油条来说，现在才开始关注zk这个东西，其实有点晚了，但没办法，以前的工作经历让我压根用不到这个玩意。只是最近因为要考虑做ledisdb的cluster方案，以及重新考虑mixer的协调管理，才让我真正开始尝试去了解zk。
什么是zookeeper
根据官网的介绍，zookeeper是一个分布式协调服务，主要用来处理分布式系统中各系统之间的协作问题的。
其实这么说有点抽象，初次接触zk，很多人真不知道用它来干啥，你可以将它想成一个总控节点（当然它能用多机实现自身的HA），能对所有服务进行操作。这样就能实现对整个分布式系统的统一管理。
譬如我现在有n台机器，需要动态更新某一个配置，一些做法可能是通过puppet或者salt将配置先分发到不同机器，然后运行指定的reload命令。zk的做法可能是所有服务都监听一个配置节点，直接更改这个节点的数据，然后各个服务就能收到更新消息，然后同步最新的配置，再自行reload了。
上面只是一个很简单的例子，其实通过它并不能过多的体现zk的优势（没准salt可能还更简单），但zk不光只能干这些，还能干更awesome的事情。网上有太多关于zk应用场景一览的文章了，这里就不详细说明，后续我只会说一下自己需要用zk解决的棘手问题。
架构
zk使用类paxos算法来保证其HA，每次通过选举得到一个master用来处理client的请求，client可以挂载到任意一台zk server上面，因为paxos这种是强一致同步算法，所以zk能保证每一台server上面数据都是一致的。架构如下：
+-------------------------------+
| |
+----+--++ +----+---+ +-+--+---+
| server | | server | | server |
| +----------+ master +--------+ |
+--^--^--+ +----^---+ +----^---+
| | | |
| | | |
| | | |
+-----+ +-----+ +------+ +---------+
| | | |
| | | |
+----+---+ +-+------+ +--+-----+ +--+-----+
| client | | client | | client | | client |
+--------+ +--------+ +--------+ +--------+
Data Model
zk内部是按照类似文件系统层级方式进行数据存储的，就像这样：
+---+
| / |
+++-+
||
||
+-------+------++----+-------+
| /app1 | | /app2 |
+-+--+--+ +---+---+
| | |
| | |
| | |
+----------++ ++---------+ +----+-----+
| /app1/p1 | | /app1/p2 | | /app2/p1 |
+----------+ +----------+ +----------+
对于任意一个节点，我们称之为znode，znode有很多属性，譬如Zxid（每次更新的事物ID）等，具体可以详见zk的文档。znode有ACL控制，我们可以很方便的设置其读写权限等，但个人感觉对于内网小集群来说意义不怎么大，所以也就没深入研究。
znode有一种Ephemeral Node，也就是临时节点，它是session有效的，当session结束之后，这个node自动删除，所以我们可以用这种node来实现对服务的监控。譬如一个服务启动之后就向zk挂载一个ephemeral node，如果这个服务崩溃了，那么连接断开，session无效了，这个node就删除了，我们也就知道该服务出了问题。
znode还有一种Sequence Node，用来实现序列化的唯一节点，我们可以通过这个功能来实现一个简单地leader服务选举，譬如每个服务启动的时候都向zk注册一个sequence node，谁最先注册，zk给的sequence最小，这个最小的就是leader了，如果leader当掉了，那么具有第二小sequence node的节点就成为新的leader。
Znode Watch
我们可以watch一个znode，用来监听对应的消息，zk会负责通知，但只会通知一次。所以需要我们再次重新watch这个znode。那么如果再次watch之前，znode又有更新了，client不是收不到了吗？这个就需要client不光要处理watch，同时也需要适当的主动get相关的数据，这样就能保证得到最新的消息了。也就是消息系统里面典型的推拉结合的方式。推只是为了提升性能，快速响应，而拉则为了更好的保证消息不丢失。
但是，我们需要注意一点，zk并不能保证client收到消息之后同时处理，譬如配置文件更新，zk可能通知了所有client，但client并不能全部在同一个时间同时reload，所以为了处理这样的问题，我们需要额外的机制来保证，这个后续说明。
watch只能应用于data（通过get，exists函数）以及children（通过getChildren函数）。也就是监控znode数据更新以及znode的子节点的改变。
API
zk的API时很简单的，如下：
- create
- delete
- exists
- set data
- get data
- get chilren
- sync
就跟通常的文件系统操作差不多，就不过多说明了。
Example
总的来说，如果我们不深入zk的内部实现，譬如paxos等，zk还是很好理解的，而且使用起来很简单。通常我们需要考虑的就是用zk来干啥，而不是为了想引入一个牛的新特性而用zk。
Lock
用zk可以很方便的实现一个分布式lock，记得最开始做企业群组盘的时候，我需要实现一个分布式lock，然后就用redis来弄了一个，其实当时就很担心redis单点当掉的问题，如果那时候我就引入了zk，可能就没这个担心了。
官方文档已经很详细的给出了lock的实现流程：
- create一个类似path/lock-n的临时序列节点
- getChilren相应的path，注意这里千万不能watch，不然惊群很恐怖的
- 如果1中n是最小的，则获取lock
- 否则，调用exists watch到上一个比自己小的节点，譬如我现在n是5，我就可能watch node-4
- 如果exists失败，表明前一个节点没了，则进入步骤2，否则等待，直到watch触发重新进入步骤2
Codis
最近在考虑ledisdb的cluster方案，本来也打算用proxy来解决的，然后就在想用zk来处理rebalance的问题，结果这时候codis横空出世，发现不用自己整了，于是就好好的研究了一下codis的数据迁移问题。其实也很简单：
- config发起pre migrate action
- proxy接收到这个action之后，将对应的slot设置为pre migrate状态，同时等待config发起migrate action
- config等待所有的proxy返回pre migrate之后，发起migrate action
- proxy收到migrate action，将对应的slot设置为migrate状态
上面这些，都是通过zk来完成的，这里需要关注一下为啥要有pre migrate这个状态，如果config直接发起migrate，那么zk并不能保证proxy同一时间全部更新成migrate状态，所以我们必须有一个中间状态，在这个中间状态里面，proxy对于特定的slot不会干任何事情，只能等待config将其设置为migrate。虽然proxy对于相应slot一段时间无法处理外部请求，但这个时间是很短的（不过此时config当掉了就惨了）。config知道所有proxy都变成pre migrate状态之后，就可以很放心的发送migrate action了。因为这时候，proxy只有两种可能，变成migrate状态，能正常工作，仍然还是pre migrate状态，不能工作，也自然不会对数据造成破坏。
其实上面也就是一个典型的2PC，虽然仍然可能有隐患，譬如config当掉，但并不会对实际数据造成破坏。而且config当掉了我们也能很快知晓并重新启动，所以问题不大。
总结
总的来说，zk的使用还是挺简单的，只要我们知道它到底能用到什么地方，那zk就真的是分布式开发里面一把瑞士军刀了。不过我挺不喜欢装java那套东西，为了zk也没办法，虽然go现在也有etcd这些类zk的东西了，但毕竟还没经受过太多的考验，所以现在还是老老实实的zk吧。
