这就是搜索引擎(3) 云存储与云计算概述
1. 背景
为什么需要云存储和云计算？对于商业搜索引擎来说，需要处理的数据超过百亿，并且不部分数据都是互联网页面这样的无结构化或者半结构化数据。云存储和云计算平台的目的，就是为了存储和管理这些海量数据变得简单化。目前来看，一套高效的云存储和云计算平台，已经成为了搜索引擎的核心竞争力。
这本书主要是通过Google提供的一整套云存储和云计算技术框架，来介绍相关的核心技术。主要是GFS/BigTable/MapReduce三驾马车。在阅读的过程中，也会选取其他公司的技术方案进行对比。
2 基本假设
由于互联网数据的爆炸性增长，导致大型互联网公司开始提倡并推行云存储与云计算，云存储和云计算平台的设计都遵循以下一些基本假设和要求
- 由大量廉价PC构成：目的主要是节省成本
- 机器节点出现故障是常态：这使得云存储和云计算技术方案在设计之初，就要在这个约束下提供可靠服务，考虑到数据的可用性和安全性
- 水平增量扩展：随着数据量的不断增大，需要靠增加机器来承载更多数据，同时必须在用户无感知的情况下实现增量扩展，对于云存储和云计算平台，这往往是通过数据的水平分割实现的。
- 弱数据一致性：云存储和云计算平台因其背景而必须拥有的特性：高可用性、易拓展性、高容错性。在此基础上，需要付出的代价就是弱数据一致性，这主要是因为很多互联网服务并不要求强数据一致性。
- 读多写少型服务：根据互联网服务的特点，设计云计算和云存储平台时，可以做出有针对性的优化来提升效率。
3 理论基础
3.1 CAP原则(Consistency/Availability/Partition Tolerance)
CAP原则又称CAP定理，指的是在一个分布式系统中，Consistency（一致性）、 Availability（可用性）、Partition Tolerance（分区容错性），三者不可得兼。
3.1.1 Partition Tolerance（分区容错性）
大多数分布式系统分布在多个子网络，每个子网络称作一个区(partition), 所谓的分区容错指的是区间通信可能会失败。实际使用中，失败指的是没有达到区之间通信的时限要求，当系统不能再时限内达成数据一致性，就意味着发生了分区的情况，这种情况下就必须在C与A之间做出选择。
对于分布式系统来说，分区容忍是天然具备的要求，所以P无法避免，在设计具体技术方案的时候，必须在一致性和可用性方面做出取舍。
3.1.2 Consistency（一致性）
一致性指的是对分布式系统所有节点的访问，都能够得到同一份最新的数据副本。
3.1.3 Availability（可用性）
可用性就是说服务可用，即每次对服务的访问都能够得到返回（不管数据是否是最新的数据）
3.1.4 为什么CAP三者不可兼得
简单来说，试想两个节点分别处于分区的两侧，如果要求至少一个节点更新状态，则会导致数据的不一致（丧失C），如果为了保证数据的一致性，将未成功更新状态的节点设置为不可用，则会导致服务不可用（丧失A），如果要求两个节点可以相互通信，保证数据的一致性，则会丧失P性质
CA without P：传统的关系数据库在三要素中会选择CA两个因素，获得强数据一致性和高可用性，但这会导致扩展性差。
CP without A：如果不要求可用，要求每个请求在Server之间强一致，那么P会导致同步的时间无限延长，很多传统的数据库分布事务属于这种模式。
AP without C：高可用并且允许分区，则需要放弃一致性，云存储数据库往往数属于此类。
3.2 ACID原则
ACID是传统关系型数据库采纳的原则，分别为原子性(Atomicity)、一致性（Consistency）、独立性（Isolation）、持久性（Durablity）
3.2.1 原子性（Atomicity）
指的是一个事务要么全部执行，要么完全不执行，也就是不允许事务执行了一半就终止。
3.2.2 一致性（Consistency）
事务在开始和结束时，应该始终满足一致性约束条件。
（例如约束了a + b = 100, 如果事务改变了a，那么必须也要改变b，否则事务会失败）
3.2.3 独立性（Isolation）
指的是多个事务如果同时执行，彼此之间不需要知晓对方存在，执行的时候相互不影响，不允许出现两个事务交错，间隔执行。
3.2.4 持久性（Durability）
指的是事务运行成功之后，对系统状态的更新是永久的，即使出现宕机也不会消失。
3.3 BASE原则
数据库系统采纳ACID原则来获得高可靠性和数据的强一致性，而云存储系统则采纳BASE原则，BASE原则是和ACID原则几乎相反的原理。BASE原则是对CAP原则权衡之后得到的结果，其核心思想是：既然无法做到强一致性，那么可以根据业务自身的特点，想办法让系统达到最终一致性。
3.3.1 基本可用（Basically Avaliable）
在绝大多数时间内系统处于可用状态，允许偶尔失败
3.3.2 软状态或者柔性状态（Soft State）
数据状态不要求在任意时刻都完全保持同步
3.3.3 最终一致性
最终一致性是一种弱一致性，尽管软状态不要求数据在任何时刻都保持一致同步，但是最终一致性要求在给定的时间窗口内数据可以到达一致性状态。
3.4 云存储系统的发展趋势
尽管当前大多数云存储系统采纳了BASE原则，但是云存储系统的发展正在向逐步提供局部的ACID特性发展，即全局而言符合BASE原则，局部支持ACID原则，这样可以获得两者各自的好处，在两者之间建立平衡。大多数的云存储平台都拿采纳了最终一致性。
- 所谓强一致性，指的是当数据更新之后或许的读取操作看到的都是最新的数据，弱一致性则放宽条件，允许读取到旧版本数据，最终一致性指的是给出一个时间窗口，在一段时间后系统能够保证所有备份数据的更新一致。
4. 数据模型
数据模型指的是云存储架构在应用开发者眼中的形式。比较常见的是KV模式和模式自由(Schema Free)列表模式。
从下图就可以看出，模式自由列表模式的记录类似于关系数据库，数据值可以由若干个列属性组成，不同的是数据库一旦确定列包含的属性就固定不变，云存储系统支持随时增加或者删除某个列属性，一行可以只存储部分列属性，不必完全存储。
云存储系统内部的存储结构可以归结为两种方式：哈希+链表/B+树，前者查询更快，但是一次只能查一条，不支持批量顺序查询，B+树则相反。两种方式各有优点，主要应用于不同场合。
5. 面临的基本问题
由于分布式存储系统来说，因其由大量廉价PC构成，因此不管采用何种方案，都会面临以下的问题。
- 数据如何在机器之间分布：海量数据下，单机无法承担全部数据的存储和计算，因此必须对数据进行切割，将大数据切成小份并分配到其他机器上，因此首先要考虑数据分布的策略。
- 多备份数据如何保证一致性：在这个背景下，随时都有可能有PC出现故障，存储在故障PC的数据因此不可用，出于数据可用性方面的考虑，云存储系统必须对数据进行多备份，而因为云计算环境下客户端程序会对数据进行并发读写，因此数据多个备份之间保证其状态一直是云存储系统的核心问题。
- 如何响应客户端的读/写请求：要求对客户端的数据读写请求做到延时尽可能短，数据尽可能正确，都是平台需要提供的基本功能和保证。
- 如何处理服务器的变更：当加入机器的时候，系统因自动为其分配任务，同样当数据损坏的时候，系统需要识别状态并对其负责存储的数据进行迁移和备份。
- 如何在机器之间进行均衡负载：这是为了解决PC之间分工不均的问题。
