浅谈---＞ZooKeeper

ZooKeeper概述

​​​​​​​​ ZooKeeper从字面意思理解，【Zoo - 动物园，Keeper - 管理员】动物园中有很多种动物，这里的动物就可以比作分布式环境下多种多样的服务，而ZooKeeper做的就是管理这些服务。
​ Apache ZooKeeper的系统为分布式协调是构建分布式应用的高性能服务。
​ ZooKeeper 本质上是一个分布式的小文件存储系统。提供基于类似于文件系统的目录树方式的数据存储，并且可以对树中的节点进行有效管理。从而用来维护和监控你存储的数据的状态变化。通过监控这些数据状态的变化，从而可以达到基于数据的集群管理。
​ ZooKeeper 适用于存储和协同相关的关键数据，不适合用于大数据量存储。是一个分布式的小文件管理系统，管理分布式服务(Web Service)。

Zookeeper发展史

​​​​​​​​ ZooKeeper 最早起源于雅虎研究院的一个研究小组。当时研究人员发现，在雅虎内部很多大型系统基本都需要依赖一个系统来进行分布式协同，但是这些系统往往都存在分布式单点问题。
​ 所以，雅虎的开发人员就开发了一个通用的无单点问题的分布式协调框架，这就是ZooKeeper。ZooKeeper之后在开源界被大量使用，很多著名开源项目都在使用zookeeper，例如：Hadoop：使用ZooKeeper 做Namenode 的高可用。HBase：保证集群中只有一个master，保存hbase:meta表的位置，保存集群中的RegionServer列表。Kafka：集群成员管理，controller 节点选举。

1：集中式到分布式

1.1什么是集中式

集中式系统，集中式系统中整个项目就是一个独立的应用，整个应用也就是整个项目，所有的东西都在一个应用里面。部署到一个服务器上。
布署项目时，放到一个tomcat里的。也称为单体架构

1.2什么是分布式

随着公司的发展，应用的客户变多，功能也日益完善，加了很多的功能，整个项目在一个tomcat上跑，tomcat说它也很累，能不能少跑点代码，这时候 就产生了。我们可以把大项目按功能划分为很多的模块，比如说单独一个系统处理订单，一个处理用户登录，一个处理后台等等，然后每一个模块都单独在一个tomcat中跑，合起来就是一个完整的大项目，这样每一个tomcat都非常轻松。

分布式系统的描述总结是：

• 多台计算机构成
• 计算机之间通过网络进行通信
• 彼此进行交互 共同目标
• 有共同的功能

1.4zookeeper的4中应用场景

1.4.1注册中心

分布式应用中，通常需要有一套完整的命名规则，既能够产生唯一的名称又便于人识别和记住，通常情况下用树形的名称结构是一个理想的选择，树形的名称结构是一个有层次的目录结构。通过调用Zookeeper提供的创建节点的API，能够很容易创建一个全局唯一的path，这个path就可以作为一个名称。
​ 阿里巴巴集团开源的分布式服务框架Dubbo中使用ZooKeeper来作为其命名服务，维护全局的服务地址列表。
个人认为注册中心就像下面途中的房产中介，房东有房源就在中介哪里注册，把房子托管给它管理。而客户找房子也会在房产中心哪里注册，留下手机号订阅房产中介的房源信息。一旦有合适的房源，中介会通知客户来看房子。其中房产中介起到了协调服务和客户的功能。

1.4.2配置中心

数据发布/订阅即所谓的配置中心：发布者将数据发布到ZooKeeper一系列节点上面，订阅者进行数据订阅，当数据有变化时，可以及时得到数据的变化通知，达到动态获取数据的目的。

ZooKeeper 采用的是推拉结合的方式。
1、推: 服务端会推给注册了监控节点的客户端 Wathcer 事件通知
2、拉: 客户端获得通知后，然后主动到服务端拉取最新的数据
个人理解配置中心如下图，以前所有的订单服务的代码里面都配置了同一个数据库地址，每当数据库发生变更的时候，所有连接的服务都需要改变。这样对于系统而言相当的难受，改了还需要重新部署。而且服务多啊。。。那个改错了都不知道。所以就需要用配置中心来解决这样的问题了。我们将连接数据库的信息都用一台配置服务器来管理，所有需要连接数据库的服务都来读取我配置中心的配置文件，当数据库发生改变时，我们就直接该配置中心的配置信息，然后通过通知告知所有订阅我的服务发送更新操作。服务通过spring容器更新会重新加载配置文件，达到更新数据库的操作。

1.4.3分布式锁

分布式锁是控制分布式系统之间同步访问共享资源的一种方式。在分布式系统中，常常需要协调他们的动作。如果不同的系统或是同一个系统的不同主机之间共享了一个或一组资源，那么访问这些资源的时候，往往需要互斥来防止彼此干扰来保证一致性，在这种情况下，便需要使用到分布式锁。
其实分布式锁就是多个服务同一时刻对相同的资源进行访问时，只能被其中的一个资源访问到，怎么控制A服务访问了，其他资源不能被访问？这时需要用到Zookeeper的数据类型了，它可以在资源下面创建一个目录，从而标记该资源被我访问了，你们其他服务都不能访问（相当于加上锁），等待A服务处理完了，那么就会删除资源下的那个目录，从而通知那些订阅了该资源的服务，资源每人用了，你们可以来抢了。但是这时又会引发另外的问题，就是譬如，有一万个服务在等这个资源，而其中这个资源一旦被某个资源释放出来那么就会被这9999个服务抢，且只能有一个服务抢到资源，这回造成资源服务压力很大。俗称惊狼效应。这时可以使用队列来解决。也可以使用Zookeeper的数据类型的有序性来解决，每个服务进来都订阅上一个服务的资源。这就可以控制每个资源释放后只会被一个服务拿到。

1.4.4分布式队列

在传统的单进程编程中，我们使用队列来存储一些数据结构，用来在多线程之间共享或传递数据。分布式环境下，我们同样需要一个类似单进程队列的组件，用来实现跨进程、跨主机、跨网络的数据共享和数据传递，这就是我们的分布式队列。譬如：RabbitMQ、ActiveMQ、RocketMQ、Kafaka等队列。

1.4.5负载均衡

负载均衡是通过负载均衡算法，用来把对某种资源的访问分摊给不同的设备，从而减轻单点的压力。

上图中左侧为ZooKeeper集群，右侧上方为工作服务器，下面为客户端。每台工作服务器在启动时都会去ZooKeeper的servers节点下注册临时节点，每台客户端在启动时都会去servers节点下取得所有可用的工作服务器列表，并通过一定的负载均衡算法计算得出一台工作服务器，并与之建立网络连接。

总结

• 注册中心: 房产中介 协调服务提供者与消费者 正常的调用

• 配置中心: 分布式的所有应该都来中心读取配置,订阅，中心一旦修改，就会通知服务，服务就会去获取新的配置，所有应该都更新配置

• 分布式锁：多个应用在同一时刻只能有一个应用能访问资源。

• zookeeper: 一旦获得资源，标记已使用（ 创建节点数据），被标记了则订阅。释放（删除数据），订阅者就会收到通知，竞争资源

• 分布式队列：使用zookeeper有序节点数据，惊群-监听上一个

• 负载均衡: 多个应用被调用的次数相对平均

• 随机

• 轮循

• 最小活跃数

• 一致性哈希