学习zookeeper

最近研究了一下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的实现流程:

  1. create一个类似path/lock-n的临时序列节点
  2. getChilren相应的path,注意这里千万不能watch,不然惊群很恐怖的
  3. 如果1中n是最小的,则获取lock
  4. 否则,调用exists watch到上一个比自己小的节点,譬如我现在n是5,我就可能watch node-4
  5. 如果exists失败,表明前一个节点没了,则进入步骤2,否则等待,直到watch触发重新进入步骤2

Codis

最近在考虑ledisdb的cluster方案,本来也打算用proxy来解决的,然后就在想用zk来处理rebalance的问题,结果这时候codis横空出世,发现不用自己整了,于是就好好的研究了一下codis的数据迁移问题。其实也很简单:

  1. config发起pre migrate action
  2. proxy接收到这个action之后,将对应的slot设置为pre migrate状态,同时等待config发起migrate action
  3. config等待所有的proxy返回pre migrate之后,发起migrate action
  4. 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吧。