qq_37756660的博客

学习了搭建分布式实验环境。首先，以 Kubernetes 为例，介绍了如何搭建 Kubernetes 集群环境，其中包括容器、Master 节点、Worker 节点等配置和安装。然后，在搭建好的 Kubernetes 集群的基础上，以 Nginx 服务为例，展示了如何在 Kubernetes 集群上部署服务。其实，今天演示的 Demo 只是冰山一角。

主要以购买火车票为例，串联了分布式技术在实践中的应用。为方便理解，将购买火车票的模型简化为三个核心步骤，即铁路局发布火车票、用户查询火车票和用户购买火车票。其次，分别分析了这三个核心步骤涉及的关键的分布式技术。对于铁路局发布火车票这个流程来说，铁路局是数据的生产者，需要将数据发布到服务器进行存储，主要涉及的是分布式数据存储相关技术，对应专栏“第五站：分布式数据存储”的内容。

我们先来看看网络分区到底是什么吧。在第 31 篇文章分享故障恢复时，介绍了故障类型中的网络故障，网络分区就是其中的一种故障类型。通常情况下，网络分区指的是在分布式集群中，节点之间由于网络不通，导致集群中节点形成不同的子集，子集中节点间的网络相通，而子集和子集间网络不通。也可以说，网络分区是子集与子集之间在网络上相互隔离了。那么，应该如何判断是否发生了网络分区呢？进一步展开了分布式系统中的网络分区问题，以加深对网络分区问题的检测、处理方式的理解，并帮助在实践应用中处理网络分区问题。

主要学习了分布式高可用技术中的故障恢复技术。首先，介绍了分布式系统中的故障类型，主要包括物理故障和软件故障，软件故障主要是由于程序或软件 Bug 等导致，通常由开发者在开发或测试过程中解决，而物理故障导致软件不可用的故障类型主要分为两类，节点故障和网络故障。其次，介绍了故障检测方法。故障检测方法主要是心跳检测方法，包括固定心跳策略和基于历史信息的心跳策略。其中，固定心跳策略的具体原理见第 22 篇文章中的相关内容；基于历史心跳策略的核心是通过统计历史数据规律，以预测当前心跳是否超时以进行故障检测；

从字面意思来看，故障隔离就是，把故障通过某种方式与其他正常模块进行隔离，以保证某一模块出现故障后，不会影响其他模块。其实，我们生活有很多故障隔离的例子，比如交通。一辆车就类似于分布式系统中的一个模块，当一辆车在高速公路上出现故障后，我们通常会将其停靠在紧急车道，或者在其前后设置故障指示牌，以防止其他车辆与其相撞，引起更大的交通事故。这种将故障车辆停靠在路边紧急车道或设置故障指标牌的方法，就是一种故障隔离。

说到流量控制，如果你学过计算机网络的话，第一反应肯定是网络传输中的流量控制。网络传输中的流量控制，就是让发送方发送数据的速率不要太快，让接收方来得及接收数据，具体的实现方法就是滑动窗口。简单来讲，滑动窗口指的是，在任意时刻，发送方都维持一个连续的允许发送的数据大小，称为发送窗口；接收方也会维持一个连续的允许接收的数据大小，称为接收窗口。每次发送方给接收方发送数据后，必须收到接收方返回的确认消息，发送窗口才可向后移动，发送新的数据。

先举个例子吧。以超市收银为例，假设现在只有一个窗口、一个收银员：一般情况下，收银员平均 2 分钟服务一位顾客，10 分钟可以服务 5 位顾客；到周末高峰期时，收银员加快收银，平均 1 分钟服务一位顾客，10 分钟最多服务 10 位顾客，也就是说一个顾客最多等待 10 分钟；逢年过节，顾客数量激增，一下增加到 30 位顾客，如果仍然只有一个窗口和一个收银员，那么所有顾客就只能排队等候了，一个顾客最多需要等待 30 分钟。这样购物体验，就非常差了。那有没有解决办法呢？当然有。

