创建可扩展性系统-4

 高可扩展性系统的一些理论基础

 

 

 

在2000年ACM的PODC座谈会上加州大学伯克利教授 Eric Brewer在主题“建立可靠的分布式系统”的演讲中提出了所谓的CAP定律，至今被大型网络公司（如亚马逊 ）作为系统构架基础理论广泛应用。

在讨论CAP定律前，先介绍CAP定律涉及到三个关键概念：一致性（Consistency），可用性（Availability） 和分区容差（Partition Tolerance）。一致性的含义是指系统在执行操作后处于一致的状态；一些写操作后所有的读操作都看到共享数据源上相同的更新结果。 可用性，尤其高可用性意味着系统的设计和实现避免了SPOF，在集群中的节点崩溃或部分软硬件由于升级维护而不能工作的情况下系统可以继续正常事务处理。 分区容差反应了系统在网络物理分区发生改变（比如节点无法相互连接，或者动态的添加和删除节点) 而继续工作的能力。

布鲁尔声称，一个“共享数据系统”至多可以同时实现CAP三个特征中两个。 CAP定律本身并不复杂。 一个简单的理解是：为了提高系统的可用性，防止SPOF，根本的策略是冗余复制，为了保证复制双方不受相互影响，必须考虑复制双方的分区； 分区必然需要考虑复制双方的状体同步， 也就是一致性问题。

进一步的讨论需要引入新的概念BASE。

（一）ACID / BASE

ACID是数据库管理系统（DBMS)中事务所具有的四个特性：原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation，又称独立性）、持久性（Durability）。例如银行转帐，从原账户扣除金额，以及向目标账户添加金额，这两个数据库操作的总和，构成一个完整的逻辑过程 。这个过程具有ACID属性， 保证了整个系统中的总金额没有变化， 系统一直处于一致性状态。

维基，博客，社交网络等互联网每天产生海量数据需要处理，储存和分析。系统

需要根据数据的不同性质， 在性能，可靠性，可用性，一致性和耐久性之间权衡。事实是，Facebook状态更新， 微博论坛的留言并不严格需要ACID。只要业务层和表示层实现了处理不一致的数据的策略， 放宽ACID要求，可以避免系统在数据库层上的瓶颈，对实现高效，高扩展的系统构架产生巨大的灵活性。

在另一方面， 即使对于大型电子商务网站和大型银行系统，越来越多的系统架构使用大量的“廉价，低端和不十分稳定的”机器， 实现相对低成本的可用性和无限可扩展性， 但同时引入了分区容差（P)的因素。 CAP定理说明在一致性，可用性和分区容差中必须牺牲其中一种属性。在分区容差不可避免 的大型和超大数据规模的Web应用系统中， 如何选择呢？作者有一次和一家著名电子商务公司的构架师聊天， 他说即使公司内部的系统出现严重问题，用户下单是不会受到影响的。 从商业角度来考虑，可用性比严格的一致性更有价值。

当然， 系统放宽ACID要求的同时， 必须有能力在业务层和表示层处理不一致的数据。 这就引入了BASE的概念。

BASE是Basic Available(基本上可用) Soft State(软状态) 和 Eventually consistent（最终一致性）的首字母缩写词。 因为ACID在英语中也有酸性的意思， BASE有碱性的意思，技巧的表明了截然两种不同的性质。BASE系统强调系统的可用性，适度退化和性能 。通俗的讲，应用程序基本上在所有的时间都是工作（基本上可用），虽然没有在所有的时间状态都是一致的（软状态）， 但最终将达到确定一致的状态（最终的一致性）

Table 3.2.: ACID vs. BASE (cf. [Bre00, slide 13])

ACID	BASE
强的一致性 隔离 强调事务的“提交” 嵌套事务 可用性？ 保守的（封闭式） 演进困难（如 架构）	弱的一致性 – 过时的数据 OK 可用性第一 尽力而为 近似答案 OK 主动式（开放式） 简单！ 更快 更容易演变

 

 

 

 

ACID是封闭的和严格要求每一个操作一致性（CAP中的C）；BASE是开放的，认为数据库的一致性存在于变化不定的状态流中。虽然这听起来很玄妙，BASE在实际中非常易于管理，而且获得了ACID无法获得的高水平的可用性（CAP中的A）。

BASE的可用性在于，通过降低严格一致性要求而去偶联分布式节点， 部分系统故障因而不影响系统的整体状态； 同时松散化各个节点的关联，架构上也进一步支持了高的横向可扩展性。

上面所有的讨论中， 一致性的观点是关键。一致性的概念比较广泛，数据一致性通常指关联数据之间的逻辑关系是否正确和完整，我们主要讨论数据复制情况下的一致性。 先举个 一致性模型的例子，假设以下情况下发生：

• 行X复制到节点M和N

• 客户端A到节点N对行X进行写操作

• 经过的时间t的期间，客户端B从节点M读取行X

可以从两方面来看待一致性问题: 从用户/程序员的角度，确定客户端B是否能够读到客户端A的写操作结果； 从服务器的角度，更新操作是如何完成的，系统所承诺的访问结果是什么。

 

早期对分布式数据一致性的研究，强调数据分布对用户的透明性。 用户应该和使用单一系统一样使用分布式系统，如果单一系统的特性没法获得，早期的选择是让整体系统失效。90年代中期， 随着大规模网络系统的出现，研究人员开始重新审视分布式系统的设计理念。Eric的 CAP 定律就是这种反思的总结。

 

常用的一致性模型有： 【见WIKI】

