Zookeeper笔记分享

Zookeeper采用zap协议来保证数据的一致性

常见的数据一致性协议采用raft协议

 

参数解读：

　　tickTime=2000：心跳包发送间隔时长

　　initLimit=10：leader与follower之间初始化时的最大超时时间，10X2000（理解为第一次链接时的超时时长）

　　syncLimit=5：leader与follower之间正常通信超时时长，5X2000（集群正常启动以后的通信超时时长）

　　clientPort=2181：客户端访问服务端的端口号

选举机制：

半数机制，推荐奇数台服务器

先选本身，若是不行就优先选择myid最大的，先入为主

 

 

Zookeeper简介

　　ZooKeeper 是一种分布式协调服务，用于管理大型主机。在分布式环境中协调和管理服务是一个复杂的过程。ZooKeeper 经过其简单的架构和 API 解决了这个问题。ZooKeeper 容许开发人员专一于核心应用程序逻辑，而没必要担忧应用程序的分布式特性。

分布式应用

　　分布式应用能够在给定时间（同时）在网络中的多个系统上运行，经过协调它们以快速有效的方式完成特定任务。一般来讲，对于复杂而耗时的任务，非分布式应用（运行在单个系统中）须要几个小时才能完成，而分布式应用经过使用全部系统涉及的计算能力能够在几分钟内完成。

经过将分布式应用配置为在更多系统上运行，能够进一步减小完成任务的时间。分布式应用正在运行的一组系统称为集群，而在集群中运行的每台机器被称为节点。

　　分布式应用有两部分， Server（服务器） 和 Client（客户端） 应用程序。服务器应用程序其实是分布式的，并具备通用接口，以便客户端能够链接到集群中的任何服务器并得到相同的结果。 客户端应用程序是与分布式应用进行交互的工具。

 

　　ZooKeeper 是一个分布式协调服务的开源框架。主要用来解决分布式集群中应用系统的一致性的问题，例如怎样避免同时操做同一数据形成脏读的问题。ZooKeeper 本质上是一个分布式的小文件存储系统。提供基于相似于文件系统的目录树方式的数据存储，而且能够对树种 的节点进行有效管理。从而来维护和监控你存储的数据的状态变化。将经过监控这些数据状态的变化，从而能够达到基于数据的集群管理。诸如：统一命名服务（dubbo）、分布式配置管理（solr的配置集中管理）、分布式消息队列（sub/pub）、分布式锁、分布式协调等功能。

 

Zookeeper 架构图

Zookeeper集群角色介绍

• Leader： ZooKeeper 集群工做的核心 事务请求（写操做）的惟一调度和处理者，保证集群事务处理的顺序性；集群内部各个服务的调度者。 对于 create，setData，delete 等有写操做的请求，则须要统一转发给 leader 处理，leader 须要决定编号、执行操做，这个过程称为一个事务。

• Follower： 处理客户端非事务（读操做）请求 转发事务请求给 Leader 参与集群 leader 选举投票2n-1台能够作集群投票 此外，针对访问量比较大的 zookeeper 集群，还能够新增观察者角色

• Observer： 观察者角色，观察ZooKeeper集群的最新状态变化并将这些状态同步过来，其对于非事务请求能够进行独立处理，对于事务请求，则会转发给Leader服务器处理 不会参与任何形式的投票只提供服务，一般用于在不影响集群事务处理能力的前提下提高集群的非事务处理能力 一般来讲就是增长并发的请求

ZooKeeper当中的主从与主备：

• 主从：主节点少，从节点多，主节点分配任务，从节点具体执行任务

• 主备：主节点与备份节点，主要用于解决咱们主机节点挂掉之后，如何选出来一个新的主节点的问题，保证咱们的主节点不会宕机

• 不少时候，主从与主备没有太明显的分界线，不少时候都是一块儿出现

Zookeeper的特性

1. 全局数据的一致：每一个 server 保存一份相同的数据副本，client 不管连接到哪一个 server，展现的数据都是一致的
2. 可靠性：若是消息被其中一台服务器接受，那么将被全部的服务器接受
3. 顺序性：包括全局有序和偏序两种：全局有序是指若是在一台服务器上消息 a 在消息 b 前发布，则在全部 server 上消息 a 在消息 b 前被发布，偏序是指若是以个消息 b 在消息 a 后被同一个发送者发布，a 必须将排在 b 前面
4. 数据更新原子性：一次数据更新要么成功，要么失败，不存在中间状态
5. 实时性：ZooKeeper 保证客户端将在一个时间间隔范围内得到服务器的更新信息，或者服务器失效的信息

分布式应用的优势