打比方来说，缓存技术其实就像一个水缸，平时它会存储一定的水，而这些水就来自深井。如果每次都去深井打水，一方面井口比较小，导致一次能接收的用水请求有限；另一方面，井比较深，打水的工序比较复杂，导致所需时间比较长。而有了这个水缸，我们就不需要去深井里打水，当水缸里没水时，水泵会将深井里的水抽到水缸中暂时存储起来。也就是说，“缓存技术”存储了满足人们一定时间内常用的“水量”，以提高用水效率。在计算机领域，缓存技术一般是指，用一个更快的存储设备存储一些经常用到的数据，供用户快速访问。

概括来讲，数据复制是一种实现数据备份的技术。比如，现在有节点 1 和节点 2，节点 1 上存储了 10M 用户数据，直观地说，数据复制技术就是将节点 1 上的这 10M 数据拷贝到节点 2 上，以使得节点 1 和节点 2 上存储了相同的数据，也就是节点 2 对节点 1 的数据进行了备份。当节点 1 出现故障后，可以通过获取节点 2 上的数据，实现分布式存储系统的自动容错。也就是说，数据复制技术，可以保证存储在不同节点上的同一份数据是一致的。

主要学习了数据分布式方法中的哈希与一致性哈希。首先，了解了分布式数据存储系统中，设计数据分布方法需要考虑的原则，主要包括数据均匀性、稳定性和节点异构性。其次，基于数据分布设计原则，介绍了哈希、一致性哈希、带有限负载的一致性哈希和带虚拟节点的一致性哈希方法，并以例子进行辅助讲解。

分布式存储系统的核心逻辑，就是将用户需要存储的数据根据某种规则存储到不同的机器上，当用户想要获取指定数据时，再按照规则到存储数据的机器里获取。如下图所示，当用户（即应用程序）想要访问数据 D，分布式操作引擎通过一些映射方式，比如 Hash、一致性 Hash、数据范围分类等，将用户引导至数据 D 所属的存储节点获取数据。静下心来想一下，获取数据的整个过程与你到商店购物的过程是不是有些类似呢？

如果之前没有听说过 CAP 理论的话，看到这三个字母第一反应或许是“帽子”吧。那么，在分布式领域中，CAP 这顶“帽子”到底是什么呢？我们先来看看这三个字母分别指的是什么吧。接下来，结合电商的例子，带你理解 CAP 的含义。假设某电商，在北京、杭州、上海三个城市建立了仓库，同时建立了对应的服务器{A, B, C}用于存储商品信息。比如，某电吹风在北京仓库有 20 个，在杭州仓库有 10 个，在上海仓库有 30 个。那么，CAP 这三个字母在这个例子中分别代表什么呢？首先，我们来看一下 C。

2. 每个节点根据集群节点列表，计算哈希值（比如根据节点 ID 计算一个哈希值），然后基于哈希值，将所有节点组成一个哈希环（比如，从小到大的顺序），如下图所示。想象一下，如果主备节点之间的网络连接断开了，那么主节点与备节点之间心跳均不可达，因此主节点会认为备节点故障，此时主节点会继续提供服务，而备节点会认为主节点故障，备升主。这里你可能会问，如果像集中式架构那样，每个节点与其他 n-1 个节点都发送心跳的话，整个集群中同一时间心跳消息为 n*(n-1)，消息量也特别大，甚至会导致网络风暴，应该怎么办。

回想一下，在上一篇学术电子论文订阅的例子中，出版社或会议方将论文发布到论文网站（或平台）上，然后论文网站再将论文推送给订阅相关论文的老师或学生。这里的论文网站就是消息中心，负责根据订阅信息将论文送货上门，角色非常关键。但其实，除了将论文送货上门外，我们还能想到另外一种模式，也就是出版社或会议方将论文发布到论文网站进行存储，老师或学生根据需要到论文网站按需购买文章。这种思想，在分布式通信领域中称为消息队列模式，论文网站充当的就是消息队列的角色，也非常关键。

