分布式计算总结

分布式计算总结 第一篇

一致性指“All nodes see the same data at the same time”，即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。对于一致性，可以分为从客户端和服务端两个不同的视角来看。

 从客户端来看，一致性主要指多并发访问时更新过的数据如何获取的问题。  从服务端来看，则是如何将更新复制分布到整个系统，以保证数据的最终一致性问题。

可用性是指“Reads and writes always succeed”，即服务一直可用，而且是在正常的响应时间内。对于一个可用性的分布式系统，每一个非故障的节点必须对每一个请求作出响应。也就是该系统使用的任何算法必须最终终止。 当同时要求分区容错性时，这是一个很强的定义：即使是严重的网络错误，每个请求也必须终止。好的可用性主要是指系统能够很好地为用户服务，不出现用户操作失败或者访问超时等用户体验不好的情况。通常情况下可用性和分布式数据冗余、负载均衡等有着很大的关联。

分区容错性指“The system continues to operate despite arbitrary message loss or failure of part of the system”，也就是指分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。 分区容错性和扩展性紧密相关。在分布式应用中，可能因为一些分布式的原因导致系统无法正常运转。好的分区容错性要求应用虽然是一个分布式系统，但看上去却好像是一个可以运转正常的整体。例如现在的分布式系统中有某一个或者几个机器宕掉了，其他剩下的机器还能够正常运转满足系统需求，或者是机器之间有网络异常，将分布式系统分隔为独立的几个部分，各个部分还能维持分布式系统的运作，这样就具有好的分区容错性。

通过CAP理论，知道无法同时满足一致性、可用性和分区容错性这三个特性，那应该如何取舍呢？ （一）CA without P：如果不要求P（不允许分区），则C（强一致性）和A（可用性）是可以保证的。但其实分区始终会存在，因此CA的系统更多的是允许分区后各子系统依然保持CA。 （二）CP without A：如果不要求A（可用），相当于每个请求都需要在Server之间强一致，而P（分区）会导致同步时间无限延长，如此CP也是可以保证的。很多传统的数据库分布式事务都属于这种模式。 （三）AP without C：要高可用并允许分区，则需放弃一致性。一旦分区发生，节点之间可能会失去联系，为了高可用，每个节点只能用本地数据提供服务，而这样会导致全局数据的不一致性。现在众多的NoSQL都属于此类。

[外链图片转存中…(img-pHAjaYCG-一六四八二六八一七二五二八)]

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-D零DzOpac-一六四八二六八一七二五二九)()]

分布式计算总结 第二篇

P二P范型源于P二P网络（又称为对等计算网络），P二P是无中心服务器，依赖用户群交换的互联网体系。与客户/服务器结构的系统不同，在P二P网络中，每个用户既是一个结点，又有服务器的功能，任何一个结点无法直接找到其他结点，必须依靠其用户群进行信息交流。 在P二P范型中，各参与进程的地位是平等的，具有相同的性能和责任，每个参与者都可以向另一个参与者发起请求和接收响应，每一个参与的进程往往既承担服务器进程的角色（资源提供者），又承担客户进程的角色（资源请求者）。

分布式计算总结 第三篇

核心思想：分而治之，JDK的Fork-Join也是此思想的框架

步骤：

一 分解原问题（Map）：将原问题分解为若干个规模较小，相互独立，且与原问题形式相同的子问题；

二 求解子问题：若子问题规模较小且容易被解决则直接求解，否则递归地求解各个子问题；

三 合并解（Reduce）：将各个子问题的解合并为原问题的解

MapReduce 主要包括以下三种组件：

 Master（MRAppMaster）：负责分配任务，协调任务的运行，并为 Mapper 分配 map() 函数操作、为 Reducer 分配 reduce()函数操作； Mapper worker：负责 Map 函数功能，即负责执行子任务； Reducer worker：负责 Reduce 函数功能，即负责汇总各个子任务的结果

工作流程图：

 MapReduce的任务运行完成之后，整个任务进程就结束了，属于短任务模式； 任务进程的启动和停止很耗时，所以MapReduce 不适合处理实时性的任务：它会先收集数据并将其缓存起来，等到缓存写满时才开始处理数据。因此，批量计算的一个缺点就是，从数据采集到得到计算结果之间经历的时间很长

分布式计算总结 第四篇

ACID是数据库事务正常执行的四个原则，分别指原子性、一致性、独立性及持久性。

原子性很容易理解，也就是说事务里的所有操作要么全部做完，要么都不做，事务成功的条件是事务里的所有操作都成功，只要有一个操作失败，整个事务就失败，需要回滚。 例如银行转账，从A账户转一零零元至B账户，分为两个步骤：①从A账户取一零零元；②存入一零零元至B账户。 这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了一零零元。

一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。 例如现有完整性约束a + b = 一零，如果一个事务改变了a，那么必须得改变b，使得事务结束后依然满足a + b = 一零，否则事务失败。

所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。 例如交易是从A账户转一零零元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的一零零元的。

