1、分布式理论
1.1 分布式架构系统回顾
1.1.1 分布式系统概念
分布式系统
- 分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统
- 通俗的理解，所谓分布式系统，就是一个业务拆分成多个子业务，分布在不同的服务器节点，共同构成的系统称为分布式系统
- 同一个分布式系统中的服务器节点在空间部署上是可以随意分布的
- 这些服务器可能放在不同的机柜中，也可能在不同的机房中，甚至分布在不同的城市
分布式与集群的区别
- 集群：多个人在一起作同样的事
- 分布式 ：多个人在一起作不同的事
- 集群和分布式的对比图
分布式系统的特点
- 分布性：分布式系统最显著的特点肯定就是分布性，以电商网站为例不同的微服务(如用户微服务、产品微服务，订单微服务等)部署在不同的tomcat中，不同的服务器中，甚至不同的集群中，整个架构都是分布在不同的地方的，在空间上是随意的，而且随时会增加，删除服务器节点
- 对等性：对等性是分布式设计的一个目标，还是以电商网站为例，比如订单服务，为了防止订单服务出现问题就需要2个或者以上的订单服务，这些服务之间完全是对等的，功能是完全一致的
- 并发性：一个分布式系统中的多个节点，可能会并发地操作一些共享资源
- 缺乏全局时钟：在分布式系统中节点可能是任意位置的，每个节点都有自己的时间系统，很难定义两个事务究竟谁先谁后，通过时间服务器解决
- 故障总是会发生：任何一个节点都可能出现停电、死机等现象，服务器集群越多出现故障的可能性就越大，怎么样保证在系统某些节点出现故障的情况下分布式系统是可用的，也是分布式系统架构应该考虑的
1.1.2 分布式系统的发展
什么是IOE
- I指的是IBM小型机
- O指的是Oracle数据库
- E指的是EMC的高端存储
为什么要去IOE
- 升级单机处理能力的性价比越来越低
- 单机处理能力存在瓶颈
- 稳定性和可用性这两个指标很难达到
1.1.3 分布式架构的演变
-
阶段一：单体应用架构
-
阶段二：应用服务器与数据服务器分离
-
阶段三：应用服务器集群
-
阶段四：应用服务器负载用户请求
-
阶段五：数据库读写分离
-
阶段六：添加所搜引擎解决读库的压力
-
阶段七：添加缓存机制解决数据库压力
-
阶段八：数据库的水平/垂直拆分
-
阶段九：应用拆分
-
阶段十：服务化
1.2 分布式系统面临的问题
1.2.1 通信异常
- 网络本身的不可靠性，因此每次网络通信都会伴随着网络不可用的风险
- 光纤、路由、DNS等硬件设备或系统的不可用等都会导致最终分布式系统无法顺利进行一次网络通信
- 即使分布式系统各节点之间的网络通信能够正常执行，其延时也会大于单机操作，存在巨大的延时差别，也会影响消息的收发过程，因此消息丢失和消息延迟变的非常普遍
1.2.2 网络分区
- 网络之间出现了网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域
- 分布式系统会出现局部小集群
- 在极端情况下，这些小集群会独立完成原本需要整个分布式系统才能完成的功能，包括数据的事务处理，这就对分布式一致性提出非常大的挑战
1.2.3 节点故障
- 节点故障是分布式系统下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象
- 根据经验来说，每个节点都有可能出现故障，并且经常发生
1.2.4 三态
- 分布式系统每一次请求与响应存在特有的"三态"概念(成功、失败和超时)
- 分布式系统中，由于网络是不可靠的，虽然绝大部分情况下，网络通信能够接收到成功或失败的响应，但当网络出现异常的情况下，就会出现超时现象
- 通常有两种情况导致超时：
1）由于网络原因，该请求并没有被成功的发送到接收方，而是在发送过程就发生了丢失现象
2）该请求成功的被接收方接收后，并进行了处理，但在响应反馈给发送方过程中，发生了消息丢失现象
1.3 分布式理论：一致性
1.3.1 什么是分布式一致性
分布式数据一致性，指的是数据在多份副本中存储时，各副本中的数据是一致的
1.3.2 副本一致性
- 如果是一台数据库处理所有的数据请求，那么通过ACID四原则，基本可以保证数据的一致性
- 分布式系统当中，数据往往会有多个副本。这就带来了同步的问题，因为我们几乎没有办法保证可以同时更新所有机器当中的包括备份所有数据
- 网络延迟，即使我在同一时间给所有机器发送了更新数据的请求，也不能保证这些请求被响应的时间保持一致存在时间差，就会存在某些机器之间的数据不一致的情况
- 总得来说，我们无法做到既保证数据的一致性，同时又不影响系统运行的性能。于是，一致性级别由此诞生（一致性分类）
1.3.3 一致性分类
强一致
这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。但是强一致性很难实现。
弱一致
这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。
-
读写一致性：用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容
方案1：一种方案是对于一些特定的内容我们每次都去主库读取
方案2：我们设置一个更新时间窗口，在刚刚更新的一段时间内，我们默认都从主库读取，过了这个窗口之后，我们会挑选最近有过更新的从库进行读取
方案3：我们直接记录用户更新的时间戳，在请求的时候把这个时间戳带上，凡是最后更新时间小于这个时间戳的从库都不予以响应 -
单调读一致性：本次读到的数据不能比上次读到的旧
解决方案：就是根据用户ID计算一个hash值，再通过hash值映射到机器。同一个用户不管怎么刷新，都只会被映射到同一台机器上。这样就保证了不会读到其他从库的内容，带来用户体验不好的影响。 -
因果一致性：指的是：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于
此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。 -
最终一致性：最终一致性是所有分布式一致性模型当中最弱的。不考虑所有的中间状态的影响，只保证当没有新的更新之后，经过一段时间之后，最终系统内所有副本的数据是正确的。它最大程度上保证了系统的并发能力，也因此，在高并发的场景下，它也是使用最广的一致性模型。
1.4 分布式理论：CAP定理
1.4.1 CAP 定理
- CAP定理是指一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A: Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个
- CAP分别解读
| 选项 | 描述 |
|---|---|
| C 一致性 | 分布式系统当中的一致性指的是所有节点的数据一致，或者说是所有副本的数据一致 |
| A 可用性 | Reads and writes always succeed. 也就是说系统一直可用，而且服务一直保持正常 |
| P 分区容错性 | 系统在遇到一些节点或者网络分区故障的时候，仍然能够提供满足一致性和可用性的服务 |
- CAP只能3选2
- 三种排列组合
| 选择 | 描述 |
|---|---|
| 舍弃A(可用性)，保留CP(一致性和分区容错性) | 一个系统保证了一致性和分区容错性，舍弃可用性。也就是说在极端情况下，允许出现系统无法访问的情况出现，这个时候往往会牺牲用户体验，让用户保持等待，一直到系统数据一致了之后，再恢复服务。 |
| 舍弃C(一致性)，保留AP(可用性和分区容错性) | 这种是大部分的分布式系统的设计，保证高可用和分区容错，但是会牺牲一致性。 |
| 舍弃P(分区容错性)，保留CA(一致性和可用性) | 如果要舍弃P，那么就是要舍弃分布式系统，CAP也就无从谈起了。可以说P是分布式系统的前提，所以这种情况是不存在的。 |
1.5 分布式理论：BASE理论
1.5.1 什么是BASE理论
- BASE全称：Basically Available(基本可用)、Soft state（软状态）、 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。
- BASE是对CAP中一致性和可用性权衡的结果，BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
1.5.2 Basically Available(基本可用)
- 基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性，但这绝不等价于系统不可用
- 响应时间上的损失：正常情况下一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒
- 功能上的损失：正常情况下，在一个电子商务网站（比如淘宝）上购物，消费者几乎能够顺利地完成每一笔
订单。但在一些节日大促购物高峰的时候（比如双十一、双十二），由于消费者的购物行为激增，为了保护
系统的稳定性（或者保证一致性），部分消费者可能会被引导到一个降级页面
1.5.3 Soft state（软状态）
- 硬状态：相对于一致性，要求多个节点的数据副本都是一致的
- 软状态：允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟
1.5.4 Eventually consistent（最终一致性）
- 最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态
- 最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性
1.6 分布式理论：分布式事务
1.6.1 数据库事务
事务有4个非常重要的特性，即我们常说的（ACID）
- Atomicity（原子性）:是说事务是一个不可分割的整体，所有操作要么全做，要么全不做；只要事务中有一个操作出错，回滚到事务开始前的状态的话，那么之前已经执行的所有操作都是无效的，都应该回滚到开始前的状态
- Consistency（一致性）：是说事务执行前后，数据从一个状态到另一个状态必须是一致的，比如A向B转账（A、B的总金额就是一个一致性状态），不可能出现A扣了钱，B却没收到的情况发生
- Isolation（隔离性）：多个并发事务之间相互隔离，不能互相干扰。并发事务是指两个事务操作了同一份数据的情况；而对于并发事务操作同一份数据的隔离性问题，则是要求不能出现脏读、幻读的情况，而为了解决这个问题，常用的手段就是加锁了，对于数据库来说就是通过数据库的相关锁机制来保证
- Durablity（持久性）：事务完成后，对数据库的更改是永久保存的
1.6.2 分布式事务
- 其实分布式事务从实质上看与数据库事务的概念是一致的，既然是事务也就需要满足事务的基本特性（ACID）
- 分布式事务相对于本地事务而言其表现形式有很大的不同
1.7 分布式理论：一致性协议2PC
1.7.1 什么是一致性协议2PC
2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Preparephase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段
1.7.2 一致性协议2PC的两个阶段过程
- 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数 据文件）
- 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源
1.7.3 一致性协议2PC执行流程
- 执行成功的流程
- 执行中断的流程
1.7.3 一致性协议2PC的优缺点
-
优点：原理简单，实现方便
-
缺点：同步阻塞，单点问题，数据不一致，过于保守
1）同步阻塞：二阶段提交协议存在最明显也是最大的一个问题就是同步阻塞，在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能
2）单点问题：协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作
3）数据不一致：假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完所有 commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题
4）过于保守：二阶段提交协议没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败
1.8 分布式理论：一致性协议3PC
1.8.1 什么是一致性协议3PC
- 一致性协议3PC全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议
- 流程图：
1.8.2 一致性协议3PC的3个阶段
-
阶段一：CanCommit
1）事务询问：协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应
2）各参与者向协调者反馈事务询问的响应：参与者在接收到来自协调者的包含了事务内容的canCommit请求后，正常情况下，如果自身认为可以顺利执行事务，则反馈Yes响应，并进入预备状态，否则反馈No响应 -
阶段二：PreCommit
情况一：执行事务预提交
1）发送预提交请求：协调者向所有参与者节点发出preCommit请求，并进入prepared阶段
2）事务预提交：参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中
3）各参与者向协调者反馈事务执行的结果：若参与者成功执行了事务操作，那么反馈Ack
情况二：中断事务
1）发送中断请求：协调者向所有参与者发出abort请求
2）中断事务：无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务 -
阶段三：doCommit
情况一：事务提交
1）发送提交请求：进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状态转化为提交状态，并向所有的参与者发送doCommit请求
2）事务提交：参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事务资源
3）反馈事务提交结果：参与者在完成事务提交后，向协调者发送Ack响应
4）完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务
情况二：事务回滚
1）发送中断请求：协调者向所有的参与者节点发送abort请求
2）事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整个事务执行期间占用的资源
3）反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息
4）中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务
1.8.3 2PC与3PC对比
- 在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到参与者的消息则默认失败;3PC对于协调者和参与者都设置了超时机制,主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下无法释放资源的问题，而这种机制也侧面降低了整个事务的阻塞时间和范围
- 通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的
- PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的
- 3PC协议也没有完全解决数据不一致问题
1.9 分布式理论：一致性算法Paxos
1.9.1 什么是Paxos算法
Paxos算法是Lamport提出的一种基于消息传递的分布式一致性算法
1.9.2 Paxos解决了什么问题
- 解决了分布式系统一致性问题
- Paxos算法需要解决的问题就是如何在一个可能发生异常的分布式系统中，快速且正确地在集群内部对某个数据的值达成一致
- 这里某个数据的值并不只是狭义上的某个数，它可以是一条日志，也可以是一条命令（command）。。。根据应用场景不同，某个数据的值有不同的含义
1.9.3 Paxos相关概念
- 提案（Proposal）：Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value)
- 客户端（Client）：客户端向分布式系统发出请求并等待响应，例如，对分布式文件服务器中文件的写请求
- 提案发起者（Proposer）：提案者提倡客户请求，试图说服Acceptor对此达成一致，并在发生冲突时充当协调者以推动协议向前发展
- 决策者（Acceptor）：Acceptor可以接受（accept）提案；如果某个提案被选定（chosen），那么该提案里的value就被选定了
- 最终决策的学习者（Learners）：学习者充当该协议的复制因素
1.9.4 问题描述
假设有一组可以提出提案的进程集合，那么对于一个一致性算法需要保证以下几点
- 在这些被提出的提案中，只有一个会被选定
- 如果没有提案被提出，就不应该有被选定的提案
- 当一个提案被选定后，那么所有进程都应该能学习（learn）到这个被选定的value
1.9.5 Paxos算法描述
算法执行过程
- 阶段一
1）Proposer选择一个提案编号N，然后向半数以上的Acceptor发送编号为N的Prepare请求。
2）如果一个Acceptor收到一个编号为N的Prepare请求，且N大于该Acceptor已经响应过的所有Prepare请求的编号，那么它就会将它已经接受过的编号最大的提案（如果有的话）作为响应反馈给Proposer，同时该Acceptor承诺不再接受任何编号小于N的提案。 - 阶段二
1）如果Proposer收到半数以上Acceptor对其发出的编号为N的Prepare请求的响应，那么它就会发送一个针对[N,V]提案的Accept请求给半数以上的Acceptor。注意：V就是收到的响应中编号最大的提案的value，如果响应中不包含任何提案，那么V就由Proposer自己决定
2）如果Acceptor收到一个针对编号为N的提案的Accept请求，只要该Acceptor没有对编号大于N的Prepare请求做出过响应，它就接受该提案
1.9.6 Learner学习被选定的value
1.9.7 如何保证Paxos算法的活性
- 通过选取主Proposer，并规定只有主Proposer才能提出议案
- 这样一来只要主Proposer和过半的Acceptor能够正常进行网络通信，那么但凡主Proposer提出一个编号更高的提案，该提案终将会被批准
- 这样通过选择一个主Proposer，整套Paxos算法就能够保持活性
1.10 分布式理论：一致性算法Raft
1.10.1 什么是Raf算法
- 概念：Raft是一种为了管理复制日志的一致性算法
- Raft算法将一致性算法分解成了3模块：
领导人选举
日志复制
安全性 - Raft算法分为两个阶段，首先是选举过程，然后在选举出来的领导人带领进行正常操作，比如日志复制等
1.10.2 领导人Leader选举
- Raft通过选举一个领导人，然后给予他全部的管理复制日志的责任来实现一致性
- 在Raft中任何一个服务器都可以扮演下面的角色之一
领导者(leader)：处理客户端交互，日志复制等动作，一般一次只有一个领导者
候选者(candidate)：候选者就是在选举过程中提名自己的实体，一旦选举成功，则成为领导者
跟随者(follower)：类似选民，完全被动的角色，这样的服务器等待被通知投票 - 选举的过程
➢初始状态下集群中的所有节点都处于 follower 状态
➢某一时刻，其中的一个 follower 由于没有收到 leader 的 heartbeat 率先发生 election timeout 进而发起选举
➢只要集群中超过半数的节点接受投票，candidate 节点将成为即切换 leader 状态
➢成为 leader 节点之后，leader 将定时向 follower 节点同步日志并发送 heartbeat
1.10.3 节点异常
节点的异常大致可以分为四种类型：
- loader不可用
- follower不可用
- 多个candidate或者多个leader
- 新节点加入集群
1.10.3.1 leader不可用
➢一般情况下，leader 节点定时发送 heartbeat 到 follower 节点
➢由于某些异常导致leader不再发送heartbeat，或follower无法收到heartbeat
➢当某一follower发生election timeout时，其状态变更为candidate，并向其他follower发起投票
➢当超过半数的follower接受投票后，这一节点将成为新的leader，leader的步进数加1，并开始向follower同步日志
➢当一段时间之后，如果之前的leader再次加入集群，则两个leader比较彼此的步进数，步进数低的leader将切换自己的状态为follower
➢较早前leader中不一致的日志将被清除，并与现有leader中的日志保持一致
1.10.3.2 follower不可用
➢集群中的某个follower节点发生异常，不再同步日志以及接收heartbeat
➢经过一段时间之后，原来的follower节点重新加入集群
➢这一节点的日志将从当时的leader处同步
1.10.3.3 多个candidate或者多个leader
➢初始状态下集群中的所有节点都处于follower状态
➢两个节点同时成为candidate发起选举
➢两个candidate都只得到了少部分follower的接受投票
➢candidate继续向其他的follower询问
➢由于一些follower已经投过票了，所以均返回拒绝接受
➢candidate也可能向一个candidate询问投票
➢在步进数相同的情况下，candidate将拒绝接受另一个candidate的请求
➢由于第一次未选出leader，candidate将随机选择一个等待间隔（150ms ~ 300ms）再次发起投票
➢如果得到集群中半数以上的follower的接受，这一candidate将成为leader
➢稍后另一个candidate也将再次发起投票
➢由于集群中已经选出leader，candidate将收到拒绝接受的投票
最低0.47元/天 解锁文章
扫一扫
2841
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
