《Zookeeper系列一》-Zookeeper入门

随着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

你可能感兴趣的:(《Zookeeper系列一》-Zookeeper入门)