【分布式协议与算法】理论篇

理论篇

拜占庭将军问题

问题定义：

如何在可能有误导信息的情况下，采用合适的通讯机制，让多个将军达成共识，制定一致性的作战计划？

如何解决

方法一：口信消息型拜占庭

• 第一轮：一个将军作为指挥官，将其作战信息发送给每位副官，副官接收作战信息，作为他的作战指令，如果没有收到作战信息，将执行默认的命令
• 第二轮：除第一轮的指挥官之外，剩余的三个将军分别作为指挥官，发送给另外两个将军作战信息。“少数服从多数”
  注：如果叛将为m 个，那么总人数必须不小于 3m+1。有m 个叛将，递归执行m 次

方法二：签名消息型拜占庭

• 通过签名的方法对消息进行签名

内容小结

• 存在恶意节点行为的场景（数字货币的区块链），必须使用拜占庭容错算法（BFT）（PBFT，PoW）
• 分布式系统存在故障，但不存在恶意节点时，采用非拜占庭容错算法，故障容错算法（CFT）（Paxos，Raft，Zab）
  如何基于签名消息

CAP理论

CAP三指标

• 一致性©：客户端每次读操作，不论访问哪个节点，要么读到的都是同一份最新的数据，要么读取失败，强调各节点的数据一致；
• 可用性(A)：任何来自客户端的请求，不管访问哪个节点，都能得到响应数据，但不保证是同一份最新数据。强调服务可用，但不保证数据的一致；
• 分区容错性§：当节点间出现任意数量的消息丢失或高延迟的时候，系统仍然可以继续提供服务，强调集群对分区故障的容错能力；

CAP不可能三角

定义：CAP 不可能三角说的是对于一个分布式系统而言，一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）3 个指标不可兼得，只能在 3 个指标中选择 2 个。

如何使用CAP理论

因为有网络交互就一定会有延迟和数据丢失，节点间的分区故障是必然发生的，也就是说，分区容错性（P）是前提，是必须要保证的

• CP：如果因为消息丢失、延迟过高发生了网络分区，部分节点无法保证特定信息是最新的，那么这个时候当集群接收到来自客户端的写请求时，会返回写失败，也即拒绝新数据写入（zk，etcd）
• AP：如果发生了网络分区，一些节点将无法返回最新的特定信息，将返回自己当前的相对新的信息（Cassandra，DynamoDB）
  注：
• 在不发生网络分区的时候，C和A能够同时保证。只有当发生分区故障的时候，才会在C 和A 之间作出选择
• 如果各节点数据不一致，影响到系统运行或业务运行，选C，否则选A

ACID理论：CAP的酸，追求一致性

二阶段提交

• 提交请求阶段（投票阶段）
• 提交执行阶段（完成阶段）
  注：在提交请求阶段，需要预留资源，无法根据业务特点弹性地调整锁的粒度，这都会影响并发性能

三阶段提交：

• 针对二阶段提交的“协调者故障，参与者长期锁定资源”的痛点，引入询问阶段或者超时机制
• 导致正常运行时，会使用更多的消息进行协商，增加系统负载和响应延迟

TCC（Try-Confirm-Cancel）

• 预留阶段
• 确认或撤销阶段
  本质上是补偿事务，核心思想是针对每个操作都需要注册一个与其对应的确认操作和撤销操作
  为了实现一致性，确认操作和撤销操作必须是幂等的，因为这两个操作可能会失败重试
  相较于二阶段提交，客户端扮演协调者的角色

ACID理论：CAP的碱，追求可用性

BASE理论

• 基本可用：本质上是一种妥协，通过牺牲非核心功能的可用性，保障核心功能的稳定运行
• 最终一致性：

实现基本可用的四板斧

• 流量削峰
• 延迟响应
• 体验降级
• 过载保护

最终一致性

定义：系统中所有的数据副本在经过一段时间的同步后，最终能够达到一个一致的状态。

如何实现最终一致性

• 读时恢复：在读取数据时，检测数据的不一致，进行修复（Cassandra 的 read repair）
• 写时恢复：在写入数据，检测数据不一致时，进行修复（Cassandra 的hinted handoff）（因为不需要做数据一致性对比，性能消耗比较低，对系统运行影响不大，推荐）
• 异步修复：最常用的方式，通过定时对账检测副本数据的一致性，并修复
  写时修复级别：all，quorum，one，any
  如何使用BASE理论
  基本可用：读和写的基本可用，通过分片和多副本保障
  最终一致性：写时修复和异步修复

小结

1.BASE理论是CAP中一致性和可用性权衡的结果，核心思想是：如果不是必须的话，不推荐实现事务或强一致性，鼓励可用性和性能优先，根据业务的场景特点，来实现非常弹性的基本可用以及数据的最终一致性
2.BASE理论主张通过牺牲部分功能的可用性，实现整体的基本可用
3.BASE理论支持的是大型分布式系统，通过牺牲强一致性获得高可用性，是NoSQL系统设计的事实上的理论支撑
4.如何设计过载保护，实现系统在过载时的基本可用，是重中之重