随着SpringBoot、SpringCloud的发布，微服务的思想越来越被重视，在短短的几年间，迅速发展并在各大公司付诸实施。微服务将一个大而全的服务分解为小而内聚的小服务，小服务之间通过通信来完成一项任务。而在多个服务并存的系统中，必须有一个服务能够协同各个服务工作，监控服务是否在线、任务是否执行完成等功能，Zookeeper正是这一服务的代表。

Zookeeper简介

Zookeeper是由雅虎研究院开发，用于协调Hadoop中各个子项目工作。由于Hadoop项目中经常以动物命名，而Zookeeper主要负责协同各个子项目工作，就像动物管理员一样管理者各个动物的行为，因此就以动物管理员（Zookeeper）命名。
Zookeeper是模仿Google的Chubby实现的，Chubby是非开源的Google自家使用的分布式协调工具。现在Zookeeper作为开源软件贡献给了Apache。

分布式协调技术

在多线程环境下，访问临界资源，需要加锁访问，保证多线程环境下的临界资源信息的正确性，在分布式环境下同样存在这样的问题，我们需要做好同步控制，保证临界资源被正确的访问，这就是分布式协调技术。Zookeeper通过主节点选取算法进行协调控制，只有主节点才能访问临界资源。下面分别看一下三种情境下的协调技术。

• 多线程
  在多核处理器的今天，多线程程序对于我们来说并不陌生，为了让多线程程序正确的执行，我们需要通过锁机制来控制线程的执行。其中锁就是多线程环境中的协调技术。
  在单机上启动一个服务进程，我们称为单机环境
• 多进程-同一机器
  由于同一机器使用的是一个操作系统，操作系统能够对机器中各个资源进行管理，其中进程调度器可以协调各个进程的行为。多个进程间可以通过进程调度器同步访问临界资源（具体怎么实现，没有研究过），进程调度器就是多进程环境中的协调技术。
  在单机上启动多个服务进程（相同的服务，服务与服务之间是有通信的，端口不能相同），我们称为伪分布式环境。
  为什么是伪分布式环境了，如果这台机器故障，整个服务就不可用了，所以这不是真正意义上的分布式系统。
• 多进程-多台机器
  如果将服务部署在多台服务器上，此时的环境多了一个不可靠的因素-网络，正是因为网络的不可靠，导致分布式协调技术难以实现。例如，请求一个服务失败，有可能是真失败了，也有可能是调用成功返回失败了。再例如，服务A先调用服务C，服务B后调用服务C，而服务B先于服务A到达了服务C。这都是在分布式环境中面临的问题。
  Zookeeper通过主节点选取算法，选举主节点，被选举为主节点的服务才能访问临界资源，其他的访问节点等待，主节点访问完临界资源后，会从Zookeeper中释放掉该节点，导致等待的节点重新选举主节点，重复以上操作。从而达到同步访问临界资源的效果。
  在多台机器上部署多个服务进程（一般一个机器部署一个服务，服务与服务之间存在通信，服务的端口需要一致，方便管理），我们称这种环境为分布式环境。
  分布式环境分摊了服务宕机的风险，但是增加了服务管理的困难。

Zookeeper能做什么

• 分布式协调
  Zookeeper最初设计的目的，也就是分布式锁的作用，同步的访问临界资源
• 服务发现
  利用临时节点的性质，动态监测服务是否正常
• 通知机制
  注册节点的通知，当节点状态或者信息发生变化时，会通知注册者。
• 配置维护
  可以将全局的配置信息存到节点中，配合通知机制动态修改配置

Zookeeper的应用

• Dubbo
  RPC中间件，zookeeper作为注册中心，用于服务的发现与订阅，动态监测provider的状态，并通知consumer
• HBase
  Hadoop的数据仓库，Zookeeper用于主节点的选取，主节点用于跟踪可用服务，保存集群元数据
• Kafka
  分布式消息中间件，Zookeeper用于主题的发现
• Solr
  检索系统，Zookeeper用于SolrCloud，存储各个服务的元数据
• Facebook Message
  Zookeeper 用于服务发现，故障恢复等

Zookeeper不适合场景

Zookeeper不适合存储海量数据，每个节点的存储数据大小是有限制的，不能大于1M

欢迎扫描下方二维码，关注公众号，我们可以进行技术交流，共同成长

qrcode_for_gh_5580beb3cba1_430.jpg