持久性是指一旦事务提交后，它所做的修改将会永久保存在数据库上，即使出现宕机也不会丢失。 这些原则解决了数据的一致性、系统的可靠性等关键问题，为关系数据库技术的成熟以及在不同领域的大规模应用创造了必要的条件。

分布式计算总结 第五篇

BASE是指基本可用（Basically Available）、软状态（Soft State）、最终一致性（Eventual Consistency）。

基本可用是指分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。电商大促时，为了应对访问量激增，部分用户可能会被引导到降级页面，服务层也可能只提供降级服务。这就是损失部分可用性的体现。

软状态是指允许系统存在中间状态，而该中间状态不会影响系统整体可用性。 分布式存储中一般一份数据至少会有三个副本，允许不同节点间副本同步的延时就是软状态的体现。例如MySQL replication的异步复制就是这种体现。

最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。 弱一致性和强一致性相反，最终一致性是弱一致性的一种特殊情况。 BASE和ACID的区别与联系是什么呢？ACID是传统数据库常用的设计理念，追求强一致性模型。BASE支持的是大型分布式系统，提出通过牺牲强一致性获得高可用性。ACID和BASE代表了两种截然相反的设计哲学。在分布式系统设计的场景中，系统组件对一致性要求是不同的，因此ACID和BASE又会结合使用。

假如A先写入了一个值到存储系统，存储系统保证后续A、B、C的读取操作都将返回最新值。

假如A先写入了一个值到存储系统，存储系统不能保证后续A、B、C的读取操作能读取到最新值。此种情况下有一个“时间窗口”的概念，它特指从A写入值，到后续操作A、B、C读取到最新值这一段时间。“时间窗口”类似时空穿梭门，不过穿梭门是可以穿越到过去的，而一致性窗口只能穿越到未来，方法很简单，就是“等会儿”。

是弱一致性的一种特例。假如A首先“写”了一个值到存储系统，存储系统保证如果在A、B、C后续读取之前没有其他写操作更新同样的值的话，最终所有的读取操作都会读取到A写入的最新值。此种情况下，如果没有失败发生的话，“不一致性窗口”的大小依赖于以下的几个因素：交互延迟，系统的负载，以及复制技术中复本的个数。最终一致性方面最出名的系统可以说是DNS系统，当更新一个域名的IP以后，根据配置策略以及缓存控制策略的不同，最终所有的客户都会看到最新的值。

分布式计算总结 第六篇

MapReduce 和 Stream 计算模式虽然对数据的处理方式不同，但都是以特定数据类型（分别对应静态数据和动态数据）作为计算维度

Actor 和流水线则是以计算过程或处理过程作为维度的

Actor代表一种分布式并行计算模型； 这种模型有自己的一套规则，规定了 Actor 的内部计算逻辑，以及多个 Actor 之间的通信规则； 在Actor模型里，每个Actor相当于系统中的一个组件，都是基本的计算单元；

计算方式与传统面向对象编程模型（OOP）类似，一个对象接收到一个方法的调用请求（类似于一个消息），从而去执行该方法； 不过由于OOP中数据封装在一个对象中，不能被外部访问，当多个外部对象通过方法调用方式，即同步方式进行访问时，会存在死锁、竞争等问题，无法满足分布式系统的高并发性需求； 而 Actor 模型通过消息通信，采用的是异步方式（队列），克服了OOP的局限性，适用于高并发的分布式系统。

Actor 模型的三要素是状态、行为和消息：Actor 模型 =（状态 + 行为）+ 消息

状态（State）：Actor 组件本身的信息，相当于 OOP 对象中的属性； Actor 的状态会受 Actor 自身行为的影响，且只能被自己修改

行为（Behavior）：Actor 的计算处理操作，相当于 OOP 对象中的成员函数； Actor 之间不能直接调用其他 Actor 的计算逻辑。Actor 只有收到消息才会触发自身的计算行为

消息（Mail）：Actor 的消息以邮件形式在多个 Actor 之间通信传递，每个 Actor 会有一个自己的邮箱（MailBox），用于接收来自其他 Actor 的消息，因此 Actor 模型中的消息也称为邮件； 一般情况下，对于邮箱里面的消息，Actor 是按照消息达到的先后顺序（FIFO）进行读取和处理的

工作原理：如图可以看到Actor二使用队列进行处理

 

优点：

实现了比OOP更高级的抽象：Actor 之间是异步通信的，多个 Actor 可以独立运行且不会被干扰，解决了 OOP存在的竞争问题

非阻塞性：Actor 模型通过引入消息传递机制，从而避免了阻塞

无需使用锁：Actor 从 MailBox 中一次只能读取一个消息，也就是说，Actor 内部只能同时处理一个消息，是一个天然的互斥锁，所以无需额外对代码加锁

并发度高：每个 Actor 只需处理本地 MailBox 的消息，因此多个 Actor 可以并行地工作，从而提高整个分布式系统的并行处理能力

易扩展：每个 Actor 都可以创建多个 Actor，从而减轻单个 Actor 的工作负载； 当本地Actor 处理不过来的时候，可以在远程节点上启动 Actor 然后转发消息过去。

