分布式理论关键知识点总结

最新推荐文章于 2022-09-15 14:56:21 发布

置顶我是一颗小小的螺丝钉

最新推荐文章于 2022-09-15 14:56:21 发布

阅读量528

点赞数

分类专栏：分布式理论文章标签：分布式

本文链接：https://blog.csdn.net/xiaosong_2016/article/details/110421058

版权

分布式理论专栏收录该内容

1 篇文章 0 订阅

订阅专栏

一、什么是分布式

1.分布式系统定义：

分布式系统是一个硬件或者软件组件分布在不同的计算机上，彼此之间仅仅通过消息传递进行通信和协调的系统

总结来说：分布式就是计算机之间的分工与合作，例如：对应现实世界中，针对某项任务，我分给一个人干还是一群人干产生的效果也是不同的，一群人干肯定要比一个人干要快的；分布式系统就是一群人一起干活，人多力量大，每个服务器的算力是有限的，但是通过分布式系统，有n个服务器组成起来的集群，算力是无限扩张的

2.分布式系统的演变

3.分布式环境面临的问题

（1）通信异常

（2）网络分区

由于网络发生异常情况，导致分布式系统中部分节点之间的网络延迟不断增大，最终导致组成分布式系统中只有部分节点之间能够正常通信，而另外一些节点则不能，这种情况称为网络分区。俗称“脑裂”。当出现网络分区时，网络之间出现了网络不通，但是各个子网的内部网络时正常的，从而导致整个系统的网络环境被分成了若干个独立的区域，分布式系统就会出现局部小集群，在极端的情况下，这些小集群会独立的完成原本需要整个分布式系统才能完成的功能，包括数据的事务处理，这就对分布式一致性提出非常大的挑战。

（3）三态

从上面的介绍，已经了解了在分布式环境下，网络是不可靠的。因此分布式系统每一次请求与响应存在特有的三态的概念：成功、失败和超时。单机系统中，应用程序调用一个函数，能够得到发出明确的响应，成功或失败。在分布式系统中由于网络时不可靠的会出现以下情况

1.由于网络原因，该请求没有被成功的发送到接收方，而是在发送过程中就发生了丢失现象

2.该请求成功的被接收方接收后，并进行了处理，但在响应反馈给发送方过程中，发生了消息丢失现象

（4）节点故障

节点故障是分布式系统下另一个比较常见的问题，指的是组成分布式系统的服务器节点出现的宕机或“僵死”的现象。

4.分布式系统设计理念

分布式系统架构的第一原则是不要分布！这句话看似矛盾实则揭露了分布式系统的很多特征。

（1）分布式系统的目标与要素

分布式系统的目标是提升系统的整体性能和吞吐量另外还要尽量保证分布式系统的容错性（假如增加10台服务器才达到单机运行效果2倍左右的性能，那么这个分布式系统就根本没有存在的意义）。

即使采用了分布式系统，我们也要尽力运用并发编程、高性能网络框架等等手段提升单机上的程序性能。

（2）分布式系统设计两大思路：中心化和去中心化

1）中心化设计：

两个角色： 中心化的设计思想很简单，分布式集群中的节点机器按照角色分工，大体上氛围两种角色： “领导” 和 “干活的”
角色职责： “领导”通常负责分发任务并监督“干活的”，发现谁太闲了，就想发设法地给其安排新任务，确保没有一个“干活的”能够偷懒，如果“领导”发现某个“干活的”因为劳累过度而病倒了，则是不会考虑先尝试“医治”他的，而是一脚踢出去，然后把他的任务分给其他人。其中微服务架构 Kubernetes 就恰好采用了这一设计思路。
中心化设计的问题：
1. 中心化的设计存在的最大问题是“领导”的安危问题，如果“领导”出了问题，则群龙无首，整个集群就奔溃了。但我们难以同时安排两个“领导”以避免单点问题。
2. 中心化设计还存在另外一个潜在的问题，既“领导”的能力问题：可以领导10个人高效工作并不意味着可以领导100个人高效工作，所以如果系统设计和实现得不好，问题就会卡在“领导”身上。
领导安危问题的解决办法： 大多数中心化系统都采用了主备两个“领导”的设计方案，可以是热备或者冷备，也可以是自动切换或者手动切换，而且越来越多的新系统都开始具备自动选举切换“领导”的能力，以提升系统的可用性。

