这是我参与第五届青训营笔记创作活动的第14天，今天我将继续总结分布式理论的相关内容，今天主要总结分布式理论中分布式事务、共识协议以及实践的相关理论知识。

分布式事务

两阶段提交

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

失败回滚：

需要考虑的问题：

性能问题

两阶段提交需要多次节点间的网络通信，耗时过大，资源需要进行锁定，徒增资源等待时间。
协调者单点故障问题

如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务。
网络分区带来的数据不一致

一部分参与者收到了Commit消息，另一部分参与者没收到Commit消息，会导致了节点之间数据不一致。

三阶段提交

将两阶段提交中的Prepare阶段，拆成两部分∶CanCommit和PreCommit机制

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

另外引入超时机制，在等待超时之后，会继续进行事务的提交。

MVCC

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

实现的两种方式：TrueTime API、时间戳预言机(TSO)

共识协议

Quorum NWR模型

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。

Log(日志）︰节点之间同步的信息，以只追加写的方式进行同步，解决了数据被覆盖的问题
Term(任期号)）:单调递增，每个Term内最多只有一个Leader
Committed:日志被复制到多数派节点，即可认为已经被提交
Applied :日志被应用到本地状态机︰执行了log中命令，修改了内存状态

Paxos协议

Paxos算法与RAFT算法区别:

Multi-Paxos可以并发修改日志，而Raft写日志操作必须是连续的
Multi-Paxos可以随机选主，不必最新最全的节点当选Leader
Paxos优势:写入并发性能高，所有节点都能写入
Paxos劣势︰没有一个节点有完整的最新的数据，恢复流程复杂，需要同步历史记录

分布式实践

MapReduce

Mapper :将输入分解为多个Job来并行处理。彼此间几乎没有依赖关系

Shuffler : 将maper结果打乱，防止数据倾斜

Reducer :对map阶段的结果进行全局汇总

分布式KV

架构︰

将海量结构化数据根据Key分成不同的Region，每个Region构建一个单机KV数据库，Region之间形成Raft Groups ,做到强一致

容错:

当Node故障时，通过Raft Learner模式进行数据修复

弹性:

当出现局部Key热点或数据膨胀时，Region可以进行Split操作，分成两个子Region，反之收缩时进行Merge操作

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