其实，发布订阅的思想在我们的生活中随处可见。比如，学术届电子论文的订阅方式。通常，各个会议方或出版社会将学术论文发布到论文网站（或平台上，比如 ACM、知网等），然后学生或老师向论文网站订阅自己感兴趣的论文，比如分布式相关的、AI 相关的等。当会议方或出版社将论文发布到论文网站后，论文网站会根据订阅信息，将相应的论文推送给订阅者（比如通过邮件的方式）。这里的会议方或出版社就相当于生产者，负责发布论文，学生或老师就相当于消费者，而论文网站就相当于一个消息中心。由此可以看出，

首先，通过一个例子，来对远程调用和本地调用有一个直观了解。以电商购物平台为例，每一笔交易都涉及订单系统、支付系统和库存系统，假设三个系统分别部署在三台机器 A、B、C 中独立运行，订单交易流程如下所示：1. 用户下单时，调用本地（机器 A）的订单系统进行下单；2. 下单完成后，会远程调用机器 B 上的支付系统进行支付，待支付完成后返回结果，之后在本地更新订单状态；3. 在本地远程调用机器 C 上的仓库系统出货，出货完成后返回出货结果。

其实，分布式领域的流水线计算模式，就是参考了工业生产中的流水作业模式，将一个任务分为多个步骤执行，使得不同任务可以并行执行。此外，你肯定还会想到计算机技术中的流水线计算吧。计算机中的流水线（Pipeline）技术是一种将每条指令拆分为多个步骤，多条指令的不同步骤重叠操作，从而实现几条指令并行处理的技术。现代 CPU 指令采用了流水线设计，将一条 CPU 指令分为取指（IF）、译码（ID）、执行（EX）、访存（MEM）、回写（WB）五级流水线来执行。

在第 10 篇文章“分布式体系结构之非集中式结构：众生平等”中，曾提到 Akka 框架基于 Actor 模型，提供了一个用于构建可扩展的、弹性的、快速响应的应用程序的平台。其中，Actor 类似于一个“黑盒”对象，封装了自己的状态和行为，使得其他 Actor 无法直接观察到它的状态，调用它的行为。多个 Actor 之间通过消息进行通信，这种消息类似于电子邮箱中的邮件。Actor 接收到消息之后，才会根据消息去执行计算操作。那么，Actor 模型又是什么呢？Actor 模型，代表一种分布式并行计算模型。

近年来，由于网络监控、传感监测、AR/VR 等实时性应用的兴起，一类需要处理流数据的业务发展了起来。比如各种直播平台中，我们需要处理直播产生的音视频数据流等。这种如流水般持续涌现，且需要实时处理的数据，我们称之为流数据。总结来讲，流数据的特征主要包括以下 4 点：数据如流水般持续、快速地到达；海量数据规模，数据量可达到 TB 级甚至 PB 级；对实时性要求高，随着时间流逝，数据的价值会大幅降低；数据顺序无法保证，也就是说系统无法控制将要处理的数据元素的顺序。

分而治之（Divide-and-Conquer），是计算机处理问题的一个很重要的思想，简称为分治法。顾名思义，分治法就是将一个复杂的、难以直接解决的大问题，分割成一些规模较小的、可以比较简单的或直接求解的子问题，这些子问题之间相互独立且与原问题形式相同，递归地求解这些子问题，然后将子问题的解合并得到原问题的解。比如，现在要统计全中国的人口数，由于中国的人口规模很大，如果让工作人员依次统计每个省市的人口数，工作量会非常大。

有同学认为，Redis 的分布式锁根本没有队列，收到 setnx 返回为 0 的进程会不断地重试，直到某一次的重试成为 DEL 命令后第一个到达的 setnx 从而获得锁，至于此进程在等待获得锁的众多进程中是不是第一个发出 setnx 的，Redis 并不关心。但其实，阻塞在实际业务中是不可能完全避免的。在 3PC 中，进入真正的提交阶段前，还会有一个预提交阶段，这个预提交阶段不会做真正的提交，而是会将相关信息记录到事务日志中，当所有参与者都返回 Yes 消息后，才会真正进入提交阶段。

