分布式理论续 | 青训营笔记

88 阅读5分钟

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


本堂课主要内容是分布式理论,下面是我个人听课时的一些笔记,本篇笔记是《分布理论初探》的续篇,主要是关于分布式理论中的理论基础分布式事务共识协议三部分。

个人笔记

理论基础

  • CAP理论

    CAP中的C:Consistence

    一致性,指数据在多个副本之间能够保持一致的特性(严格的一致性)

    CAP中的A:Availability

    可用性,指系统提供的服务必须一致处于可用的状态,每次请求都能获取到非错的响应,但是不能保证获取的数据为最新数据

    CAP中的P:Network partitioning

    分区容错性,分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络都发生了故障

    但是CAP这三个特性不能做到全部兼顾,只能兼顾其中的两个方面

    • CA系统:放弃分区容错性,加强一致性和可用性,其实就是传统的单机数据库的选择
    • AP系统:放弃一致性(这里说的是强一致性),追求可用性和分区容错性,例如游戏等一些更注重用户体验的系统
    • CP系统:放弃可用性,追求一致性和分区容错性,如与金钱交易相关的系统
  • ACID理论

    事务是数据库系统中非常重要的概念,它是数据库管理系统执行过程中的一个逻辑单元,它能够保证一个事务中的所有操作要么全部执行,要么全都不执行。 数据库事务拥有四个特性ACID,即分别是原子性(Atomicity) 、一致性 (Consistency) 、隔离性(Isolation) 和持久性(Durability)

    • 原子性(A):原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚。
    • 一致性(C):一致性是指事务必须使数据库从一个致性状态变换到另一个致性状态,也就是说一个事务执行之前和执行之后都必须处于一致性状态。
    • 隔离性(I):隔离性是当多个用户并发访问数据库时,数据库为每一个用户开启的事务 ,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离。
    • 持久性(D):持久性是指一 个事务旦被提交了,那么对数据库中的数据的改变就是永久性的, 即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。

    原子性关注的是操作,一致性关注的是状态

  • BASE理论

    Base理论是对CAP中一致性可用性权衡的结果(可以看做一个AP系统,放弃对一致性的追求,更看重可用性),其来源于对大型互联网分布式实践的总结,是基于CAP定理逐步演化而来的。

分布式事务

  • 二阶段提交(Two- phase Commit) :为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。

    提交分为Prepare阶段和Commit阶段

  • 三阶段提交:将二阶段提交中的Prepare阶段,拆成两部分:CanCommit阶段和PrePare阶段,在CanCommit阶段询问是否可以执行,可以则进入PreCommit阶段,失败或超时则退出

    解决了单点故障问题和阻塞问题

  • MVCC

    悲观锁:操作数据时直接把数据锁住,直到操作完成后才会释放锁;上锁期间其他人不能修改数据

    乐观锁:不会上锁,只是在执行更新时判断别人是否修改数据,只有冲突时才放弃操作

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

共识协议

  • Quorum NWR模型

    该模型的三要素

    N:在分布式存储系统中,有多少份备份数据

    w:代表次成功的更新操作要求至少有w份数据写入成功

    R:代表次成功的读数据操作要求至少有R份数据成功读取

    为了保证强一致性, 需要保证W+R>N Quorum NWR模型将CAP的选择交给用户,是一种简化版的一 致性 模型。

  • RAFT协议

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

    RAFT中的节点有三种状态:Leader、Follower、Candidate

    Leader - 领导者,通常一个系统中是一主(Leader) 多从(Follower)。Leader 负责处理所有的客户端请求,并向Follower同步请求日志,当日志同步到大多数节点上后,通知Follower提交日志。

    Follower - 跟随者,不会发送任何请求。接受并持久化Leader同步的日志,在Leader告知日志可以提交后,提交日志。当Leader出现故障时,主动推荐自己为Candidate。 Candidate - 备选者,Leader选举过程中的临时角色。向其他节点发送请求投票信息。如果获得大多数选票,则晋升为Leader。

    image.png

  • Paxos协议

    课上只讲到Paxos算法与RAFT算法的区别:

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

    Paxos优势:写入并发性能高,所有节点都能写入

    Paxos劣势:没有一个节点有完整的最新的数据,恢复流程复杂,需要同步历史记录

参考