分布式理论学习|青训营笔记

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

在后面会依次倒叙回顾之前的学习课程，便于复习~

一、课程重点内容

• 分布式理论
• 共识模型

下面是对课程重点内容的思考与总结，有问题或者错误，可以批评指正呐~

二、分布式理论

分布式的三大理论，作为分布式实现的基础保障：

• CAP理论

  • 定义：三个字母分别代表一致性、可用性、分区容错性，鱼与熊掌不可兼得，这三个是不能同时满足的。

  • 应用：基于CAP理论诞生了三类系统

    • CA系统：传统数据库的代表
    • AP系统：放弃强一致性，保证高可用，不少nosql存储系统采用。故障发生时，为了保证可用性，允许不同进程读到不同的数据
    • CP系统：放弃可用性，保证数据一致性。故障发生时，为了避免读到不一致的数据，可能拒绝访问

  • 故障的处理：由于一个系统不能满足三个条件，于是会出现故障，此时会采用一系列的办法进行故障处理，这里有一个较好的解决方法：

    • 允许主进程作为Master，存在一个进程作为Backup，当故障时将请求转移给Backup进行处理，等价于容灾处理

• ACID理论

  • 定义：

    • A原子性。事务是数据库的逻辑工作单位，事务中包含的各操作要么都做，要么都不做
    • C一致性。事 务执行的结果必须是使数据库从一个一致性状态变到另一个一致性状态。因此当数据库只包含成功事务提交的结果时，就说数据库处于一致性状态。如果数据库系统 运行中发生故障，有些事务尚未完成就被迫中断，这些未完成事务对数据库所做的修改有一部分已写入物理数据库，这时数据库就处于一种不正确的状态，或者说是 不一致的状态。
    • I隔离性。一个事务的执行不能其它事务干扰。即一个事务内部的操作及使用的数据对其它并发事务是隔离的，并发执行的各个事务之间不能互相干扰。
    • D持续性。也称永久性，指一个事务一旦提交，它对数据库中的数据的改变就应该是永久性的。接下来的其它操作或故障不应该对其执行结果有任何影响。

  • 特点：这里的四个特性是针对数据库的事务，它是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行，要么全都不执行

  • 事务级别：

    SQL标准定义了4类隔离级别，包括了一些具体规则，用来限定事务内外的哪些改变是可见的，哪些是不可见的。低级别的隔离级一般支持更高的并发处理，并拥有更低的系统开销。

    • Read Uncommitted（读取未提交内容）

      在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。

    • Read Committed（读取提交内容）

      这是大多数数据库系统的默认隔离级别（但不是MySQL默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别 也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的commit，所以同一select可能返回不同结果。

    • Repeatable Read（可重读）

      这是MySQL的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读 （Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻影” 行。InnoDB和Falcon存储引擎通过多版本并发控制（MVCC，Multiversion Concurrency Control）机制解决了该问题。

    • Serializable（可串行化）

      这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

• BASE理论

  BASE理论是基于CAP理论逐步演化而来的，是CP（强一致性）和AP（强可用性）权衡的结果。 BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点采用适当的方式来使系统达到最终一致性。

  • Basically Available（基本可用）

    • 响应时间上的损失：正常情况下，处理用户请求需要0.5s返回结果，但是由于系统出现故障，处理用户请求的时间变成3s。
    • 系统功能上的损失：正常情况下，用户可以使用系统的全部功能，但是由于系统访问量突然剧增，系统的非核心功能无法使用。

  • Soft state（软状态）

    • 数据同步允许一定的延迟。

  • Eventually consistent（最终一致性）

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

三、共识模型

• Quorum NWR模型

  • 三要素：

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

  • 为了保证强一致性，需要保证 W+R>N

  • Quorum NWR模型将CAP的选择交给用户，是一种简化版的一致性模型

    引起的并发更新问题

    • 如果允许数据被覆盖，则并发更新容易引起一致性问题，例如

      读者如果读到副本1和副本2，得出v=3的结论如果读到副本2和副本3，得出v=2的结论

• RAFT协议

  • 概述：Raft协议是一种分布式一致性算法（共识算法），即使出现部分节点故障，网络延时等情况，也不影响各节点，进而提高系统的整体可用性。Raft是使用较为广泛的分布式协议。

  • 三种角色：

    • Leader ：Leader 负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志
    • Follower ：接受并持久化Leader同步的日志，在Leader告知日志可以提交后，提交日志
    • Candidate ：Leader选举过程中的临时角色。向其他节点发送请求投票信息

  • 定义行为：

    • Log（日志）：节点之间同步的信息，以只追加写的方式进行同步，解决了数据被覆盖的问题
    • Term（任期号）：单调递增，每个Term内最多只有一个Leader
    • Committed：日志被复制到多数派节点，即可认为已经被提交
    • Applied：日志被应用到本地状态机：执行了log中命令，修改了内存状态

  • Leader选举过程：

    • 初始全部为Follower

    • Current Term + 1

    • 选举自己

    • 向其它参与者发起RequestVote请求，retry直到

      • 收到多数派请求，成为Leader，并发送心跳
      • 收到其它Leader的请求，转为Follower，更新自己的Term
      • 收到部分，但未达到多数派，选举超时，随机timeout开始下一轮

  • Re_vote重新选取：

    当Leader出现问题时，就需要进行重新选举

    • Leader发现失去Follower的响应，失去Leader身份
    • 两个Follower之间一段时间未收到心跳，重新进行选举，选出新的Leader，此时发生了切主
    • Leader自杀重启，以Follower的身份加入进来

• Paxos协议

  • Paxos算法与RAFT算法区别：

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

  • 优缺点：

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

四、课程个人总结

第一次接触分布式系统，对新知识还是很感兴趣，再接再厉呀！