初步认识zookeeper

问题的引入

随着服务的模块化分布式架构的衍出，集群化越来越严重

1.协议地址的维护

传统方式模块间互相调用通过webservice方式，但是存在好多个订单服务，用户模块调用订单服务通过http：//****?wsdl路径访问一个订单服务就要好多个这种路径，那么怎么维护这个路径？

2.负载均衡机制

存在n个订单服务，不能指望一个订单服务处理所有请求

3.服务动态上下线感知

假如其中一个订单down掉怎么感知，从而不往这个服务发送请求？

这个时候我们就需要一个中间件所有订单服务注册到中间件上，用户模块只需要与中间件交互获取一个地址簿由中间件进行转发维护管理

这个中间件就是zookeeper(分布式协调服务)

本例

我们可以创建一个orderservice节点

节点下维护了所有订单地址

分布式请求牵扯到共享资源的访问，单进程模块我们可以用线程锁控制，但是分布式环境是多进程服务，就需要一个中间件来维护共享资源。zookeeper就起到这个作用

但是为了保证zookeeper的高可用我们基本上不会只用一个zookeeper，这就形成了一个zookeeper集群。假设所有的订单服务都往集群中注册，部分注册到zookeeperA中部分注册到zookeeperB中这就牵扯到zookeeper的同步问题

zookeeper集群角色leader，follower 所有的事务请求在leader所有的写请求在follower

当事务请求发生在leader时，leader要同步给follower(因为模块可以访问任意zookeeper，要保证数据一致性)

数据同步问题怎么解决呢？

CAP理论(2pc最终一致性解决)，不可能大到强一致性，保证高性能高可用

中心化

我们上边讲到zookeeper集群是中心化的，即存在leader follower，那么什么是中心化？

假设我们项目团队是一个集群，那么我们的项目经理就是一个leader ,如果leader有问题了就没人派发任务了。

去中心化

所有人平等，例子全球互联网化，局部机房出问题并不会影响全部。