Zookeeper学习脑图
2022-07-09 16:41:33 0 举报AI智能生成
登录查看完整内容
该脑图参考“《从Paxos到Zookeeper 分布式一致性原理与实践》【倪超著】”编辑完成。
作者其他创作
大纲/内容
由一台或多台计算机组成中心节点，这个中心节点承担数据集中存储、所有业务单元的集中部署、系统所有功能的处理。部署结构简单，无需考虑多节点部署和多节点之间的分布式协调问题。
集中式特点
分布式系统是一个硬件和软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。——《分布式系统概念与设计》
分布式概念
分布式系统中的多台计算机都会在空间上随意分布，同时，机器的分布情况也会随时变动。
分布性
数据副本：数据恢复
服务副本：服务容灾
在此特点上延申的副本概念
分布式系统中的计算机没有主从之分，既没有控制整个系统的主机，也没有被控制的从机。所有的计算机节点是对等的。
对等性
分布式系统中的多个节点，可能会并发的操作一些共享的资源。
并发性
由于分布式系统缺乏一个全局的始终序列控制，因此，很难定义两个时间究竟谁先谁后。
缺乏全局时钟
任何在设计阶段考虑到的异常情况，一定会在系统实际运行中发生，并且在系统实际运行过程中还会遇到很多在设计时未能考虑到的异常故障。因此，除非需求指标允许，在系统设计时不能放过任何异常情况。
故障总是会发生
特点
分布式特点
由于网络本身存在不可靠性，分布式系统中的节点在网络通信过程时刻会伴随着网络不可用的问题。从而导致最终分布式系统无法顺利完成一次网络通信。并且由于网络间通信有更高的延时，系统消息的收发过程也会受到影响，因此消息丢失和消息延迟会变得非常普遍。
通信异常
俗称“脑裂”。即在网络异常的情况下，分布式系统中部分节点的网络延迟不断增大，导致只有另外部分节点能够进行正常通信。这些正常节点形成的局部小集群，承担起了原本需要整个分布式系统才能完成的功能。
网络分区
成功、失败、超时。
三态
节点故障
分布式环境的各种问题
从集中式到分布式
事务是一系列对系统中数据进行访问与更新的操作所组成的一个程序执行逻辑单元，狭义的事务特指数据库事务。
定义
当多个应用程序并发访问数据库时，事务可以在这些应用程序之间提供一个隔离方法，以防止彼此的操作互相干扰。
事务为数据库操作序列提供了一个从失败中恢复正常状态的方法。
事务为数据库提供了在异常状态下仍能保持数据一致性的方法。
思想
事务必须是一个原子的操作序列单元，其中包含的各项操作在一次执行过程中，要么全部执行，要么全部不执行。并且任何一项操作失败都将导致整个事务的失败，同时其他已经被执行的操作都将被撤销并回滚。
原子性（Atomicity）
事务的执行不能破坏数据库数据的完整性和一致性，即：一个事务在执行前后，数据库都必须处于一致性状态。
一致性（Consistency）
在并发环境中，并发的事务是互相隔离的，一个事务的执行不能被其他事务干扰。即：不同的事务并发操纵相同的数据时，每个事务都有各自完整的数据空间，一个事务内部的操作及使用的数据对其他并发事务是隔离的，并发执行的事务之间不能相互干扰。
概念
脏读、幻读
读未提交（Read Uncommitted）
幻读
读已提交（Read Committed）
可重复读（Repeatable Read）
串行化（Serializable）
隔离级别
隔离性（Isolation）
持久性（Durability）
特征
事务
ACID
事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上。通常一个分布式事务中会涉及对多个数据源或业务系统的操作。
分布式事务
数据在多个副本之间是否能够保持一致的特性。当一个系统在数据一致的状态下执行更新操作后，应该保证系统的数据仍然处于一致的状态。
系统提供的服务必须一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。
可用性（Availability）
分布式系统在遇到任何网络分区故障的时候，仍然需要能够保证对外提供满足一致性和可用性的服务，除非是整个网络环境都发生了故障。
分区容错性（Partition tolerance）
将所有数据都放在一个分布式节点上，同时也就意味着放弃了系统的可扩展性。
放弃P
一旦系统遇到网络分区或其他故障时，那么收到影响的服务需要等待一定的时间，因此在等待期间系统无法对外提供正常的服务，即不可用。
放弃A
并非完全不需要数据一致性。即放弃数据的强一致性，保留数据的最终一致性。
放弃C
定理应用
CAP
响应时间上的损失
功能上的损失
分布式系统在出现不可预知故障的时候，允许损失部分可用性。
基本可用（Basically Available）
也称为“弱状态”。允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性。即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时。
软状态（Soft State）
系统中所有的数据副本，在经过一段时间的同步之后，最终能够达到一个一致的状态。
因果一致性（Causal Consistency）
读己之所写（Read Your Writes）
会话一致性（Session Consistency）
一个进程从系统中读取一个数据项的某个值后，那么系统对于该进程后续的任何数据访问都不应该返回更旧的值。
单调读一致性（Monotonic Read Consistency）
一个系统需要更够保证来自同一个进程的写操作被顺序的执行。
单调写一致性（Monotonic Write Consistency）
实践中的变种
实践中可以将若干各变种互相结合起来，以构建一个具有最终一致性的分布式系统。
最终一致性（Eventually Consistent）
BASE
CAP和BASE理论
从ACID到CAP/BASE
分布式架构
用来统一调度所有分布式节点的执行逻辑。
协调者
被“协调者”调度的分布式节点称为“参与者”。
参与者
当一个事务操作需要跨越多个分布式节点的时候，为了保持事务处理的ACID特性，需要引入“协调者”和“参与者”两个角色。协调者负责调度参与者的行为，并最终决定这些参与者是否要把事务真正进行提交。
基础思想
是计算机网络尤其是在数据库内，为了使基于分布式系统架构下的所有节点在进行事务梳理过程中能够保持原子性的一致性而涉及的一种算法。也被认为是一种一致性协议，用来保证分布式系统数据的一致性。
能够非常方便的完成所有分布式事务参与者的协调，统一决定事务的提交或回滚。被广泛应用。
协调者向所有参与者发送事务内容，询问是否可以执行事务操作，并开始等待各参与者的响应。
事务询问
各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中。
执行事务
参与者成功执行了事务操作，反馈给协调者Yes响应，表示事务可以执行。
Yes响应
参与者没有成功执行事务，反馈给协调者No响应，表示事务不可以执行。
No响应
各参与者向协调者返回事务询问的响应
阶段一：提交事务请求
协调者向所有参与者节点发送Commit请求。
发送提交请求
参与者接收到Commit请求之后，会正式执行事务提交工作，并在完成提交之后释放整个事务执行期间占用的事务资源。
事务提交
参与者在完成事务提交之后，向协调者发送Ack消息。
反馈事务提交结果
协调者接收到所有参与者反馈的Ack消息后，完成事务。
完成事务
Yes响应：执行事务提交
协调者向所有参与者节点发送Rollback请求。
发送回滚请求
参与者接收到Rollback请求之后，会利用其在阶段一中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放整个事务执行期间占用的事务资源。
事务回滚
参与者在完成事务回滚之后，向协调者发送Ack消息。
反馈事务回滚结果
协调者接收到所有参与者反馈的Ack消息后，完成事务中断。
中断事务
No响应：中断事务
阶段二：执行事务提交
说明
原理简单，易于实现。
优点
在提交执行的过程中，所有参与该事务的逻辑都处于阻塞状态，即各个参与者在等待其他参与者响应的过程中，将无法进行其他任何操作。这会极大地限制分布式系统的性能。
同步阻塞
一旦协调者出现问题，那么整个二阶段提交流程将无法运转。并且，如果协调者是在阶段二中出现问题，那么其他参与者将会一直处于锁定事务资源的状态中，而无法继续完成事务操作。
单点问题
在阶段二中，如果部分协调者或参与者由于网络或自身问题，导致事务服务最终提交，那么整个分布式系统便会出现数据不一致的情况。
脑裂
二阶段提交没有设计较为完善的容错机制，任意一个节点的失败都会导致整个事务的失败。
保守
缺点
优缺点
二阶段提交将一个事务的处理过程分为了投票和执行两个阶段，其核心是对每个事务都采用先尝试后提交的处理方式，因此也可以将二阶段提交看作一个强一致性的算法。
总结
二阶段提交（2PC）
各参与者向协调者反馈事务询问的响应
阶段一：Can Commit
协调者向所有参与者节点发送preCommit请求。并进入Prepared阶段。
发送预提交请求
各参与者节点在接收到preCommit请求后，执行事务操作，并将Undo和Redo信息记入事务日志中。
事务预提交
如果参与者成功完成了事务操作，就向协调者发送Ack消息。同时等待最终的命令：提交（commit）或终止（abort）。
各参与者向协调者反馈事务执行的响应
执行事务预提交
阶段一中各参与者全部反馈Yes响应
协调者向所有参与者节点发送abort请求。
发送中断请求
无论是收到来自协调者的abort请求，或者是在等待协调者请求过程中出现了超时，参与者都会终端事务。
阶段一中任何一个参与者反馈No响应
阶段二：Pre Commit
进入这一阶段，假设协调者处于正常工作状态，并且它及收到了来自所有参与者的Ack响应，那么它将从“预提交”状态转换到“提交”状态，并向所有参与者发送doCommit请求。
参与者接收到doCommit请求之后，会正式执行事务提交工作，并在完成提交之后释放整个事务执行期间占用的事务资源。
执行提交
参与者接收到abort请求之后，会利用其在阶段二中记录的Undo信息来执行事务回滚操作，并在完成回滚之后释放整个事务执行期间占用的事务资源。
协调者接收到所有参与者反馈的Ack消息后，中断事务。
阶段三：Do Commit
相较于二阶段提交协议，三阶段提交协议降低了参与者的阻塞范围，并且能够在出现单点故障后继续达成一致。
参与者在接收到preCommit消息后，如果出现网络分区，该参与者依然会进行事务的提交，这必然会出现数据的不一致性。
三阶段提交（3PC）
2PC与3PC
是一种基于消息传递且具有高度容错性的一致性算法。
在一个可能出现网络分区的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致，并且保证不论发生任何异常，都不会破坏整个系统的一致性。
解决的问题
追本溯源
“拜占庭问题”，“Paxos小岛议会问题”，Leslie Lamport，Butler Lampson
Paxos理论的诞生
要保证最终有一个提按会被选定，当提案被选定后，进程最终也能获取到被选定的提案。
目标
Proposer\\Acceptor\\Leaner
相关角色
P1：一个Acceptor必须批准它收到的第一个提案
保证了只有一个value被选定
P2：如果编号为M0、Value值为V0的提案，即[M0，V0]被选定了，那么所有比编号M0更高的，且被选定的提案，其Value必须也是V0。
P2a：如果编号为M0、Value值为V0的提案，即[M0，V0]被选定了，那么所有比编号M0更高的，且被Acceptor批准的提案，其Value必须也是V0。
数学归纳法证明
P2b：如果一个提案[M0，V0]被选定后，那么之后任何Proposer产生的编号更高的提案，其Value值都是V0.
推导过程
引入了“过半”理念，同时支持分布式节点角色之间的转换，极大的避免了分布式单点的出现，因此Paxos既解决了无限期等待问题，也解决了“脑裂”问题。
Paxos算法详解（详见书籍）
Paxos算法
一致性协议
是一个面向松耦合分布式系统的锁服务，通常用于为一个由大量小型计算机构成的松耦合分布式系统提供高可用的分布式锁服务。
概述
提供了粗粒度的分布式锁服务，开发人员不需要使用复杂的同步协议，而是直接调用Chubby的所服务接口即可实现分布式系统中多个进程之间粗粒度的同步控制，从而保证分布式数据的一致性。
实现
集群中服务器的Master选举
应用场景
对上层应用程序的入侵性更小
便于提供数据的发布与订阅
开发人员基于锁的接口更为熟悉
引入Quorum机制，即“过半机制”
更便捷地构建更可靠的服务
锁服务优点
提供一个完整的、独立的分布式服务、而非仅仅是一个一致性协议的客户端库
应用场景是客户端获得锁之后会进行长时间持有（数小时或数天），而非用于短暂获取所得场景。所以当锁服务暂时失效时，Chubby需要保持所有锁的持有状态，以避免持有锁的客户端出现问题。
提供粗粒度的锁服务
提供对小文件的读写服务，以使得被选举出来的Master可以在不依赖额外服务的情况下，非常方便的向所有客户端发布自己的状态信息。
在提供所服务的同时提供对小文件的读写功能
高可用、高可靠
提供事件通知机制
设计目标
客户端
服务端
系统结构
RPC调用
结构上类似Unix系统
会在其对那个的客户端会话失效后被自动删除，生命周期与客户端会话绑定。
临时节点
显式调用API接口删除
持久节点
节点类型
用于标识Chubby创建该数据节点的顺序
实例编号
用于标识文件内容的变化情况
文件内容编号（只针对文件）
用于标识节点锁状态变更情况，该编号会在节点锁从free状态转换到被持有状态时增加。
锁编号
标识节点的ACL信息变更情况
ACL编号
节点结构
节点（命名空间，包括文件和目录）
目录与文件
锁延迟
锁序列器
锁与锁序列器
文件内容变更
节点删除
子节点新增、删除
Master服务器转移
事件通知机制
客户端向服务端注册时间通知，通知事件触发时，服务端异步发送消息。
在客户端对文件内容和元数据信息进行缓存，并通过租期机制来保证缓存一致性（强一致性）。
缓存
在正常运行过程中，每一个Chubby客户端总是会有一个KeepAlive请求阻塞在Matser服务器上。
会话与会话激活
客户端“危险状态”、“宽限期”、jeopardy/safe/expired事件通知机制
会话超时
Chubby技术架构
最底层：容错日志系统（Fault-Tolerant Log）
中间层：Key-Value类型的容错数据库（Fault-Tolerant DB）
最上层：Chubby对外提供的分布式锁服务和小文件存储服务
Chubby基本架构分层
图示
Paxos协议实现
Chubby
使用C++实现的开源、高性能、可伸缩的数据库。Hypertable只支持最基本的增、删、改、查功能，对于事务处理和关联查询等关系型数据库的高级特性尚未支持。并且在数据量少的情境下，性能还不如传统的关系型数据库。
支持对大量并发请求的处理。
支持对海量数据的管理。
扩展性好，在保证可用性的前提下，能够通过随意添加集群中的机器来实现水平扩容。
可用性极高，具有非常好的容错性，任何节点的失效，既不会造成系统的瘫痪，也不会影响数据的完整性。
提供了对分布式锁服务的支持以及对元数据的管理，是保证Hypertable数据一致性的核心。
Hyperspace
对外提供服务的组件单元，负责数据的读取和写入。
RangerServer
元数据管理中心，管理包括创建表、删除表或是其他表空间变更在内的所有元数据操作，同时负责检测RangServer的工作状态。一旦某一个RangeServer宕机或是重启，能够自动进行Range的重新分配，从未实现对RangeServer集群的管理和负载均衡。
Master
文件系统包括HDFS\\MapR\\Ceph\\KFS，针对任何其他的文件系统，只需要实现一个对应的DFS Broker，就可以将其快速接入到整个Hypertable系统中。
是底层分布式文件系统的抽象层，用于衔接上层Hypertable和底层文件存储。
DFS Broker
核心组件
Active Server\\Standby Server\\Master选举，任意时刻只有Active Server能够对外提供服务。
Active Server
BDB、Master选举
事务请求处理
所有服务器上事务日志的更新时间越新，被选举为Active Hyperspace的可能性就越大。
Active HyperSpace 选举
算法实现
Hypertable
Paxos的工程实践
为分布式应用提供了高效且可靠的分布式协调服务，提供了诸如统一命名服务、配置管理、分布式锁等基础服务。在解决分布式数据一致性方面，Zookeeper并没有直接采用Paxos算法，而是采用了ZAB（Zookeeper Atomic Broadcast）一致性协议。
分布式系统可以基于它实现诸如数据发布/订阅、负载均衡、命名服务、分布式协调/通知，集群管理、Master选举、分布式锁和分布式队列等功能。
将复杂且容易出错的分布式一致性服务封装起来，构成一个高效可靠的原语集，并以一系列简单易用的接口提供给用户使用。
同一个客户端发起的事务请求，会被严格的按照其发起顺序被应用到Zookeeper中去。
顺序一致性
所有事务请求的处理结果在整个集群中所有机器的应用情况都是一致的。
原子性
客户端连接的任意Zookeeper服务器，其看到的服务端数据模型都是一致的。
单一视图
一旦服务端成功的应用了一个事务，并完成对客户端的响应，那么该事务所引起的服务端状态便泵将会被一直保存下来，除非有另一个事务又对其进行了变更。
可靠性
Zookeeper仅仅保证在一定的时间段内，客户端最终一定能够从服务端上读取到最新的数据状态。
实时性
一致性特性
数据模型有一系列的Znode数据节点组成，类似于文件系统。并且将全量数据存储在内存中，以此来实现提高服务器吞吐，减少延迟的目的。
简单的数据模型
可以构建集群
对于来自客户端的更新请求，Zookeeper都会分配一个全局唯一的递增编号，这个编号反应了所有事务操作的先后顺序，应用程序可以使用Zookeeper的这个特性来实现更高层次的同步原语。
顺序访问
100%读请求场景下压测结果是12~13W的QPS
高性能
设计目的：高性能、高可用、严格的顺序访问控制能力
Zookeeper介绍
yahoo
Zookeeper从何而来
Zookeeper集群中的所有机器可以通过一个Leader选举过程来选定一台被称为”Leader“的机器，Leader服务器为客户端提供读和写服务。
Leader
提供读服务，参与Leader选举。
Follower
提供读服务，不参与Leader选举。可以在不影响写性能的情况下提升集群的读性能。
Observer
集群角色
会话
数据节点（Znode）
version（当前ZNode的版本）
cversion（当前ZNode子节点的版本）
aversion（当前ZNode的ACL版本）
对于每一个ZNode，Zookeeper都会为其维护一个叫做Stat的数据结构，Stat中记录了这个ZNode的三个数据版本
版本
Zookeeper允许用户在指定节点上注册一些Watcher，并且在一些特定事件触发的时候，Zookeeper服务端会将事件通知到感兴趣的客户端上去，该机制是Zookeeper实现分布式协调服务的重要特性。
Watcher（事件监听器）
创建子节点的权限
CREATE
获取节点数据和子节点列表的权限
READ
更新节点数据的权限
WRITE
删除子节点的权限
DELETE
设置节点ACL的权限
ADMIN
Zookeeper采用ACL（Access Control Lists）策略来进行权限控制。
ACL
Zookeeper基本概念
初识Zookeeper
Zookeeper专门设计的一种支持崩溃恢复的原子广播协议。基于该协议，Zookeeper实现了一种主备模式的系统架构来保持集群中各副本之间数据的一致性。
所有事务请求必须由一个全局唯一的服务器来协调处理，这样的服务器被称为Leader服务器，而余下的其他服务器则成为Follower服务器。Leader服务器负责将一个客户端事务请求转换成一个事务Proposal（提议），并将该Proposal分发给集群中所有的Follower服务器。之后Leader服务器需要等待所有Follower服务器的反馈，一旦超过半数的Follower服务器进行了正确的反馈后，那么Leader就会再次向所有的Follower服务器分发commit消息，要求其将前一个Proposal进行提交。
核心是定义了那些会改变Zookeeper服务器数据状态的事务请求的处理方式
ZAB协议(概念)
当整个服务框架在启动过程中，或是当Leader服务器出现网络中断、崩溃推出与重启异常情况时，ZAB协议就会进入恢复模式并选举产生新的Leader服务器。当选举产生了新的Leader服务器，同时集群中已经有过半的机器与改Leader服务器完成了状态同步之后，ZAB协议就会退出恢复模式。
崩溃恢复模式
当集群中已经有过半的Follower服务器完成了和Leader服务器的状态同步，那么整个服务框架就进入消息广播模式。
消息广播模式
两种基本模式
消息广播过程使用的是一个原子广播协议，类似于一个二阶段提交过程。此时的二阶段提交协议移除了中断逻辑，所有的Follower服务器要么正常反馈Leader提出的事务Proposal，要么就抛弃Leader服务器。
消息广播
ZAB协议需要一个高效且可靠的Leader选举算法，从而确保能够快速的选举出新的Leader。同时，Leader选举算法不仅仅需要让Leader自己知道其自身已经被选举为Leader，同时还需要让集权中的所有其他机器也能够快速的感知的选举产生的新的Leader服务器。
Leader服务器崩溃
网络原因导致Leader服务器失去了过半Follower的联系
数据一致性隐患
ZAB协议需要确保那些已经在Leader服务器上提交的事务最终被所有服务器都提交。
ZAB协议需要确保丢弃那些只在Leader服务器上被提出的事务。
ZAB协议在崩溃恢复过程中需要保证的基本特性
让Leader选举算法能够保证新选举出来的Leader服务器拥有集群中所有机器编号做高的事务Propsal，那么就可以保证这个新选举出来的Leader一定具有所有已经提交的提案。
让具有最高编号事务Proposal的机器来成为Leader，就可以省去Leader服务器检查Proposal的提交和丢弃工作的这一步操作了。
满足该特性的Leader选举算法
崩溃恢复
Leader服务器为每一个Follower服务器准备一个队列，并将那些没有被各Follower服务器同步的事务以Proposal消息的形式逐个发送给Follower服务器。
在每一个Proposal消息后面紧接着再发送一个Commit消息，以表示该事务已经被提交。
等到Follower服务器将所有其尚未同步的事务Proposal都从Leader服务器上同步过来并成功应用到本地数据库中后。
Leader服务器将该Follower服务器加入到真正的可用Follower列表中，并开始之后的其他流程。
崩溃恢复后的数据同步
一个简单的单调递增计数器，针对客户端的每一个事务请求，Leader服务器会在产生一个新的事务Proposal时，对该计数器进行加1操作。
低32位
代表Leader周期epoch编号，每当选举出一个新的Leader服务器，就会从这个Leader服务器上取出其本地日志中最大事务Proposal的ZXID，并从该ZXID中解析出对应的epoch值，然后再对其进行加1操作，之后会以此编号作为新的epoch，并将低32位置0来开始成成新的ZXID。
高32位
ZXID结构
当另外一台服务器被选举为新的Leader之后，当前集群中一定包含一个Quorum集合，该集合中的机器一定包含了更高epoch的事务Proposal，因此这台机器的事务Proposal肯定不是最高，也就无法称为Leader了。当这台机器以Follower加入到集群并连接上Leader之后，Leader会根据自己服务器上最后被提交的Proposal来和Follower服务器的Proposal进行对比，对比的结果时Leader会要求Follower进行一个回退操作——回退到一个确实已经被集群中过半机器提交的最新的事务Proposal。
原理
ZAB对需要被丢弃的Proposal的处理方式
协议介绍
存在这样的一个进程自己Q，其必定是进程组Π的子集；同时存在任意两个进程子集Q1和Q2，其交集必定非空。
数学模型
Pi、Pj表示进程组Π的两个不同进程，Cij表示Pi和Pj之间的网络通信信道
进程Pj如果收到了来自Pi的消息m，那么Pi一定确实发送了消息m。
完整性（Integrity）
如果进程Pj收到了消息m，那么存在这样的消息m'：如果消息m'是消息m的前置消息，那么Pj务必先接收到消息m'，然后再接收到消息m。
前置性（Prefix）
基本特性
网络通信信道
系统模型
高吞吐低延迟
能够很好的在高并发情况下完成分布式数据的一致性处理
能够优雅的处理运行时故障
具备快速的从故障中恢复过来的能力
问题描述
主进程周期
发现（Discovery）
同步（Synchronization）
广播（Broadcast）
可以将消息广播和崩溃恢复两个过程细分为三个阶段
循环的执行这三个阶段，一个循环称为一个主进程周期
算法描述
LOOKING：Leader选举阶段
FOLLOWING：Follower服务器和Leader保持同步状态
LEADING：Leader服务器作为主进程领导状态
ZAB协议的设计中，每一个进程都有三种状态
在ZAB协议运行过程中，每个进程都会在LEADING、FOLLOWING、LOOKING状态之间不断的切换。
运行分析
深入ZAB协议
两者都存在一个类似于Leader进程的角色，由其负责协调多个Follower进程的运行
Leader进程都会等待超过半数的Follower做出正确的反馈后，才会将一个提案进行提交
在ZAB协议中，每个Proposal中都包含了一个epoch值，用来代表当前的Leader周期，在Paxos算法中，同样存在这样的一个标识，只是名字变成了Ballot
联系
读阶段、写阶段、广播
Paxos Leader
同步阶段的引入，能有效的保证Leader在新的周期中提出事务Proposal之前，所有的进程都已经完成了对之前所有事务Proposal的提交。
发现、同步、广播
ZAB Leader
区别
ZAB和Paxos算法的联系与区别
Zookeeper的ZAB协议
Zookeeper与Paxos
系统环境
集群模式
伪集群模式
单机模式
集群与单机
运行服务
部署与运行
创建
读取
更新
删除
客户端脚本
创建会话
创建节点
删除节点
读取数据
更新数据
监测节点是否存在
权限控制
Java客户端API使用
ZkClient
Curator
客户端开源
小结
使用Zookeeper（详见书本）
即配置中心，发布者降数据发布到Zookeeper的一个或一系列节点上，供订阅者进行数据订阅，进而打到动态获取数据的目的，实现配置信息的集中式管理和数据的动态更新。
服务端主动将数据更新发送给所有订阅的客户端
推（Push）
客户端主动发起请求来获取最新数据，定时轮询拉取。
拉（Pull）
设计模式
Zookeeper采用推拉相结合的方式
数据量比较小
数据内容在运行时会发生动态变化
集群中各机器共享，配置一致
全局配置信息具备的特性
存储在本地配置文件或是内存变量中
小集群
在Zookeeper上选取一个数据节点用于配置的存储
配置存储
集群中每台机器在启动初始化阶段，首先会从Zookeeper配置节点上读取数据库信息，同时，客户端还需要在该配置节点上注册一个数据变更的Watcher监听，一旦发生数据节点变更，所有订阅的客户端都能够获取到数据变更通知。
配置获取
当Zookeeper配置节点上的数据发生变更时，Zookeeper就能够将数据变更的通知发送到各个客户端，每个客户端在接收到这个变更通知后，就可以重新进行最新数据的获取。
配置变更
分布式化存储
大集群
全局配置信息的存储
数据发布/订阅
硬件负载
与配置管理相同，在Zookeeper上创建一个节点来进行域名配置。
域名配置
应用会首先从域名节点中获取一份IP地址和端口的配置，进行自行解析。同时还会再域名节点上注册一个数据变更Watcher监听，以便及时收到域名变更的通知。
在DDNS中，域名的解析过程是由每一个应用自己负责。
域名解析
同配置变更
域名变更
一种动态的DNS服务
负责集群域名的动态注册
Register集群
负责域名解析
Dispatcher集群
负责监测以及维护服务状态（探测服务的可用性、屏蔽异常服务节点等）
Sacnner集群
提供各种语言的系统接入协议，提供服务注册以及查询接口
SDK
负责收集服务信息以及对DDNS自身状态的监控
Monitor
是一个后台管理的Console，负责授权管理、流量控制、静态配置服务和手动屏蔽服务等功能，另外，系统的运维人员也可以在上面管理Register、Dispatcher和Sacnner等集群。
Controller
DDNS系统架构体系主要角色
服务提供者通过SDK提供的API接口，将域名、IP地址和端口发送给Register集群。
Register获取到域名、IP地址和端口配置后，根据域名将信息写入相对应的Zookeeper域名节点中。
每个服务提供者在启动的过程中，会把自己的域名信息注册到Register集群中去。
域名注册
服务消费者在使用域名的时候，会向Dispatcher发出域名解析请求。
Dispatcher收到请求后，会从Zookeeper上指定的域名节点读取响应的IP:PROT列表，通过一定的策略选取其中一个返回给前端应用。
需要在服务端和客户端之间建立起一个TCP长链接
服务端主动发起健康度心跳检测
服务者主动向Scanner进行状态汇报，即每个服务提供者都会定时向Scanner汇报自己的状态。心跳间隔为5秒。
DDNS架构使用的域名探测方式。
客户端主动向服务端发起健康度心跳检测
检测方式
域名探测
自动化的DNS服务-运行方式
软件负载
负载均衡
命名服务是分布式系统最基本的公共服务之一。在分布式系统中，被命名的实体通常可以是集群中的机器、提供的服务地址或远程对象等——都可以通称为他们的”名字“。其中较为常见的就是一些分布式服务框架中的服务地址列表，通过使用命名服务，客户端应用能够根据指定名字来获取资源的实体、服务地址和提供者的信息。
开发人员在使用JNDI时，可以完全不需要关心与数据库相关的任何信息，包括数据库类型、JDBC驱动类型、数据库账户
JNDI命名服务
所有客户端都会根据自己的任务类型，在指定类型的任务下面通过create()接口来创建一个顺序节点。
节点创建完毕后，create()接口会返回一个完整的节点名。
客户端拿到这个返回值后，拼接上type类型。
分布式全局ID的生成
Zookeeper命名服务，与JNDI类似
实践
命名服务
不同的客户端都对Zookeeper上同一个数据节点进行Watcher注册，监听数据节点的变化，如果数据节点发生变化，那么所有订阅的客户端都能够接收到响应的Watcher通知，并做出相应的处理。
是一个数据实时复制框架，用于在不同的MySQL数据库实例之间进行异步数据复制和数据变化通知
MySQL数据库集群
消息队列系统
任务管理监控平台
Core
Server
Zookeeper集群
分别为一个单独的进程，通过Zookeeper进行数据交换
整体组成结构
共同组成包含数据生产作者、复制管道和数据消费者等部分的数据总线系统。
Core进程在启动时，首先会向/mysql_replicator/tasks节点注册任务，如果在注册过程中发现该子节点已经存在，说明已经有其他Task机器注册了该任务，因此自己不需要再创建该节点了。
任务注册
为了应对复制任务故障或者复制任务所在主机故障，复制组件采用”热备份“的容灾方式，即将同一个复制任务部署在不同的主机上，我们称这样的机器为”任务机器“，主、备任务机器通过Zookeeper互相检测运行健康状况。
任务热备份
热备切换
记录执行状态
控制台协调
冷备切换
冷热备份对比
具体实现
MySQL数据复制总线：Mysql_Replicator
基于Zookeeper临时节点特性，可以让不同的机器都在Zookeeper的一个指定节点下创建临时子节点，不同的机器之间可以根据这个临时节点来判断对应的客户端机器是否存活。
检测系统和被检测系统之间不需要直接相关联，而是通过Zookeeper上的某个节点进行关联，从而降低系统耦合性，
心跳检测
在常见的任务分发系统中，通常任务被分发到不同的机器上执行后，需要实时的将自己的任务执行进度汇报给分发系统。
场景
通过判断临时节点是否存在来确定任务机器是否存活。
各个任务机器会实时的将自己的任务执行进度写到这个临时节点上，以便中心系统能够哦实时的获取到任务的执行进度。
在Zookeeper上选择一个节点，每个任务客户端都在这个节点下面创建临时子节点
Zookeeper实现
工作进度汇报
控制台负责将一些指令信息发送给所有的客户端，以控制他们进行相应的业务逻辑。
控制台与客户端
系统调度
一种通用的分布式系统机器间通信方式
分布式协调/通知
侧重对集群运行时状态的收集
集群监控
侧重对集群进行操作与控制
集群控制
核心
希望知道当前集群中究竟有多少机器在工作
对集群中每台机器的运行时状态进行数据收集
对集群中机器进行上下线操作
常见场景
在集群中每台客户端机器上部署一个Agent，由这个Agent负责主动向指定的监控中心系统汇报自己所在机器的状态。
大规模升级困难
统一的Agent无法满足多样的需求
编程语言多样性
大规模集群应用中的弊端
传统的Agent
客户端如果对Zookeeper的一个数据节点注册Watcher监听，那么该数据节点的内容或是其子节点列表发生变更时，Zookeeper服务器就会向订阅的客户端发送变更通知。
对在Zookeeper上创建的临时节点，一旦客户端与服务器之间的会话失效，那么该临时节点也就被自动清除。
特性
收集分布在不同机器上的系统日志
核心工作
整个日志系统会把所有需要收集的日志机器（日志源机器）分为多个组别，每个组别对应一个收集器，其实就是一个后台机器（收集器机器），用于收集日志
架构设计
变化中的日志源机器
变化中的收集器机器
如何快速、合理、动态的为每一个收集器分配配对应的日志源机器。
在Zookeeper上创建一个节点作为收集器的根节点，每个收集器机器在启动的时候，都会在收集器节点下创建自己的节点。
注册收集器机器
待所有收集器机器都创建好自己对应的节点后，系统根据收集器节点下子节点的个数，将所有日志源机器分成对应的若干组，然后将分组后的机器列表分别写到这些收集器机器创建的子节点上去。
任务分发
每个收集器机器在创建完自己的专属节点后，还需要在对应的子节点上创建一个状态子节点，每个收集器都需要定期向该节点写入自己的状态信息。日志系统根据该状态子节点的最后更新时间来判断对应的收集器机器是否存活。
状态汇报
全局动态分配
局部动态分配
动态分配
使用持久节点来标识每一个收集器机器，同时在这个持久节点下面分别创建状态节点来表征每一个收集器机器的状态。
应考虑放弃监听设置，而是采用日志系统主动轮询收集器节点的策略。以节省网卡流量，缺点是有一定的延时。
日志系统节点监听
注意事项
应用的实现
分布式日志收集系统
虚拟主机提供商对集群机器的监控。
如何快速的统计出当前生产环境一共有多少台机器
如何快速的获取到机器上/下线的情况
如何实时监控集群中每台主机的运行时状态
机器上/下线
机器监控
在线云主机管理
Zookeeper
实现方式
集群管理
Master选举
通过Zookeeper上的数据节点来表示一个锁，例如/exclusive_lock/lock节点就可以被定义为一个锁
定义锁
所有客户端会试图通过调用create()接口创建临时节点，创建成功代表成功获取锁。创建失败的客户端则会在节点上注册一个子节点变更的Watcher监听，以便实时监听到lock节点的变更情况。
获取锁
当前获取锁的客户端机器发生宕机，那么Zookeeper上的这个临时节点就会被移除
正常执行完业务逻辑后，客户端就会主动将自己创建的临时节点删除
释放锁
排他锁（写锁、独占锁）
加上排他锁后，数据对象只对一个事务可见，而加上共享锁后，数据对所有事务可见。
与排他锁的区别
通过Zookeeper上的数据节点来表示一个锁，是一个类似于”/shared_lock/[Hostname]-请求类型-序号“的临时顺序节点，例如/shared_lock/192.168.0.1-R-000000000001
所有客户端都会到/shared_lock这个节点下面创建一个临时顺序节点，如果当前是读请求，那么就创建例如/shared_lock/192.168.0.1-R-000000000001的节点；如果是写请求，那么就创建例如/shared_lock/192.168.0.1-W-000000000001的节点。
创建完节点后，获取/shared_lock节点下的所有子节点，并对该节点注册子节点变更的Watcher监听。
如果没有比自己序号小的子节点，或者是所有比自己序号小的子节点都是读请求，那么表明自己已经成功获取到了共享做，同时开始执行读取逻辑。
如果比自己序号小的子节点中有写请求，那么就需要进入等待。
读请求
如果自己不是序号最小的子节点，那么就需要进入等待
写请求
确定自己的节点序号在所有子节点中的顺序
接收到Watcher通知后，重复步骤
判断读写顺序
同排他锁的释放。
共享做（读锁）
如果同一时间有多个和节点对应的客户端完成事务或是事务中断引起节点消失，Zookeeper服务器就会在短时间内向其余客户端发送大量的事件通知。
客户端调用create()方法创建一个类似于”/shared_lock/[Hostname]-请求类型-序号“的临时顺序节点
客户端调用gerChildren()接口来获取所有已经创建的子节点列表，注意，这里不注册任何watcher。
向比自己序号小的最后一个写请求节点注册Watcher监听。
相比自己序号小的最后一个节点注册Watcher监听。
如果无法获取共享锁，那么就调用exist()来对比自己小的哪个节点注册Watcher。
等待Watcher通知，继续进入步骤
改进
羊群效应
分布式锁
所有客户端都会到”/queue_fifo“这个节点下面创建一个临时顺序节点。
设计思路
调用getChildren()接口来获取/queue_fifo节点下的所有子节点，即获取队列中所有的元素
如果自己不是序号最小的子节点，那么就需要进去等待，同时向比自己序号小的最后一个节点注册Watcher监听。
执行顺序
FIFO：先进先出
在分布式系统中，”屏障“特指系统之间的一个协调条件，规定了一个队列的元素必须都聚集后才能统一进行安排，否则一直等待。
最终的合并运算需要基于很多并行极端的子结果来进行。
开始时，/queue_barrier节点是一个已经存在的默认节点，并且将其节点的数据内容赋值为一个数字n来代表Barrier值，表示只有当/queue_barrier节点下的子节点数量达到10后，才会打开Barrier。
之后，所有的客户端都会到/queue_barrier节点下创建一个临时节点。
通过调用getData()接口获取/queue_barrier节点的数据内容：n
通过调用getChildren()接口获取/queue_barrier节点下的所有子节点，即获取队列中德所有元素，同时注册对子节点列表变更的Watcher监听。
统计子节点个数
如果子节点个数还不足n个，那么就需要进入等待
Barrier：分布式屏障
分布式队列
典型应用场景及实现
具体参考书本
Hadoop
HBase
Kafka是一个吞吐量极高的分布式消息系统，其整体设计是典型的分布式与订阅模式系统。在Kafka集群中，没有”中心主节点“的概念，集群中所有的服务器都是对等的。
主要用于实现低延迟的发送和收集大量的事件和日志数据——这些数据通常都是活跃的数据。
应用
即Producer，是消息产生的源头，负责生成消息并发送到Kafka服务器上。
消息生产者
即Consumer，是消息的使用方，负责消费Kafka服务器上的消息。
消息消费者
生产者发送消息到指定Topic下
消费者从这个Topic下消费消息
即Topic，由用户定义并配置在Kafka服务端，用于建立生产者和消费者之间的订阅关系
主题
即Partition，一个Topic下会分为多个分区。
消息分区
即Kafka的服务器，用于存储消息，在消息中间件中通常被称为Broker。
Broker
即Group，用于归组同类消费者。在Kafka中，多个消费者可以共同消费一个Topic下的消息，每个消费者消费其中的部分消息，这些消费者就组成了一个分组，拥有同一个分组名称，通常也被称为消费者集群。
消费者分组
消息存储在Kafka的Broker上，消费者拉去消息数据的过程中需要知道消息在文件中的偏移量，这个偏移量就是所谓的Offset。
Offset
术语介绍
每个Broker服务器在启动时，都会到Zookeeper上进行注册，即到Broker节点下创建属于自己的节点，其节点路径为/broker/ids/[0...N]。
Broker创建的节点是一个临时节点。
Broker注册
Topic注册
四层负载均衡
使用Zookeeper进行负载均衡
生产者负载均衡
消费者负载均衡
Kafka
Zookeeper在大型分布式系统中的应用
案例一 消息中间件：Metamorphosis
案例二 RPC服务框架：Dubbo
案例三 基于MySQL Binlog的增量订阅与消费
案例四 分布式数据库同步系统：Otter
案例五 轻量级分布式通用搜索平台： 终搜
案例六 实时计算引擎： JStorm
Zookeeper在阿里巴巴的实践与应用
Zookeeper的典型应用场景
数据模型
节点特性
版本——保证分布式数据原子性操作
Watcher——数据变更的通知
ACL——保障数据的安全
Jute介绍
使用Jute进行序列化
深入Jute
通信协议
序列化与协议
一次会话的创建过程
服务器地址列表
ClientCnxn：网络I/O
会话状态
会话创建
会话管理
会话清理
重连
单机版服务器启动
集群版服务器启动
服务器启动
Leader选举概述
Leader选举的算法分析
Leader选举的实现细节
Leader选举
集群间消息通信
服务器个角色介绍
会话创建请求
SetData请求
事务请求转发
GetData请求
请求处理
内存数据
事务日志
snapshot——数据快照
初始化
数据同步
数据与存储
Zookeeper技术内幕
基本配置
高级配置
配置详解
四字命令
开启远程JMX
通过JConsole链接Zookeeper
JMX
实时监控
数据统计
监控
集群组成
容灾
扩容与缩容
创建一个高可用的集群
数据与日志管理
Too many connections
磁盘管理
日常运维
Zookeeper运维
分布式锁的目的是允许它的客户端进程同步彼此的操作，并对当前所处环境的基本状态信息达成一致
0 条评论
回复 删除
下一页