2)去中心化设计

终生地位平等： 在去中心化的设计里，通常没有“领导”和“干活的”这两种角色的区分，大家的角色都是一样的，地位是平等的，全球互联网就是一个典型的去中心化的分布式系统，联网的任意节点设备宕机，都只会影响很小范围的功能。
“去中心化”不是不要中心，而是由节点来自由选择中心。 （集群的成员会自发的举行“会议”选举新的“领导”主持工作。最典型的案例就是ZooKeeper及Go语言实现的Etcd）
去中心化设计的问题： 去中心化设计里最难解决的一个问题是 “脑裂”问题 ，这种情况的发声概率很低，但影响很大。脑裂问题，这种情况的发生概率很低，但影响很大。脑裂指一个集群犹豫网络的故障，被分为至少两个彼此无法通信的单独集群，此时如果两个集群都各自工作，则可能会产生眼中的数据冲突何错误。一般的设计思路是，当集群半段发声了脑裂问题是，规模较小的集群就“自杀”或者拒绝服务。

二、分布式理论：一致性

1.什么是分布式一致性

分布式数据一致性，指的是数据在多份副本中存储时，各副本中的数据是一致的。

2.分布式一致性的提出

分布式系统当中，数据往往会有多个副本。如果是一台数据库处理所有的数据请求，那么通过ACID四原则，基本可以保证数据的一致性。而多个副本就需要保证数据会有多份拷贝。这就带来了同步的问题，因为我们几乎没有办法保证可以同时更新所有机器当中的包括备份所有数据。网络延迟，即使我在同一时间给所有机器发送了更新数据的请求，也不能保证这些请求被响应的时间保持一致存在时间差，就会存在某些机器之间的数据不一致的情况。

总得来说，我们无法找到一种能够满足分布式系统所有系统属性的分布式一致性解决方案。因此，如何既保证数据的一致性，同时又不影响系统运行的性能，是每一个分布式系统都需要重点考虑和权衡的。于是，一致性级别由此诞生。

3.一致性分类

强一致性：

这种一致性级别是最符合用户直觉的，它要求系统写入什么，读出来的也会是什么，用户体验好，但实现起来往往对系统的性能影响大。但是强一致性很难实现。

弱一致性

这种一致性级别约束了系统在写入成功后，不承诺立即可以读到写入的值，也不承诺多久之后数据能够达到一致，但会尽可能地保证到某个时间级别（比如秒级别）后，数据能够达到一致状态。

最终一致性

最终一致性是所有分布式一致性模型当中最弱的。可以认为是没有任何优化的“最”弱一致性，弱一致性中的一个特例。它的意思是说，我不考虑所有的中间状态的影响，只保证当没有新的更新之后，经过一段时间之后，最终系统内所有副本的数据是正确的。它最大程度上保证了系统的并发能力，也因此，在高并发的场景下，它也是使用最广的一致性模型。

读写一致性

用户读取自己写入结果的一致性，保证用户永远能够第一时间看到自己更新的内容。比如我们发一条朋友圈，朋友圈的内容是不是第一时间被朋友看见不重要，但是一定要显示在自己的列表上。

解决方案:
方案1：一种方案是对于一些特定的内容我们每次都去主库读取。 （问题主库压力大）
方案2：我们设置一个更新时间窗口，在刚刚更新的一段时间内，我们默认都从主库读取，过了这个窗口之后，我们会挑
选最近有过更新的从库进行读取
方案3：我们直接记录用户更新的时间戳，在请求的时候把这个时间戳带上，凡是最后更新时间小于这个时间戳的从库都
不予以响应。

单调读一致性

本次读到的数据不能比上次读到的旧。由于主从节点更新数据的时间不一致，导致用户在不停地刷新的时候，有时候能刷出来，再次刷新之后会发现数据不见了，再刷新又可能再刷出来，就好像遇见灵异事件一样。

解决方案:
就是根据用户ID计算一个hash值，再通过hash值映射到机器。同一个用户不管怎么刷新，都只会被映射到同 一台机器上。这样就保证了不会读到其他从库的内容，带来用户体验不好的影响

因果一致性

如果节点 A 在更新完某个数据后通知了节点 B，那么节点 B 之后对该数据的访问和修改都是基于 A 更新后的值。于此同时，和节点 A 无因果关系的节点 C 的数据访问则没有这样的限制。

