1. 分布式

分布式系统是指在不同的物理设备上，将网络作为信息传递的媒介，通过应用程序来共同完成一项任务。简单的来说，分布式系统就是一组计算机系统一起工作，但从表面上看只有一台计算机在工作。这组一起工作的计算机，拥有共享的状态，它们同时运行，且单个机器的故障不会影响整个系统的正常运行。

1.1 分布式系统的特征

1.1.1 可用性

指的是系统在面对各种异常时可以正确提供服务的能力。系统的可用性可以用系统停止服务的时间与总的时间之比衡量。

分布式系统由于有多台服务器组成，如果一台挂了，还有其他服务器提供服务，这里涉及到有：

分布式协同、共识算法
负载均衡

1.1.2 一致性

组成分布式系统的服务，需要保证数据状态的一致性，这样整个分布式系统才是可靠的。
这里面涉及的有：

数据一致性理论基础：CAP/BASE
分布式事务
分布式锁

1.1.3 可扩展性

指的是分布式系统通过扩展集群机器规模提高系统性能 (吞吐、响应时间、完成时间)、存储容量、计算能力的特性。

当流量增加时，需要更多机器加入来支撑系统时，可以快速且无损的增加机器
当流量低峰时，可以减少机器，提高机器资源的使用率，从来降低成本

1.1.4 容错性

在分布式系统中，错误是不可能避免的。既然错误无可避免，那么，我们应该做的是，将容错也作为功能去实现。

为什么在系统错误是不可以避免的，这里要说到的就是【错误的分布式假设理论】：

网络是稳定的
网络传输的延迟是零
网络的带宽是无穷大
网络是安全的
网络的拓扑不会改变
只有一个系统管理员
传输数据的成本为0
整个网络是同构的

要深刻地认识这8个错误。

1.2 分布式系统的分类

1.2.1 分布式计算

基于分布式计算模式，包括批处理计算、离线计算、在线计算、融合计算等，根据应用类型构建高效智能的分布式计算框架。

1.2.2 分布式存储

解决数据的分布式和多元化问题。包括分布式数据库、分布式文件系统、分布式缓存等，支持不同类型的数据的存储和管理。

1.2.3 分布式通信

解决进程间的分布式通信问题。通过消息队列、远程调用等方式，实现简单高效的通信。

1.2.4 分布式分布式资源管理

解决资源的分布式和异构性问题。将 CPU、内存、IO 等物理资源虚拟化，实现逻辑资源池，来统一管理

2. 分布式一致性

2.1 ACID

ACID 是数据库事务正确执行的四个基本要素。

原子性
1. 事务被视为不可分割的最小单元，事务中的所有操作要么全部提交成功，要么全部失败回滚。
2. 回滚可以用日志来实现，日志记录着事务所执行的修改操作，在回滚时反向执行这些修改操作即可。
一致性
1. 数据库在事务执行前后都保持一致性状态。
2. 在一致性状态下，所有事务对一个数据的读取结果都是相同的。
隔离性
1. 一个事务所做的修改在最终提交以前，对其它事务是不可见的。
持久性
1. 一旦事务提交，则其所做的修改将会永远保存到数据库中。即使系统发生崩溃，事务执行的结果也不能丢失。
2. 可以通过数据库备份和恢复来实现，在系统发生奔溃时，使用备份的数据库进行数据恢复。

2.2 CAP

CAP定理是加州大学计算机科学家埃里克·布鲁尔提出来的猜想，后来被证明成为分布式计算领域公认的定理。

CAP定理：在一个分布式系统中，最多只能同时满足以下其中两项。

一致性（Consistency）：在任何给定时间，网络中的所有节点都具有完全相同（最近）的值。
可用性（Availability）：对网络的每个请求都会收到响应，但不能保证返回的数据是最新的。
分区容错性（Partition Tolerance）：即使任意数量的节点出现故障，网络仍会继续运行

2.2.1 一致性

一致性（Consistency）指的是多个数据副本是否能保持一致的特性。
在一致性的条件下，分布式系统在执行写操作成功后，如果所有用户都能够读取到最新的值，该系统就被认为具有强一致性。
数据一致性又可以分为：

强一致性：数据更新操作结果和操作响应总是一致的，即操作响应通知更新失败，那么数据一定没有被更新，而不是处于不确定状态。
最终一致性：即物理存储的数据可能是不一致的，终端用户访问到的数据可能也是不一致的，但系统经过一段时间的自我修复和修正，数据最终会达到一致。

