精华内容
参与话题
问答
  • 分布式系统理论学习总结

    千次阅读 2018-07-04 17:53:11
    分布式理论 CAP CAP定理讲的是三个性。consistency数据一致性,availability可用性,partition tolerance分区容错性。 三者只能选其中两者。为什么呢,看看这三个性质意味着什么吧。 首先看看分区容错性,分区...

    ##本文基于之前的分布式系统理论系列文章总结而成,主要是理论部分,详细内容可见我的专栏:分布式系统理论与实践

    ##https://blog.csdn.net/column/details/24090.html

    本文主要是按照我自己的理解以及参考之前文章综合而成的,其中可能会有一些错误,还请见谅,也请指出。

    分布式理论

    CAP

    CAP定理讲的是三个性。consistency数据一致性,availability可用性,partition tolerance分区容错性。

    三者只能选其中两者。为什么呢,看看这三个性质意味着什么吧。

    首先看看分区容错性,分区容错性指的是网络出现分区(丢包,断网,超时等情况都属于网络分区)时,整个服务仍然可用。

    由于网络分区在实际环境下一定存在,所以必须首先被考虑。于是分区容错性是必须要保证的,否则一旦出现分区服务就不可用,那就没办法弄了。

    所以实际上是2选1的问题。在可用性和一致性中做出选择。

    在一个分布式环境下,多个节点一起对外提供服务,如果要保证可用性,那么一台机器宕机了仍然有其他机器能提供服务。
    但是宕机的机器重启以后就会发现数据和其他机器存在不一致,那么一致性就无法得到保证。

    如果保证一致性,如果有机器宕机,那么其他节点就不能工作了,否则一定会产生数据不一致。

    BASE

    在这么严苛的规定下,CAP一般很难实现一个健壮的系统。于是提出了BASE来削弱这些要求。

    BASE是基本可用basically available,soft state软状态,eventually consistent最终一致性。

    基本可用就是允许服务在某些时候降级,比如淘宝在高峰时期会关闭退货等服务。

    软状态就是允许数据出现中间状态,比如支付宝提交转账以后并不是立刻到账,中间经过了多次消息传递和转发。

    最终一致性就是指数据最终要是一致的,比如多个节点的数据需要定期同步,支付宝转账最终一定会到账。

    分布式系统关键词

    时钟,时间,事件顺序

    分布式系统的一个问题在与缺少全局时钟,所以大家没有一个统一的时间,就很难用时间去确定各个节点事件的发生顺序,为了保证事件的顺序执行,

    Lamport timestamps

    Leslie Lamport 在1978年提出逻辑时钟的概念,并描述了一种逻辑时钟的表示方法,这个方法被称为Lamport时间戳(Lamport timestamps)[3]。

    [外链图片转存失败(img-J9mY3bqO-1565108332493)(https://images2015.cnblogs.com/blog/116770/201605/116770-20160501174922566-1686627384.png)]

    分布式系统中按是否存在节点交互可分为三类事件,一类发生于节点内部,二是发送事件,三是接收事件。Lamport时间戳原理如下:

    每个事件对应一个Lamport时间戳,初始值为0
    如果事件在节点内发生,时间戳加1
    如果事件属于发送事件,时间戳加1并在消息中带上该时间戳
    如果事件属于接收事件,时间戳 = Max(本地时间戳,消息中的时间戳) + 1
    

    这样的话,节点内的事件有序,发送事件有序,接收事件一定在发送事件以后发生。再加上人为的一些规定,因此根据时间戳可以确定一个全序排列。

    Vector clock

    Lamport时间戳帮助我们得到事件顺序关系,但还有一种顺序关系不能用Lamport时间戳很好地表示出来,那就是同时发生关系(concurrent)[4]。
    Vector clock是在Lamport时间戳基础上演进的另一种逻辑时钟方法,它通过vector结构不但记录本节点的Lamport时间戳,同时也记录了其他节点的Lamport时间戳[5][6]。

    [外链图片转存失败(img-fBb0fp1Z-1565108332495)(https://images2015.cnblogs.com/blog/116770/201605/116770-20160502134654404-1109556515.png)]

    如果 Tb[Q] > Ta[Q] 并且 Tb[P] < Ta[P],则认为a、b同时发生,记作 a <-> b。例如图2中节点B上的第4个事件 (A:2,B:4,C:1) 与节点C上的第2个事件 (B:3,C:2) 没有因果关系、属于同时发生事件。

    因为B4 > B3并且 C1<C2,说明两者之间没有顺序关系,否则不会出现一大一小,因此他们是同时发生的。

    Version vector

    基于Vector clock我们可以获得任意两个事件的顺序关系,结果或为先后顺序或为同时发生,识别事件顺序在工程实践中有很重要的引申应用,最常见的应用是发现数据冲突(detect conflict)。

    分布式系统中数据一般存在多个副本(replication),多个副本可能被同时更新,这会引起副本间数据不一致[7],Version vector的实现与Vector clock非常类似[8],目的用于发现数据冲突[9]。

    当两个写入数据事件同时发生则发生了冲突,于是通过某些方法解决数据冲突。

    Vector clock只用于发现数据冲突,不能解决数据冲突。如何解决数据冲突因场景而异,具体方法有以最后更新为准(last write win),或将冲突的数据交给client由client端决定如何处理,或通过quorum决议事先避免数据冲突的情况发生[11]。

    选主,租约,多数派

    选举(election)是分布式系统实践中常见的问题,通过打破节点间的对等关系,选得的leader(或叫master、coordinator)有助于实现事务原子性、提升决议效率。

    多数派(quorum)的思路帮助我们在网络分化的情况下达成决议一致性,在leader选举的场景下帮助我们选出唯一leader。

    租约(lease)在一定期限内给予节点特定权利,也可以用于实现leader选举。

    选举(electioin)

    一致性问题(consistency)是独立的节点间如何达成决议的问题,选出大家都认可的leader本质上也是一致性问题,因而如何应对宕机恢复、网络分化等在leader选举中也需要考量。

    在一致性算法Paxos、ZAB[2]、Raft[3]中,为提升决议效率均有节点充当leader的角色。

    ZAB、Raft中描述了具体的leader选举实现,与Bully算法类似ZAB中使用zxid标识节点,具有最大zxid的节点表示其所具备的事务(transaction)最新、被选为leader。

    多数派(quorum)

    在网络分化的场景下以上Bully算法会遇到一个问题,被分隔的节点都认为自己具有最大的序号、将产生多个leader,这时候就需要引入多数派(quorum)[4]。多数派的思路在分布式系统中很常见,其确保网络分化情况下决议唯一。

    租约(lease)

    选举中很重要的一个问题,以上尚未提到:怎么判断leader不可用、什么时候应该发起重新选举?

    最先可能想到会通过心跳(heart beat)判别leader状态是否正常,但在网络拥塞或瞬断的情况下,这容易导致出现双主。

    租约(lease)是解决该问题的常用方法,其最初提出时用于解决分布式缓存一致性问题[6],后面在分布式锁[7]等很多方面都有应用。

    (a). 节点0、1、2在Z上注册自己,Z根据一定的规则(例如先到先得)颁发租约给节点,该租约同时对应一个有效时长;这里假设节点0获得租约、成为leader
    
    (b). leader宕机时,只有租约到期(timeout)后才重新发起选举,这里节点1获得租约、成为leader
    

    租约机制确保了一个时刻最多只有一个leader,避免只使用心跳机制产生双主的问题。在实践应用中,zookeeper、ectd可用于租约颁发。

    一致性,2pc和3pc

    一致性(consensus)

    何为一致性问题?简单而言,一致性问题就是相互独立的节点之间如何达成一项决议的问题。分布式系统中,进行数据库事务提交(commit transaction)、Leader选举、序列号生成等都会遇到一致性问题。

    为了保证执行的一致性,可以使用2pc两段式提交和3pc三段式提交。

    2PC

    2PC(tow phase commit)两阶段提交[5]顾名思义它分成两个阶段,先由一方进行提议(propose)并收集其他节点的反馈(vote),再根据反馈决定提交(commit)或中止(abort)事务。我们将提议的节点称为协调者(coordinator),其他参与决议节点称为参与者(participants, 或cohorts):

    举个例子,首先用户想要执行一个事务,于是提交给leader,leader先让各个节点执行该事务。

    我们要知道,事务是通过日志来实现的。各个节点使用redo日志进行重做,使用undo日志进行回滚。

    于是各个节点执行事务,并把执行结果是否成功返回给leader,当leader收到全部确认消息后,发送消息让所有节点commit。如果有节点执行失败,则leader要求所有节点回滚。

    2pc可能出现的一些问题是:

    1 leader必须等待所有节点结果,如果有节点宕机或超时,则拒绝该事务,并向节点发送回滚的信息。

    2 如果leader宕机,则一般配置watcherdog自动切换成备用leader,然后进行下一次的请求提交。

    3这两种情况单独发生时都没有关系,有对应的措施可以进行回滚,但是如果当一个节点宕机时leader正在等待所有节点消息,其他节点也在等待leader最后的消息。

    此时leader也不幸宕机,切换之后leader并不知道一个节点宕机了,这样的话其他的节点也会被阻塞住导致无法回滚。

    3PC
    [外链图片转存失败(img-iJHwccXm-1565108332495)(https://images2015.cnblogs.com/blog/116770/201603/116770-20160314002734304-489496391.png)]
    coordinator接收完participant的反馈(vote)之后,进入阶段2,给各个participant发送准备提交(prepare to commit)指令

    。participant接到准备提交指令后可以锁资源,但要求相关操作必须可回滚。coordinator接收完确认(ACK)后进入阶段3、进行commit/abort,3PC的阶段3与2PC的阶段2无异。协调者备份(coordinator watchdog)、状态记录(logging)同样应用在3PC。

    participant如果在不同阶段宕机,我们来看看3PC如何应对:

    阶段1: coordinator或watchdog未收到宕机participant的vote,直接中止事务;宕机的participant恢复后,读取logging发现未发出赞成vote,自行中止该次事务

    阶段2: coordinator未收到宕机participant的precommit ACK,但因为之前已经收到了宕机participant的赞成反馈(不然也不会进入到阶段2),coordinator进行commit;watchdog可以通过问询其他participant获得这些信息,过程同理;宕机的participant恢复后发现收到precommit或已经发出赞成vote,则自行commit该次事务

    阶段3: 即便coordinator或watchdog未收到宕机participant的commit ACK,也结束该次事务;宕机的participant恢复后发现收到commit或者precommit,也将自行commit该次事务
    因为有了准备提交(prepare to
    commit)阶段,3PC的事务处理延时也增加了1个RTT,变为3个RTT(propose+precommit+commit),但是它防止participant宕机后整个系统进入阻塞态,增强了系统的可用性,对一些现实业务场景是非常值得的。

    总结一下就是:阶段一leader要求节点准备,节点返回ack或者fail。

    如果节点都是ack,leader返回ack进入阶段二。
    (如果fail则回滚,因为节点没有接收到ack,所以最终都会回滚)

    阶段二时节点执行事务并且发送结果给leader,leader返回ack或者fail。由于阶段二的节点已经有了一个确定的状态ack,如果leader超时或宕机不返回,成功执行节点也会进行commit操作,这样即使有节点宕机也不会影响到其他节点。

    一致性算法paxos

    Basic Paxos

    何为一致性问题?简单而言,一致性问题是在节点宕机、消息无序等场景可能出现的情况下,相互独立的节点之间如何达成决议的问题,作为解决一致性问题的协议,Paxos的核心是节点间如何确定并只确定一个值(value)。

    和2PC类似,Paxos先把节点分成两类,发起提议(proposal)的一方为proposer,参与决议的一方为acceptor。假如只有一个proposer发起提议,并且节点不宕机、消息不丢包,那么acceptor做到以下这点就可以确定一个值。

    proposer发出提议,acceptor根据提议的id和值来决定是否接收提议,接受提议则替换为自己的提议,并且返回之前id最大的提议,当超过一半节点提议该值时,则该值被确定,这样既保证了时序,也保证了多数派。

    Multi Paxos

    通过以上步骤分布式系统已经能确定一个值,“只确定一个值有什么用?这可解决不了我面临的问题。” 你心中可能有这样的疑问。

    其实不断地进行“确定一个值”的过程、再为每个过程编上序号,就能得到具有全序关系(total order)的系列值,进而能应用在数据库副本存储等很多场景。我们把单次“确定一个值”的过程称为实例(instance),它由proposer/acceptor/learner组成。

    Fast Paxos

    在Multi Paxos中,proposer -> leader -> acceptor -> learner,从提议到完成决议共经过3次通信,能不能减少通信步骤?

    对Multi Paxos phase2a,如果可以自由提议value,则可以让proposer直接发起提议、leader退出通信过程,变为proposer -> acceptor -> learner,这就是Fast Paxos[2]的由来。

    多次paxos的确定值使用可以让多个proposer,acceptor一起运作。多个proposer提出提议,acceptor保留最大提议比返回之前提议,proposer当提议数量满足多数派则取出最大值向acceptor提议,于是过半数的acceptor比较提议后可以接受该提议,于是最终leader将提议写入acceptor,而acceptor再写入对应的learner。

    raft和zab

    Zab

    Zab[5][6]的全称是Zookeeper atomic broadcast protocol,是Zookeeper内部用到的一致性协议。相比Paxos,Zab最大的特点是保证强一致性(strong consistency,或叫线性一致性linearizable consistency)。

    和Raft一样,Zab要求唯一Leader参与决议,Zab可以分解成discovery、sync、broadcast三个阶段:

    [外链图片转存失败(img-NGmuIEi7-1565108332497)(https://images2015.cnblogs.com/blog/116770/201610/116770-20161025133734734-658183229.jpg)]

    discovery: 选举产生PL(prospective leader),PL收集Follower epoch(cepoch),根据Follower的反馈PL产生newepoch(每次选举产生新Leader的同时产生新epoch,类似Raft的term)

    sync: PL补齐相比Follower多数派缺失的状态、之后各Follower再补齐相比PL缺失的状态,PL和Follower完成状态同步后PL变为正式Leader(established leader)

    broadcast: Leader处理Client的写操作,并将状态变更广播至Follower,Follower多数派通过之后Leader发起将状态变更落地(deliver/commit)

    Raft:

    单个 Candidate 的竞选

    有三种节点:Follower、Candidate 和 Leader。Leader 会周期性的发送心跳包给 Follower。每个 Follower 都设置了一个随机的竞选超时时间,一般为 150ms~300ms,如果在这个时间内没有收到 Leader 的心跳包,就会变成 Candidate,进入竞选阶段。

    • 下图表示一个分布式系统的最初阶段,此时只有 Follower,没有 Leader。Follower A 等待一个随机的竞选超时时间之后,没收到 Leader 发来的心跳包,因此进入竞选阶段。

    [外链图片转存失败(img-WZSpcVzx-1565108332497)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/111521118015898.gif)]

    • 此时 A 发送投票请求给其它所有节点。

    [外链图片转存失败(img-vfOo5ycb-1565108332498)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/111521118445538.gif)]

    • 其它节点会对请求进行回复,如果超过一半的节点回复了,那么该 Candidate 就会变成 Leader。

    [外链图片转存失败(img-xpjQk551-1565108332498)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/111521118483039.gif)]

    • 之后 Leader 会周期性地发送心跳包给 Follower,Follower 接收到心跳包,会重新开始计时。

    [外链图片转存失败(img-Gps4mrHb-1565108332499)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/111521118640738.gif)]

    多个 Candidate 竞选

    • 如果有多个 Follower 成为 Candidate,并且所获得票数相同,那么就需要重新开始投票,例如下图中 Candidate B 和 Candidate D 都获得两票,因此需要重新开始投票。

    [外链图片转存失败(img-K8gqUxWR-1565108332500)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/111521119203347.gif)]

    • 当重新开始投票时,由于每个节点设置的随机竞选超时时间不同,因此能下一次再次出现多个 Candidate 并获得同样票数的概率很低。

    [外链图片转存失败(img-VDSYSg3w-1565108332501)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/111521119368714.gif)]

    日志复制

    • 来自客户端的修改都会被传入 Leader。注意该修改还未被提交,只是写入日志中。

    [外链图片转存失败(img-JLtIsxVa-1565108332501)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/7.gif)]

    • Leader 会把修改复制到所有 Follower。

    [外链图片转存失败(img-1lGaEsEA-1565108332501)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/9.gif)]

    • Leader 会等待大多数的 Follower 也进行了修改,然后才将修改提交。

    [外链图片转存失败(img-vCpD06JE-1565108332502)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/10.gif)]

    • 此时 Leader 会通知的所有 Follower 让它们也提交修改,此时所有节点的值达成一致。

    [外链图片转存失败(img-4SxE5Fps-1565108332502)(https://github.com/CyC2018/Interview-Notebook/raw/master/pics/11.gif)]

    zookeeper

    zookeeper在分布式系统中作为协调员的角色,可应用于Leader选举、分布式锁、配置管理等服务的实现。以下我们从zookeeper供的API、应用场景和监控三方面学习和了解zookeeper(以下简称ZK)。

    ZK API

    ZK以Unix文件系统树结构的形式管理存储的数据,图示如下:

    其中每个树节点被称为znode,每个znode类似一个文件,包含文件元信息(meta data)和数据。

    以下我们用server表示ZK服务的提供方,client表示ZK服务的使用方,当client连接ZK时,相应创建session会话信息。

    有两种类型的znode:

    Regular: 该类型znode只能由client端显式创建或删除

    Ephemeral: client端可创建或删除该类型znode;当session终止时,ZK亦会删除该类型znode

    znode创建时还可以被打上sequential标志,被打上该标志的znode,将自行加上自增的数字后缀

    ZK提供了以下API,供client操作znode和znode中存储的数据:
    
    create(path, data, flags):创建路径为path的znode,在其中存储data[]数据,flags可设置为Regular或Ephemeral,并可选打上sequential标志。
    
    delete(path, version):删除相应path/version的znode
    
    exists(path,watch):如果存在path对应znode,则返回true;否则返回false,watch标志可设置监听事件
    
    getData(path, watch):返回对应znode的数据和元信息(如version等)
    
    setData(path, data, version):将data[]数据写入对应path/version的znode
    
    getChildren(path, watch):返回指定znode的子节点集合
    

    K应用场景

    基于以上ZK提供的znode和znode数据的操作,可轻松实现Leader选举、分布式锁、配置管理等服务。

    Leader选举

    利用打上sequential标志的Ephemeral,我们可以实现Leader选举。假设需要从三个client中选取Leader,实现过程如下:

    1、各自创建Ephemeral类型的znode,并打上sequential标志:

    [zk: localhost:2181(CONNECTED) 4] ls /master
    [lock-0000000241, lock-0000000243, lock-0000000242]

    2、检查 /master 路径下的所有znode,如果自己创建的znode序号最小,则认为自己是Leader;否则记录序号比自己次小的znode

    3、非Leader在次小序号znode上设置监听事件,并重复执行以上步骤2

    配置管理

    znode可以存储数据,基于这一点,我们可以用ZK实现分布式系统的配置管理,假设有服务A,A扩容设备时需要将相应新增的ip/port同步到全网服务器的A.conf配置,实现过程如下:

    1、A扩容时,相应在ZK上新增znode,该znode数据形式如下:

    [zk: localhost:2181(CONNECTED) 30] get /A/blk-0000340369
    {“svr_info”: [{“ip”: “1.1.1.1.”, “port”: “11000”}]}
    cZxid = 0x2ffdeda3be
    ……

    2、全网机器监听 /A,当该znode下有新节点加入时,调用相应处理函数,将服务A的新增ip/port加入A.conf

    3、完成步骤2后,继续设置对 /A监听

    ZK监控

    ZK自身提供了一些“四字命令”,通过这些四字命令,我们可以获得ZK集群中,某台ZK的角色、znode数、健康状态等信息:

    小结

    zookeeper以目录树的形式管理数据,提供znode监听、数据设置等接口,基于这些接口,我们可以实现Leader选举、配置管理、命名服务等功能。结合四字命令,加上模拟zookeeper client 创建/删除znode,我们可以实现对zookeeper的有效监控。在各种分布式系统中,我们经常可以看到zookeeper的身影。

    微信公众号

    个人公众号:程序员黄小斜

    微信公众号【程序员黄小斜】新生代青年聚集地,程序员成长充电站。作者黄小斜,职业是阿里程序员,身份是斜杠青年,希望和更多的程序员交朋友,一起进步和成长!专注于分享技术、面试、职场等成长干货,这一次,我们一起出发。

    关注公众号后回复“2019”领取我这两年整理的学习资料,涵盖自学编程、求职面试、算法刷题、Java技术学习、计算机基础和考研等8000G资料合集。

    技术公众号:Java技术江湖

    微信公众号【Java技术江湖】一位阿里 Java 工程师的技术小站,专注于 Java 相关技术:SSM、SpringBoot、MySQL、分布式、中间件、集群、Linux、网络、多线程,偶尔讲点Docker、ELK,同时也分享技术干货和学习经验,致力于Java全栈开发!

    关注公众号后回复“PDF”即可领取200+页的《Java工程师面试指南》强烈推荐,几乎涵盖所有Java工程师必知必会的知识点。

    展开全文
  • 分布式理论

    2019-08-20 23:41:47
    分布式-设计诸如:CAP,BASE理论分布式一致性算法:2PC,3PC,Paxos,ZAB以及关于数据的一致性,我们在数据库中有了解过,因为数据库事务的ACID特性的C就代表一致性,这ACIC可以简单的把一致性理解为正确性或者完整性...

    分布式-设计诸如:CAP,BASE理论,分布式一致性算法:2PC,3PC,Paxos,ZAB以及关于数据的一致性,我们在数据库中有了解过,因为数据库事务的ACID特性的C就代表一致性,这ACIC可以简单的把一致性理解为正确性或者完整性,那么数据一致性通常指关联数据之间的逻辑关系是否正确和完整。我们知道,在数据库系统中通常用事务(访问并可能更新数据库中各种数据项的一个程序执行单元)来保证数据的一致性和完整性。那么,我们现在所说的分布式一致性指的是什么呢?为什么会出现一致性的问题?我们必须首先解决这个疑问,才能继续探究各种分布式一致性的理论与相关算法。

    分布式的问题

    我们先来介绍一下,为什么要分布式?随着大型网站的各种高并发访问、海量数据处理等场景越来越多,如何实现网站的高可用、易伸缩、可扩展、安全等目标就显得越来越重要。为了解决这样一系列问题,大型网站的架构也在不断发展。提高大型网站的高可用架构,不得不提的就是分布式。集中式系统用一句话概括就是:一个主机带多个终端。终端没有数据处理能力,仅负责数据的录入和输出。而运算、存储等全部在主机上进行。现在的银行系统,大部分都是这种集中式的系统,此外,在大型企业、科研单位、军队、政府等也有分布。集中式系统,主要流行于上个世纪。集中式系统的最大的特点就是部署结构非常简单,底层一般采用从IBM、HP等厂商购买到的昂贵的大型主机。因此无需考虑如何对服务进行多节点的部署,也就不用考虑各节点之间的分布式协作问题。但是,由于采用单机部署。很可能带来系统大而复杂、难于维护、发生单点故障(单个点发生故障的时候会波及到整个系统或者网络,从而导致整个系统或者网络的瘫痪)、扩展性差等问题。
        对于淘宝,腾讯等亿级用户量以及复杂的业务逻辑,且不说耦合严重,难于维护,单是这么庞大的并发量,集中式机构根本扛不住,所以就得需要进行分布式了,从2009年开始,阿里就启动了去“IOE”计划,其电商系统正式迈入分布式系统时代。分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。可以将不同的业务模块,数据进行水平切分部署。分布式意味着可以采用更多的普通计算机(相对于昂贵的大型机)组成分布式集群对外提供服务。计算机越多,CPU、内存、存储资源等也就越多,能够处理的并发访问量也就越大。

        分布式因为网络的不确定性,节点故障等情况,会带来各种复杂的问题。我们在学习分布式的相关理论时,一定要明确这样一个道理,就是:网络不可靠,网络分区以及节点宕机是常态,另外网络带宽资源是及其珍贵的,我们必须在网络不可靠、分区以及节点宕机的前提下,构建高性能、高可用的分布式系统。

     分布式环境的问题有:


    1. 通信异常:从集中式向分布式演变过程中,必然会引入网络因素,而由于网络本身的不可靠性,因此也引入了额外的问题。分布式系统需要在各个节点之间进行网络通信,因此当网络通信设备故障就会导致无法顺利完成一次网络通信,就算各节点的网络通信正常,但是消息丢失和消息延时也是非常普遍的事情。
    2. 网络分区(脑裂):网络发生异常情况导致分布式系统中部分节点之间的网络延时不断增大,最终导致组成分布式系统的所有节点,只有部分节点能够正常通行,而另一些节点则不能。我们称这种情况叫做网络分区(脑裂),当网络分区出现时,分布式系统会出现多个局部小集群(多个小集群可能又会产生多个master节点),所以分布式系统要求这些小集群要能独立完成原本需要整个分布式系统才能完成的功能,这就对分布式一致性提出了非常大的挑战。
    3. 节点故障:节点宕机是分布式环境中的常态,每个节点都有可能会出现宕机或僵死的情况,并且每天都在发生。
    4. 三态:由于网络不可靠的原因,因此分布式系统的每一次请求,都存在特有的“三态”概念,即:成功,失败与超时。在集中式单机部署中,由于没有网络因素,所以程序的每一次调用都能得到“成功”或者“失败”的响应,但是在分布式系统中,网络不可靠,可能就会出现超时的情况。可能在消息发送时丢失或者在响应过程中丢失,当出现超时情况时,网络通信的发起方是无法确定当前请求是否被成功处理的,所以这也是分布式事务的难点。

    为什么会有分布式数据一致性问题


    在上面,我们介绍了一下分布式和分布式下的一些问题,接下来,我们要讨论,为什么会出现分布式数据一致性问题。因为在分布式系统中,节点宕机是常态,为了高可用性,我们一般会部署多台服务器,势必就会存在数据的复制问题。分布式系统对于数据的复制需求一般来自于以下两个原因:
    高可用:将数据复制到分布式部署的多台机器中,可以消除单点故障,防止系统由于某台(些)机器宕机导致的不可用。
     性能:通过负载均衡技术,能够让分布在不同地方的数据副本全都对外提供服务。有效提高系统性能。

    在分布式系统引入复制机制后,不同的数据节点之间由于网络延时等原因很容易产生数据不一致的情况。复制机制的目的是为了保证数据的一致性。但是数据复制面临的主要难题也是如何保证多个副本之间的数据一致性。
    对分布式数据一致性简单的解释就是:当对集群中一个副本数据进行更新的同时,必须确保能够同步更新到其他副本,否则不同副本之间的数据将不再一致。举个例子来说就是:当客户端C1将系统中的一个值K由V1更新为V2,但是客户端C2读的是另一个还没有同步更新的副本,K的值依然是V1,这就导致了数据的不一致性。其中,常见的就是主从数据库之间的复制延时问题。

    我们这个系统要重点介绍的分布式一致性协议就是来解决上边的问题的,其中Zookeeper就是分布式一致性问题的工业解决方案paxos是理论算法,其中zab,raft和众多开源算法是对paxos的工业级实现。Zookeeper使用zab来保证其自身系统的高可用与数据一致性的。
     

    CAP 、BASE 请看上一篇;

     

    https://blog.csdn.net/lavorange/article/details/52489998

    展开全文
  • 分布式理论-初探

    2020-05-16 21:44:34
    分布式理论 什么是分布式系统 分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。...

    转自:狂神说JAVA

    分布式理论

    什么是分布式系统

    分布式系统是由一组通过网络进行通信、为了完成共同的任务而协调工作的计算机节点组成的系统。分布式系统的出现是为了用廉价的、普通的机器完成单个计算机无法完成的计算、存储任务。其目的是利用更多的机器,处理更多的数据

    分布式系统是建立在网络之上的软件系统

    历程

    img

    单一应用架构—>垂直应用架构----->分布式服务架构---->流动计算架构

    RPC

    RPC【Remote Procedure Call】是指远程过程调用,是一种进程间通信方式,他是一种技术的思想,而不是规范。它允许程序调用另一个地址空间(通常是共享网络的另一台机器上)的过程或函数,而不用程序员显式编码这个远程调用的细节。即程序员无论是调用本地的还是远程的函数,本质上编写的调用代码基本相同。

    RPC两个核心模块:通讯,序列化。

    序列化:数据传输需要转化

    Dubbo

    Apache Dubbo |ˈdʌbəʊ| 是一款高性能、轻量级的开源Java RPC框架,它提供了三大核心能力:面向接口的远程方法调用,智能容错和负载均衡,以及服务自动注册和发现。

    img

    节点角色说明

    节点 角色说明
    Provider 暴露服务的服务提供方
    Consumer 调用远程服务的服务消费方
    Registry 服务注册与发现的注册中心
    Monitor 统计服务的调用次数和调用时间的监控中心
    Container 服务运行容器

    调用关系说明

    l 服务容器负责启动,加载,运行服务提供者。

    l 服务提供者在启动时,向注册中心注册自己提供的服务。

    l 服务消费者在启动时,向注册中心订阅自己所需的服务。

    l 注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。

    l 服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。

    l 服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。

    展开全文
  • 分布式系统的经典基础理论

    万次阅读 多人点赞 2018-05-24 21:22:02
    历史优质文章: 可能是最漂亮的Spring事务管理详解 面试中关于Java虚拟机(jvm)的问题...分布式系统的目标是提升系统的整体性能和吞吐量另外还要尽量保证分布式系统的容错性(假如增加10台服务器才达到单机运...

    历史优质文章:

    可能是最漂亮的Spring事务管理详解

    面试中关于Java虚拟机(jvm)的问题看这篇就够了

    Java NIO 概览

    分布式系统设计理念

    分布式系统架构的第一原则是不要分布!这句话看似矛盾实则揭露了分布式系统的很多特征。

    分布式系统的目标与要素

    分布式系统的目标是提升系统的整体性能和吞吐量另外还要尽量保证分布式系统的容错性(假如增加10台服务器才达到单机运行效果2倍左右的性能,那么这个分布式系统就根本没有存在的意义)。

    即使采用了分布式系统,我们也要尽力运用并发编程、高性能网络框架等等手段提升单机上的程序性能。

    分布式系统设计两大思路:中心化和去中心化

    分布式系统设计两大思路:中心化和去中心化

    1)中心化设计:

    • 两个角色: 中心化的设计思想很简单,分布式集群中的节点机器按照角色分工,大体上分为两种角色: “领导”“干活的”
    • 角色职责: “领导”通常负责分发任务并监督“干活的”,发现谁太闲了,就想发设法地给其安排新任务,确保没有一个“干活的”能够偷懒,如果“领导”发现某个“干活的”因为劳累过度而病倒了,则是不会考虑先尝试“医治”他的,而是一脚踢出去,然后把他的任务分给其他人。其中微服务架构 Kubernetes 就恰好采用了这一设计思路。
    • 中心化设计的问题
      1. 中心化的设计存在的最大问题是“领导”的安危问题,如果“领导”出了问题,则群龙无首,整个集群就奔溃了。但我们难以同时安排两个“领导”以避免单点问题。
      2. 中心化设计还存在另外一个潜在的问题,既“领导”的能力问题:可以领导10个人高效工作并不意味着可以领导100个人高效工作,所以如果系统设计和实现得不好,问题就会卡在“领导”身上。
    • 领导安危问题的解决办法: 大多数中心化系统都采用了主备两个“领导”的设计方案,可以是热备或者冷备,也可以是自动切换或者手动切换,而且越来越多的新系统都开始具备自动选举切换“领导”的能力,以提升系统的可用性。

    2)去中心化设计

    • 众生地位平等: 在去中心化的设计里,通常没有“领导”和“干活的”这两种角色的区分,大家的角色都是一样的,地位是平等的,全球互联网就是一个典型的去中心化的分布式系统,联网的任意节点设备宕机,都只会影响很小范围的功能。
    • “去中心化”不是不要中心,而是由节点来自由选择中心。 (集群的成员会自发的举行“会议”选举新的“领导”主持工作。最典型的案例就是ZooKeeper及Go语言实现的Etcd)
    • 去中心化设计的问题: 去中心化设计里最难解决的一个问题是 “脑裂”问题 ,这种情况的发声概率很低,但影响很大。脑裂问题,这种情况的发生概率很低,但影响很大。脑裂指一个集群由于网络的故障,被分为至少两个彼此无法通信的单独集群,此时如果两个集群都各自工作,则可能会产生严重的数据冲突和错误。一般的设计思路是,当集群判断发生了脑裂问题时,规模较小的集群就“自杀”或者拒绝服务。

    分布式与集群的区别是什么?

    • 分布式: 一个业务分拆多个子业务,部署在不同的服务器上
    • 集群: 同一个业务,部署在多个服务器上。比如之前做电商网站搭的redis集群以及solr集群都是属于将redis服务器提供的缓存服务以及solr服务器提供的搜索服务部署在多个服务器上以提高系统性能、并发量解决海量存储问题。

    CAP定理

    CAP定理
    在理论计算机科学中,CAP定理(CAP theorem),又被称作布鲁尔定理(Brewer’s theorem),它指出对于一个分布式计算系统来说,不可能同时满足以下三点:

    • 一致性(Consistence) :所有节点访问同一份最新的数据副本
    • 可用性(Availability):每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
    • 分区容错性(Partition tolerance) : 分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。

    CAP仅适用于原子读写的NOSQL场景中,并不适合数据库系统。现在的分布式系统具有更多特性比如扩展性、可用性等等,在进行系统设计和开发时,我们不应该仅仅局限在CAP问题上。

    注意:不是所谓的3选2(不要被网上大多数文章误导了):

    大部分人解释这一定律时,常常简单的表述为:“一致性、可用性、分区容忍性三者你只能同时达到其中两个,不可能同时达到”。实际上这是一个非常具有误导性质的说法,而且在CAP理论诞生12年之后,CAP之父也在2012年重写了之前的论文。

    当发生网络分区的时候,如果我们要继续服务,那么强一致性和可用性只能2选1。也就是说当网络分区之后P是前提,决定了P之后才有C和A的选择。也就是说分区容错性(Partition tolerance)我们是必须要实现的。

    我在网上找了很多文章想看一下有没有文章提到这个不是所谓的3选2,用百度半天没找到了一篇,用谷歌搜索找到一篇比较不错的,如果想深入学习一下CAP就看这篇文章把,我这里就不多BB了:《分布式系统之CAP理论》 : http://www.cnblogs.com/hxsyl/p/4381980.html

    BASE理论

    BASE理论由eBay架构师Dan Pritchett提出,在2008年上被分表为论文,并且eBay给出了他们在实践中总结的基于BASE理论的一套新的分布式事务解决方案。

    BASEBasically Available(基本可用)Soft-state(软状态)Eventually Consistent(最终一致性) 三个短语的缩写。BASE理论是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的总结,是基于CAP定理逐步演化而来的,它大大降低了我们对系统的要求。

    BASE理论的核心思想

    即使无法做到强一致性,但每个应用都可以根据自身业务特点,采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性,系统中一部分数据不可用或者不一致时,仍需要保持系统整体“主要可用”。

    针对数据库领域,BASE思想的主要实现是对业务数据进行拆分,让不同的数据分布在不同的机器上,以提升系统的可用性,当前主要有以下两种做法:

    • 按功能划分数据库
    • 分片(如开源的Mycat、Amoeba等)。

    由于拆分后会涉及分布式事务问题,所以eBay在该BASE论文中提到了如何用最终一致性的思路来实现高性能的分布式事务。

    BASE理论三要素

    BASE理论三要素

    1. 基本可用

    基本可用是指分布式系统在出现不可预知故障的时候,允许损失部分可用性。但是,这绝不等价于系统不可用。

    比如:

    • 响应时间上的损失:正常情况下,一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果,但由于出现故障,查询结果的响应时间增加了1~2秒
    • 系统功能上的损失:正常情况下,在一个电子商务网站上进行购物的时候,消费者几乎能够顺利完成每一笔订单,但是在一些节日大促购物高峰的时候,由于消费者的购物行为激增,为了保护购物系统的稳定性,部分消费者可能会被引导到一个降级页面

    2. 软状态

    软状态指允许系统中的数据存在中间状态,并认为该中间状态的存在不会影响系统的整体可用性,即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

    3. 最终一致性

    最终一致性强调的是系统中所有的数据副本,在经过一段时间的同步后,最终能够达到一个一致的状态。因此,最终一致性的本质是需要系统保证最终数据能够达到一致,而不需要实时保证系统数据的强一致性。

    总结

    本文主要是简单的介绍了三个常见的概念: 分布式系统设计理念CAP定理BASE理论 ,关于分布式系统的还有很多很多东西。
    分布式系统的经典基础理论总结

    我是Snailclimb,一个以架构师为5年之内目标的小小白。 欢迎关注我的微信公众号:“Java面试通关手册”(一个有温度的微信公众号,期待与你共同进步~~~坚持原创,分享美文,分享各种Java学习资源)

    最后,就是使用阿里云服务器一段时间后,感觉阿里云真的很不错,就申请做了阿里云大使,然后这是我的优惠券地址.

    展开全文
  • 首先,关于分布式,有些纯理论的知识需要开发有个基本的概念: 1、什么是分布式,什么是集群,二者有什么区别? 2、分布式的 CAP理论、BASE理论? 3、什么是分布式的数据一致性? 4、2PC、3PC、TCC等 画重点...
  • 推荐:分布式理论系列

    千次阅读 2018-02-10 12:35:57
    从ACID到CAP到BASE2PC到3PC到Paxos到Raft到ISR复制、分片和路由副本更新策略负载均衡算法及手段RWN及Quorum与强一致性序本文主要讲述分布式系统开发的一些相关理论基础。一、ACID事务的四个特征:1、Atomic原子性...
  • 分布式理论(一)

    2020-10-10 00:04:27
    CAP定理,指在一个分布式系统中,Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性)这三个基本需求,最多只能同时满足其中的2个。 简介 选项 描述 ...
  • [分布式]:分布式系统的CAP理论

    千次阅读 多人点赞 2018-05-24 17:00:11
    2000年7月,加州大学伯克利分校的Eric ...之后,CAP理论正式成为分布式计算领域的公认定理。 CAP理论概述 一个分布式系统最多只能同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition...
  • 分布式理论

    2019-07-04 20:42:09
    CAP定理:参考链接:... Base理论:参考链接:https://www.cnblogs.com/stateis0/p/9062123.html 一致性协议(2pc):参考链接:https://www.cnblogs.com/stateis0/p/9062126.html 一致性协议(3pc):参考链...
  • Zookeeper系列(1)--分布式一致性理论,CAP,BASE理论

    千次阅读 多人点赞 2018-01-30 22:20:26
    Zookeeper系列,会从分布式一致性理论开始介绍,设计诸如:CAP,BASE理论分布式一致性算法:2PC,3PC,Paxos,ZAB以及Zookeeper的节点特性,Zookeeper如何保证一致性及高可用,最后会介绍zk的各种应用。 关于数据的...
  • 分布式理论基础

    2017-06-13 20:44:46
    一、什么是分布式分布式就是计算机之间的分工与合作 例如:对应现实世界中,针对某项任务,我分给一个人干还是一群人干产生的效果也是不同的,一群人干肯定要比一个人干要快的; 和计算机一样,在计算机内部首先...
  • 分布式理论

    2017-01-16 14:22:46
    数据重力:这个概念由Basho CTO Dave McCrory所提出,是指数据应该被看成是一种能够吸引更多其他事物的东西。更多的数据会吸引更多的服务和应用。随着搜集到的数据越来越多,不可避免的,我们需要更多的计算资源,...
  • 分布式理论架构设计

    2020-07-21 15:51:52
    分布式理论 分布式架构系统回顾 分布式系统概念 分布式系统是一个硬件或软件组件分布在不同的网络计算机上,彼此之间仅仅通过消息传递进行通信和协调的系统。 通俗的理解,所谓分布式系统,就是一个业务拆分成多个子...
  • 我们想要了解zookeeper就需要了解一些分布式领域的一些概念,接下来 1. 分布式背景 1.1 集中式服务 所谓集中式系统就是指由一台或多台主计算机组成中心节点,数据集中存储于这个中心节点中,并且整个系统的所有业务...
  • 分布式理论相关

    2018-11-28 09:52:48
    一:CAP理论 1. 一个分布式系统中最多只能同时满足一致性(Consistency)、可用性(Availability)、分区容错性(Partition tolerance)中的两项; 2.关于一致性Consistency:客户端和服务端关心的一致性不一样,服务端...
  • 分布式架构,需要的理论基础。 一、CAP理论 CAP理论是指在一个分布式系统中, Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),三者不可兼得。 C (Consistency),一致性...
  • 分布式理论

    2019-06-10 12:32:18
    分布式服务框架设计 ...分布式理论(一) —— CAP 定理 https://www.cnblogs.com/stateis0/p/9062121.html 分布式理论(二)——Base 理论 https://www.cnblogs.com/stateis0/p/9062123.html 分布式理论(六)—...
  • 分布式系统的 CAP 理论:首先把分布式系统中的三个特性进行了如下归纳: ● 一致性(C): 在分布式系统中的所有数据备份,在同一时刻是否同样的值。(等同于所有节点访问同一份最新的数据副本) ● 可用性(A): 在集群...
  • 分布式理论

    2019-03-02 19:50:35
    https://www.cnblogs.com/szlbm/p/5588543.html
  • 分布式基础理论

    2017-03-14 23:09:23
    CAP理论:一个分布式系统不能同时满足一致性,分区容错性,可用性。 一致性:在分布式环境中,一致性是指多个副本直接是否能够保持一致的特性。 可用性:指系统的服务必须一直处于可用的状态,对于用户的每一个操作...

空空如也

1 2 3 4 5 ... 20
收藏数 136,347
精华内容 54,538
关键字:

分布式理论