4.分布式事务

在单机数据库中，我们很容易能够实现一套满足 ACID特性的事务处理系统，但在分布式数据库中，数据分散在各台不同的机器上，如何对这些数据进行分布式的事务处理具有非常大的挑战。

分布式事务是指事务的参与者、支持事务的服务器、资源服务器以及事务管理器分别位于分布式系统的不同节点上，通常一个分布式事务中会涉及对多个数据源或业务系统的操作。

可以设想一个．典型的分布式事务场景：一个跨银行的转账操作涉及调用两个异地的银行服务，其中一个是本地银行提供的取款服务，另一个则是目标银行提供的存款服务，这两个服务本身是无状态并且相互独立的，共同构成了一个完整的分布式事务。如果从本地银行取款成功，但是因为某种原因存款服务失败了，那么就必须回滚到取款之前的状态，否则用户可能会发现自己的钱不冀而飞了。

从这个例子可以行到，一个分布式事务可以，做是多个分布式的操作序列组成的，例如上面例子的取款服务和存款服务，通常可以把这一系列分布式的操作序列称为子事务。因此，分布式事务也可以被定义为一种嵌套型的事务，同时也就具有了 ACID 事务特性。但由于在分布式事务中，各个子事务的执行是分布式的，因此要实现一种能够保证 ACID特性的分布式事务处理系统就显得格外复杂，尤其是对于一个高访问量，高并发的互联网分布式系统来说，如果我们期望实现一套严格满足 ACID特性的分布式事务，很可能出现的情况就是在系统的可用性和严格一致性之间出现冲突-----因为当我们要求分布式系统具有严格一致性时，很可能就需要牺牲掉系统的可用性。但毋庸置疑的一点是，可用性又是一个消费者不允许我们讨价还价的系统属性，比如像淘宝这样的在线购物网站，就要求 7x24 小时不间断地对外提供服务，而对于一致性，则更加是所有消费者对于一个软件的刚需。因此，在可用性和一致性之间永远无法存在一个两全其美的方案，于是如何构建一个兼顾可用性和一致性的分布式系统成为了无数开发人员探讨的难题，于是就出现了以 CAP 和 BASE这样的分布式系统经典理论。

三、分布式理论：CAP定理

1.什么是CAP定理

在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer’s theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：
- 一致性（Consistence） :所有节点访问同一份最新的数据副本
- 可用性（Availability）:每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据
- 分区容错性（Partition tolerance） : 分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。

CAP仅适用于原子读写的NOSQL场景中，并不适合数据库系统。

从CAP定理可以看出，一个分布式系统不可能同时满足一致性，可用性和分区容错性这三个基本需求，最多只能同时满足其中的两个，还需要说明的一点：对于一个分布式系统而言，分区容错性可以说是一个最基本的需求。所以架构师只能在C和A之间寻求平衡

注意：不是所谓的3选2:

现实生活中，大部分人解释这一定律时，常常简单的表述为：“一致性、可用性、分区容忍性三者你只能同时达到其中两个，不可能同时达到”。实际上这是一个非常具有误导性质的说法，而且在CAP理论诞生12年之后，CAP之父也在2012年重写了之前的论文。

当发生网络分区的时候，如果我们要继续服务，那么强一致性和可用性只能2选1。也就是说当网络分区之后P是前提，决定了P之后才有C和A的选择。也就是说分区容错性（Partition tolerance）我们是必须要实现的。

四、分布式理论：BASE理论

BASE 是 Basically Available（基本可用） 、Soft-state（软状态） 和 Eventually Consistent（最终一致性）三个短语的缩写，由eBay架构师Dan Pritchett提出。BASE理论是对CAP中一致性和可用性权衡的结果，其来源于对大规模互联网系统分布式实践的总结，是基于CAP定理逐步演化而来的，它大大降低了我们对系统的要求。

1.BASE理论的核心思想

即使无法做到强一致性（Strong consistency），但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。也就是牺牲数据的一致性来满足系统的高可用性，系统中一部分数据不可用或者不一致时，仍需要保持系统整体“主要可用”。

针对数据库领域，BASE思想的主要实现是对业务数据进行拆分，让不同的数据分布在不同的机器上，以提升系统的可用性，当前主要有以下两种做法：

