本文共 3690 字,大约阅读时间需要 12 分钟。
**zookeeper主要是对分布式系统提供服务的,ES集群,分布式文件系统,mysql主从复制,主要不是工作同一节点的都称为分布式系统
分布式系统:是一个硬件或软件组件分布在网络中的不同的计算机之上,彼此间仅通过消息传递进行通信和协作的系统。 **特征: 分布性、对等性、并发性(同时向外提供服务)、缺乏全局时钟、故障必然会发生(网络不是一直靠谱的)
面临的典型问题: 通信异常、网络分区、三态(成功、失败、超时)、节点故障CAP:2000,7, Eric Brewer, ACM PODC (会议), 2002, MIT (麻省理工学院), Seth Gilbert, Nancy Lynch; 任何分布式系统只能完成CAP中的两个 P:分区容错性 CP:一致性,容错性 AP:可用性,容错性 保证可用,数据不一致,这样是没有意义的
BASE: BA:基本可用,(分布式系统出现故障时,允许损失部分可用性) S:软状态 (允许系统存在中间状态,并认为该状态,不会影响系统的整体可用性) E:最终一致性(系统中的所有副本同步以后,最终可以达到一致的状态) 因果一致性、会话一致性(在一个会话中读的数据始终是一致的)、单调读一致性、单调写一致性、读己之所写一致性(自己写的数据自己始终可以读到,前后需是一致的,只保证一个人,在 自己写的时候,读的是一致的); 保证分布式系统的一致性多种协议: 2PC:2 Phase-Commit 2端式提交,整个数据留存袭来要分2步进行, 1.提交准备(请求和确认) 请求和执行 3PC:3 Phase-Commit 3端式提交, CanCommit可提交(判断集群中 哪些节点可以提交)->PreCommit预提交–>DoCommit Paxos 帕客所思协议(古希腊,天马paxos):Leslie Lamport,1990年提出,唯一公认在解决分布式方面,一致性问题,最有效的方法之一 但是现在有更简单的,能够为分布式系统提供服务协调和注册管理,2个方案,zookeeper,etcd,docker就用了etcd分布式中的各节点 zookeeper并不是paxos实现,而是Paxos 之上对整个协议变更,把实现思路做了变更。因为paxos真正用计算机算法实现非常难,2PC:2 Phase-Commit 2端式提交,整个数据留存袭来要分2步进行, 1.提交准备(请求和确认) 请求和执行 有个问题,第一个发出请求的会被阻塞(木桶理论的,短板效应),最后请求完成了,才算全部完成,没有全部完成,是不足以请求下一阶段的
Google Chubby,分布式锁服务,GFS(google file system,hdfs hadoopfs)/BigTable(HBASE山寨了BIG table)都用到了chubby,(高可用分布式锁服务) 作用: 分面式协作、元数据存储、Master选举;
有一个公共的服务,多个节点运行的进程进行协调,节点之间要协调,节点之间需要发送消息的,但如果中间有节点挂了,就没有办法进行协调了, 因此这三个节点进行协调就不在彼此之间进行通信了,都与公共的存储进行通信,他们都能把自己的状态按周期同步到公共存储,每一个节点保证让其他节点看到相关信息,可以在公共存储保存一个数据节点,一旦这个服务器挂了,这个链接被终止时,存储随之被移除,其他节点 获取不到这个节点相关数据时,就认为这个节点不存在了 这个服务器自己还支持主节点选取功能,公共存储服务,也需要高可用,一般是基数,三个以上节点来保证自己挂了,其他继续服务山寨chubby就是zookeeper
HDFS/HBase, Zookeeper zookeeper是一个开源的分面式协调服务,由知名互联网公司Yahoo创建,它是Chubby的开源实现;换句话讲,zk是一个典型的分布式数据一致性解决方案,分布式应用程序可以基于它实现数据的发布/订阅、负载均衡、名称服务、分布式协调/通知、集群管理、Master选举、分布式锁和分布式队列;
HDFS+mapreduce=hadoop hbase山寨big table 在hdfs上提供列式数据服务的
puppet在同步更新是一个个来的,zk可以通知所有订阅者
基本概念: 集群角色:Leader, Follower 评, Observer 观察员(zk至少三个节点,是个集群,一般是2个follower,一个leader) Leader:选举产生,提供读/写服务; Follower:参与选举,可被选举(leader挂了,可以当master),读服务; Observer:参与选举,不可被选举(无法成为master),提供读服务;
会话:ZK中,客户端<–>服务端,建立TCP长连接,直到节点不参与分布式系统; sessionTimeout(网络问题导致链接不上可以设置) zk数据管理模型是倒置树状的管理结构,一个分布式应用可以注册一个子节点,在这个节点,每个主机都可以有一个叶子节点,用来保存当前主机的信息 ,在线就存在,不在线,就不存在, 主机连接到zk后,会话信息会一直存在,主机宕机,这个会话信息才会关掉 分布式要每个节点都能协调 需要每个节点和zk建立持久会话,通过这个会话,不断更新自己在zk当中,关于自己节点状态的相关信息,比如每隔三秒,其他节点正是看到这个节点的文件还在,就认为这个节点还活着数据节点(ZNode):即zk数据模型中的数据单元;zk的数据都存储于内存中,数据模型为树状结构(ZNode Tree);每个ZNode都会保存自己的数据于内存中; 节点有两类 持久节点:仅显式删除才消失 临时节点:会话中止即自动消失(zk客户端与zk建立的会话链接)
数据节点有版本
版本(version):ZK会为每个ZNode维护一个称之为Stat的数据结构,记录了当前ZNode的三个数据版本 version:当前版本 cversion:当前znode的子节点的版本 aversion:当前znode的ACL的版本(访问列表) 多个分布式系统可能用一个zk,所以zk需要把他们隔离开来 ACL:ZK使用ACL机制进行权限控制 CREATE, READ,WRITE,DELETE,ADMIN 事件监听器(Watcher): ZK上,由用户指定的触发机制,在某些事件产生时,ZK能够将通知给相关的客户端; 节点向zk注册监听器,一旦数据发生变化,zk可以立即将变化通知给注册监听器的相关节点,然后大家过来选新的村长 所有分布式节点都可以基于zk来完成选举,协调,发布订阅,zk实现,是靠zk的专门协议 ZAB协议:Zookeeper Atomic Broadcast,ZK原子广播协议;zab协议完成,各节点参者间的leader选举 保证leader崩溃时可以重新选举出新的leader,还要保证数据完整性的, 支持崩溃恢复机制, 所有事物请求由leader处理,其他服务器,follow,obsrv,只提供读 ZAB协议中存在三种状态: (1) Looking, (2) Following, (3) Leading当用户发出写请求,是发给zk 的leader,leader收到信息后,把这个修改的请求转为一个提案,向zk的集群进行广播,修改数据是否同意,下面的follower举手同意,过半数的时候,把数据更新到源数据
zk的所有事物,都要由leader来接受和处理,客户端无论连接在哪个zk节点上,如果不是一个leader的话,应该把这些信息转给leader,leader会把每一个客户端请求转为一个提案向队员的当前集群中进行广播,在收到过半数的follower投票的时候,将会确认此操作,并将这个结果广播给其他的follower而后完成提交
ZAB协议中存在三种状态: (1) Looking, 每一个zk节点刚启动的时候,要找leader,(选举过程,looking过程) (2) Following,已经有leader (3) Leading leader节点的状态 每一个节点都有可能在三个节点进行转换,zk启动时,所有节点都是默认Looking状态,然后整个集群会尝试选举一个leader,被选举的切换为 leading,其他的切换为following 选出leader以后,zab协议将进入原子广播阶段,leader数据需要打包给follow节点,leader节点和follower节点,必须使用心跳检测机制,去检测每一个follower是不是,处于正常状态的,这种检测机制,相当于follower不断 在集群中某个数据节点更新数据版本,如果一直更新,leader就认为 他们是正常的,如果超过时间,一个follower没有在更新自己的指定信息,就认为失去连接。如果失去的是leader,大家都转换为looking,就提案自己当leader 选举,发布,同步,广播等阶段
转载地址:http://kjkgn.baihongyu.com/