• 第四章 分布式系统核心问题


    一、一致性问题
    1. 定义与重要性
    定义:指对于分布式系统中的多个服务节点,给定一系列操作,在约定协议的保障下,试图使得它们对处理结果达成“某种程度”的认同。
    注意:一致性并不代表结果正确与否,而是系统对外呈现的状态一致与否;例如,所有节点都达成失败状态也是一种一致。
    2. 问题与挑战
    节点之间的网络通信是不可靠的,包括消息延迟、乱序和内容错误等;节点的处理时间无法保障,结果可能出现错误,甚至节点自身可能发生宕机;同步调用可以简化设计,但会严重降低分布式系统的可扩展性。
    3. 一致性要求
    可终止性:一致的结果在有限时间内能完成
    约同性:不同节点最终完成决策的结果是相同的
    合法性:决策的结果必须是某个节点提出的提案
    4. 带约束的一致性
    顺序一致性
    线性一致性
     
    二、共识算法
    一致性往往指分布式系统中多个副本对外呈现的数据的状态。如前面提到的顺序一致性、线性一致性,描述了多个节点对数据状态的维护能力。而共识则描述了分布式系统中多个节点之间,彼此对某个状态达成一致结果的过程。因此,一致性描述的是结果状态,共识则是一种手段。
     
    1. 问题与挑战
    如通信网络会发生中断、节点会发生故障、甚至存在恶意节点故意要伪造消息,破坏系统的正常工作流程。
    非拜占庭错误:也可以称为“故障错误”,即出现故障(不响应)但不会伪造信息的情况
    拜占庭错误:伪造信息恶意响应的情况
    2. 常见算法
    根据解决的是非拜占庭的普通错误情况还是拜占庭错误情况,共识算法可以分为Crash Fault Tolerance(CFT)类算法和Byzantine Fault Tolerance(BFT)类算法。
    3. 理论界限
    即便在网络通信可靠情况下,可扩展的分布式系统的共识问题,其通用解法的理论下限是——没有下限(无解)
     
    三、FLP不可能原理
    1. 定义
    FLP不可能原理: 在网络可靠,但允许节点失效(即便只有一个)的最小化异步模型系统中,不存在一个可以解决一致性问题的确定性共识算法(No completely asynchronous consensus protocol can tolerate even a single unannounced process death)。
    2. 正确理解
    FLP原理实际上说明对于允许节点失效情况下,纯粹异步系统无法确保一致性在有限时间内完成。
     
    四、CAP原理
    1. 定义
    CAP原理:分布式计算系统不可能同时确保以下三个特性:一致性(Consistency)、可用性(Availability)和分区容忍性(Partition),设计中往往需要弱化对某个特性的保证。
    2. 应用场景
    既然CAP三种特性不可同时得到保障,则设计系统时必然要弱化对某个特性的支持。那么可能出现下面三个应用场景。
    弱化一致性
    弱化可用性
    弱化分区容忍性
     
    五、ACID原则
    ACID原则描述了分布式数据库需要满足的一致性需求,同时允许付出可用性的代价。
    ACID特征如下:
    Atomicity:每次操作是原子的,要么成功,要么不执行;
    Consistency:数据库的状态是一致的,无中间状态;
    Isolation:各种操作彼此之间互相不影响;
    Durability:状态的改变是持久的,不会失效。
    与ACID相对的一个原则是BASE(Basic Availability,Soft-state,EventualConsistency)原则,牺牲掉对一致性的约束(但实现最终一致性),来换取一定的可用性。
     
    六、Paxos算法和Raft算法
    1. Paxos算法
    单个提案者+多接受者:只有一个节点是提案者,其他节点投票,要么达成,要么失败。
    多个提案者+单接受者:限定某个节点作为接受者。这种情况下,共识也很容易达成,接受者收到多个提案,选第一个提案作为决议,发送给其他提案者即可。
    多个提案者+多接受者:
    两阶段的提交:准备阶段和提交阶段
    2. Raft算法
    Raft算法包括三种角色:Leader(领导者)、Candidate(候选领导者)和Follower(跟随者),决策前通过选举一个全局的leader来简化后续的决策过程。Leader角色十分关键,决定日志(log)的提交。日志只能由Leader向Follower单向复制。
     
    七、拜占庭问题与算法
    拜占庭问题之所以难解,在于任何时候系统中都可能存在多个提案(因为提案成本很低),并且要完成最终一致性确认过程十分困难,容易受干扰。
    比特币的区块链网络在设计时提出了创新的PoW(Proof of Work)概率算法思路,针对这两个环节进行了改进。
    首先,限制一段时间内整个网络中出现提案的个数(通过增加提案成本);其次是放宽对最终一致性确认的需求,约定好大家都确认并沿着已知最长的链进行拓展。系统的最终确认是概率意义上的存在。这样,即便有人试图恶意破坏,也会付出相应的经济代价(超过整体系统一半的计算力)。
     
    八、可靠性指标
    1. 几个9的指标
    2. 两个核心时间,平均故障间隔时间(Mean Time Between Failures)、平均修复时间(Mean Time to Repair)
    3. 提高可靠性
    依靠单点实现的可靠性毕竟是有限的。要想进一步地提升,那就只好消灭单点,通过主从、多活等模式让多个节点集体完成原先单点的工作。这可以从概率意义上改善服务对外的整体可靠性,这也是分布式系统的一个重要用途。
     
     
  • 相关阅读:
    day12 bash中的if、for
    day11 grep正则匹配
    day10 nfs服务,nginx负载均衡,定时任务
    SpringMVC11文件上传
    SpringMVC10数据验证
    SpringMVC09异常处理和类型转化器
    SpringMVC08转发和重定向
    SpringMVC07处理器方法的返回值
    SpringMVC06以对象的方式获取前台的数据
    SpringMVC05使用注解的方式
  • 原文地址:https://www.cnblogs.com/yahb/p/8993357.html
Copyright © 2020-2023  润新知