目录
一、分布式概念
1.1、分布式系统的回顾
1.1.1 分布式系统概念
分布式系统是一个硬件或软件组件分布在不同的网络计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统。
俗的理解，所谓分布式系统，就是一个业务拆分成多个子业务，分布在不同的服务器节点，共同构成的系统称为分布式系统，同一个分布式系统中的服务器节点在空间部署上是可以随意分布的，这些服务器可能放在不同的机柜中，也可能在不同的机房中，甚至分布在不同的城市。
Tip：
分布式与集群的区别：
集群：多个人在一起作同样的事 。
分布式 ：多个人在一起作不同的事 。
分布式系统的特点：
-
分布性
多个服务以集群的方式
-
对等性
-
并发性
-
缺乏全局时钟
-
故障总是会发生
1.1.2 分布式系统的发展
阿里巴巴发起的"去 IOE"运动 (IOE 指的是 IBM 小型机、Oracle 数据库、EMC 的高端存储)。阿里巴巴2009 年“去 IOE”战略技术总监透露，截止到 2013 年 5 月 17 日阿里巴巴最后一台 IBM 小型机在支付宝下线。
为什么要去IOE 1.升级单机处理能力的性价比越来越低
2.单机处理能力存在瓶颈
3.稳定性和可用性这两个指标很难达到
3、 分布式架构的演变
阶段3 负载的问题、 session 的问题
二、 分布式系统面临的问题
2.1通信异常
网络本身的不可靠性，因此每次网络通信都会伴随着网络不可用的风险（光纤、路由、DNS等硬件设备或系统的不可用），都会导致最终分布式系统无法顺利进行一次网络通信，另外，即使分布式系统各节点之间的网络通信能够正常执行，其延时也会大于单机操作，存在巨大的延时差别，也会影响消息的收发过程，因此消息丢失和消息延迟变的非常普遍。
2.2 网络分区
网络之间出现了网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域，分布式系统就会出现局部小集群，在极端情况下，这些小集群会独立完成原本需要整个分布式系统才能完成的功能，包括数据的事务处理，这就对分布式一致性提出非常大的挑战。
2.3 节点故障
节点故障是分布式系统下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象，根据经验来说，每个节点都有可能出现故障，并且经常发生
2.4 三态
分布式系统每一次请求与响应存在特有的“三态”概念，即成功、失败和超时。
分布式系统中，由于网络是不可靠的，虽然绝大部分情况下，网络通信能够接收到成功或失败的响应，但当网络出现异常的情况下，就会出现超时现象，通常有以下两种情况：
- 由于网络原因，该请求并没有被成功的发送到接收方，而是在发送过程就发生了丢失现象。
- 该请求成功的被接收方接收后，并进行了处理，但在响应反馈给发送方过程中，发生了消息丢失现象。
三、分布式的一些理论
3.1、分布式理论：一致性
3.1.1、什么是分布式一致性
分布式数据一致性，指的是数据在多份副本中存储时，各副本中的数据是一致的
3.1.2 副本一致性
分布式系统当中，数据往往会有多个副本。如果是一台数据库处理所有的数据请求，那么通过ACID四原则，基本可以保证数据的一致性。而多个副本就需要保证数据会有多份拷贝。这就带来了同步的问题，因为我们几乎没有办法保证可以同时更新所有机器当中的包括备份所有数据。 网络延迟，即使我在同一时间给所有机器发送了更新数据的请求，也不能保证这些请求被响应的时间保持一致存在时间差，就会存在某些机器之间的数据不一致的情况。
总得来说，我们无法找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，一致性级别由此诞生：
3.1.3 一致性分类
-
强一致性
这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。但是强一致性很难实现。 -
弱一致性
这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。
读写一致性
用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容。
比如我们发一条朋友圈，朋友圈的内容是不是第一时间被朋友看见不重要，但是一定要显示在自己的列表上.
解决方案:
方案1：一种方案是对于一些特定的内容我们每次都去主库读取。 （问题主库压力大）
方案2：我们设置一个更新时间窗口，在刚刚更新的一段时间内，我们默认都从主库读取，过了这个窗口之后，我们会挑选最近有 过更新的从库进行读取
方案3：我们直接记录用户更新的时间戳，在请求的时候把这个时间戳带上，凡是最后更新时间小于这个时间戳的从库都不予以响 应。
单调读一致性
本次读到的数据不能比上次读到的旧。
由于主从节点更新数据的时间不一致，导致用户在不停地刷新的时候，有时候能刷出来，再次刷新之后会发现数据不见了，再刷新 又可能再刷出来，就好像遇见灵异事件一样
解决方案:就是根据用户ID计算一个hash值，再通过hash值映射到机器。同一个用户不管怎么刷新，都只会被映射到同一台机器 上。这样就保证了不会读到其他从库的内容，带来用户体验不好的影响。
因果一致性
指的是：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于 此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。
最终一致性
最终一致性是所有分布式一致性模型当中最弱的。可以认为是没有任何优化的“最”弱一致性，它的意思是说，我不考虑所有的中间 状态的影响，只保证当没有新的更新之后，经过一段时间之后，最终系统内所有副本的数据是正确的。
它最大程度上保证了系统的并发能力，也因此，在高并发的场景下，它也是使用最广的一致性模型
3.2、分布式理论：CAP定理
CAP 定理
2000 年7月的时候，加州大学伯克利分校的Eric Brewer 教授提出了 CAP 猜想，2年后，被 来自于麻省理工的Seth Gilbert 和 Nancy Lynch 从理论上证明了猜想的可能性，从此，CAP 定理正式在学术上成为了分布式计算领域的公认定理。并深深的影响了分布式计算的发展。
CAP 理论含义是，一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A: Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个。
| 选项 | 描述 |
|---|---|
| C 一致性 | 分布式系统当中的一致性指的是所有节点的数据一致，或者说是所有副本的数据一致 |
| A 可用性 | Reads and writes always succeed. 也就是说系统一直可用，而且服务一直保持正常 |
| P 分区容错性 | 系统在遇到一些节点或者网络分区故障的时候，仍然能够提供满足一致性和可用性的服务 |
-
C - Consistency
一致性是值写操作后读操作可以读到最新的数据状态,当数据分布在多个节点上时,从任意节点读取到的数据都是最
新的.
商品信息读写要满足一致性需要实现如下目标: 1.商品服务写入主数据库成功, 则想从数据库查询数据也成功
2.商品服务写入主数据库失败,则向从数据库查询也失败
如何实现一致性? 1.写入主数据库后要数据同步到从数据库
2.写入主数据库后,在向从数据库同步期间要将从数据库锁定, 等待同步完成后在释放锁,以免在写新数据后,向从数据
库查询到旧的数据.
分布式一致性的特点: 1.由于存在数据库同步过程,写操作的响应会有一定的延迟
2.为了保定数据的一致性,对资源暂时锁定,待数据同步完成后释放锁定资源
3.如果请求数据同步失败的节点则会返回错误信息, 一定不会返回旧数据. -
A - Availability
可用性是指任何操作都可以得到响应的结果,且不会出现响应超时或响应错误。
商品信息读写要满足可用性需要实现如下目标: 1.从数据库接收到数据库查询的请求则立即能够响应数据查询结果
2.从数据库不允许出现响应超时或错误
如何实现可用性?
1.写入主数据库后要将数据同步到从数据
2.由于要保证数据库的可用性,不可以将数据库中资源锁定
3.即使数据还没有同步过来,从数据库也要返回查询数据, 哪怕是旧数据,但不能返回错误和超时. -
P - Partition tolerance
分布式系统的各个节点部署在不同的子网中, 不可避免的会出现由于网络问题导致节点之间通信失败,此时仍可以对
外提供服务, 这个就是分区容错性 (分区容忍性).
商品信息读写要满足分区容错性需要实现如下目标: 1.主数据库想从数据库同步数据失败不形象写操作
2.其中一个节点挂掉不会影响另一个节点对外提供服务
如何实现分区容错性? 1.尽量使用异步取代同步操作,举例 使用异步方式将数据从主数据库同步到从数据库, 这样节点之间能有效的实现松
耦合; 2.添加数据库节点,其中一个从节点挂掉,由其他从节点提供服务
关于CAP这三个特性我们就介绍完了，接下来我们试着证明一下为什么CAP不能同时满足。
假设有一个系统如下：
有用户向N1发送了请求更改了数据，将数据库从V0更新成了V1。由于网络断开，所以N2数据库依然是V0，如果这个时候有一个请 求发给了N2，但是N2并没有办法可以直接给出最新的结果V1，这个时候该怎么办呢？
这个时候无法两种方法，一种是将错就错，将错误的V0数据返回给用户。第二种是阻塞等待，等待网络通信恢复，N2中的数据更新 之后再返回给用户。显然前者牺牲了一致性，后者牺牲了可用性。
这个例子虽然简单，但是说明的内容却很重要。在分布式系统当中，CAP三个特性我们是无法同时满足的，必然要舍弃一个。三者 舍弃一个，显然排列组合一共有三种可能。
- 舍弃A(可用性)，保留CP(一致性和分区容错性)
一个系统保证了一致性和分区容错性，舍弃可用性。也就是说在极端情况下，允许出现系统无法访问的情况出现，这个时候往往会 牺牲用户体验，让用户保持等待，一直到系统数据一致了之后，再恢复服务。
- 舍弃C(一致性)，保留AP(可用性和分区容错性)
这种是大部分的分布式系统的设计，保证高可用和分区容错，但是会牺牲一致性。
- 舍弃P(分区容错性)，保留CA(一致性和可用性)
如果要舍弃P，那么就是要舍弃分布式系统，CAP也就无从谈起了。可以说P是分布式系统的前提，所以这种情况是不存在的。
3.2.1 分布式理论：BASE 理论
什么是BASE理论
BASE：全称：Basically Available(基本可用)，Sox state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。
Base理论 对 CAP理论的协调
3.2.3、2PC一致性协议详解
3.2.3.1
2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。
在计算机中部分关系数据库如Oracle、MySQL支持两阶段提交协议
两个阶段过程：
- 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数 据文件）
- 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。
3.2.3.2
成功执行事务事务提交流程
阶段一:
- 事务询问
协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。- 执行事务 (写本地的Undo/Redo日志)
- 各参与者向协调者反馈事务询问的响应 总结: 各个参与者进行投票是否让事务进行.
Tip: 什么是Ack:
1.ACK 确认字符，在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。
阶段二:
- 发送提交请求： 协调者向所有参与者发出 commit 请求。
- 事务提交： 参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
- 反馈事务提交结果： 参与者在完成事务提交之后，向协调者发送 Ack 信息。
- 完成事务： 协调者接收到所有参与者反馈的 Ack 信息后，完成事务。
中断事务步骤如下：
假如任何一个参与者向协调者反馈了No响应，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务
阶段一:
- 事务询问 协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
- 执行事务 (写本地的Undo/Redo日志)
- 各参与者向协调者反馈事务询问的响应 总结: 各个参与者进行投票是否让事务进行.
阶段二
- 发送回滚请求： 协调者向所有参与者发出 Rollback 请求。
- 事务回滚： 参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整 个事务执行期间占用的资源。
- 反馈事务回滚结果： 参与者在完成事务回滚之后，向协调者发送 Ack 信息。
- 中断事务： 协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。
从上面的逻辑可以看出，二阶段提交就做了2个事情：投票，执行。
3.2.3.3、2PC协议的优缺点
-
优点:
原理简单，实现方便 -
缺点
同步阻塞、单点问题、数据不一致、过于保守
-
同步阻塞
二阶段提交协议存在最明显也是最大的一个问题就是同步阻塞，在二阶段提交的执行过程中，所有参与该事务操作
的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，无法进行其他操作。这种同步阻
塞极大的限制了分布式系统的性能。 -
单点问题
协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的
是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。 -
数据不一致
假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完所有 commit
请求之前自身发生了崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。 -
于保守
如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，
这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提
交协议没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败。
3.3、 3PC一致性协议详解
3.3.1、 什么是三阶段提交
3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。
3.3.2、 第一阶段：CanCommit
① 事务询问
协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
② 各参与者向协调者反馈事务询问的响应
参与者在接收到来自协调者的包含了事务内容的canCommit请求后，正常情况下，如果自身认为可以顺利执行事务，则反馈Yes响应，并进入预备状态，否则反馈No响应。
3.3.2、 第二阶段：PreCommit
协调者在得到所有参与者的响应之后，会根据结果有2种执行操作的情况：执行事务预提交，或者中断事务.
假如所有参与反馈的都是Yes，那么就会执行事务预提交。
- 执行事务预提交分为 3 个步骤
① 发送预提交请求：
协调者向所有参与者节点发出preCommit请求，并进入prepared阶段。
② 事务预提交：
参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。
③ 各参与者向协调者反馈事务执行的结果：
若参与者成功执行了事务操作，那么反馈Ack
若任一参与者反馈了No响应，或者在等待超时后，协调者尚无法接收到所有参与者反馈，则中断事务
2. 中断事务也分为2个步骤：
① 发送中断请求：
协调者向所有参与者发出abort请求。
② 中断事务：
无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务
3.3.3、阶段三：do Commit
该阶段做真正的事务提交或者完成事务回滚，所以就会出现两种情况：
- 执行事务提交
① 发送提交请求：
进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状
态转化为提交状态，并向所有的参与者发送doCommit请求。
② 事务提交：
参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事
务资源。
③ 反馈事务提交结果
参与者在完成事务提交后，向协调者发送Ack响应。
④ 完成事务：
协调者接收到所有参与者反馈的Ack消息后，完成事务。
- 中断事务
① 发送中断请求：协调者向所有的参与者节点发送abort请求。
② 事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整个
事务执行期间占用的资源。
③ 反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息。
④ 中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务。
注意：一旦进入阶段三，可能会出现 2 种故障： - 协调者出现问题
- 协调者和参与者之间的网络故障
如果出现了任一一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针对这种情况，参与者
都会在等待超时之后，继续进行事务提交
3.3.4、2PC对比3PC
1.首先对于协调者和参与者都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收
到参与者的消息则默认失败）,主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无
法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机
制也侧面降低了整个事务的阻塞时间和范围。 2.通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较
于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 。 3.PreCommit是一个
缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。
问题：3PC协议并没有完全解决数据不一致问题。
3.4、分布式理论：一致性算法 Paxos
3.4.1、一致性算法 Paxos概念
Paxos算法是Lamport提出的一种基于消息传递的分布式一致性算法，使其获得2013年图灵奖。
Paxos由Lamport于1998年在《The Part-Time Parliament》论文中首次公开，最初的描述使用希腊的一个小岛Paxos
作为比喻，描述了Paxos小岛中通过决议的流程，并以此命名这个算法，但是这个描述理解起来比较有挑战性。后
来在2001年，Lamport觉得同行不能理解他的幽默感，于是重新发表了朴实的算法描述版本《Paxos Made Simple》 自Paxos问世以来就持续垄断了分布式一致性算法，Paxos这个名词几乎等同于分布式一致性。Google的很多大型分
布式系统都采用了Paxos算法来解决分布式一致性问题，如Chubby、Megastore以及Spanner等。开源的ZooKeeper，
以及MySQL 5.7推出的用来取代传统的主从复制的MySQL Group Replication等纷纷采用Paxos算法解决分布式一致性
问题。
然而，Paxos的最大特点就是难，不仅难以理解，更难以实现。
3.4.2、Paxos 解决了什么问题
答：解决了分布式系统一致性问题。
分布式系统才用多副本进行存储数据 , 如果对多个副本执行序列不控制, 那多个副本执行更新操作,由于网络延迟 超时等故障到 值各个副本的数据不一致. 我们希望每个副本的执行序列是 [ op1 op2 op3 … opn ] 不变的, 相同的. Paxos 一次来确定不可变变量 opi的取值 , 每次确定完Opi之后,各个副本执行opi操作,一次类推。
结论： Paxos算法需要解决的问题就是如何在一个可能发生上述异常的分布式系统中，快速且正确地在集群内部对某个数据的值 达成一致.
注：这里某个数据的值并不只是狭义上的某个数，它可以是一条日志，也可以是一条命令（command）。。。根据应用场景不同， 某个数据的值有不同的含义
我们假设一种情况，在一个集群环境中，要求所有机器上的状态是一致的，其中有2台机器想修改某个状态，机器
A 想把状态改为 A，机器 B 想把状态改为 B，那么到底听谁的呢？
有的同学会想到，可以像 2PC，3PC 一样引入一个协调者，谁先到，听谁的
但是如果，协调者宕机了呢？
所以需要对协调者也做备份，也要做集群。这时候，问题来了，这么多协调者，听谁的呢？
Paxos 算法就是为了解决这个问题而生的
3.4.3 Paxos相关概念
首先一个很重要的概念叫提案（Proposal）。最终要达成一致的value就在提案里。
提案 (Proposal)：Proposal信息包括提案编号 (Proposal ID) 和提议的值 (Value) 在Paxos算法中，有如下角色：
Client：客户端
客户端向分布式系统发出请求 ，并等待响应 。例如，对分布式文件服务器中文件的写请求。
Proposer：提案发起者
提案者提倡客户请求，试图说服Acceptor对此达成一致，并在发生冲突时充当协调者以推动协议向前发展
Acceptor：决策者，可以批准提案
Acceptor可以接受（accept）提案；如果某个提案被选定（chosen），那么该提案里的value就被选定了
Learners：最终决策的学习者
学习者充当该协议的复制因素
3.4.4 问题描述
假设有一组可以提出提案的进程集合，那么对于一个一致性算法需要保证以下几点：
- 在这些被提出的提案中，只有一个会被选定
- 如果没有提案被提出，就不应该有被选定的提案。
- 当一个提案被选定后，那么所有进程都应该能学习（learn）到这个被选定的value
3.4.5 推导过程
3.4.5.1 最简单的方案——只有一个Acceptor
假设只有一个Acceptor（可以有多个Proposer），只要Acceptor接受它收到的第一个提案，则该提案被选定，该提案
里的value就是被选定的value。这样就保证只有一个value会被选定。
但是，如果这个唯一的Acceptor宕机了，那么整个系统就无法工作了！
因此，必须要有多个Acceptor！
3.4.5.2 多个Acceptor
多个Acceptor的情况如下图。那么，如何保证在多个Proposer和多个Acceptor的情况下选定一个value呢？
