前言

这是我参与【第五届青训营】伴学笔记创作活动第八天，今天的学习重点是什么是分布式，怎么用分布式，分布式是做什么的。

正文

1. 分布式定义：

分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源实现共同目标，可以分步式计算，分布式存储，分布式数据库等

2. 分布式优点：

去中心化，低成本，弹性，资源共享，可靠性高。分布式挑战：普遍的节点故障，不可靠网络，异构的机器与硬件环境，安全。

3. Why-How-What：

使用者视角：

WHY：数据爆炸，对存储和计算有大规模运用的述求，成本低，构建再廉价的服务器上。

HOW：分布式架构，成熟的分布式系统。

WHAT：理清规模，负载，一致性要求等，明确稳定性要求，指定稳定性要求，制定技术方案等

学习者视角：

WHY:后端开发必备技能，帮助理解后台服务器之间协作的机理

HOW：掌握分布式理论，了解一致性协议

what：把要点深入展开，针对难点搜索互联网进程，将所学的知识用于实践。

4. 系统模型

- 故障模型：

• Byzantine failure ：节点可以任意篡改发送给其他节点的数据
• Authentication detectable byzantine failure ( ADB ): Byzantine failure 的特例；节点可以篡改数据，但不能伪造其他节点的数据
• Performance failure ：节点未在特定时间段内收到数据，即时间太早或太晚
• Omission failure ：节点收到数据的时间无限晚，即收不到数据
• Crash failure ：在 omission failure 的基础上，增加了节点停止响应的假设，也即持续性地 omission failure
• Fail - stop failure ：在 Crash failure 的基础上增加了错误可检测的假设
• 拜占庭将军问题
• 共识和一致性
• 时间和事件顺序

5. 理论基础

- CAP理论

• C（Consistence ）：一致性，指数据在多个副本之间能够保持一致的特性（严格的一致性）
• A ( Availability）可用性，指系统提供的服务必须一直处于可用的状态，每次请求都能获取到非错的响应﹣﹣但是不保证获取的数据为最新数据。
• P ( Network partitioning )： 分区容错性，分布式系统在遇到任何网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务，除非整个网络环境都发生了故障。
• 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 （最终一致性）：系统能够保证在没有其他新的更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取到最新的值。

5.分布式事务

- 两阶段提交：

• 为了是基于分布式系统架构下所有节点进行事务提交时保持一致性而设计的一种演算法
• 三个假设：
• 1.引入协调者和参与者，互相进行网络通信
• 2.所有节点都采用预写式日志，且日志被写入后即被保持在可靠的存储设备上
• 3.所有节点不会永久性损坏，即使损坏后仍然可恢复
• 可能出现情况：
• 情况1) Coordinator 不宕机， Participant 宕机。如下图所示，需要进行回滚操作
• 情况2) Coordinator 宕机， Participant 不宕机。可以起新的协调者，待查询状态后，重复二阶段
• 提交情况3) Coordinator 宕机， Participant 宕机。
• 回滚：在 Prepare 阶段，如果某个事务参与者反馈失败消息，说明该节点的本地事务执行不成，必须回滚。
• 情况3：无法确认状态，需要数据库管理员的介入，防止数据库进入一个不一致的状态。
• 需注意问题：
• 1.性能问题：两阶段提交需要多次节点间的网络通信，耗时过大，资源需要进行锁定，徒增资源等待时间。
• 2.协调者单点故障问题：如果事务协调者节点宕机，需要另起新的协调者，否则参与者处于中间状态无法完成事务
• 3.网络分区带来的数据不一样：一部分受到了Commit消息，另一部分参与者没收到Commit消息，会导致节点之间数据不一致。

- 三阶段提交

• 将两阶段提交中Prepare阶段，拆分为两阶段：CanCommit和PreCommit机制
• 解决了两个问题：单点故障问题和阻塞问题
• 另外引入了超时机制，在等待超市之后，会继续进行事务的提交

6.共识协议

- MVCC：

• 悲观锁：操作数据时直接把数据锁住，知道操作完成后才会释放锁，上锁期间其他人不能修改数据
• 乐观锁：不会上锁，只是执行更新时判断别人是否修改数据，只有冲突时放弃操作
• MVCC是一种并发控制方法，维持一个数据的多个版本使读写操作没有冲突，既不会阻塞写，又不会阻塞读，MVCC为每个修改保存一个版本，和事务的时间戳相关联。可以提高并发性能，可以解决脏读问题。

- Quorum NWR模型

• Quorum NWR 三要素
• N ：在分布式存储系统中，有多少份备份数据。
• W ：代表一次成功的更新操作要求至少有 w 份数据写入成功
• R ：代表一次成功的读数据操作要求至少有 R 份数据成功读取
• 为了保证强一致性，需要保证 W + RxN
• 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中命令，修改了内存状态
• 切主： 当 Leader 出现问题时，就需要进行重新选举。

1. Leader 发现失去 Follower 的响应，失去 Leader 身份2．两个 Follower 之间一段时间未收到心跳，重新进行选举，选出新的 Leader ，此时发生了切主
2. Leader 自杀重启，以 Follower 的身份加入进来问题：老 leader 未失去身份，新 leader 已经选出，产生了"双主"，该如何解决呢？

• Stale 读： 发生 Leader 切换， old leader 收到了读请求。如果直接响应，可能会有 Stale Read 。
• 解决方案，保证读的强一致
• 读操作在 lease timeout 内，默认自己是 leader ;不是则发起一次 heartbeat ，等待 Commit Index 应用到状态机。 自从上次心跳之后一定超过了 Election Election timeout > lease timeout ：新 leader 上任，自从上次心跳之后一定超过了 Election timeout ,旧 leader 大概率能够发现自己的 Lease 过期

- Paxos协议

• Paxos 算法与 RAFT 算法区别：
• 1. Multi - Paxos 可以并发修改日志，而 Raft 写日志操作必
• 2. Multi - Paxos 可以随机选主，不必最新最的节点当选 Leader
• Paxos 优势：写入并发性能高，所有节点都能写入
• Paxos 劣势：没有一个节点有完整的最新的数据，恢复流程 Accept ( n , value ）到所有节复杂，需要同步历史记录。

7.分布式实践

-MapReduce

- 分布式KV

• 架构： 将海量结构化数据根据 Key 分成不同的 Region ，每个 Region 构建一个单机 KV 数据库， Region 之间形成 Raft Groups ,做到强一致
• 容错： 当 Node 故障时，通过 Raft Learner 模式进行数据修复
• 弹性： 当出现局部 Key 热点或数据膨胀时， Region 可以进行 Split 操作，分成两个子 Region ，反之收缩时进行 Merge 操作