分布式理论初探(二) | 青训营笔记

five_guns
74 阅读5分钟

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

本文主要介绍了分布式事务，包括两阶段提交、三阶段提交以及MVCC；Quorum NWR模型以及RAFT协议等共识协议。

分布式事务

二阶段提交

定义：为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法，分为prepare阶段和commit阶段。

三个假设：

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

image.png

image.png

可能出现的情况︰

  • 情况1 ：Coordinator不宕机，Participant宕机。如下图所示，需要进行回滚操作
  • 情况2 ：Coordinator宕机，Participant不宕机。可以起新的协调者，待查询状态后，重复二阶段提交
  • 情况3 ：Coordinator宕机，Participant宕机。此时，无法确认状态，需要数据库管理员的介入，防止数据库进入一个不一致的状态。

两阶段提交需解决的问题：

  • 性能问题：需要多次网络通信，资源需要等待并锁定，徒增资源等待时间
  • 协调者单点故障问题：如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务。
  • Commit阶段网络分区带来的数据不一致：非所有节点都收到Commit请求

两个问题：

日志被保存在「可靠」的存储设备上。如何保证这一点？

  • 高可用硬件来保证
  • 分布式时，建立分布式kv系统等

参与者Commit了，但Ack信息协调者没收到。怎么办？

  • 回滚（虽然很浪费时间和资源）

三阶段提交

image.png

针对两阶段提交的补充，将两阶段提交中的Prepare阶段，拆成两部分：CanCommit和PreCommit机制并引入了超时机制，解决了单点故障问题和阻塞问题：
  • CanCommit阶段：询问是否可以执行；PreCommit阶段：重新确认是否可以执行
  • DoCommit阶段：向所有人提交事务

相对于2PC，3PC协调者和参与者都设置的超时时间（2PC中只有协调者有超时时间），主要解决的单点故障问题，并减少阻塞，因为一旦参与者无法及时收到来自协调者的信息之后，他会默认执行commit，而不会一直持有事务资源并处于阻塞状态。但是这种机制也会导致数据一致性问题，因为，由于网络原因，协调者发送的abort响应没有及时被参与者接收到，那么参与者在等待超时之后执行了commit操作，这样就和其他接到abort命令并执行回滚的参与者之间存在数据不一致的情况。

MVCC

MVCC：多版本并发控制的方法。维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。提高并发性能的同时也解决了脏读的问题。

悲观锁和乐观锁

  • 悲观锁：操作数据时直接把数据锁住，直到操作完成后才会释放锁；上锁期间其他人不能修改数据
  • 乐观锁：不会上锁，只是在执行更新时判断别人是否修改数据，只有冲突时才放弃操作

版本的选取：使用物理时钟或逻辑时钟

  • 物理时钟：提供TrueTime API，有Master节点维持一个绝对时间，保证各个服务器之间时钟误差控制在ϵ内，通常ϵ<7ms，如下图所示。
  • 逻辑时钟：中心化授时的方式--时间戳预言机（TSO），所有协调者向中心化节点获取时钟，方法简单，实现方便，但需要每个节点都与他进行交互，会产生一些网络通信的成本。TSO的授时中就需要考虑性能以及更好的容错性。

image.png

共识协议

Quorum NWR模型

  • 三要素：

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

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

RAFT协议

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

  • 三种角色

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

  • 四种定义：

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

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

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

image.png

Leader选举过程：

  • 初始全部为Follower

  • Current Term + 1

  • 选举自己

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

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

Log Replication过程：

  • 新Leader产生，Leader和Follower不同步，Leader强制覆盖Followers的不同步的日志
avatar
文章
阅读
粉丝