2.2.2 可用性

可用性指分布式系统在面对各种异常时可以提供正常服务的能力，可以用系统可用时间占总时间的比值来衡量，4 个 9 的可用性表示系统 99.99% 的时间是可用的。

在可用性条件下，系统提供的服务一直处于可用的状态，对于用户的每一个操作请求总是能够在有限的时间内返回结果。

2.2.3 分区容错性

分区容错性（Partition Tolerance）指分布式系统在遇到任何网络分区故障的时候，仍然需要能对外提供一致性和可用性的服务，除非是整个网络环境都发生了故障。

由于【错误的分布式假设理论】我们可以知道：网络是不稳定的，所以网络分区也会出现，我们在系统设计的时候，就必须考虑到这种情况。因此可以认为 CAP 的 P总是成立。CAP定理告诉我们，剩下的 C 和 A 无法同时做到。

一致性和可用性，为什么不可能同时成立？

在分布式环境下，为了保证系统可用性，通常都采取了复制的方式，避免一个节点损坏，导致系统不可用。那么就出现了每个节点上的数据出现了很多个副本的情况，而数据从一个节点复制到另外的节点时需要时间和要求网络畅通的，所以，当P发生时，也就是无法向某个节点复制数据时，这时候你有两个选择：
1. 选择可用性 A(Availability)，此时，那个失去联系的节点依然可以向系统提供服务，不过它的数据就不能保证是同步的了（失去了C属性）。
2. 选择一致性C(Consistency)，为了保证数据库的一致性，我们必须等待失去联系的节点恢复过来，在这个过程中，那个节点是不允许对外提供服务的，这时候系统处于不可用状态(失去了A属性)。

综上所述，系统设计时只能选择一个目标。如果追求一致性，那么无法保证所有节点的可用性；如果追求所有节点的可用性，那就没法做到一致性。

2.2.4 AP和CP的使用场景

根据ap和cp的特性，

使用CP的场景要求数据的强一致性：
1. 支付交易领域
2. Hbase 等分布式数据库领域
3. 分发及订阅元数据的 Zookeeper，也是选择优先保证 CP
使用AP的场景要求系统的可用性，可以容忍一段时间内的数据不一致：
1. 服务组册与管理平台，在 AP 模式下，如果请求到不准确的服务实例信息，导致请求发送到一个宕机的服务端，只要做好失败重试机制和负载均衡，这次请求能够顺利的进行。
2. 优先保证用户体验的场景

2.3 BASE

BASE 是基本可用（Basically Available）、软状态（Soft State）和最终一致性（Eventually Consistent）三个短语的缩写。

BASE 理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

2.3.1 基本可用

基本可用（Basically Available）保证核心可用，允许损失部分可用性。例如，电商在做促销时，为了保证购物系统的稳定性，部分消费者可能会被引导到一个降级的页面。

2.3.2 软状态

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

2.3.3 最终一致性

最终一致性（Eventually Consistent）强调的是系统中所有的数据副本，在经过一段时间的同步后，最终能达到一致的状态。

BASE 的理论的核心思想是：即使无法做到强一致性，但每个应用都可以根据自身业务特点，采用适当的方式来使系统达到最终一致性。

ACID 要求强一致性，通常运用在传统的数据库系统上。而 BASE 要求最终一致性，通过牺牲强一致性来达到可用性，通常运用在大型分布式系统中。

结论：在实际的分布式场景中，不同业务单元和组件对一致性的要求是不同的，因此 ACID 和 BASE 往往会结合在一起使用。

3. 共识算法

在分布式计算中，不同的节点通过通讯交换信息达成共识而按照同一套协作策略行动。但有时候，系统中的节点可能出错而发送错误的信息，用于传递信息的通讯网络也可能导致信息损坏，使得网络中不同的成员关于全体协作的策略得出不同结论，从而破坏系统一致性。

3.1 拜占庭将军问题

兰伯特针对拜占庭将军问题，给出了两个解决方案：口头协议和书面协议。
在口头协议中，拜占庭将军问题被简化为将军 - 副官模型，其核心规则如下：

忠诚的副官遵守同一命令。
若将军是忠诚的，所有忠诚的副官都执行他的命令。

如果叛徒人数为 m，将军人数不能少于 3m + 1 即大于3m，那么拜占庭将军问题就能解决了。

分布式理论基础