• 严格一致性（linearizability, strict/atomic Consistency） 要求无论写操作发生在哪个副本上 ， 所有的读操作必须返回最近完成的写操作的结果 。 这意味着对于不同节点上的读写操作必须执行分布式事务协议（如两阶段提交协议）来保证严格的一致性。分布式事务协议的本质是把各个副本通过协议紧密偶联，造成了SPOF而影响系统的可用性。 这和CAP定理得到的结论相同：ACID强调严格的一致性。

• 顺序一致性（sequential consistency）：程序在各个机器上并行运行时，任何一种有效的交错访问顺序都是可认可的行为，但所 有使用者以同样的顺序看到对同一数据的操作。 顺序一致性是常见的多线程程序执行顺序的模型。

• 因果一致性（causal consistency ，Hutto和Ahamad，1990 ）是顺序一致性（SC)的弱化 。 因果一致性 按有无可能的潜在因果联系来区分各事件。 假设进程P1写变量x，然后P2读出x，写入y。这里读出x和写入y之间可能有潜在的因果联系，因为y的计算很可能决定于P2读到的x值（即P1写入的值）。 只有存在因果关系的写操作才要求所有使用者以相同的次序看到，对于无因果关系的写入则并行进行，无次序保证 。但在实现时可以使用向量时间戳建立与维护因果依赖图，需要一定开销。

• 管道一致性（PRAM/FIFO consistency）：在因果一致性模型上的进一步弱化，要求由某一个进程完成的写操作可以被其他所有的进程按照顺序的感知到，就像写入一个的管道一样；而从不同进程中来的写操作则无需保证顺序。管道一致性实现 相对来说比较容易。

• 弱一致性（weak consistency）：只要求对共享数据结构的访问保证顺序一致性。弱一致性的另一个定义是指所有弱于顺序一致性的一致性模型。

• 释放一致性（release consistency）： 使用两个不同的操作语句acquire-release。需要写入前acquire该对象，写操作结束后release。 提供 释放一致性也就意味着当release发生后和新的acquire前，所有使用者应该可以看到该操作结果。

• 最终一致性（eventual consistency）：当没有新更新的情况下，系统随着时间的推移最终将返回最后写入的值；虽然在数据更新过程中，因为各个副本的同步需要时间，客户端可能会面临数据不一致的状态。允许采用最终一致性模型的关键前提是：偶尔读出陈旧数据是可以接受的。

• delta consistency：系统会在固定的delta时间窗口内达到一致。

• 最终一致性的几种具体实现：
  1、读不旧于写一致性（Read-your-writes consistency， RYOW）：使用者读

到的数据，总是不旧于自身上一个写入的数据。RYOW一致性是一种特殊因果一致性。RYOW意味着一个用户完成写操作后可以立刻看到更新的结果，即使读写是发生在不同的服务器上。其他用户对他的更新不是立刻可见的。
2、会话一致性（Session consistency）：也翻译成任务一致性， 它比RYOW更弱化，是RYOW的应用版。使用者在一个会话中才保证读写一致性，启动新会话后则一致性失效。
3、单读一致性（Monotonic read consistency）：任何使用者读到的数据总是不旧于任何使用者上一次读到的数据。
4、单写一致性（Monotonic write consistency）：保持同一个使用者写操作的顺序，写操作完成后才能开始下一次的写入。这是编程的最低要求。

在实践应用中可以组合应用上述的几种最终一致性模式。比如 单读一致性 和 会话一致性的组合应用。 设计师需要根据应用程序实际需要来选择特定模式。Werner Vogels认为：在很多互联网应用中，单读一致性和RYOW 可以提供足够的一致性了。

最终一致性模式并不是高度分布式系统独有的。比如传统RDBMS的异步备份机制在备份恢复过程中就存在数据不一致的时间窗口。

 

下面转入服务器端的一致性讨论。

在分片构架上引入复制的概念不仅仅增加了系统的可靠性， 而且可以均衡对特定物理节点的读操作的负载。 Voldermort开发小组 认为，以下3个因素影响在分片数据上的读写操作。

1. N: 读写操作对象的副本数目

2. R: 读操作涉及到的副本数目

3. W: 写操作中阻断的副本数目， 也是写操作完成前同步写入的副本数目。

在RYOW一致性模型中， 以下关系成立

R +W > N

也就是当读操作的副本和写操作的副本有重叠时，系统可以保证比较严格的一致性。 在完全同步的条件下， R+W = R + N > N , 系统严格一致。

系统的常用使用方式和优化要求决定了设置R,W，N的值。如果系统把一致性放

在首位，如果设W=N，这样同时增加了W失败的可能性；常用的策略是设W=3， 然后再写更新其他副本。这种情况往往导致 R+ W <= N， 系统具有弱化的最终一致性。 对于Amazon的Dynamo 而言，为了处理终端用户的写操作高可用性，R,W，N的值设为 N=3， R=2， W=2。

系统架构的其他因素也影响一致性的获得。 服务器前端的负载平衡使用粘性连接（Sticky Connection), 将很容易获得 会话一致性和 单读一致性。有的时候 RYOW一致性也可以通过客户端使用写操作的版本号来实现。

 

EBay和Amazon都公开表示他们的系统严格不使用2PC。如何在没有2PC的分布式系统中保证系统的一致性？ 上面引入的BASE概念表明， 最终一致性答案不再是一个BOOL值，而是一个范围； 最终一致性的获得，也不再是一个原子操作，而是一个过程。 常见的策略包括：精心设计的数据库读写操作的顺序； 通过异步事件或者协调批处理（reconciliation batch)来实现最终一致性。

本文出自 “静水流深” 博客，转载请与作者联系！