分布式系统

在介绍分布式系统之前，先说一说与之对应的集中式系统。

集中式系统有一个大型的中央处理系统，往往是一台高性能的计算机，所有数据的运算和处理都在中央计算节点上完成，然后由多个终端进行访问连接，终端只用来输入输出，不具备处理能力。像我们日常生活中见到的银行自动提款机 ATM 就是使用的集中式系统。

这类系统最大的特点就是部署简单，但是由于采用单机部署，系统会很复杂，容易发生单点故障，从而导致整个系统服务崩溃，扩展性比较差。

当然，分布式系统也有问题，系统中的各个部分彼此分开放置，这本身就带来了极大的困难，远程进程间的通信链路可能既慢又不可靠，分布式领域中的大多数研究都与“没有什么是完全可靠的”这一事实有关。

背景

维基百科的定义：分布式系统是一组电脑，透过网络相互连接传递消息与通信后并协调它们的行为而形成的系统。组件之间彼此进行交互以实现一个共同的目标。把需要进行大量计算的工程数据分割成小块，由多台计算机分别计算，再上传运算结果后，将结果统一合并得出数据结论的科学。

Google 以三驾马车开启了大数据领域的先河，此处简单罗列这三篇论文：

1. 2003 年公布的第一篇论文，这是一个可扩展的分布式文件系统，用于大型的、分布式的、对大量数据进行访问的应用。

2. 2004 年发布的 MapReduce 基本上可以代表大数据处理思想的出现了，其核心是将任务拆解然后在多台廉价的计算机节点上进行运算，最后再将结果合并。

3. 2006 年发布的 BigTable 启发了无数的 NoSQL 数据库，最典型的比如：Cassandra、HBase等等。

概述

那么，为什么人们要创建一个分布式系统呢？

• 通过并行增加计算能力
• 通过复制增加容错
• 将计算物理上靠近外部实体，通过某种通信方式克服距离
• 通过隔离实现安全，解决通信协议的安全、孤立问题

分布式系统虽好，但同时其复杂程度也是呈几何倍上升的，在创建和设计一个分布式系统的过程中就不可避免地产生许多问题，比如网络异常、节点故障、负载均衡、资源调度、数据的一致性、分布式事务等等。

在解决这些问题的过程中，逐渐产生了一些理论，譬如 CAP、BASE 等等，当然还有很多理论，此处暂不讨论。

CAP 理论

2000 年 7 月，加州大学伯克利分校的 Eric Brewer 教授在 ACM PODC 会议上提出 CAP 猜想。2 年后，麻省理工学院的 Seth Gilbert 和 Nancy Lynch 从理论上证明了 CAP。之后，CAP 理论正式成为分布式计算领域的公认定理，明确指出任何分布式系统最多可以具有以下三个属性中的两个：

• C：Consistency
• A：Availability
• P：Partition tolerance

一致性

即在写操作之后的读操作，必须返回该值。

举例说明：某条记录是 G1=a，同时这条记录有一个备份 G2=a，用户向 G1 发起写请求，将 a 改为 b，然后用户再向 G1 发起读请求得到 b，这就满足了一致性，但是用户也可能向 G2 发起读请求得到的却还是 a，这就不满足一致性。

解决方案：为了在 G2 进行读操作的时候与 G1 得到相同的结果，就要在 G1 进行写操作时，让 G1 向 G2 也发送一条信息，要求 G2 将 a 改为 b，这样用户向 G2 发起读请求时也能得到 b。

此处的一致性要区别于数据库 ACID 中的一致性，这里的一致性是指数据副本的一致性，而事务的一致性则指数据从一个状态变为另一个状态的整体是一致的。比如银行转账，甲（5元）转账给乙（10元）5 元，那么甲就一定要变为 0 元，乙一定就变为 15 元，而不是甲还有 5 元这种整体的一致性。

可用性

即系统中非故障节点收到用户的请求后，都必须做出响应。要求系统在一个或多个节点出现故障或不可用的情况任然能够处理请求。

分区容错性

从一个节点发送到另一个节点的消息允许丢失。

大多数分布式系统都存在多个子网络分区，这些分区间的通信有可能会失败，一般来说，分区容错是无法避免的，比如一台服务器在北京，一台服务器在上海，它们之间可能因为很多问题导致通信失败，所以基本可以认为分布式系统中 P 一定是成立的。

冲突点

在网络分区的情况下，我们无法实现一个同时保证可用性和一致性的分布式系统。

举例来说，如果要保证一致性，我们在向 G1 发起写操作时，需要锁定 G2 的读写操作，直到数据同步后再开放，但在锁定期间，G2 是不可用的，违背了可用性；如果要保证 G2 的可用性，那就不能锁定 G2，无法保证一致性。

因此，我们只能在提供尽力而为的可用性的同时保证强一致性，或者在提供尽力而为一致性的同时保证可用性，于是就有了下面两种系统：

1. 一致性和分区容忍系统 CP
   CP 系统更倾向于拒绝请求，而不是提供可能不一致的数据
2. 可用性和分区容忍系统 AP
   AP系统则放松了一致性的要求，允许再请求期间提供可能不一致的值

BASE 理论

概述

eBay 的架构师 Dan Pritchett 源于对大规模分布式系统的实践总结，在 ACM 上发表文章提出 BASE 理论，BASE 理论是对 CAP 理论的延伸，核心思想是即使无法做到强一致性（Strong Consistency，CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性（Eventual Consitency）。四个字母是 Basically Available（基本可用）、Soft state（软状态）和 Eventually consistent（最终一致性）的简写。

基本可用

分布式系统在出现故障的时候，允许损失部分可用性，即保证核心可用。

举例来说，假设系统出现不可预知的故障：

1. 响应时间上的损失：正常情况搜索引擎 0.5s 返回结果，而基本可用的搜索引擎在 2s 内返回结果
2. 功能上的损失：正常情况电商平台用户可以顺利下订单，但是促销时，为了保护购物的稳定性，部分消费者可能会被引导到一个降级页面。

软状态

允许系统存在中间状态，而该中间状态不会影响系统整体可用性，即允许系统在多个不同节点的数据副本存在数据延时。数据的三个副本和 MySQL Replication 的异步复制都是一种体现。

最终一致性

最终一致性是指系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。在实际工程实践中，有五种情况。

因果一致性（Causal consistency）

如果进程 A 在更新完某个数据项后通知了进程 B，那么进程 B 之后对该数据项的访问都应该能够获取到进程 A 更新后的最新值，并且如果进程 B 要对该数据项进行更新操作的话，务必基于进程 A 更新后的最新值，即不能发生丢失更新情况。与此同时，与进程 A 无因果关系的进程 C 的数据访问则没有这样的限制。

读己之所写（Read your writes）

读己之所写是指，进程 A 更新一个数据项之后，他自己总是能够访问到更新过的最新值，而不会看到旧值。

会话一致性（Session consistency）

将对系统数据的访问过程框定在了一个会话当中：系统能保证在同一个有效地会话中实现“读己之所写”的一致性。

单调读一致性（Monotonic read consistency）

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

单调写一致性（Monotonic write consistency）

一个系统需要能够保证来自同一个进程的写操作被顺序的执行。