分布式系统涉及理论基础

拜占庭将军问题

• 拜占庭将军有10只军队但分散各地，敌国可以同时抵御5只军队的进攻，因此将军要战胜敌国，就必须找出至少让6只军队同时进攻敌国的办法。问题10个支军队中间可能有叛徒，叛徒可以更改通讯兵的消息，指令就被更改无法分辨。

前提

• 通讯兵一定是消息可以被送达
• 每个将军都是随时可以应答

解决办法1

• 口信消息：
  • m 叛将数量 则军队数量n 必须为3m+1;
  • 需要m+1轮协商
  • 例如存在2忠将一个叛将： 此时需要增加一个协调者 即四个将军
  • 协调者分别给每个将军发送指令，收到指令就是作战，没收到则撤退，然后剩下三个将军分别相互给其他两个将军发送指令。四轮下来 少数服从多数 只有一个不一样指令就是假的
  • 因为假设只有一个叛将 就算伪造指令每个将军也只能收到一个假的，剩下三个就是真的 依然可以按时作战

解决办法2

• 数字签名
• 每个忠将的签名不被为伪造，相互之前也可以鉴别真伪 此时可以的容忍的叛将为 n -2 = m ，此时人需要m+1 协商

拜占庭容错算法（Byzantine Fault Tolerance，BFT）

• 存在恶意攻击的节点的场景共识算法 适用于拜占庭容错算法
• 如区跨链算法 PBFT、Pow算法

非拜占庭容错算法 故障容错算法（Crash FaultTolerance，CFT）

• 分布式存在故障节点的，但是不存在恶意攻击节点的共识算法
• 如 分布式存在重复消息、丢失消息 但是不存在错误消息、伪造消息 适用用Paxos、Raft、ZAB 协议

CAP 理论

• C 一致性 分布式系统向客户端承诺： 无论在何时访问返回的数据都是一样 即最新的数据
• A 可以用性 分布式系统对客户端承诺： 无论何时只要向服务发送请求，一定会响应
• P 分区容错 分布式系统承诺：无论何时只要都会一直运行，提供服务

CAP 理论的取舍 不可能同时满足

• P必须满足： 网络的不可靠性是分布式系统无法解决的问题，因此只能是CP、AP 之间做选择
• CA? ：只要满足CA就行了，这样就是一个单节点毫无意义，自然不是分布式系统
• AP : 可用性优先 不保证数据一致性 适用于实时性要求不高场景，
  • 保证核心业务运行
    • 服务降级处理 例如使用小图片代替高清大图
    • 削峰处理 错开时间段处理 12306的不同时段的不同地区的售票
    • 延迟响应 在队列中排队，过一段时间才会开始处理
    • 过载保护 设置一定长度队列，队列满了就移除一部分请求然后拒绝服务
  • 例如 cassandra和dynamodb数据库 cassandra选择读补偿和写补偿当查询或者写入的时候修复数据
• CP : 一致性优先 要不拒接服务 要不提供一致性服务

CP 经典场景 分布式事物

分布式事物ACID 要不执行要不全部不执行

• 原子性 ： 不可分割行一个事物必须是原子的作为一个整体
• 隔离性 ： 独立性 不能其他事物共享 四个隔离级别决定隔离的强弱
• 持久性 ： 事物一旦成功就是永久的，即使故障也不会丢失
• 一致性 ： 事物正在过程完整的，整个顺序和语义没有被破坏

两段提交

• 参与者将操作结果通知协调者，协调汇总全部参与者决定提交还是中止 更像是仲裁决议
• 应用场景一般数据库 强一致性： XA、TCC、Raft、Paxos 协议
• 两个阶段：
  • 第一阶段 也称投票阶段 类似给个选民发放选票
  • 协调者给每个参与发送 prepar消息、要不直接拒绝不合法请求、要不执行本地事物 写redo、undo log
  • 第二阶段： 提交议案或者选票阶段
  • 协调根如果收到操作失败 直接给每个参与发送回滚通知；全部成功则提交事物，参与释放锁定的资源
• 2pc存在的缺陷
  • 协调者单点 协调者第二阶段故障 参与者资源全部被锁定无法释放 第一阶段可以重现选举协调者 但是协调者也会阻塞
  • 事物整个过程参与全部被阻塞： 这个投票到提交资源独占的，其他第三方无法使用。
  • 数据一致或者不同步 协调者故障后的部分提交 部分未提交
  • 事物不确定性 无法解决的问题 即 协调者发出commit后故障、唯一收到的commit的参与者也故障了，即使心得协调者被选举出来，也无法确定参与者是否提交

三段提交

• 在协调者和参与者引入超时机制
• 在第一阶段和第二阶段中 引入准备阶段，确保提交前每个参与者状态一致
• 三阶段提交：主要处理单点故障，减少资源阻塞
  • 第一阶段：协调者给参与者canprepar消息 查询参与事物能力
  • 第二阶段： 协调收只要一个参与者不具备条件事物能力，直接发送中止消息，否则执行执行事物
  • 第三阶段 ： 如果收到失败或者超时 则通知参与者回滚消息，全部成功提交事物
• 3pc的缺点：
  超时后协调者自动提交，但是网络故障部分节点收不到终止通知 也会造成数据的不一致

架构的取舍 AP的延伸

BASE 理论 基本可用 Basically Available 最终一致 Eventually consistent

• 因为互联网都强调可用性 因此只能选择AP
  • 对一致性让步：进行容忍允许一段时间的不同副本的不同步 只要最终一致即可
• 基本可用：
  • 允许部分服务不可用
  • 分布式系统遇到不可预知的故障时，保证核心功能可用，损失部分可用性，如削峰、降级、延迟响应、过载保护
• 最终一致实现方式：
  • 读补偿 ：读取数据发现不一致 则主动修复
  • 写补偿 ：写数据发现不一致 ，则主动同步，如果失败缓存下来 定时重试后再同步
  • 异步修复 ： 常用的一种方式： 定时任务检测不一致就主动修复