按功能划分数据库
分片（如开源的Mycat、Amoeba等）。

由于拆分后会涉及分布式事务问题，所以eBay在该BASE论文中提到了如何用最终一致性的思路来实现高性能的分布式事务。

2.BASE理论三要素

（1）Basically Available（基本可用）

基本可用是指分布式系统在出现不可预知故障的时候，允许损失部分可用性。但是，这绝不等价于系统不可用。

比如：

响应时间上的损失:正常情况下，一个在线搜索引擎需要在0.5秒之内返回给用户相应的查询结果，但由于出现故障，查询结果的响应时间增加了1~2秒
系统功能上的损失：正常情况下，在一个电子商务网站上进行购物的时候，消费者几乎能够顺利完成每一笔订单，但是在一些节日大促购物高峰的时候，由于消费者的购物行为激增，为了保护购物系统的稳定性，部分消费者可能会被引导到一个降级页面

（2）Soft State（软状态）

什么是软状态呢？相对于一致性，要求多个节点的数据副本都是一致的，这是一种“硬状态”。

软状态指允许系统中的数据存在中间状态，并认为该中间状态的存在不会影响系统的整体可用性，即允许系统在不同节点的数据副本之间进行数据同步的过程存在延时

（3）Eventually consistent（最终一致性）

最终一致性强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能够达到一个一致的状态。因此，最终一致性的本质是需要系统保证最终数据能够达到一致，而不需要实时保证系统数据的强一致性

在实际工程中最终一致性存在以下五类变种：

1.因果一致性（Causal consistency）

指的是：如果节点A在更新完某个数据后通知了节点B，那么节点B之后对改数据的访问和修改都是基于A更新后的值。与此同时，和节点A无因果关系的节点C的数据访问则没有这样的限制

2.读己一致性（Read your writes）

这就简单了，节点A更新一个数据后，它自身总是能访问到自身更新过的值，而不会看到旧值。也就是说，对于单个数据获取者来说，其读取到的数据，一定不会比上次写入的旧，因此，读己之所写也可以看成一种特殊的因果一致性

3.会话一致性（Session consistency）

会话一致性将对系统数据的访问过程框定在了一个会话当中：系统能保证同一个有一个有效的会话中实现“读己之所写”的一致性，也就是说，执行完更新操作后，客户端能够在同一个会话中始终读取到该数据项的最新值。

4.单调读一致性（Monotonic read consistency）

如果一个节点从系统中读取一个数据项的某个值后，那么系统对于该节点后续的任何数据访问都不应该返回更旧的值

5.单调写一致性（Monotonic write consistency）

指一个系统要能够保证来自同一个节点的写操作被顺序执行。

总结：BASE理论面向的是大型高可用可拓展的分布式系统，和传统的ACID是相反的，它完全不同于ACID的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间是不一致的，但最终要保证数据一致。

五、分布式理论协议：一致性协议2PC

1.什么是2PC

2PC是Two-Phase Commit缩写，即两阶段提交，顾名思义，二阶段提交就是将事务的提交过程分成两个阶段来处理。是计算机网络，尤其是数据库领域，为了是基于分布式系统架构下的所有节点在进行事务处理过程中能够保持原子性和一致性而设计的一种算法，通常2PC也被认为是一种协议，用来保证分布式系统的数据一致性。目前绝大部分的关系型数据库都是采用二阶段提交协议来完成分布式事务。

2.2PC执行流程

（1）请求阶段

①.事务询问

协调者向所有参与者发送事务内容，询问是否可以执行事务提交，并开始等待参与者的响应

②.执行事务

各参与者节点执行事务操作，并将Undo和Redo信息记入事务日志中(Redo用来保证事务的原子性和持久性，Undo能保证事务的一致性，两者也是系统恢复的前提基础)

③.各参与者向协调者反馈事务询问的响应

如果参与者成功的执行了事务操作，那么就反馈给协调者Yes响应，表示事务可以执行；反之返回No，表示事务不可执行

（2）执行事务

提交事务步骤

假如协调者从所有参与者获取的反馈都是yes，那就执行事务提交

①发送提交请求

协调者向所有参与者发出commit请求

②事务提交

参与者收到commit请求后，会正式执行事务提交操作，并在完成提交之后释放整个事务执行期间占用的事务资源

