这是我参与「第五届青训营 」伴学笔记创作活动的第 9 天，参与青训营的第19天。今天主要学习了分布式理论。
分布式：
分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。可以分为分布式计算，分布式存储，分布式数据库等。
优势：
1、去中心化
2、低成本
3、弹性
4、资源共享
5、可靠性
挑战：
1、普遍的节点故障
2、不可靠的网络
3、异构的机器与硬件环境
4、安全性
常见的分布式系统
分布式存储：
1、Google File System （GFS）
2、Ceph
3、Hadoop HDFS
4、Zookeeper
分布式数据库：
1、Google Spanner
2、TiDBi
3、HBase
4、MongoDB
分布式计算：
1、Hadoop
2、Spark
3、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的基础上增加了错误可检测的假设
拜占庭将军问题
两个将军：
结论：两将军问题被证实无解的电脑通信问题，两支军队理论上永远无法达成共识。
TCP三次握手是在两个方向确认包的序列号，增加了超时重试，是两将军问题的一个工程解。
更普适的场景下的拜占庭将军问题。
共识和一致性
最终一致性和线性一致性。
如果要保证“线性”一致性，多个节点间势必需要进行协商，以寻求一致。正要增加了延迟，系统可用性便会受损。
时间和时间顺序
基础理论
CAP理论
CAP理论往往运用于数据库领域，同样可以适用于分布式存储方向
CA : 放弃分区容错性，加强一致性和可用性，其实就是传统的单机数据库的选择
AP : 放弃一致性（强一致性），追求分区容错性和可用性，例如一些注重用户体验的系统。
CP : 放弃可用性，追求一致性和分区容错性，例如与钱财安全相关的系统。
无法同时满足CAP三种选项。
ACID理论
事务时数据库系统中非常重要的概念，它是数据库管理系统执行过程中的一个逻辑单元，它能够保证一个事务中的所有操作要么全部执行，要么全都不执行。
数据库事务拥有四个特征ACID，即分别是原子性（Atomicity），一致性（Consistency），隔离性（Isolation）和持久性（Durability）。
原子性（A） ：原子性是指事务包含的所有操作要么全部成功，要么全部失败回滚。
一致性（C） ：一致性是指事务性必须使数据库从一个一致性变换到另一个一致性状态，也就是说一个事务执行之前和执行之后都必须处于一致性状态。
隔离性（I）：隔离性是当多个用户并发访问数据库时，数据库为每一个用户开启的事务，不能被其他事务的操作所干扰，多个并发事件之间要相互隔离。
持久性（D）：持久性是指一个事务一旦被提交了，那么对数据库中的数据的改变就是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失事务的操作。
BASE理论
Base理论是对CAP中一致性和可用性权衡的结果，其来源于对大型互联网分布式实践的总结，是基于CAP定理逐步演化而来的。
核心思想为
Basically Available（基本可用）：假设系统出现了不可预知的故障，但还是能用，相比较正常的系统而言：响应时间上的损失，或功能上的损失。
Soft state（软状态）：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。
Eventually consistent（最终一致性）：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能偶达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。
分布式事务
两阶段提交（Two-phase Commit）
为了使基于分布式系统架构下的所有节点在进行事务提交时保持一致性而设计的一种演算法。
三个假设：
1、引入协调者（Coordinator）和参与者（Participants），互相进行网络通信。
2、所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上。
3、所有节点不会永久性损坏，即使损坏后仍然可以恢复。
可能出现的情况：
- Coordinator不宕机，Participants宕机。需要进行回滚操作。
- Coordinator宕机，Participants不宕机。可以起新的协调者，待查询状态后，重复二阶段提交。
- Coordinator宕机，Participants宕机。无法确认状态，需要数据库管理员的接入，防止数据库进入一个不一致的状态。
注意的问题：
1、性能问题
两阶段提交需要多次结点间的网络通信，耗时过大，资源需要进行锁定，徒增资源等待时间。
2、协调者单点故障问题
如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务。
3、网络分区带来的数据不一致
一部分参与者收到了Commit消息，另一部分参与者没收到Commit消息，会导致了节点之间的数据不一致。
三阶段提交
将两阶段提交中的Prepare阶段，拆成两部分：Can Commit和PreCommit机制。
解决了：单点故障问题 ；阻塞问题
另外引入超时机制，在等待超时之后，会继续进行事物的提交。
MVCC
MVCC是一种并发控制的方法，维持一个数据的各个版本使读写操作没有冲突。所以既不会阻塞写，也不会阻塞读。MVCC为每个修改保存一个版本，和事务的时间戳相关联。可以提高并发性能，解决脏读的问题。
提供他物理时钟，或者使用时间戳预言机（TSO），采用中心化的授时方式，所有协调者向中心化节点获取时钟。优点是算法简单，实现方便，但需要每个节点都与它进行交互，会产生一些网络通信的成本。TSO的授时中就需要考虑低延迟，高性能以及更好的容错性。
共识协议
Quorum NWR模型
N：在分布式存储系统中，有多少份备份数据
W：代表一次成功的更新操作要求至少有w分数据写入成功
R：代表一次成功的读数据操作要求至少有R份数据成功读取。
为了保证强一致性，需要保证 W+R>N
Quorum NWR模型将CAP的选择交给用户，是一种简化版的一致性模型。
RAFT协议
Raft协议是一种分布式一致性算法（共识算法），即使出现部分节点故障，网络延时等情况，也不影响各节点，进而提高系统的整体可用性。Raft是使用较为广泛的分布式协议。一定意义上讲，RAFT也使用了Quorum机制。
Leader-领导者，通常一个系统中是一主（Leader）多从（Follower）。Leader负责处理所有的客户端请求，并向Follower同步请求日志，当日志同步到大多数节点上后，通知Follower提交日志。
Follower-跟随者，不会发送任何请求。接受并持久化Leader同步的日志，在Leader告知日志可以提交后，提交日志。当Leader出现故障时，主动推荐自己为Candidate。
Candidate-备选者，Leader选举过程中的临时角色。向其他节点发送请求投票信息。如果获得大多数选票，则晋升为Leader。
Leader选举过程：
- 在一个任期内每个参与者最多投一票（持久化）
- 要成为Leader，必须拿到多数投票
Log Replication过程：
新Leader产生，Leader和Follower不同步，Leader强制覆盖Followers的不同步的日志。
Paxos协议
分布式实践
MapReduce
分布式KV
今日总结：
今日学习当今应用广泛的分布式理论，对于多个机群合作以提供更好性能提供了知识理论，从常见的分布式系统到系统模型，和分布式的基础理论，最后是共识协议。