• 可靠性 - 单个或几个系统的故障不会使整个系统出现故障。
• 可扩展性 - 能够在须要时增长性能，经过添加更多机器，在应用程序配置中进行微小的更改，而不会有停机时间。
• 透明性 - 隐藏系统的复杂性，并将其显示为单个实体/应用程序。

分布式应用的挑战

• 竞争条件 - 两个或多个机器尝试执行特定任务，实际上只需在任意给定时间由单个机器完成。例如，共享资源只能在任意给定时间由单个机器修改。
• 死锁 - 两个或多个操做等待彼此无限期完成。
• 不一致 - 数据的部分失败。

什么是Apache ZooKeeper？

　　Apache ZooKeeper是由集群（节点组）使用的一种服务，用于在自身之间协调，并经过稳健的同步技术维护共享数据。ZooKeeper自己是一个分布式应用程序，为写入分布式应用程序提供服务。

ZooKeeper提供的常见服务以下 :

• 命名服务 - 按名称标识集群中的节点。它相似于DNS，但仅对于节点。
• 配置管理 - 加入节点的最近的和最新的系统配置信息。
• 集群管理 - 实时地在集群和节点状态中加入/离开节点。
• 选举算法 - 选举一个节点做为协调目的的leader。
• 锁定和同步服务 - 在修改数据的同时锁定数据。此机制可帮助你在链接其余分布式应用程序（如Apache HBase）时进行自动故障恢复。
• 高度可靠的数据注册表 - 即便在一个或几个节点关闭时也能够得到数据。

　　分布式应用程序提供了不少好处，但它们也抛出了一些复杂和难以解决的挑战。ZooKeeper框架提供了一个完整的机制来克服全部的挑战。竞争条件和死锁使用故障安全同步方法进行处理。另外一个主要缺点是数据的不一致性，ZooKeeper使用原子性解析。

ZooKeeper的好处

如下是使用ZooKeeper的好处：

• 简单的分布式协调过程
• 同步 - 服务器进程之间的相互排斥和协做。此过程有助于Apache HBase进行配置管理。
• 有序的消息
• 序列化 - 根据特定规则对数据进行编码。确保应用程序运行一致。这种方法能够在MapReduce中用来协调队列以执行运行的线程。
• 可靠性
• 原子性 - 数据转移彻底成功或彻底失败，但没有事务是部分的。

 

 

Zookeeper = 树形节点znode文件系统+通知系统

 

每个znode节点默认存储1MB的数据

一、一个领导者与多个跟随者构成的集群

二、集群中过半节点存活，zookeeper集群就能正常服务

三、全局数据一致：每个server都会同步当前最新的数据副本，client不管链接到那一台server数据都是一致的

四、更新请求顺序执行，来自同一个Client的更新请求按其发送顺序依次执行（针对每个客户端的更新请求顺序执行）

五、实时性

 

Zookeeper的应用场景

• 分布式锁
• 集群选主
• 统一命名服务
• 统一配置管理（监听配置）
• 携程配置中心 阿波罗
• 统一集群管理（监听集群中节点变化）
• 服务器节点动态上下线
• 负载均衡

 

节点类型

 

 

zkCli指令 

zkCli.sh --server host:port：链接到指定的服务端

建立节点必需要设置数据

create (path | znode) data ：建立持久节点

create -s (path | znode) data ：建立持久顺序编号目录节点

create -e (path | znode) data ：建立短暂节点

create -e -s (path | znode) data ：建立短暂顺序编号目录节点

get znode：能够获取节点内存储的数据和源数据

get znode watch：注册某个节点的监听服务

set znode newData：设置节点的值

ls znode：查看节点下的子节点

ls znode watch：注册某个节点全部子节点的监听服务

ls2 znode：查看节点的元数据

delete znode：删除节点

rmr znode：递归删除节点

stat znode：查看节点状态

 

zookeeper就两种集群部署方式：单机部署和集群部署

 

zk来最适合进行选主，和分布式锁（串行化方式）

 

ZK写操做

 

任何一个分布式系统都要知足分区容错性 P，由于不能由于集群中某一的节点宕机，就致使整个集群不具有容错性而致使不能再正常提供服务

 

 

什么是AP模型？简单的说就是集群中通常以上节点宕机以后集群仍然能够提供服务，但其实它还涉及到一点，就是服务端每一次的请求都能收到响应，而ZK必须知足一半以上节点存活才能提供服务，并且在选举Leader期间也是不对外提供服务的，由此推断ZK输入CP模型

 

 

 

1 eureka AP

eureka 保证了可用性，实现最终一致性。

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工做，剩余的节点依然能够提供注册和查询服务。而Eureka的客户端在向某个Eureka注册或时若是发现链接失败，则会自动切换至其它节点，只要有一台Eureka还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)，其中说明了，eureka是不知足强一致性，但仍是会保证最终一致性

