我们每天都在讲分布式和分布式，那么我们知道什么是分布式，分布式会遇到什么问题，有哪些理论支持，有哪些经典方案，行业如何设计和保证分布式的高可用？系统？

1.建筑设计

本节将从一些经典的开源系统架构设计开始，看看如何设计一个高质量的分布式系统；

一般的设计出发点无非就是

1.1 主备架构

为现有服务构建备份服务。两者的功能完全相同。不同的是，通常只有主应用提供外部服务能力；而备用应用只需要保证主应用的能力与主应用的能力一致即可。服务; 当主应用出现故障时，备用应用切换为主应用，原主应用下线；快速主备切换，有效缩短故障时间

综上所述，主备架构的特点就比较清楚了。

其次，在这个架构模型中最需要考虑的是如何实现主备切换？

1.2 主从架构

主从一般称为读写分离。 提供读写能力， 只提供读写能力。

从目前的互联网应用来看，大多是读多写少的场景；读更容易成为性能瓶颈，所以使用读写分离可以有效提升整个集群的响应能力

主从架构可以分为：一主、多从+一主、一从、多从。以主从架构模型为例进行说明

主从模式的主要特点是

关键问题是

1.3 多主多从架构

一主多从面对单主节点的瓶颈，再考虑多主多从的策略。也负责提供read和，提供read；

但是这里有一个核心点就是多个之间的数据同步，如何保证数据的一致性是这个架构模型的重点

比如双主双从可以说是一个典型的应用场景。除了以上的一致性，实际使用中还需要考虑主键id冲突的问题。

1.4 普通集群模式

没有主节点，集群中所有应用功能都是平等的，没有主次之分（目前大部分业务服务都属于这一类），一个请求可以被集群中的任何一个服务响应；

这也可以称为去中心化设计模式，如集群模式、注册中心，以可用性为首要目标

对于普通集群模式，要考虑的关键点是

数据一致性：如何保证所有实例数据一致，或者最终一致

1.5 数据分片架构

此分片模型的描述可能不准确。当你阅读它时，专注于理解这个想法。

在之前的架构中，都是采用数据冗余的方式，即所有实例都有全量数据，而这里的数据分片是从数据拆分的思想来处理的，全量数据通过。将一定的规则划分为多个系统，每个系统包含部分数据，减少单个节点的压力，主要用于解决数据量大的场景

例如，在集群模式下，分区是由散列槽执行的。

es等索引分片存储

1.6 灰色总结

本节主要从架构设计层面对当前分布式系统解决方案进行简单的分类和总结，不一定全面。欢迎留言指正

基于冗余的思想：

分裂思维：

对于分割这块，我们常说的分库分表也体现了这个思想

2.理论基础

本节将介绍分布式系统中的经典理论，如广义过程的CAP/BASE理论、一致性理论基础、raft、信息交换协议、两阶段、三阶段等。

本节主要内容指

2.1 CAP 定理

CAP 定理指出，分布式系统不可能同时提供以下三个要求：

： 可用性

: 分区容错

一般来说，很难不保证P。当服务部署在多个实例上时，节点异常和网络故障是正常的，根据不同的业务场景进行选择。

对于服务有限的应用，AP是保证高可用的首选。即使部分机器出现异常，也不会导致整个服务不可用；例如，大多数前台应用程序是这样的

对于数据一致性要求高的场景，比如涉及钱的支付结算，CP可能更重要

CAP的三种组合描述如下

2.2 基础理论

作为上限的延伸，基础理论的核心特征是摒弃强一致性，追求最终一致性

软：软状态

: 最终一致性

综合以上描述可以看出，BASE理论适用于大规模高可用、可扩展的分布式系统

注意，它不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内不一致，但最终达到一致状态

2.3 定理

没听说过，以下来自：

定理的第一部分（PAC）与CAP定理相同，ELC是一个扩展。整个论点假设我们通过复制保持高可用性。因此，当它失败时，CAP 定理占上风。但如果不是，我们仍然需要考虑复制系统中一致性和延迟之间的权衡。

2.4 共识算法

该算法解决的问题是分布式共识问题，即分布式系统中的各个进程如何通过共识就某个值（分辨率）达成一致

根据上面的描述，可以看出非常适合选举；它的工作流程

角色划分：

：不参与决策一致性hash算法php开源，获取最新提案

2.5 Raft 算法

推荐感兴趣的朋友，查看

为了解决复杂度，raft算法提供了一个更易理解的算法基础，其核心流程为：

接受请求并转发到，当收到大部分响应时，通知所有提交请求，自己提交请求并告诉调用者 ok

角色划分：

2.6 ZAB 协议

ZAB() 协议是专为分布式协调服务设计的支持崩溃恢复的一致性协议。基于该协议，实现了主从模式的系统架构，以保持集群中副本之间的数据一致性。

主要用于zk的数据一致性场景。核心思想是收到交易请求后，通过给定，当一半以上返回ACK时，提交提案并发送信息给

角色划分

: 追随者

: 是从 3.3.0 开始引入的一个角色，

