分布式(Zookeeper)基本概念

ZooKeeper是一个分布式的,开放源码的分布式应用程序协调服务,是Google的Chubby一个开源的实现,是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件,提供的功能包括:配置维护、域名服务、分布式同步、组服务等。
ZooKeeper的目标就是封装好复杂易出错的关键服务,将简单易用的接口和性能高效、功能稳定的系统提供给用户。
ZooKeeper包含一个简单的原语集,提供Java和C的接口。
ZooKeeper代码版本中,提供了分布式独享锁、选举、队列的接口,代码在zookeeper-3.4.3/src/recipes。其中分布锁和队列有Java和C两个版本,选举只有Java版本。

更多精彩内容请看 web前端中文站
www.lisa33xiaoq.net 可按Ctrl + D 进行收藏

分布式(Zookeeper)基本概念

分布式基本概念

分布式架构:在集中式的系统环境中,可以简单通过事务(ACID)保证数据的一致性;而在分布式系统环境中,由于缺少全局时钟、故障无法避免等痛点,过去的方式不在适用,而适用新的CAP定理和BASE理论。
CAP定理
Consistency一致性:指数据在多个副本间是否能保持一致的特性。针对一个数据项的更新,所有用户都可以读取到最新的值,则系统被认为是强一致的。
Availablity可用性:指系统一直处于可用状态,对于每一个请求都能在单位时间内返回结果。
Partition tolerance分区容错性:分布式系统在遇到任何网络故障时,仍然可以对外提供满足一致性和可用性的服务,除非整个网络都出现故障。
该原理指出,一个分布式系统无法同时满足这三个基本需求,因此需要作出合理的选择。由于P是分布式系统的基础,那么核心就是平衡A和C,最常见的就是BASE理论。
BASE:其核心思想是即使无法做到强一致性,但每个应用都可以根据自身业务特点,
Basically Available基本可用:指分布式系统出现不可知故障时,允许损失部分可用性,比如响应时间上的损失、功能上的损失(服务降级)。
Soft state软状态:允许系统中数据存在中间状态,即允许不同节点的数据副本之间进行数据同步时存在延时。
Eventually consistent最终一致性:需要保证最终数据保持一致,而不需要实时保证系统的强一致性。在实践中,最终一致性存在5中变种,因果一致性,读自己之所写,会话一致性,单调读一致性和单调写一致性。比如关系型数据库,常通过同步或一部的方式实现主备数据复制,其实主备之间就存在数据不一致,但其通过多次重试或认为数据修订等方式保证了数据最终一致性,算是一个经典案例。
一致性协议:提到一致性协议,最基础的就是2PC(Two-Phase Commit protocol)两阶段提交协议,绝大多数的关系型数据库都是采用的2PC来完成分布式事务处理的。
2PC的流程:提交事务阶段,包括事务询问、执行事务、各参与者向协调者反馈事务询问的响应等步骤;执行事务阶段,包含两种情况,成功时执行事务提交,包括发送提交请求、事务提交、反馈事务提交结果、完成事务等步骤,而失败时会中断事务,包括发送回滚请求、事务回滚、反馈事务回滚结果、中断事务等步骤。其优点是原理简单、实现方便,但存在同步阻塞、单点问题、脑裂等痛点。

分布式(Zookeeper)基本概念

3PC:其实就是2PC的改进版,将提交事务请求阶段分成了CanCommit,PreCommit阶段,最后的DoCommit没有变化。
Paxos:是Lamport与1990提出的基于消息传递且有高度容错特性的一致性算法,其成功的解决了“拜占庭将军”问题(这个问题在区块链中也涉及)。其包括三种参与角色,分别是Proposer、Acceptor和Learner,这儿不展开介绍其基于数据归纳法的证明(个人也没打算深入研究),但一个重点的观念就是,2PC是基于所有参与者都同意的情况,而Paxos是基于读书参与者同意的情况>50%,google的chubby就是基于该算法的实现。

【注:本文源自网络文章资源,由站长整理发布】

0
如无特殊说明,文章均为原作者原创,转载请注明出处

该文章由 发布

这货来去如风,什么鬼都没留下!!!
发表我的评论

Hi,请填写昵称和邮箱!

取消评论
代码 贴图 加粗 链接 删除线 签到