2 zookeeper CP

zookeeper在选举leader时，会中止服务，直到选举成功以后才会再次对外提供服务，这个时候就说明了服务不可用，可是在选举成功以后，由于一主多从的结构，zookeeper在这时仍是一个高可用注册中心，只是在优先保证一致性的前提下，zookeeper才会顾及到可用性

• C（一致性）：全部的节点上的数据时刻保持同步
• A（可用性）：每一个请求都能接受到一个响应，不管响应成功或失败
• P（分区容错）：系统应该能持续提供服务，即便系统内部有消息丢失（分区）

高可用、数据一致是不少系统设计的目标，可是分区又是不可避免的事情：

• CA without P：若是不要求P（不容许分区），则C（强一致性）和A（可用性）是能够保证的。但其实分区不是你想不想的问题，而是始终会存在，所以CA的系统更多的是容许分区后各子系统依然保持CA。
• CP without A：若是不要求A（可用），至关于每一个请求都须要在Server之间强一致，而P（分区）会致使同步时间无限延长，如此CP也是能够保证的。不少传统的数据库分布式事务都属于这种模式。
• AP wihtout C：要高可用并容许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每一个节点只能用本地数据提供服务，而这样会致使全局数据的不一致性。如今众多的NoSQL都属于此类。

Zookeeper怎么保证数据的一致性？

　　ZooKeeper写数据的机制是客户端把写请求发送到leader节点上(若是发送的是follower节点，follower节点会把军请求转发到leader节点)， leader节点会把数据经过proposal请求发送到全部节点(包括本身)，全部的节点接受到数据之后都会写到本身到本地磁盘上面，写好了之后会发送一个ack请求给leader，leader只要接受到过半的节点发送ack响应回来，就会发送commit消息给各个节点，各个节点就会把消息放入到内存中（放内存是为了保证高性能)，该消息就会用户可见了。那么这个时候，若是ZooKeeper要想保证数据一致性，就须要考虑以下两个状况∶

 

 

状况一∶leader执行commit了，还没来得及给follower发送commit的时候,leader宕机了，这个时候如何保证消息一致性?

 

解决︰当leader宕机之后，ZzooKeeper会选举出来新的Leader，新的leader后动之后要到磁盘上面去检查是否存在没有comit到消息，若是存在，就继续检查看其余follower有没有对这条消息进行了commit，若是有过半节点对这条消息进行了ack，可是没有commit，那么新对1eader要完成commit对操做。

 

状况二︰客户端把消息写到leader了，可是leader还没发送proposal消息给其余节点，这个时候leader宕机了，leader宕机后恢复的时候此消息又该如何处理?

 

解决∶客户端把消息写到leader了，可是leader还没发送portal消息给其余节点，这个时候leader宕机了，这个时候对于用户来讲，这条消息是写失败的。假设过了一段时间之后leader节点又恢复了，不过这个时候角色就变为了follower了，它在检查本身磁盘的时候会发现本身有一条消息没有进行commit，此时就会检测消息的编号，消息是有编号的，由高32位和低32位组成，高32位是用来体现是否发生过leader切换的，低32位就是展现消息的顺序的。这个时候当前的节点就会根据高32位知道目前leader已经切换过了，因此就把当前的消息删除，而后重新的leader同步数据，这样保证了数据一致性。

Zookeeper的Observer节点

对应一个ZooKeeper集群，咱们可能有多个客户端，客户端能任意链接其中一台ZzooKeeper节点，可是全部的客户端都只能往leader节点上面去写数据，全部的客宁端能从全部的节点上面读取数据。若是有客户端链接的是follower节点，而后往follower上发送了写数据的请求，这个时候follower就会把这个写请求转发给1eader节点处理。leader接受到写请求就会往其余节点（包括本身)同步数据，若是过半的节点接受到消息后发送回来ack消息，那么leader节点就对这条消息进行commit,commit后该消息就对用户可见了。由于须要过半的节点发送ack后，l1eader才对消息进行comnit，这个时候会有一个问题，若是集群越大，那么等待过半节点发送回来ack消息这个过程就须要越久，也就是说节点越多虽然会增长集群的读性能，可是会影响到集事的写性能，因此咱们通常建议ZooKeeper的集群规模在3到5个节点左右。为了解决这个问题，后来的Zookeeper中增长了一个observer 的角色，这个节点不参与投票，只是负责同步数据。好比咱们leader写数据须要过半的节点发送ack响应，这个observer节点是不参与过半的数量统计的。它只是负责从leader同步数据，而后提供给客户端读取，因此引入这个角色目的就是为了增长集群读的性能，而后不影响集群的写性能。用户搭建集群的时候能够本身设置该角色。