这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天
分布式理论
分布式概述
什么是分布式?
分布式系统是计算机程序的集合,这些程序利用跨多个独立节点的资源来实现共同的目标,可以分为分布式计算、分布式存储和分布式数据库等。
分布式系统的优点:
- 去中心化、低成本(可以运行在廉价的服务器集群上,而不需要大型机的支持)
- 弹性、资源共享
- 可靠性高
分布式系统的挑战:
- 普遍的节点故障(节点数目大,即便单个节点故障概率低,总体故障很常见)
- 网络不可靠(网络延迟、网络出错)
- 异构的软硬件环境
- 安全(服务器集群被攻破时影响面广)
Why,How,What?
-
Why?
- 数据量爆炸,对存储和计算有大规模运用的需求
- 分布式系统可以构建在廉价服务器集群之上
-
How
- 使用分布式框架
- 搭建成熟的分布式系统
-
What
- 理清规模,负载和一致性要求等
- 明确稳定性要求,制定技术方案
常见的分布式系统有哪些?
常见的分布式系统可以分为三类:
-
分布式存储
- GFS、Ceph、 HDFS、Zookeper等
-
分布式数据库
- Google Spanner、TiDB、HBase、MongoDB
-
分布式计算
- Hadoop、Spark、YARN
系统模型
故障模型
从Byzantine failure、ADB、Performance failure、Omission failure、Crash failure到Fail-stop的6种模型,从广义到狭义的一个划分。
- 在分布式系统中,一个慢速的服务甚至比彻底故障无法响应的服务更糟糕
- 磁盘、网络、服务器、CPU故障等硬件故障和软件故障可能引发上述的故障模型的任何一种
拜占庭将军问题
一组拜占庭将军分别带领军队围攻一座城市,将军之间通过投票来达成一致策略进攻或者撤退,他们通过信使沟通,是否能达成共识?
系统的问题在于信使中可能存在叛徒(对应分布式系统网络出错的情况),使得不同的将军得出不同的结论(对应分布式系统中的一致性破坏)。
理论上可以得出,如果有3m+1个将军,可以容纳m个叛徒,通过m轮协商达成一致。
共识与一致性
多个客户端同时读写同一份数据时可能发生一致性问题,我们可以将一致性分为如下几类:
-
最终一致性(Eventually Consistent)
例如C在写入数据,此时A和B并发读取时可能读到旧值,但是当写入完成后,A和B最终能读到一致的数据
-
线性一致性(Linearizability):也称为强一致性
当一个客户端A读取到更新的版本后(会同步给其他客户端),所有其他的客户端读到的不会再是旧版本(不会发生回退)。
要求强一致性就会导致可用性下降(有额外的同步开销)
时间与事件顺序
-
happens before关系 a->b
- 同一个节点上,a在b之前发生
- 不同节点上a与b有因果关系
- 传递性,a->b, b->c =》 a->c
-
并发:
- 当a与b之间没有任何happens before关系时,两者是并发的
-
Lamport逻辑时钟:
- 可以对整个系统中的所有事件,按照一个逻辑时钟进行全局排序
分布式理论基础
CAP理论
- Consistence:数据的一致性
- Availability:服务的可用性
- Network Partitioning:网络分区容错
CAP理论即任何一个系统,只能在上述三者中保证两者,必须放弃一个。
对于分布式系统而言,P是必然的,因此只能在一致性和可用性之间选择一个。
ACID理论
ACID理论是数据库中的重要理论,它用来保证一个事务中的所有操作要么全部执行,要么全部不执行。
ACID即Atomicity原子性,Consistency一致性,Isolation隔离性和Durability持久性。
-
ACID的一致性与CAP的一致性不一样,指的是事务的一致性:
- 例如A向B转账的事务,无论发生多少次,A和B的账号总额是不变的。
BASE理论
BASE理论是对CAP中一致性和可用性权衡的结果:
- Basically Available(基本可用):假设系统出现故障,可以允许存在响应时间上或者功能上的损失
- Soft state(软状态):允许中间状态存在,即允许不同节点的数据副本有延迟
- Eventually consistent(最终一致性):没有其他操作的情况下,数据最终一定能达到一致
一些互联网应用可能不需要很高的一致性,例如评论系统就不需要金融相关系统相关的一致性要求。
分布式事务
以转账为例,A向B转账的事务如果发生在分布式系统中,会需要一些手段来保证事务。
2PC
二阶段提交:为了使分布式系统所有节点在进行事务提交时保证一致性而设计的算法。
两个阶段是Prepare和Commit,通过协调者来执行,当失败时进行回滚,以保证一致性。
日志保存在【可靠】的存储设备上(例如TiDB将日志保存到TiKV上)
3PC
在2pc的基础上将prepare阶段分成了Can Commit和Pre Commit两个阶段,解决了单点故障和阻塞问题,但仍然存在性能问题和网络分区带来的数据一致性问题。
MVCC
-
锁的概念
- 悲观锁:操作时将数据锁住,操作完成后释放锁,期间无法被其他人修改
- 乐观锁:不会加锁,在执行更新是通过版本编号来判断其他人是否修改了数据,如果修改了则放弃操作
MVCC是一个并发版本控制的方法,维持一个数据的多个版本使得读写操作不冲突,所以不会阻塞写,也不会阻塞读。MVCC为每一个修改保存一个版本,和事务的时间戳相关联,可以提高并发性能,解决脏读的问题。
时间戳的实现:
- Spanner提到的通过一个同步的物理时钟来使得任何机器的时间戳偏差在1到7ms之间
- TSO通过一个中心化的服务器分发网络时钟,可以不依赖硬件但是会增加网络通信开销
共识协议
- Quorum NWR模型
- RAFT协议
- Paxos协议