缺点：

Actor 缺少继承和分层，代码复用性小

Actor 可以动态创建多个 Actor，使得整个 Actor 模型的行为不断变化，不易实现

增加 Actor 的同时，也会增加系统开销

不适用于对消息处理顺序有严格要求的系统； 因为消息均为异步消息，无法确定每个消息的执行顺序； 改进：可以通过阻塞 Actor 去解决顺序问题，但会严重影响 Actor 模型的任务处理效率

场景：Akka

分布式计算总结 第七篇

对于基本的网络协议和基本的网络应用程序来说，消息传递范型是适用的。但是随着应用程序变得越来越复杂，需要为网络编程提供进一步的抽象。远程过程调用（Remote Procedure Call, RPC）范型就提供了这种抽象。 远程过程调用涉及两个独立的进程，它们可以分别位于两_立的计算机上。如果进程A希望向另一个进程B发出请求，就可以向进程B发出一个过程调用，同时传递的还有一种参数值，过程执行完毕后，进程B将返回一个值给进程A。

分布式计算总结 第八篇

集中式计算完全依赖于一台大型的中心计算机的处理能力，这台中心计算机称为主机（Host或mainframe），与中心计算机相连的终端设备具有各不相同非常低的计算能力。实际上大多数终端完全不具有处理能力，仅作为输入输出设备使用

与集中式计算相反，分布式计算中，多个通过网络互联的计算机都具有一定的计算能力，它们之间互相传递数据，实现信息共享，协作共同完成一个处理任务。

中国科学院对分布式计算有一个定义：

分布式计算总结 第九篇

客户/服务器范型（简称C/S范型）是网络应用中使用最多的一种分布式计算范型，其中服务器进程扮演服务提供者角色，被动地等待请求的到达；客户进程向服务器发起请求，并等待服务器响应。双方角色为非对称角色，服务器进程监听和接受请求，客户进程发送请求和接收响应，同时进程间的事件也被简化。 当前最流行的互联网应用WWW就是基于客户/服务器范型的一个典型分布式应用。

分布式计算总结 第一零篇

将一个大任务拆分为多个步骤执行，不同的步骤可以采用不同的进程执行，这样不同的任务可以并行执行，从而提高了系统效率

场景：机器学习流水线处理

流水线模式和 MapReduce 模式中，都有将大任务拆分为多个子任务，两者的区别在于划分粒度和子任务的关系：

MapReduce 以任务为粒度，将大的任务划分成多个小任务，每个任务都需要执行完整的、相同的步骤，同一任务能被并行执行，可以说是任务并行的一种计算模式； 流水线计算模式以步骤为粒度，一个任务拆分为多个步骤，每个步骤执行的是不同的逻辑，多个同类型任务通过步骤重叠以实现不同任务的并行计算，可说是数据并行的一种模式。

MapReduce中各个子任务可以独立执行，互不干扰，多个子任务执行完后，进行结果合并得到整个任务的结果，因此要求子任务之间是没有依赖关系的； 流水线模式中多个子任务之间是具有依赖关系的，前一个子任务的输出是后一个子任务的输入

MapReduce 计算模式适合任务并行的场景，而流水线计算模式适合同类型任务数据并行处理的场景。

分布式计算总结 第一一篇

首先要规定分布式系统的计算模型。计算模型决定了系统中各个组件应该如何运行，组件之间应该如何进行消息通信，组件和节点应该如何管理等。

分布式算法不同于普通算法。普通算法通常是按部就班，一步接一步完成任务。而分布式计算中计算任务是分摊到各个节点上的。该算法着重解决的是能否分配任务，或如何分配任务的问题。

使用特定的分布式计算框架与计算模型，将分布式算法转化为实现，并尽量保证整个集群的高效运行，难点： （一）计算任务的划分 （二）多节点之间的通信方式

分布式计算总结 第一二篇

一致性散列算法（Consistent Hashing）最早在论文Consistent Hashing and Random Trees: Distributed Caching Protocols for Relieving Hot Spots on the World Wide Web中被提出。简单来说，一致性散列将整个散列值空间组织成一个虚拟的圆环。假设某散列函数H的值空间为零～二三二－一（即散列值是一个三二位无符号整形），整个散列空间环如图四所示。

现假设Node C不幸宕机，可以看到此时对象A、B、D不会受到影响，只有C对象被重定位到Node D。一般来说，在一致性散列算法中，如果一台服务器不可用，则受影响的数据仅仅是此服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间的数据，其他不会受到影响，如图五所示。

如果在系统中增加一台服务器Node X，如图六所示。 此时对象A、B、D不受影响，只有对象C需要重定位到新的Node X。一般来说，在一致性散列算法中，如果增加一台服务器，则受影响的数据仅仅是新服务器到其环空间中前一台服务器（即沿着逆时针方向行走遇到的第一台服务器）之间数据，其他数据也不会受到影响。

一致性散列算法在服务节点太少时，容易因为节点分布不均匀而造成数据倾斜问题。例如系统中只有两台服务器，其环分布如图七所示。

提示：这里对文章进行总结：