• 分布式共识算法


    分布式共识算法

    什么是一致性

    CAP theorem(CAP 理论)

    • 对于一个分布式系统,不能 t时刻同时满足以下三点:

      • 一致性(Consistency)
      • 可用性(Availability)
      • 分区容错性(Partition tolerance)
    • 一般来说,分区容错无法避免,因此可以认为 CAP 的 P 总是成立。CAP 定理告诉我们,剩下的 C 和 A 无法同时做到。

    • 一致性和可用性,为什么不可能同时成立?答案很简单,因为可能通信失败(即出现分区容错)。

    • 业界普遍做法:

      • 采取AP,保证分布式高可用,并通过弱一致性或最终一致性来同步数据。系统可以不同时达到CAP,而是分时达到。
    • CAP 理论说在一个系统中对某个数据不存在一个算法同时满足 Consistency, Availability, Partition-tolerance。

      • 在一个系统中,可以对某些数据做到 CP, 对另一些数据做到 AP,就算是对同一个数据,调用者可以指定不同的算法,某些算法可以做到 CP,某些算法可以做到 AP。
    • BASE是Basically Available(基本可用)、Soft state(软状态)和Eventually consistent(最终一致性)三个短语的简写,BASE是对CAP中一致性和可用性权衡的结果,其来源于对大规模互联网系统分布式实践的结论,是基于CAP定理逐步演化而来的,其核心思想是即使无法做到强一致性(Strong consistency),但每个应用都可以根据自身的业务特点,采用适当的方式来使系统达到最终一致性(Eventual consistency)。

    • 以算法划分,到能分出几类:

      1. 以Leader选举为主的一类算法,比如paxos、viewstamp,就是现在zookeeper、Chuby等工具的主体
      2. 以分布式事务为主的一类主要是二段提交,这些分布式数据库管理器及数据库都支持
      3. 以若一致性为主的,主要代表是Cassandra的W、R、N可调节的一致性
      4. 以租赁机制为主的,主要是一些分布式锁的概念,目前还没有看到纯粹“分布式”锁的实现
      5. 以失败探测为主的,主要是Gossip和phi失败探测算法,当然也包括简单的心跳
      6. 以弱一致性、因果一致性、顺序一致性为主的,开源尚不多,但大都应用在Linkedin、Twitter、Facebook等公司内部
      7. 当然以异步解耦为主的,还有各类Queue
    • 参考资料:

    一致性模型

    • 需要一致性的根源是数据不能存在单节点上。
    • 弱一致性模型, 只要最终一致就行
      • DNS(Domain Name System)
      • Gossip(Cassandra的通信协议)
    • 强一致性模型
      • 同步
      • Paxos, Paxos其实是一个共识算法。系统的最终一致性,不仅需要达成共识,还取决于client的行为。
      • Ratf(multi-paxos)
      • ZAB(multi-paxos)
    • 强一致性算法:
      • 需要主从同步,主从同步复制, 但也会导致一定的问题: 一个节点的失败,Master阻塞,导致整个集群不可用,保证了一致性,可用性却大大降低。
        1. Master 接受写请求
        2. Master 复制日志到 slave
        3. Master 等待, 直到所有从库返回
      • 多数派: 问题:并发环境下,无法保证系统正确性,顺序非常重要。
        • 每次写都保证写入大于N/2个节点,每次读保证从大于N/2个节点中读。

    强一致性算法

    Paxos 算法

    • Paxos 算法衍生为三类:
      • Basic Paxos
        • 潜在问题,难实现、效率低(2轮RPC)、活锁(liveness)
      • Multi Paxos
      • Fast Paxos
    • 参考资料

    Raft 算法

    • 划分成三个子问题:
      • Leader Election
      • Log Replication
      • Safety
    • 重新定义角色
      • Leader
      • Follower
      • Candidate
    • Raft要求系统在任意时刻最多只有一个Leader,正常工作期间只有Leader和Followers。
    • 拥有最新的已提交的log entry的Follower才有资格成为Leader。
    • Raft采用对整个系统进行snapshot来解决,snapshot之前的日志都可以丢弃。
    • 参考资料:

    ZAB 算法

    • 基本与Raft相同。
    • 在一些名词的叫法上有些区别:如ZAB将某一个leader周期称为epoch,而raft则称为term。
    • 实现上也有些许不同:Raft保证日志连续性,心跳方向为leader至follower。ZAB刚好相反。
    • 参考资料:
  • 相关阅读:
    docker-compose运行nginx
    docker后台持续运行
    docker-compose运行tomcat
    集群session解决方案
    docker运行mysql
    docker运行svn
    mongodb数据的导出和导入
    mongodb副本集的docker化安装
    grafana使用json数据源监控数据
    docker化安装grafana
  • 原文地址:https://www.cnblogs.com/longjiang-uestc/p/12438987.html
Copyright © 2020-2023  润新知