通过我们前两篇文章的讲述，不难发现，集群中需要管理的对象主要包括两种：一是，资源的分配和使用状态；二是，任务的调度和执行状态；在单体调度中，这两种对象都是由单体调度器管理的，因此可以比较容易地保证全局状态的一致性，但问题是可扩展性较差（支持业务类型受限），且存在单点瓶颈问题。而在两层调度中，这两种对象分别由第一层中央调度器和第二层 Framework 调度器管理，由于 Framwork 调度器只能看到部分资源，因此不能保证全局状态的一致性，也不容易实现全局最优的调度。

在单体调度架构中，中央服务器的单点瓶颈问题，会限制调度的效率和支持的任务类型。中央服务器的性能会限制调度的效率，很好理解，但为什么会限制支持的任务类型呢？简单地说，这是因为不同的服务具有不同的特征，对调度框架和计算的要求都不一样。比如说，你的业务最开始时只有批处理任务，后来发展到同时还包括流数据任务，但批处理任务是处理静态数据，流数据任务却是处理实时数据。显然，单体调度框架会随着任务类型增加而变得越来越复杂，最终出现扩展瓶颈。

分布式系统中的单体调度是指，一个集群中只有一个节点运行调度进程，该节点对集群中的其他节点具有访问权限，可以对其他节点的资源信息、节点状态等进行统一管理，同时根据用户下发的任务对资源的需求，在调度器中进行任务与资源匹配，然后根据匹配结果将任务指派给合适的节点。单体调度器拥有全局资源视图和全局任务，可以很容易地实现对任务的约束并实施全局性的调度策略。目前很多集群管理系统采用了单体调度设计，比如我们第 9 讲中提到的 Google Borg、Kubernetes 等。

在非集中式结构中，服务的执行和数据的存储被分散到不同的服务器集群，服务器集群间通过消息传递进行通信和协调。也就是说，在非集中式结构中，没有中央服务器和节点服务器之分，所有的服务器地位都是平等（对等）的，也就是我们常说的“众生平等”。这样一来，相比于集中式结构，非集中式结构就降低了某一个或者某一簇计算机集群的压力，在解决了单点瓶颈和单点故障问题的同时，还提升了系统的并发度，比较适合大规模集群的管理。

集中式结构就是，由一台或多台服务器组成中央服务器，系统内的所有数据都存储在中央服务器中，系统内所有的业务也均先由中央服务器处理。多个节点服务器与中央服务器连接，并将自己的信息汇报给中央服务器，由中央服务器统一进行资源和任务调度：中央服务器根据这些信息，将任务下达给节点服务器；节点服务器执行任务，并将结果反馈给中央服务器。集中式结构最大的特点，就是部署结构简单。

2016 年 3 月，Google AlphaGo 以 4:1 的比分赢得了世界围棋冠军李世石。这场围棋人机大战，将人工智能技术推向了高潮。现在，人工智能已经广泛渗透到了我们的生活中，比如手机拍照美化、人脸识别、平安城市、自然语言处理、语音识别等。那么，到底什么是人工智能呢？所谓人工智能，其实就是希望机器能够模拟人的思维，像人一样智能。目前，对人工智能的定义大多可划分为四类，即机器“像人一样思考“像人一样行动”“理性地思考”和“理性地行动”。这里的行动，指的是采取行动或制定行动的决策。

以电商购物为例，首先剖析了什么是分布式锁，以及为什么需要分布式锁；然后，与你介绍了三种实现分布式锁的方法，包括基于数据库实现、基于缓存实现（以 Redis 为例），以及基于 ZooKeeper 实现。分布式锁是解决多个进程同时访问临界资源的常用方法，在分布式系统中非常常见，比如开源的 ZooKeeper、Redis 中就有所涉及。通过今天这篇文章对分布式锁原理及方法的讲解，相信会发现分布式锁不再那么神秘、难懂，然后以此为基础对分布式锁进行更深入的学习和应用。

