这是我参与「第五届青训营」伴学笔记创作活动的第 8 天
分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可以分为分布式计算、分布式存储、分布式数据库等。
- 优势
- 去中心化
- 低成本
- 弹性
- 资源共享
- 可靠性高
- 挑战
- 普遍的节点故障
- 不可靠的网络
- 异构的机器与硬件环境
- 安全
- 常见的分布式系统
- 故障模型
- 拜占庭将军问题
共识和一致性
- 最终一致性：客户端A读到x=0，当客户端C正在写入时，客户端A和B可能读到0或者1。但是当C写入完成后，A和B最终能读到一致的数据。我们称这样的一致性为Eventuallyconsistent(最终一致性)
- 线性一致性：当客户端A读到更新的版本x=1后，及时将消息同步给其他客户端，这样其他客户端立即能获取到x=1。我们称这样的一致性为Linearizability(线性一致性)
时间和事件顺序
理论
CAP理论
- CAP理论往往运用于数据库领域，同样可以适用于分布式存储方向
- CA:放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择
- AP:放弃一致性（这里说的一致性是强一致性)，追求分区容错性和可用性，例如一些注重用户体验的系统
- CP:放弃可用性，追求一致性和分区容错性，例如与钱财安全相关的系统
ACID理论
BASE理论
- Base理论是对CAP中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于CAP定理逐步演化而来的。其核心思想是:
- Basically Available(基本可用):假设系统，出现了不可预知的故障，但还是能用，相比较正常的系统而言:响应时间上的损失,或功能上的损失
- Soft state(软状态)∶允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
- Eventually consistent(最终一致性)∶系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。
二阶段提交
- 二阶段提交(Two-phase Commit):为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的—种演算法。
- 三个假设:
- 引入协调者(Coordinator)和参与者(Participants)，互相进行网络通信
- 所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
- 所有节点不会永久性损坏，即使损坏后仍然可以恢复
- 可能出现的情况
- 问题
三阶段提交
- 将两阶段提交中的Prenare阶段拆成两部分CanCommit和PreCommit机制
- 解决单点故障、阻塞问题
- 另外引入超时机制，在等待超时之后，会继续进行事务的提交。
三阶段提交在二阶段算法的基础上进行了优化和改进。在整个三阶段提交的过程中，相比二阶段提交，增加了预提交阶段。
-
canCommit阶段：协调者首先询问所有的参与者的状态，当前是否可以执行业务；如果可以\不可以执行，就直接返回可以/不可以。
-
preCommit阶段：协调者根据参与者canCommit阶段的响应来决定是否可以继续事务的preCommit操作。preCommit阶段和二阶段提交里面的请求阶段一致
- 协调者通知每个参与者准备提交
- 参与者在本地执行事务：
- 执行成功后，并不提交，告知协调者自己本地已经执行成功；
- 执行失败后，告知协调者本地作业执行故障
-
doCommit阶段：协调者根据参与者preCommit阶段的响应来决定是否可以继续事务的doCommit操作。 发送doCommit后，若接收到了所有参与者的haveCommitted响应，则执行成功；若仅接收到了部分haveCommitted响应，则事务执行中断。
MVCC
- MVCC是一种并发控制的方法，维持一个数据的多个版本使读写操作没有冲突。所以既不会阻塞写，也不阻塞读。MVCC为每个修改保存一个版本，和事务的时间戳相关联。可以提高并发性能，解决脏读的问题。
- 另外一种时间戳的实现:时间戳预言机(TSO)，采用中心化的授时方式，所有协调者向中心化节点获取时钟。优点是算法简单，实现方便，但需要每个节点都与他进行交互，会产生一些网络通信的成本。TSO的授时中就需要考虑低延迟，高性能以及更好的容错性。
共识协议
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。
