分布式基础之二-分布式桥梁zookeeper

想一想在自己单位开发的系统，属于比较传统的系统，是不是没有用到分布式呢？其实不然，系统之间的调用已经非常多了，比如ILOG的调用，征信系统的查询，信贷管理系统，账务系统的调用，都是系统间的调用，做一个项目、一个应用，涉及到这么多系统，把这些接口都看做服务的话，这肯定是属于分布式的。 只是，从感觉上，这“很不分布式”。为什么？因为：

1.我们的视角，是按“系统”这个层面去划分，而不是按“服务”这个层面去划分，每个系统都太庞大了，而且服务也没有标准化，存在重复造轮子和不统一的情况。所以更让人感觉到一个个的系统屏障，并没有在一个云里面组装服务的概念。
2.各系统间，采用的是负载均衡F5。 访问一个服务，是访问的一个F5地址，负载到后端的服务器上。 各服务的发布，都还是传统的was应用的停止启动，任何一点配置文件，系统功能的修改，都需要消耗漫长的运维时间，所以，这也让人感觉并不是一个灵活的高效的分布式系统。

现在我们就从这角度切入来讨论一下分布式桥梁，本文并不去讲解zk的原理，而是着重于对zk的理解：
因为目前我们所做的项目也是在一个分布框架下的，而F5就是这个分布式桥梁。但是F5担任这角色的表现并不好：F5是一个单点的中心化的桥梁，一旦F5宕机，那么整个集群崩溃。你可以选择用双备F5，但是F5很贵（不排除F5厂商提供新的更适合分布式架构的策略）。
所以这时候zookeeper就登场了，zookeeper提供树形的文件结构，保存一个生态系统中的所有提供服务的server地址和服务名，即我们所说的zk充当服务注册中心。客户端访问一个服务，不再是访问单点的f5，而是在zk服务注册中心里获取所有提供服务的server地址，并根据负载均衡策略，选择一个地址进行访问。这里有几个要点必须掌握：
1.zk是一个CP的应用（CAP的中CP），能够保证数据的一致性和分区错误可容忍度。这意味着客户端总是能够获取到正确的server地址，并且，在使用集群zk的情况下，只要多数zk没有宕机，服务注册中心总是能正常工作。作为一个软件，它没有f5集群的昂贵费用，也能像f5一样提供所有的server地址供访问，这是物美价廉的。
2.zk是一个去中心化的访问，客户端把server地址保存在本地缓存，仅在zk上的node放生改变时再去同步新的数据，这样的去中心化很显然增加了HA。
3.对于负载均衡的策略，需要客户端自己去实现，有简单的轮训，IPhash值法，加权轮询，最小连接数法。这部分不展开讲了，相信不是在极端情况下不需要很复杂的算法实现都能够满足负载的合理分布。
4.zk在服务调用时去中心化，但是在服务注册和管理上，却是一个中心化的存储地，相当于把多个f5上挂在的server地址都统一到一个zk上了，便于监控和管理。
至此，应该可以理解了为什么会把zookeeper称为分布式桥梁，它的确很好的发挥了一个桥梁的作用。

接下来再记录一下自己对zk内部原理的一些理解：
1.对于leader的理解：
1.1假设zk没有设置leader，那么同一时间如果有多个server对同一个node的数据进行修改（虽然我至今还没想到有什么真实场景会发生这事情），就会涉及到分布式数据一致性问题。很明显这是paxos要负责解决的问题，那么多个zk机器同时提交修改，通过paxos算法最终确定修改值？这样是有问题的，也就是无限的活锁问题。为解决这问题，zk加入了leader选举。一个zk集群有一个leader，所有的写操作，都由这个唯一的leader来完成。
1.2由于leader的存在，那么在对zk进行数据修改时，再也不存在一致性问题，那么也和paxos无关了，zk这时候变成了一个主从系统，主负责写，所有主从都可以读。但是，在每次选leader的过程中，依然是paxos算法的体现。需要用zxid（全局统一的对zk上数据做修改操作时对应的编号）作为epoch来获取投票。
1.3之前还被一个牛角尖困扰过很久，既然由leader负责一切写操作，那么干嘛要选leader？指派一个不就行了？宕机了再换下一个呗？突然有一天恍然大悟，大家都是平等的，何来指派一说呢。当要选举的时候，谁都是平等的都有机会当leader，你让谁去指派啊？因此，需要一个公平的大家都认可的选举协议，这就是为什么要用paxos来选leader。

2.对于zab的理解：
zk在选完leader以后，要做的第二件事情，就是通过zab来完成数据修改。这个zab我理解是和paxos没有什么关系的，最多只能算是paxos的第二阶段（所以网上有人说是paxos简化，zab作者说不是同一个东西）。那就是不需要提议，而是直接发布决议，对所有follower提交修改，有半数以上的follower完成数据同步即认为修改成功。

最后，再说说zookeeper的其他用法：
1.分布式锁，这也是一个坑爹的地方，因为看起来和选leader很像，选leader要最大的zxid，而获取分布式锁，却正好需要最小的编号。这里把自己的理解明确一下：获得分布式锁的方法，和选leader没有半毛钱关系，而最小的那个编号，也和epoch没关系。这个用法的逻辑只是：同一时间如果可能有多个server做同一操作（比如修改数据库的同一字段）。那么这些server可以请求zk来帮助他们进行并发控制，所有server首先向zk的同一父节点提交node创建请求（记住必须是临时的有序节点），请求时可以带上自己的特定信息作为数据内容，创建完成后获取该父节点下的所有children，如果最小的那个有序节点是自己，相当于自己获得了分布式锁。
问题在于，如果分布式锁一直不释放怎么办？这个需要一种可恢复的机制，这机制，留待后续研究。另外，锁还有互斥锁，读写锁等好几种形式，这个也需要区分研究。
2.配置文件管理，这个很容易理解了，同样需要客户端改造，取代了was应用的启停，实现了实时的配置项切换。
3.集群管理。
3.1在一个主从结构的系统中，master需要给slave分配任务，所以master需要掌握slave的生命状况。很显然，这个监控任务可以交给zk来帮忙处理。master注册对slaves目录的监听，动态掌握机器状况，重新分配任务。
3.2 在一个主从结构系统中，master也可以是选出来的，如果master宕机，也可以重新选举master，所以这个选master的工作也可以由zk来代劳了。这里还有个让人绕进去的地方：选master的逻辑，我觉得就是和获取分布式锁的逻辑一样一样的，为什么，这么多人都说，选master是一个leader election？！！！！ 我靠啊，是我理解错了吗？zk的leader选举和选master完全不一样好吗？如果我错了，希望有人来点拨我，非常感谢！

其他应用场景：
http://www.superwu.cn/2014/11/26/1461/ 这个文章对于应用场景的描述我觉得较为全面。