分布式理论知识
1、分布式系统架构
1.1基础概念
分布式 ： 将一个单体项目分成很多个模块，各个模块协同工作，各个模块构成了分布式系统
集群：针对单个模块或者单个系统在多台服务器上部署，称为集群。为了提高系统的可用性，增加系统的负载。
1.2分布式系统演变
1.3分布式系统面临的问题
问题描述通信异常网络本身的不可靠性，因此每次网络通信都会伴随着网络不可用的风险（光纤、路由、DNS等硬件设备或系统的不可用），都会导致最终分布式系统无法顺利进行一次网络通信，另外，即使分布式系统各节点之间的网络通信能够正常执行，其延时也会大于单机操作，存在巨大的延时差别，也会影响消息的收发过程，因此消息丢失和消息延迟变的非常普遍。网络分区网络之间出现了网络不连通，但各个子网络的内部网络是正常的，从而导致整个系统的网络环境被切分成了若干个孤立的区域，分布式系统就会出现局部小集群，在极端情况下，这些小集群会独立完成原本需要整个分布式系统才能完成的功能，包括数据的事务处理，这就对分布式一致性提出非常大的挑战。节点故障节点故障是分布式系统下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或"僵死"现象，根据经验来说，每个节点都有可能出现故障，并且经常发生。三态分布式系统每一次请求与响应存在特有的“三态”概念，即成功、失败和超时。分布式系统中，由于网络是不可靠的，虽然绝大部分情况下，网络通信能够接收到成功或失败的响应，但当网络出现异常的情况下，就会出现超时现象，通常有以下两种情况：1. 由于网络原因，该请求并没有被成功的发送到接收方，而是在发送过程就发生了丢失现象。2. 该请求成功的被接收方接收后，并进行了处理，但在响应反馈给发送方过程中，发生了消息丢失现象。
1.4分布式系统一致性问题
1.4.1概念
分布式数据一致性指的是数据在多份副本中存储时，各副本中的数据是一致的。
1.4.2副本数据一致性
分布式系统当中，数据往往会有多个副本。如果是一台数据库处理所有的数据请求，那么通过ACID四原则，基本可以保证数据的一致性。而多个副本就需要保证数据会有多份拷贝，这就带来了同步的问题，因为我们几乎没有办法保证可以同时更新所有机器当中的包括备份所有数据。
网络延迟，即使我在同一时间给所有机器发送了更新数据的请求，也不能保证这些请求被响应的时间保持一致存在时间差，就会存在某些机器之间的数据不一致的情况。
总得来说，我们无法找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，一致性级别由此诞生。
1.4.3一致性分类
强一致性：
这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。但是强一致性很难实现。
弱一致性：
这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。弱一致性可以分为
1、读写一致性
用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容。比如我们发一条朋友圈，朋友圈的内容是不是第一时间被朋友看见不重要，但是一定要显示在自己的列表上。
解决方案:
方案1：直接读主库。 （问题主库压力大）。
方案2：我们设置一个更新时间窗口，在刚刚更新的一段时间内，我们默认都从主库读取，过了这个窗口之后，我们会挑选最近有过更新的从库进行读取
方案3：我们直接记录用户更新的时间戳，在请求的时候把这个时间戳带上，凡是最后更新时间小于这个时间戳的从库都不予以响应。
2、单调读一致性
本次读到的数据不能比上次读到的旧。【产生原因是不同从库上数据更新有延迟导致的】
由于主从节点更新数据的时间不一致，导致用户在不停地刷新的时候，有时候能刷出来，再次刷新之后会发现数据不见了，再刷新又可能再刷出来，就好像遇见灵异事件一样
解决方案：就是根据用户ID计算一个hash值，再通过hash值映射到机器。同一个用户不管怎么刷新，都只会被映射到同一台机器上。这样就保证了不会读到其他从库的内容，带来用户体验不好的影响。
3、因果一致性
指的是：如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。
4、最终一致性
最终一致性是所有分布式一致性模型当中最弱的。可以认为是没有任何优化的“最”弱一致性，它的意思是说，我不考虑所有的中间状态的影响，只保证当没有新的更新之后，经过一段时间之后，最终系统内所有副本的数据是正确的。
它最大程度上保证了系统的并发能力，也因此，在高并发的场景下，它也是使用最广的一致性模型。
1.5CAP定理
CAP 理论含义是，一个分布式系统不可能同时满足一致性（C:Consistency)，可用性（A: Availability）和分区容错性（P：Partition tolerance）这三个基本需求，最多只能同时满足其中的2个。
选项描述C（Consistency） 一致性分布式系统当中的一致性指的是所有节点的数据一致，或者说是所有副本的数据一致A （Availability）可用性Reads and writes always succeed. 也就是说系统一直可用，而且服务一直保持正常P （Partition tolerance）分区容错性系统在遇到一些节点或者网络分区故障的时候，仍然能够提供满足一致性和可用性的服务
举个场景来说明CAP：
Consistency-一致性
一致性是在写操作后进行读操作可以读到最新的数据状态,当数据分布在多个节点上时,从任意节点读取到的数据都是最新的。
商品信息读写要满足一致性需要实现如下目标：
1.商品服务写入主数据库成功, 则想从数据库查询数据也成功
2.商品服务写入主数据库失败,则向从数据库查询也失败
实现：
1.写入主数据库后要数据同步到从数据库
2.写入主数据库后,在向从数据库同步期间要将从数据库锁定, 等待同步完成后在释放锁,以免在写新数据后,向从数据库查询到旧的数据。
分布式一致性的特点:
1.由于存在数据库同步过程,写操作的响应会有一定的延迟。
2.为了保定数据的一致性,对资源暂时锁定,待数据同步完成后释放锁定资源。
3.如果请求数据同步失败的节点则会返回错误信息, 一定不会返回旧数据。
Availability-可用性
可用性是指任何操作都可以得到响应的结果,且不会出现响应超时或响应错误。
商品信息读写要满足可用性需要实现如下目标:
1.从数据库接收到数据库查询的请求则立即能够响应数据查询结果
2.从数据库不允许出现响应超时或错误
实现：
1.写入主数据库后要将数据同步到从数据。
2.由于要保证数据库的可用性,不可以将数据库中资源锁定。
3.即使数据还没有同步过来,从数据库也要返回查询数据, 哪怕是旧数据,但不能返回错误和超时。
Partition tolerance-分区容错性
分布式系统的各个节点部署在不同的子网中, 不可避免的会出现由于网络问题导致节点之间通信失败,此时仍可以对外提供服务, 这个就是分区容错性 (分区容忍性)。
商品信息读写要满足分区容错性需要实现如下目标:
1.主数据库想从数据库同步数据失败不形象写操作
2.其中一个节点挂掉不会影响另一个节点对外提供服务
实现：
1.尽量使用异步取代同步操作,举例 使用异步方式将数据从主数据库同步到从数据库, 这样节点之间能有效的实现松耦合;
2.添加数据库节点,其中一个从节点挂掉,由其他从节点提供服务
在实际系统中CAP是不能同时满足的，思考为啥不能同时满足CAP？
回答：假设有一个系统如下：
有用户向Node1发送了请求更改了数据，将数据库从V0更新成了V1。由于网络断开，所以Node2数据库依然是V0，如果这个时候有一个请求发给了Node2，但是Node2并没有办法可以直接给出最新的结果V1， 这个时候该怎么办呢？
这个时候无法两种方法，一种是将错就错，将错误的V0数据返回给用户。第二种是阻塞等待，等待网络通信恢复，Node2中的数据更新之后再返回给用户。显然前者牺牲了一致性，后者牺牲了可用性。
这个例子虽然简单，但是说明的内容却很重要。在分布式系统当中，CAP三个特性我们是无法同时满足的，必然要舍弃一个。三者舍弃一个，显然排列组合一共有三种可能。
结论：在分布式系统中只能保证CP、AP，根据不同的系统选择不同的实现方案。
1.6BASE理论
1.6.1概念
BASE：全称：Basically Available(基本可用)，Soft state（软状态）,和 Eventually consistent（最终一致性）三个短语的缩写，来自 ebay 的架构师提出。
BASE是对CAP中一致性和可用性权衡的结果，BASE理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。
1.6.2各个理论详解
1、Basically Available（基本可用）
基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性——但请注意，这绝不等价于系统不可用。比如：响应时间上的损失：正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障（比如系统部分机房发生断电或断网故障），查询结果的响应时间增加到了1~2秒。
2、Soft state（软状态）
什么是软状态呢？相对于一致性，要求多个节点的数据副本都是一致的，这是一种 “硬状态”。
软状态指的是允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本之间进行数据同步的过程中存在延迟。
3、Eventually consistent（最终一致性）
最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性。
1.7一致性协议2PC
在了解2PC之前了解下分布式事务概念，分布式事务从实质上看与数据库事务的概念是一致的，既然是事务也就需要满足事务的基本特性（ACID），只是分布式事务相对于本地事务而言其表现形式有很大的不同。
1.7.1概念
2PC （ Two-Phase Commit缩写）即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare
phase）、提交阶段（commit phase），2是指两个阶段，P是指准备阶段，C是指提交阶段。（准备、提交协议）
在计算机中部分关系数据库如Oracle、MySQL支持两阶段提交协议.
两个阶段过程：
1. 准备阶段（Prepare phase）：事务管理器给每个参与者发送Prepare消息，每个数据库参与者在本地执行事务，并写本地的Undo/Redo日志，此时事务没有提交。 （Undo日志是记录修改前的数据，用于数据库回滚，Redo日志是记录修改后的数据，用于提交事务后写入数 据文件）
2. 提交阶段（commit phase）：如果事务管理器收到了参与者的执行失败或者超时消息时，直接给每个参与者发送回滚(Rollback)消息；否则，发送提交(Commit)消息；参与者根据事务管理器的指令执行提交或者回滚操作，并释放事务处理过程中使用的锁资源。注意:必须在最后阶段释放锁资源。
1.7.2执行流程
场景一 执行成功提交流程
说明：ACK 确认字符，在数据通信中，接收站发给发送站的一种传输类控制字符。表示发来的数据已确认接收无误。
阶段一
1. 事务询问：协调者向所有的参与者发送事务内容，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
2. 执行事务 (写本地的Undo/Redo日志)
3. 各参与者向协调者反馈事务询问的响应
总结: 各个参与者进行投票是否让事务进行
阶段二
1. 发送提交请求：协调者向所有参与者发出 commit 请求。
2. 事务提交： 参与者收到 commit 请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源。
3. 反馈事务提交结果： 参与者在完成事务提交之后，向协调者发送 Ack 信息。
4. 完成事务： 协调者接收到所有参与者反馈的 Ack 信息后，完成事务
场景二执行失败事务中断流程
阶段一 也是准备阶段，跟成功时候的准备阶段一致。
阶段二
1. 发送回滚请求： 协调者向所有参与者发出 Rollback 请求。
2. 事务回滚： 参与者接收到 Rollback 请求后，会利用其在阶段一中记录的 Undo 信息来执行事务回滚操作，并在完成回滚之后释放在整个事务执行期间占用的资源。
3. 反馈事务回滚结果： 参与者在完成事务回滚之后，向协调者发送 Ack 信息。
4. 中断事务： 协调者接收到所有参与者反馈的 Ack 信息后，完成事务中断。从上面的逻辑可以看出，二阶段提交就做了2个事情：投票，执行。
1.7.3 2PC总结
优点：原理简单，实现方便。
缺点：同步阻塞，单点问题，数据不一致，过于保守
同步阻塞：二阶段提交协议存在最明显也是最大的一个问题就是同步阻塞，在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
单点问题：协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转，更重要的是：其他参与者将会处于一直锁定事务资源的状态中，而无法继续完成事务操作。
数据不一致：假设当协调者向所有的参与者发送 commit 请求之后，发生了局部网络异常或者是协调者在尚未发送完所有 commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了 commit 请求。这将导致严重的数据不一致问题。
过于保守：如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意一个节点失败都会导致整个事务的失败。
1.8一致性协议3PC
1.8.1概念
3PC，全称 “three phase commit”，是 2PC 的改进版，将 2PC 的 “提交事务请求” 过程一分为二，共形成了由CanCommit、PreCommit和doCommit三个阶段组成的事务处理协议。
1.8.2 3PC流程说明
阶段一CanCommit
① 事务询问：协调者向所有的参与者发送一个包含事务内容的canCommit请求，询问是否可以执行事务提交操作，并开始等待各参与者的响应。
② 各参与者向协调者反馈事务询问的响应：参与者在接收到来自协调者的包含了事务内容的canCommit请求后，正常情况下，如果自身认为可以顺利执行事务，则反馈Yes响应，并进入预备状态，否则反馈No响应。
阶段二：PreCommit
协调者在得到所有参与者的响应之后，会根据结果有2种执行操作的情况：执行事务预提交，或者中断事务假如所有参与反馈的都是Yes，那么就会执行事务预提交。
执行事务的话分为3个步骤：
① 发送预提交请求：协调者向所有参与者节点发出preCommit请求，并进入prepared阶段。
② 事务预提交：参与者接收到preCommit请求后，会执行事务操作，并将Undo和Redo信息记录到事务日志中。
③ 各参与者向协调者反馈事务执行的结果：若参与者成功执行了事务操作，那么反馈Ack
如果任何一个参与者反馈了No响应之后则就会中断事务。
中断事务分为2个步骤：
① 发送中断请求：协调者向所有参与者发出abort请求。
② 中断事务：无论是收到来自协调者的abort请求或者等待协调者请求过程中超时，参与者都会中断事务。
阶段三：do Commit
该阶段做真正的事务提交或者完成事务回滚，所以就会出现两种情况：
场景一执行事务提交：
① 发送提交请求：进入这一阶段，假设协调者处于正常工作状态，并且它接收到了来自所有参与者的Ack响应，那么他将从预提交状态转化为提交状态，并向所有的参与者发送doCommit请求。
② 事务提交：参与者接收到doCommit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行过程中占用的事务资源。
③ 反馈事务提交结果：参与者在完成事务提交后，向协调者发送Ack响应。
④ 完成事务：协调者接收到所有参与者反馈的Ack消息后，完成事务。
场景二中断事务
① 发送中断请求：协调者向所有的参与者节点发送abort请求。
② 事务回滚：参与者收到abort请求后，会根据记录的Undo信息来执行事务回滚，并在完成回滚之后释放整个事务执行期间占用的资源。
③ 反馈事务回滚结果：参与者在完成事务回滚后，向协调者发送Ack消息。
④ 中断事务：协调者接收到所有参与者反馈的Ack消息后，中断事务。
注意
一旦进入阶段三，可能会出现 2 种故障：
1. 协调者出现问题
2. 协调者和参与者之间的网络故障
如果出现了任何一种情况，最终都会导致参与者无法收到 doCommit 请求或者 abort 请求，针 这种情
况，参与者都会在等待超时之后，继续进行事务提交。
1.8.3 2PC与3PC对比
1、首先对于协调者和参与者都设置了超时机制（在2PC中，只有协调者拥有超时机制，即如果在一定时间内没有收到参与者的消息则默认失败）,主要是避免了参与者在长时间无法与协调者节点通讯（协调者挂掉了）的情况下，无法释放资源的问题，因为参与者自身拥有超时机制会在超时后，自动进行本地commit从而进行释放资源。而这种机制也侧面降低了整个事务的阻塞时间和范围。
2、通过CanCommit、PreCommit、DoCommit三个阶段的设计，相较于2PC而言，多设置了一个缓冲阶段保证了在最后提交阶段之前各参与节点的状态是一致的 。
3、PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。但是3PC协议并没有完全解决数据不一致问题。