2.7 2PC 协议

二、两阶段提交协议，主要解决强一致性，集中式强一致性协议

角色划分

实施过程

协调者节点接收到请求，然后将其提交给参与者节点。当所有参与者都回复ok后，协调节点提交给所有参与者节点，全部返回ok后，数据确认提交。

当参与者在第一阶段失败时，所有参与者节点都回滚

特征

优点是易于实现

缺点也很明显

2.8 3PC 协议

分布式事务：两阶段提交与三阶段提交

在两阶段展开的基础上，第一阶段分为两部分，+，第三阶段为

第一阶段

在这个阶段，协调者会询问每个参与者是否可以正常执行交易，参与者会根据自己的情况回复一个估计值。与真正的执行交易相比，这个过程是轻量级的

第二阶段

在这个阶段，协调者会根据第一阶段的查询结果采取相应的行动。如果所有参与者都返回ok，则协调者将向参与者提交事务执行（单个未提交）通知；否则，将通知参与者回滚

第三阶段

如果第二阶段的事务没有中断，这个阶段的协调者会根据事务执行返回的结果来决定提交或回滚事务。如果所有参与者都正常执行，他们将提交；否则，协调者 + 参与者将回滚

在这个阶段一致性hash算法php开源，如果参与者因为协调者或网络问题而未能收到协调者的 OR 请求，参与者不会像两阶段提交那样被阻塞，而是会等待超时继续进行，相比于两阶段提交- 减少同步阻塞，但仍不能完全避免数据不一致

特征

数据不一致依然存在

2.9 协议

该协议，顾名思义，就像八卦一样，采用一种随机且具有传染性的方式在整个网络中传播信息，并使系统中的所有节点在一定时间内保持一致。通过以上特性，协议可以保证系统在极端情况下也能运行（例如集群中只有一个节点在运行）

主要用于分布式数据库系统中各个副本节点同步数据。这种场景的最大特点之一是形成的网络的节点都是对等节点，是一个非结构化的网络。

工作过程

特征

缺点

2.10 灰色摘要

本节主要介绍分布式系统设计中一些常见的理论基石，例如如何保证分布式系统的一致性以及如何就一个提案达成共识

3.算法

本节将主要介绍分布式系统中的经典算法，如分区常用的一致性哈希算法、适合一致性的NWR算法、PBFT拜占庭容错算法、区块链中广泛使用的PoW等。算法等

3.1 一致性哈希算法

一致性哈希算法，主要用于数据分片场景，有效降低增删服务对数据复制的影响

通过对数据项的键进行散列来映射其在环上的位置，然后顺时针遍历环，找到位置大于项的位置的第一个节点，将键标识的每个数据分配给散列环一个节点

一致性哈希的主要优点是增量稳定性；节点的增删，对于整个集群，只影响其近邻，其他节点不受影响。

注意：

3.2 NWR 算法

用于确保数据冗余和最终一致性的投票算法的主要数学思想来自鸽巢原理

NWR算法要求每个数据拷贝对象可以投1票，每次操作的执行需要获得最少的读票和写票；一般来说网站开发，写入票数W一般需要超过N/2，也就是我们通常说的get超过一半的票数说明数据写入成功

实际上，当 W=N 且 R=1 时，称为 WARO（All Read One）。这就是CAP理论中CP模型的场景。

3.3 PBFT拜占庭算法

拜占庭算法主要针对分布式场景下无响应，或者响应不可信时的容错问题。其核心分为三个阶段，如下

假设集群节点数为N，f个故障节点（无响应）和f个问题节点（无响应或错误响应），f+1个正常节点，即3f+1=n

与完全不适合有人作恶的场景的 Raft 算法相比，PBFT 算法可以容忍（n 1)/3 个恶意节点（也可以是故障节点）。另外，与PoW算法，PBFT的优点是不消耗算力，PBFT算法是O(n^2)的消息复杂度算法，所以随着消息数量的增加，网络延迟会有更大对系统运行的影响，限制了PBFT算法的运行，分布式系统的规模也决定了PBFT算法适用于中小型分布式系统

3.4 PoW算法

工作量证明（Of Work，简称PoW）也用于分布式一致性场景。它不同于之前的raft和pbft。它采用投票机制来达成共识方案。PoW 使用工作证明。

客户端需要做一些困难的工作才能得到一个结果，但验证者可以通过结果轻松检查客户端是否做了相应的工作。通过消耗一定的工作量，增加了消息伪造的成本。广泛应用于链条，广为人知。下面简单说一下PoW算法与区块链的应用场景。

以转BTC为例，A转n个BTC给B，如何保证n个币不会同时转给C？

PoW算法主要用于上述区块提交的验证，通过哈希值计算消耗算力来证明矿工确实付出了，在多数同意的情况下才能达成共识。

3.5 灰色总结

本节主要介绍当前分布式下的常用算法，

4.技术思路

与前面的内容相比，本节的内容不容易分类清楚；主要包括一些优质分布式系统实践中推荐的设计思路和技术细节

