分布式理论 | 青训营笔记

22 阅读7分钟

这是我参与「第五届青训营 」笔记创作活动的第5天

最近的课程都在向着抽象的方向发展了,也没有具体的代码,只有大量的概念。简单看一遍只能建立一个大概的感性认识,但是真要自己手动去实现一个一致性协议绝非易事。所以我觉得当下最重要的是记住概念,将来在实践的时候能够想起来,起到一个指导实践的作用。

什么是分布式

通俗来说,就是使用跨多个独立计算节点的计算资源来实现共同的目标,可以分为分布式计算、分布式存储、分布式数据库等。

怎么学分布式

为什么要用分布式,对所有人而言都是显然的。而对于我这样的学生而言,最重要的是怎么学。

  1. 掌握分布式理论
  2. 了解一致性协议

实践起来,需要我们把要点展开,对难点进行深入剖析。最重要的,就是把所学知识用于实践

常见的分布式系统

分布式存储

  1. Google File System(GFS):大名鼎鼎的分布式文件系统,但是还没体验过它的好处,想试试
  2. Ceph
  3. Hadoop HDFS:基于GFS架构的开源分布式文件系统
  4. Zookeeper:

分布式数据库

  1. Google Spanner:google可扩展的、全球分布式的数据库
  2. TiDB:开源分布式关系型数据库
  3. HBase:开源Nosql数据库
  4. MongoDB:文档数据库

分布式计算

  1. Hadoop:基于MapReduce分布式计算框架
  2. Spark:在Hadoop基础上,用内存来存储数据
  3. YARN:分布式资源调度

故障模型

在分布式系统中,故障是必然的。根据故障处理的难度,分为以下的模型:

  • Byzantine failure:节点可以任意篡改发送给其他节点的数据
  • Authentication detectable byzantine failure:前者的特例;节点可以篡改数据,但不能伪造其它节点的数据
  • Permance failure:节点收到数据时间过早或过晚(不符合预期的时间会导致不确定的状态,比收不到数据更棘手)
  • Omission failure:节点收不到数据
  • Crash failure:在前者基础上,增加节点停止响应的假设,即持续性Omission failure
  • Fail-stop failure:在前者基础上增加了错误可检测的假设

拜占庭将军问题

即两支军队互相派遣信使进行通信,在信使均有可能被俘虏的情况下,对发起进攻的时间达成共识。结论是,两支军队理论上永远无法达成共识。

无论重复确认多少次,始终存在无法达成共识的情况。

在工程上,可以采用同时发送N个信使和设置超时重传的方法,一般采用后者(如TCP)。

推广拜占庭将军问题,当有3m+1个将军,其中m个叛徒时,可以增加m轮协商,最终达成一致。

共识和一致性

共识和一致性实际上并不是相同的概念。

最终一致性:读写并发的时候,可能读到旧的数据,但写完成后,最终能够读到一致的数据。

线性一致性(强一致性):读到更新的数据后,立即同步给其它客户端。会有可用性受损。

时间和事件顺序

使用Lesile Lamport的逻辑时钟图来梳理事件的时间顺序和逻辑顺序,就能够对整个系统中的事件进行全序排序。

CAP理论

C(Consistence):一致性,指数据在多个副本之间能够保持一致 A(Availability):可用性,指服务必须一直处于可用,但不保证获取的数据最新 P(Network partitioning):分区容错性,在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境都发生了故障。

CAP中,只能够完全地达到其中两个。当选择了其中两个时,只能放弃另外一个。一般根据应用的需求选择。

BASE理论

Base 理论是对CAP中一致性和可用性权衡的结果。核心思想是:

Basically Available(基本可用):假设系统出现不可预知的故障,仍然能够提供服务,只是损失一些时间或功能

Soft state(软状态):允许系统在多个不同节点的数据副本存在数据延时

Eventually consistent(最终一致性):确保所有客户端最终都能够获取到最新的值

二阶段提交

为了使分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。

三个假设:

  1. 引入协调者(Coordinator)和参与者(Participants),互相进行网络通信
  2. 所有节点采用预写式日志,且日志被写入后即保持在可靠的存储设备上
  3. 所有节点不会永久性损坏,损坏后可以恢复。

二阶段,指Prepare阶段和Commit阶段。

在Prepare阶段,某个参与者反馈失败,说明该节点本地事务执行不成功,必须回滚。而回滚操作,可以视Coordinator和Participants的状态进行不同的操作。

三阶段提交

将二阶段提交中的Prepare阶段,拆成两部分:CanCommit和PreCommit机制。另外引入超时机制,等待超时后,继续进行事务的提交。

即提前确认足够数量参与者收到commit决定。

解决了两个问题:

  1. 单点故障问题:即使协调者宕机,参与者之间也可以相互通信来决定应该提交还是中止事务
  2. 阻塞问题:由于提前确认了收到commit,参与者也不用阻塞等待。

但因为开销太大,没有实际运用。

MVCC

MVCC,即多版本并发控制。

MVCC维持一个数据的多个版本使读写操作没有冲突,所以既不会阻塞写,也不阻塞读。为每个修改保存一个版本,和事务的时间戳相关联,可以提高并发性能,解决脏读的问题。

Quorum NWR模型

Quorum NWR三要素

N:在分布式存储系统中,有多少份备份数据 W:代表一次成功的更新操作要求至少有W份数据写入成功 R:代表一次成功的读数据操作至少有R份数据成功读取

为了保证强一致性,需要保证W+R>N(这样至少会读到一份写入成功的数据)

将CAP的选择交给用户,是一种简化的一致性模型。

RAFT协议

一种分布式一致性算法(共识算法),即使出现部分节点故障,网络延时等情况,也不影响各节点,进而提高系统整体可用性。一定意义上RAFT也使用了Quorum机制。

Leader,负责处理所有客户端请求,并向Follower同步请求日志。当日志同步到大多数节点上后,通知Follower提交日志。

Follower,不发送任何请求。接受并持久化Leader同步的日志,在Leader告知日志可以提交后,提交日志。当Leader出现故障,推荐自己为Candidate。

Candiate,Leader选举中的临时角色。向其它节点发送请求投票信息。如果获得大多数选票,则晋升为Leader。

Log(日志):节点之间同步的信息,以只追加写的方式进行同步,解决了数据被覆盖的问题

Term(任期号):单调递增,每个Term内最多只有一个Leader

Committed:日志被复制到多数派节点,既可认为已经被提交

Applied:日志被应用到本地状态机:执行了log中命令,修改了内存状态

Paxos协议

Paxos算法与RAFT算法区别:

  1. Multi-Paxos 可以并发修改日志,而Raft写日志操作必须连续
  2. Multi-Paxos 可以随机选主,不必最新最全的节点当选Leader

优势:写入并发性能高,所有节点都能写入 劣势:没有一个节点有完整的最新数据,回复流程复杂,需要同步历史记录