Zookeeper的知识概要

一、分布式架构

1.集中式系统:指一台或多台计算机组成中心节点,系统的所有业务和数据都部署在这个节点上。
优点:部署结构简单。缺点:价格昂贵,存在明显的单点问题(一旦一台大型主机出现故障,整个系统
将处于不可用状态)。
2.分布式系统:指硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通讯
和协调。特征有:
分布性:计算机在空间上随意分布。
对等性:计算机没有主/从之分,节点都是对等的。
并发性:多个节点可能会并发地操作一些共享资源。
缺乏全局时钟:不能区分事件的先后。
故障总是会发生
3.分布式事务满足ACID(原子性、一致性、隔离性、持久性)
4.CAP定理:一个分布式系统不可能同时满足一致性、可用性和分区容错性这三个基本需求,最多只能满足
其中的两项。三个特性如下:
一致性(Consistency):指数据在多个副本之间保持一致。一个数据更新后,所有的用户能看到最新的值。
可用性(Availability):指系统提供的服务必须一直处于可用的状态,对用户的每一个操作请求总是能够在有限的时间内返回结果。
分区容错性(Partition tolerance):在遇到任何网络分区故障的时候,任然需要能够对外提供满足一致性和可用性的服务,除非是整个网络
环境都发生了故障。
CAP定理应用:放弃A或放弃C或放弃P。
5.BASE理论是对CAP中的一致性和可用性的权衡结果。即使无法做到强一致性,也可以采用适当的方法达到最终一致性。
BASE三要素:
基本可用:系统在发生不可预知的故障时,允许损失部分的可用性(包括响应时间、功能上的损失)。
弱状态:也叫软状态,与硬状态相对。存在中间状态,允许系统在不同节点的数据副本在进行数据同步的时候存在延时。
最终一致性:系统的所有数据副本,经过一段时间以后,最终能够达到一致的状态,不需要实时保证数据的强一致性。

二、一致性协议

1.2PC:(包含协调者和参与者) 二阶段协议。分为两个阶段:阶段一:提交事务请求;阶段二:执行事务提交。
执行过程:协调者向对所有参与者进行询问,看它们是否都需要事务提交,若都需要则进行事务提交;当事务提交后,协调者接收
反馈信息,若反馈No响应或等待超时后,就会中断事务,协调者向所有参与者发出回滚请求。
优缺点:
同步阻塞:提交的执行过程中,所有参与该事务操作的逻辑都处于阻塞状态。
单点问题:如果协调者出现问题,其他参与者将处于锁定状态,无法继续完成实务操作。
数据不一致:在执行事务提交的时候,可能会出现只有部分参与者接收到提交请求,导致数据不一致。
太过保守:没有完善的容错机制,只要一个节点失败就导致整个事务失败。
2.3PC:三阶段协议。对二阶段协议进行改进,分为CanCommit、PreCommint(预提交)、doCommit阶段,多了预提交阶段。
执行过程:协调者向对所有参与者进行询问,看它们是否都需要事务提交,若都需要则进行事务预提交;在事务预提交中,协调者接收
反馈信息,若反馈No响应或等待超时后,就会中断事务;若预提交执行成功,则进行真正的事务提交。
优缺点:
优点:降低参与者的阻塞范围,能够在出现单点故障后继续达成一致。
缺点:在PreCommit后,如果出现网络分区,协调者所在的节点和参与者无法进行正常网络通信,导致数据不一致性。
3.Paxos算法:
包含的角色有:Proposer(申请者)、Acceptor(接收者)、Learner(领导者);
执行过程:
提案的选定:一个Proposer向一个或多个Acceptor发提案,由半数以上Acceptor批准的提案会被选定。
Proposer生成提案:在确定提案后,Proposer会将该提案再次发送给某个Acceptor集合,并期望获得它们的批准。
Acceptor批准提案:Aceeptor接到Proposer的Prepare或Accept请求后,做出相应的响应。
提案的获取:Learner获取提案。
优点:引入“过半”的概念,即少数服从多数的原则,并且支持节点角色之间的轮换,极大地避免了分布式的出现,也解决了
无限等待和“脑裂”等问题。

三、Paxos工程实践