4.1 个 CQRS

也就是我们通俗理解的读写分离，核心思想是将两种不同的操作分开，在独立的服务中实现

目的是将领域模型与查询功能分离，让一些复杂的查询摆脱领域模型的限制，以更简单的DTO形式显示查询结果。同时，不同的数据存储结构分离，让开发者可以根据查询的功能和需求更自由地选择数据存储引擎

4.2 复制负载均衡服务

复制负载均衡服务（Load，RLBS）可以简单理解为我们常说的负载均衡。多个相同的服务实例构建一个集群，每个服务可以响应请求，负载均衡器负责将请求分发到不同的实例。上，常见的加载算法

4.3 心跳机制

分布式环境下，如何判断一个服务是否存活，目前最常见的解决方案就是心跳

比如在raft算法中，向all发送心跳意味着你还活着，避免了新的选举；

比如哨兵机制也是利用ping/pong的心跳来判断节点是否下线，是否需要选择新的主节点；

再比如我们日常业务应用的健康监测，判断服务是否正常

4.4 租赁机制

租约就像一把锁，但即使客户离开它也能工作。客户端请求一个有限期限的租约，之后租约到期。如果客户端想要延长租约，它可以在租约到期之前更新租约。

租约主要是为了避免一个资源被某个对象长期持有，一旦对方挂掉，就不会主动释放的问题；在实际场景中，有两种典型应用

分布式锁

业务获取的分布式锁一般都有有效期。如果在有效期内没有主动释放，锁依然会被释放，其他业务也可以抢占锁；因此，对于持有锁的业务方，如果发现在到期之前，如果业务逻辑还没有处理完，可以续约，让自己继续持有锁

一个典型的实现是看门狗机制

raft算法的任期

在 raft 算法中，每个人都有一个任期，之后会被重新选举。为了避免连任，一般会定期发送心跳来续约。

4.5 &

这个很容易理解，上面很多系统都采用了这种方案，尤其是在共识算法中，负责代表整个集群做出决策，并将决策传播到所有其他服务器

领导者选举发生在服务器启动时。每台服务器在启动时都会发起一次领导选举，并尝试选举一个领导。除非选举出领导者，否则系统不接受任何客户端请求

4.6

在-模型中，当失效时，无法确定已经停止工作，比如网络慢或者网络分区可能触发新的选举，即使之前的还在运行并且认为依然是赛事的领头羊

指在先前活动的领导者周围放置一个栅栏，使其无法访问集群资源，从而阻止任何读/写请求被服务

4.7 法定人数

，常用于选举和共识算法。当超过的节点数被确认后，提案通过（数据更新成功）。通常，法定人数是=一半的节点+1

4.8 高分

高水位线，（）上的最后一个日志条目，并且该条目被成功复制到（）>（），意味着该日志被整个集群接受

该条目在日志中的索引称为高水位线索引。领导者仅将数据暴露给高水印索引。

例如，为了处理不可重复读取并确保数据一致性，会跟踪高水位线，这是特定分区的最大偏移量。用户只能看到达到高水位线的消息。

4.9 Phi 累积故障检测

使用历史心跳信息的自适应阈值

通用应计故障检测器不会判断服务器是否处于活动状态，但会输出有关服务器的可疑级别。

eg（开源分布式数据库）使用 Phi 累积故障检测算法来确定集群中节点的状态

4.10 - 记录预写日志

预写日志是针对操作系统中文件系统不一致问题的高级解决方案。当我们提交写入操作系统的文件缓存时，业务会认为已经提交成功；有一个时差。如果此时机器宕机，缓存中的数据就会丢失，导致完整性丢失。

为了解决这个问题，例如es等都采用了- log的机制来避免这个问题

：

：

4.11 段日志

将日志拆分为多个较小的文件，而不是单个大文件，以便于操作。

在启动时读取单个日志文件可能会增长并成为性能瓶颈。较旧的日志会定期清理，很难对单个大文件进行清理操作。

单个日志被分成多个段。日志文件在指定的大小限制后滚动。使用日志分段，需要一种简单的方法将逻辑日志偏移（或日志序列号）映射到日志段文件。

这其实很常见。比如我们实际业务应用配置的日志，一般都是按天拆分，固定大小网站建设，并不是所有的日志都放在一个日志文件中。

再比如es的分段存储，一个就是一个小的存储文件

4.12 检查

在分布式系统中，当数据在组件之间移动时，从节点获取的数据可能会损坏。

计算校验和并将其与数据一起存储。

要计算校验和，请使用加密哈希函数，例如 MD5、SHA-1、SHA-256 或 SHA-512。哈希函数接受输入数据并产生一个固定长度的字符串（包含字母和数字）；这个字符串称为校验和。

当系统存储一些数据时，它会计算数据的校验和，并将校验和与数据一起存储。当客户端检索数据时，它会验证从服务器接收到的数据是否与存储的校验和匹配。如果没有，客户端可能会选择从另一个副本中检索该数据。

HDFS 并将每个文件的校验和与数据一起存储。

4.13 灰色总结