美文网首页
2020-11-27(分布式基础)

2020-11-27(分布式基础)

作者: 冰菓_ | 来源:发表于2020-12-14 08:22 被阅读0次

    问题:分布式环境下数据无法保证(可用的一致性的),假设一台机器崩了,其他机器如何获取崩掉的这台机器上的信息
    失效转移的一种解决方案:


    image.png

    1.集中式和分布式

    集中式
    由于采用单机部署,很可能带来系统大而复杂、难于维护、发生单点故障(单个点发生故障的时候会波及到整个系统或者网络,从而导致整个系统或者网络的瘫痪)、扩展性差

    分布式

    分布性:多节点
    对等性:副本处理
    并发性:高效协调
    时钟观念:缺乏一个全局的时钟序列控制
    故障总是会发生:对人的错误的容忍

    2.分布式系统面临的问题

    通信异常
    网络分区
    三态:无法确认超时,当前请求是否被成功处理的
    单节点故障

    3.CAP定理

    在网络分区的情况下,无法保证可用性和强一致性

    CA without P 如果不要求P(不允许分区),则C(强一致性)和A(可用性)是可以保证的。但其实分区不是你想不想的问题,而是始终会存在,因此CA的系统更多的是允许分区后各子系统依然保持CA。
    CP without A 如果不要求A(可用),相当于每个请求都需要在Server之间强一致,而P(分区)会导致同步时间无限延长,如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。
    AP wihtout C 要高可用并允许分区,则需放弃一致性。一旦分区发生,节点之间可能会失去联系,为了高可用,每个节点只能用本地数据提供服务,而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

    对于P的理解
    Partition字面意思是网络分区,即因网络因素将系统分隔为多个单独的部分,有人可能会说,网络分区的情况发生概率非常小啊,是不是不用考虑P,保证CA就好。要理解P,我们看回CAP证明中P的定义: In order to model partition tolerance, the network will be allowed to lose arbitrarily many messages sent from one node to another. 网络分区的情况符合该定义,网络丢包的情况也符合以上定义,另外节点宕机,其他节点发往宕机节点的包也将丢失,这种情况同样符合定义。现实情况下我们面对的是一个不可靠的网络、有一定概率宕机的设备,这两个因素都会导致Partition,因而分布式系统实现中 P 是一个必须项,而不是可选项。 对于分布式系统工程实践,CAP理论更合适的描述是:在满足分区容错的前提下,没有算法能同时满足数据一致性和服务可用性[11]: In a network subject to communication failures, it is impossible for any web service to implement an atomic read/write shared memory that guarantees a response to every request.

    可用性在CAP定理里指所有读写操作必须要能终止,实际应用中从主调、被调两个不同的视角,可用性具有不同的含义。当P(网络分区)出现时,主调可以只支持读操作,通过牺牲部分可用性达成数据一致。

    工程实践中,较常见的做法是通过异步拷贝副本(asynchronous replication)、quorum/NRW,实现在调用端看来数据强一致、被调端最终一致,在调用端看来服务可用、被调端允许部分节点不可用(或被网络分隔)的效果

    4.Base理论

    BASE理论是Basically Available(基本可用),Soft State(软状态)和Eventually Consistent(最终一致性)三个短语的缩写。
    即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。
    软状态指的是:允许系统中的数据存在中间状态,并认为该状态不影响系统的整体可用性,即允许系统在多个不同节点的数据副本存在数据延时。
    最终一致性 上面说软状态,然后不可能一直是软状态,必须有个时间期限。在期限过后,应当保证所有副本保持数据一致性,从而达到数据的最终一致性。这个时间期限取决于网络延时、系统负载、数据复制方案设计等等因素。

    5.分布式一致性协议

    Gossip算法
    Gossip协议的整体流程非常简单,初始由几个节点发起消息,这几个节点会将消息的更新内容告诉自己周围的节点,收到消息的节点再将这些信息告诉周围的节点。依照这种方式,获得消息的节点会越来越多,总体消息的传输规模会越来越大,消息的传偶速度也越来越快。虽然不是每个节点都能在相同的时间达成一致,但是最终集群中所有节点的信息必然是一致的。Gossip协议确保的是分布式集群的最终一致性
    Pow算法
    完全专注于尽可能地解决"拜占庭将军"问题,防止消息的篡改。它可以不计代价地去要求各个节点参与竞选,以付出巨大算力为代价保证平台的安全性
    Raft协议
    ZAB协议

    相关文章

      网友评论

          本文标题:2020-11-27(分布式基础)

          本文链接:https://www.haomeiwen.com/subject/sobtwktx.html