这是我参与「第五届青训营 」伴学笔记创作活动的第 8 天
分布式概述
分布式系统是计算机程序的集合,这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可以分为分布式计算、分布式存储、分布式数据库等。
常见的分布式系统
分布式存储
- Google File System(GFS)——google分布式文件系统
- Ceph——统一的分布式存储系统
- Hadoop HDFS——基于GFS架构的开源分布式文件系统
- Zookeeper——高可用的分布式数据管理和系统协调框架
分布式数据库
- Google Spanner
- TiDB——开源分布式关系型数据库
- Hbase——开源Nosql数据库
- MongoDB——文档数据库
分布式计算
- Hadoop——基于MapReduce分布式计算框架
- Spark——在hadoop基础上使用内存来存储数据
- YARN——分布式资源调度
系统模型
故障模型
- Byzantine failure:节点可以任意篡改发送给其他节点的数据
- Authentication detectable byzantine failure(ADB): Byzantine failure的特例;节点可以篡改数据,但不能伪造其他节点的数据
- Performance failure:节点未在特定时间段内收到数据,即时间太早或太晚
- Omission failure:节点收到数据的时间无限晚,即收不到数据
- Crash failure:在omission failure的基础上,增加了节点停止响应的假设,也即持续性地omission failure
- Fail-stop failure:在Crash failure的基础上增加了错误可检测的假设
拜占庭将军问题
两支军队的将军只能派信使穿越敌方领土互相通信,以此约定进攻时间。该问题希望求解如何在两名将军派出的任何信使都可能被俘虏的情况下,就进攻时间达成共识。
两将军问题是被证实无解的电脑通信问题,两支军队理论上永远无法达成共识
方案一:同时发送N个信使,任何一个达到对方军队,都算成功。
方案二:设置超时时间,发送后未在一定时间返回,则加派信使。
TCP三次握手是在两个方向确认包的序列号,增加了超时重试,是两将军问题的一个工程解。
拜占庭将军考虑更加普适的场景,例如3个将军ABC互相传递消息,消息可能丢失,也可能被篡改,当有一个将军是“叛徒”(即出现拜占庭故障)时,整个系统无法达成一致。
共识和一致性
客户端A读到x=0,当客户端C正在写入时客户端A和B可能读到O或者1。但是当C写入完成后,A和B最终能读到一致的数据。我们称这样的一致性为Eventually Consistent (最终一致性)
当客户端A读到更新的版本x=1后,及时将消息同步给其他客户端,这样其他客户端立即能获取到x=1。我们称这样的一致性为Linearizability(线性─致性)
如果要保证“线性”一致性,多个节点间势必需要进行协商,以寻求一致。这样增加了延迟,系统可用性便会受损
时间和事件顺序
- 如果a和b是在相同节点上的两个事件,a在b之前发生,则定义:a→b
- 如果事件a表示某个节点发送某条消息,b是另一个节点接受这条消息则有a→b
逻辑时钟
对于每一个节点Pi我们定义时钟Ci为一个函数,它为任意的事件a赋值编号为Ci(a)
- 如果a和b是在相同节点Pi上的两个事件,a在b之前发生,则有Ci(a)<Ci(b)
- 如果事件a表示节点Pi发送某条消息,b表示节点Pj接受这人消息,则有Ci(a)<Cj(b)
我们可以对整个系统中的事件进行全序排序
理论基础
CAP理论
- C (Consistence)一致性,指数据在多个副本之间能够保持一致的特性(严格的一致性)
- A (Availability)可用性,指系统提供的服务必须一直处于可用的状态,每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据。
- P (Network partitioning)分区容错性,分布式系统在遇到任何网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务,除非整个网络环境都发生了故障。 CAP三个条件无法同时满足,只能满足其中2个
ACID理论
数据库事务拥有四个特性ACID,即分别是原子性(Atomicity) 、一致性(Consistency )、隔离性( Isolation)和持久性(Durability)
- 原子性是指事务包含的所有操作要么全部成功,要么全部失败回滚。
- 一致性是指事务必须使数据库从一个一致性状态变换到另一个一致性状态,也就是说一个事务执行之前和执行之后都必须处于一致性状态
- 隔离性是当多个用户并发访问数据库时,数据库为每一个用户开启的事务,不能被其他事务的操作所干扰,多个并发事务之间要相互隔离
- 持久性是指一个事务一旦被提交了,那么对数据库中的数据的改变就是永久性的,即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。
分布式事务
二阶段提交
为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。
- 1.引入协调者(Coordinator)和参与者(Participants),互相进行网络通信
- 2.所有节点都采用预写式日志,且日志被写入后即被保持在可靠的存储设备上
- 3.所有节点不会永久性损坏,即使损坏后仍然可以恢复
情况1)Coordinator不宕机,Participant宕机。如下图所示,需要进行回滚操作
情况2)Coordinator宕机,Participant不宕机。可以起新的协调者,待查询状态后,重复二阶段提交
情况3)Coordinator宕机,Participant宕机。
需要注意的问题
- 性能问题
- 两阶段提交需要多次节点间的网络通信,耗时过大,资源需要进行锁定,徒增资源等待时间。
- 协调者单点故障问题
- 如果事务协调者节点宕机,需要另起新的协调者,否则参与者处于中间状态无法完成事务。
- 网络分区带来的数据不一致
- 一部分参与者收到了Commit消息,另一部分参与者没收到Commit消息,会导致了节点之间数据不一致。
三阶段提交
将两阶段提交中的Prepare阶段,拆成两部分:CanCommit和PreCommit机制
MVCC
悲观锁:操作数据时直接把数据锁住,直到操作完成后才会释放锁;上锁期间其他人不能修改数据
乐观锁:不会上锁,只是在执行更新时判断别人是否修改数据,只有冲突时才放弃操作
MVCC是一种并发控制的方法,维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写,c也不阻塞读。MVCC为每个修改保存一个版本,和事务的时间戳相关联。可以提高并发性能,解决脏读的问题。
共识协议
Quorum NWR模型
Quorum NWR三要素
- N:在分布式存储系统中,有多少份备份数据
- W:代表一次成功的更新操作要求至少有w份数据写入成功
- R:代表一次成功的读数据操作要求至少有R份数据成功读取
为了保证强一致性,需要保证W+R>N
RAFT协议
Raft协议是一种分布式一致性算法(共识算法),即使出现部分节点故障,网络延时等情况,也不影响各节点,进而提高系统的整体可用性。Raft是使用较为广泛的分布式协议。一定意义上讲,RAFT也使用了Quorum机制。
Leader -领导者,通常一个系统中是一主(Leader)多从(Follower)。Leader负责处理所有的客户端请求,并向Follower同步请求日志,当日志同步到大多数节点上后,通知Follower提交日志。
Follower -跟随者,不会发送任何请求。接受并持久化Leader同步的日志,在Leader告知日志可以提交后,提交日志。当Leader出现故障时,主动推荐自己为Candidate。
Candidate -备选者,Leader选举过程中的临时角色。向其他节点发送请求投票信息。如果获得大多数选票,则晋升为Leader。
Paxos协议
Paxos算法与RAFT算法区别: 1.Multi-Paxos可以并发修改日志,而Raft写日志操作必须是连续的 2.Multi-Paxos可以随机选主,不必最新最全的节点当选Leader Paxos优势:写入并发性能高,所有节点都能写入 Paxos劣势:没有一个节点有完整的最新的数据,恢复流程复杂,需要同步历史记录