在介绍分布式事务之前，我们首先来看一下什么是事务。事务（Transaction）提供一种机制，将包含一系列操作的工作序列纳入到一个不可分割的执行单元。只有所有操作均被正确执行才能提交事务；任意一个操作失败都会导致整个事务回滚（Rollback）到之前状态，即所有操作均被取消。简单来说，事务提供了一种机制，使得工作要么全部都不做，要么完全被执行，即 all or nothing。通常情况下，我们所说的事务指的都是本地事务，也就是在单机上的事务。而事务具备四大基本特征 ACID，具体含义如下。

假设，现在有 5 台服务器，分散在美国华盛顿、英国伦敦、法国巴黎、中国北京、中国上海，分别对应着用户{A,B,C,D,E}。现在，用户 A 给用户 B 转了 100 元。在传统方法中，我们通过银行进行转账并记录该笔交易。但分布式在线记账方法中，没有银行这样的一个集中方，而是由上述 5 台服务器来记录该笔交易。但是，这 5 台服务器均是有各自想法的个体，都可以自主操作或记录，那么如何保证记录的交易是一致的呢？这，就是分布式共识技术要解决的问题。可以看出，

今天，首先讲述了什么是分布式选举，以及为什么需要分布式选举。然后，介绍了实现分布式选举的 3 种方法，即：Bully 算法、Raft 算法，以及 ZooKeeper 中的 ZAB 算法，并通过实例与展示了各类方法的选举流程。将今天的主要内容总结为了如下所示的思维导图，来帮助加深理解与记忆。

想象一下，你正在一家餐厅使用自助咖啡机泡制咖啡，突然有个人过来挪走了你的杯子，开始泡制他自己的咖啡。你耐着性子等他操作完，继续泡制自己的咖啡。结果你开始没多久，他又回来中断了你泡制咖啡的过程。相信要不了几个回合，你和他就会上演一场“有你没我，有我没你”的格斗了。这样现实的问题也同样存在于分布式世界。就像我们使用自助咖啡机时不希望被打扰一样，对于同一共享资源，一个程序正在使用的时候也不希望被其他程序打扰。这，就要求同一时刻只能有一个程序能够访问这种资源。在分布式系统里，这种排他性的资源访问方式，叫作。

按照不同维度，分布式系统的指标可以分为性能、资源占用、可用性、可扩展性这四大类。我们自然希望自己的系统，是高性能、高可用、高扩展和低资源占用的，但考虑到硬件成本、开发效率等因素，必须要在设计不同的系统、业务时有所取舍。所以，又分析了典型的电商、IoT、电信、HPC（高性能计算）、大数据、云计算、区块链等业务或系统的不同诉求，进而得出了系统设计者需要关注哪些指标。你在设计其他类型的系统时，可以按照这个思路进行取舍。在文中提到了，分布式系统的指标之间会存在一些冲突或约束。

在今天这篇文章中，分享了分布式的起源，即从单机模式到数据并行（也叫作数据分布式）模式，再到任务并行（也叫作任务分布式）模式。单机模式指的是，所有业务和数据均部署到同一台机器上。这种模式的好处是功能、代码和数据集中，便于维护、管理和执行，但计算效率是瓶颈。也就是说单机模式性能受限，也存在单点失效的问题。数据并行（也叫作数据分布式）模式指的是，对数据进行拆分，利用多台计算机并行执行多个相同任务，通过在相同的时间内完成多个相同任务，从而缩短所有任务的总体执行时间，但对提升单个任务的执行性能及降低时延无效。

第一，分布式技术错综复杂，各种技术相互耦合，确实无法简单地像网络等技术一样划分层次，所以我会结合自己多年的积累和思考，首先为你梳理出一个脉络清晰、四纵四横的分布式核心技术知识体系，然后从这个纵横的技术体系中抽取最核心、最普适的技术思想以及概念，结合各种适用场景一一解析。这样的设计，旨在帮助你找到核心知识点，并将这些知识点联系起来，快速形成分布式核心技术的知识网络，从而形成自己的技术判断力，进而规划出自己的技术路线。而网上的各种技术文章虽然多，却鲜有体系化的说明，一个个概念如同一座座信息孤岛。