③反馈事务提交结果

参与者在完成事务提交之后，向协调者发ACK信息

④完成事务

协调者收到所有参与者反馈的ACK信息后完成事务

中断事务步骤

如果任何一个参与者反馈给协调者反馈No，或者在等待超时之后，协调者尚无法接收到所有参与者的反馈响应，那么就会中断事务

①发送回滚请求

②事务回滚

③反馈事务回滚结果

④中断事务

总结

从上面逻辑可以看出二阶段就做了两个事情：投票、执行

协调者通知事务参与者准备提交或者取消事务，然后进入表决阶段
在表决过程中，参与者将告知协调者自己决策：
同意（事务参与者本地执行成功）
取消（事务参与者本地执行失败）

3、2PC优缺点

优点：原理简单，实现方便

缺点：同步阻塞，单点问题，数据不一致，过于保守

●同步阻塞二阶段提交协议存在最明显也是最大的一个问题就是同步阻塞，在二阶段提交的执行过程中，所有参与该事务操作的逻辑都处于阻塞状态，也就是说，各个参与者在等待其他参与者响应的过程中，无法进行其他操作。这种同步阻塞极大的限制了分布式系统的性能。
●单点问题:协调者在整个二阶段提交过程中很重要，如果协调者在提交阶段出现问题，那么整个流程将无法运转,更重要的是:其他参与者将会处于-直锁定事务资源的状态中，而无法继续完成事务操作。
●数据不一致:假设当协调者向所有的参与者发送commit请求之后，发生了局部网络异常或者是协调者在尚未发送完所有commit请求之前自身发生了崩溃，导致最终只有部分参与者收到了commit请求。这将导致严重的数据不-致问题。
●过于保守:如果在二阶段提交的提交询问阶段中，参与者出现故障而导致协调者始终无法获取到所有参与者的响应信息的话，这时协调者只能依靠其自身的超时机制来判断是否需要中断事务，显然，这种策略过于保守。换句话说，二阶段提交协议没有设计较为完善的容错机制，任意-个节点失败都会导致整个事务的失败。

六、分布式理论协议：一致性协议3PC

1.什么是3PC

3PC全称“three phase commit”，是2PC改进版，将2PC的“提交事务请求”过程一分为二。共形成了CanCommit̵、PreCommit和doCommit三个阶段组成的事务处理协议

2.3PC执行流程

（1）阶段一CanCommit

①事务询问

②各参与者向协调者反馈事务询问的响应

（2）阶段二PreCommit

假如收到所有参与者反馈yes，执行事务预提交，执行事务预提交3个步骤为

①发送预提交请求

②事务预提交

③各个参与者向协调者反馈事务执行结果

假如任一参与者反馈no，或者等待超时，则中断事务，中断事务步骤为

①发送中断请求

②中断事务

（3）阶段二Do Commit

执行事务提交

①发送提交请求

②事务提交

③反馈事务提交结果

④完成事务

中断事务

①发送中断请求

②事务回滚

③反馈事务回滚请求

④中断事务

注意:一旦进入阶段三，可能会出现2种故障:

1.协调者出现问题

2.协调者和参与者之间的网络故障

如果出现了任一一种情况，最终都会导致参与者无法收到doCommit请求或者abort请求，针对这种情况，参与者都会在等待超时之后，继续进行事务提交

3.3PC优缺点

优点：相比较2PC，最大的优点就是降低了参与者的阻塞范围(第一个阶段是不阻塞的)，其次能够在单点故障后继续达成一致(2PC 在提交阶段会出现此问题，而3PC会根据协调者的状态进行回滚或者提交)。
缺点：如果参与者收到了preCommit消息后，出现了网络分区，此时协调者所在的节点和参与者所在的节点无法进行正常的网络通信，那么参与者等待超时后，会进行事务的提交,这必然会出现分布式数据不一致的问题。
2PC对比3PC
首先对于协调者和参与者都设置了超时机制(在2PC中，只有协调者拥有超时机制，即如果在-定时间内没有收到参与者的消息则默认失败)。其次在2PC的准备阶段和提交阶段之间，插入预提交阶段,使3PC拥有CanCommit、PreCommit、 DoCommit三个阶段。PreCommit是一个缓冲，保证了在最后提交阶段之前各参与节点的状态是一致的。