1.Chubby是一个分布式锁服务,底层一致性实现是以Paxos算法为基础的。
应用场景:集群服务器中的Master选举。
Chubby系统结构主要由服务端和客户端两部分组成,客户端通过RPC调用与服务器进行通信。
客户端可以向服务端注册事件通知,当触发这些事件的时候,服务端就会向服务端发送对应的事件通知。
Chubby中一些关键词:锁与锁序列器、缓存、会话和会话激活、故障恢复、Paxos协议实现。
2.Hypertable:构建一个针对分布式海量数据的高并发数据库。
只支持基本的添、删、改、查,还没有支持事务处理和关联查询等特性。
核心组件有:
Hyperspace:提供对分布式锁服务的支持和及对元数据的管理,是保证数据一致性的核心。
RangeServer:提供对外服务,负责数据的读取和写入。
Master:元数据管理中心。
DFS Broker:底层分布式文件系统的抽象层。

四、Zookeeper

1.zookeeper是一个典型的分布式数据一致性的解决方法,可以实现数据发布/订阅、负载均衡、命名服务、
分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列等功能。
zookeeper将全量数据存储在内存中,来实现提高服务器吞吐、减少延迟的目的。
2.基本概念;
集群角色:没有Master/Slave概念,有Leader、Follower、Observer三个角色。Leader服务器为客户端提供
读和写服务。Follower和Observer都能提供读服务,但Observer不参与Leader选举过程。
会话:指客户端和服务器之间的一个TCP连接。
节点:机器节点(集群中的机器),数据节点(Znode数据模型中的数据单元,分为持久节点和临时节点)
版本:version、cversion等
Watcher:可在指定的节点上注册事件,当事件触发的时候,服务器会通知客户端。
ACL:用来进行权限控制。
3.ZAB协议:是为分布式协调服务Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。
ZAB协议包括两种基本模式:崩溃恢复和消息广播。
在消息广播中,Leader服务器会为每一个Follower服务器各自分配一个单独的队列,将需要广播的事务依次放入
这些队列中,并根据FIFO的策略进行消息发送。
崩溃恢复:当Leader服务器出现崩溃或者由于网络原因导致Leader服务器失去与过半Follower的联系,就进入崩溃恢复模式。
进程正常工作时,处于UP状态;进程崩溃时,称为处于DOWN状态。
ZAB协议是整个Zookeeper框架的核心所在,它规定任何时候都需要保证只有一个主进程负责进行消息广播,如果主进程崩溃了
就要选举一个新的主进程,选举机制和消息广播机制是紧密相关。
ZAB与Paxos的联系与区别:
联系:都存在类似于Leader进程的角色,负责协调多个Follower进程的运行;Leader进程都会等待超过半数的Follower做出正确
的反馈后,才会将一个提案进行提交。
区别:设计目标不一样。ZAB用于构建一个高可用的分布式数据主备系统,Paxos用于构建分布式一致性状态机系统。

五、使用Zookeeper

1.部署与运行:
Zookeeper使用Java编写,需要Java环境的支持。
2.运行模式:集群模式、单机模式(只有一台机器)。
3.配置zoo.cfg、创建myid文件等。
4.伪集群模式:在同一台机器上的不同端口上启动不同的进程。
5.可执行脚本:zkCleanUp、zkCli、zkEnv、zkServer等。
6.Java客户端API中节点操作:创建、更新、删除、读取等(每个路径对应一个节点)。
7.检测节点是否存在、权限控制、事件监听、Master选举、分布式锁。
8.开源客户端:ZkClient、Curator。

六、Zookeeper应用

一些关联的技术:
Hadoop:Apache开源的大型分布式计算框架。它的核心是HDFS和MapReduce,分别提供对海量数据的存储和计算能力。
YARN:为了提高计算节点的分布式调度框架,可以支持MapReduce、Spark、Storm等计算引擎。
HBase:Hadoop Database,是基于Hadoop文件系统设计的面向海量的数据高可靠性、高性能、面向列、可伸缩的
分布式存储系统,可以在廉价的PC服务器上搭起大规模结构化的存储集群。对数据写入具有强一致性。
Kafka:由Scala语言开发、吞吐量极高的分布式消息系统,可以用于实现低延迟的发送和收集大量的事件和日志数据。
它包含:消息生产者Producer、消息消费者Consumer、主题Topic、消息分区(一个Topic下可以有多个分区)、
Broker(服务器,用于存储消息)、消费者分组Group、Offset(消息在文件中的偏移量)。
Broker注册、Topic注册、生产者和消费者负载均衡、消费进度Offset记录。

七、Zookeeper技术内幕

1.在Zookeeper中,每一个数据节点都称为一个ZNode,所有的ZNode按层次化结构进行组织,形成一棵树。
2.Zookeeper中的事务:指能够改变服务器状态的操作,比如节点的创建、删除等。每一个事务请求都会有
一个全局唯一的事务ID。
3.节点特性:
节点类型(节点的生命周期):持久节点、临时节点、顺序节点。
状态信息:包含事务ID、创建时间、版本号等信息。
版本:记录节点的修改次数,用来保证分布式数据的原子性操作(悲观锁:一个事务对数据进行处理时,在整个过程
都将数据锁定,其它事务无法对这个数据进行更新,直到这个事务完成;乐观锁:假定多个事务在处理过程中不会彼此影响,所以
在大部分时间不需要加锁)
4.Watcher:客户端向服务端注册一个Watcher,当服务端指定事件触发时,就会向指定的客户端发送一个事件通知。
Watcher接口、WatchedEvent、回调方法等等。
5.ACL:“schema:id:permission”
schema权限模式:
IP:通过IP地址粒度进行权限控制。
Digest:类似于“username:password”形式。
World:对所有用户开放。
Super:对超级用户开放。
授权对象ID:指权限赋予的用户或一个指定实体。
权限Permission:CREATE(创建权限)、DELETE(删除权限)、READ(读取权限)、WRITE(更新权限)、ADMIN(管理权限)。
6.序列化:使用Jute实现序列化和反序列化。
7.通信协议:Zookeeper基于TCP/IP协议,实现了自己的通信协议来完成客户端与服务器、服务器与服务器之间的网络通信。
对于请求主要包括请求头和请求体,对于响应,主要包含响应头和响应体。
8.解析服务器地址:将多个服务器地址打散后,装入一个循环队列中,然后再遍历选取。
9.ClientCnxn网络IO:负责维护客户端与服务端之间的网络连接并进行一系列的网络通信。
10.会话:在Zookeeper客户端和服务端成功完成连接创建后,就建立了一个会话,在运行期间会在不同的回话状态
之间进行切换。会话状态有CONNECTING、CONNECTED、CLOSE等等。
会经历会话创建,会话检查,会话删除等。
11.Leader选举:
服务器启动时期的选举:(1)每个Server发出一个投票(以(myid,ZXID)表示,myid表示要投的服务器,初始时都会投给自己);
(2)接收来自各服务器的投票(判断投票的有效性);(3)处理投票(将别人的投票和自己的投票PK,先比较ZXID,若相同再比较myid,
比较大的作为Leader);(4)统计投票(每次投票后,统计是否有过半的机器接收到相同的投票信息);(5)改变服务器状态
(选出Leader后,就更改状态,FOLLOWING、LEADING)
服务器运行期间的选举:在运行时候,当Leader所在的机器挂掉时,就会进行新一轮的Leader选举,先把其余服务器状体变为LOOKING
其余选举过程和启动时选举一致。
服务器状态:LOOKING(寻找Leader状态)、FOLLOWING(跟随者状态)、LEADING(领导者状态)、OBSERVING(观察者状态)。
12.服务器中的角色:
Leader:事务请求的唯一调度和处理者,保证集群事务处理的顺序性;集群内部各服务器的调度者。
Follower:处理客户端非事务请求,转发事务请求给Leader服务器;参数事务请求Proposal投票;参与Leader选举投票。
Observer:和Follower基本是一致的,只是不参与任何形式的投票。
13.集群间消息通信:
分为数据同步型、服务器初始化型、请求处理型和会话管理型。
14.Proposal流程:每一个事务请求都需要集群中过半机器投票认可才能被应用到Zookeeper的内存数据库中去。
包括(1)发起事务投票;(2)生成提议Proposal;(3)广播提议;(4)收集投票;(5)将请求放入toBeApplied队列;(6)广播COMMIT消息
15.数据与存储:分为内存数据存储和磁盘数据存储。
内存数据:DataTree(是一颗树结构,代表一份完整的数据),DataNode(数据存储的最小单元),
ZKDatabase是Zookeeper的内存数据库,负责管理Zookeeper的所有会话、DataTree存储和事务日志。
数据快照:用来记录Zookeeper服务器上某一个时刻的全量内存数据内容,并将其写入到指定的磁盘文件中。

数据同步:将没有在Leader服务器上提交过的事务请求同步给Leader服务器。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值