基于云计算的分布式数据库系统：《分布式数据库技术》的解析

2023-10-28 理论教育版权反馈

【摘要】：第17.2.3节讨论的云数据库往往也会分布化。基于云计算的分布式数据库系统有其特有的特点，下面我们进一步讨论。在内部层，数据库管理系统扮演核心角色，因此是持续性的。近年来，由于负载加重和高可伸缩性要求，对系统吞吐量的要求越来越高，分布式数据库系统越来越受到计算机产业界的关注。然而，构建分布式数据库系统有其困难性和复杂性。

云计算的广泛使用，让大家开始认同实现虚拟基础设施服务来获得高可用性和高可伸缩性是可能的。为了满足用户容错（高可用性）和改进性能（随着用户数的增加而保持系统的吞吐量和响应时间）的要求，常常在分布式数据库系统中使用数据复制技术。复制技术的使用遇到了三个挑战：①复制控制机制，即何时和何地更新复制副本；②复制体系结构，即在哪里实现复制逻辑；③如何保证一致性和目标应用的可靠性需求。负载均衡是要考虑的一个重要因素。

由于复制技术的应用，尽管出现了故障，系统仍能同时保证高可用性和高可伸缩性。复制数据可以跨越广域网。第17.2.3节讨论的云数据库往往也会分布化。基于云计算的分布式数据库系统有其特有的特点，下面我们进一步讨论。

参考文献［3］中给出了一个基于三层Web应用的云架构（见图17.3）。

图17.3中，从前端到后台可将环境分成五个层次。

●第一层是最终用户层，形态是客户端App，如浏览器、桌面/移动App，使用HTTP协议交互。

●第二层称为表现层（云服务Tier-1），域名服务器（DNS）、Web服务器和内容分发网络（CDN）服务器是该层提供的云服务（这类服务一般是无状态的（stateless）），负责接收和处理客户端的请求。如果是只读请求，可以借助缓存的数据立即获得服务，更新请求则会传递给下面一层的服务。

●第三层为应用/逻辑层（云服务Tier-2），在这一层，应用服务器基于编码好的逻辑处理上面一层传递过来的请求，使用内存数据对象（可用的话）处理运算，或者从下面的数据库层存取数据。MVC（model view controller）就是一个样例。应用服务器是有状态的（stateful）。

pagenumber_ebook=386,pagenumber_book=371

图17.3　一个基于三层Web应用的云架构^[9]

●第四层为数据库/持续层（云服务Inner-Tier），在这个层次活跃的是索引文件、关系型/非关系型数据库管理系统。

●第五层为分析层（后台云服务），在这一层工作的是Hadoop、Map-Reduce批处理等。

如图17.3所示，自下而上，ACID的要求逐步在降低。可扩展性在逐步增加。从第一层来看，只读用户的请求可能在第一层云服务得到满足（如直接在缓存获得答案）。但是，可能该数据存储到数据库时由于故障而舍弃，所以持续性是无保障的。因为这一层是处于无状态的，这是Web服务固有的特点，所以，在这一层无法探知缓存的数据是否被顺利写入稳定存储。而且，这种情况的发生是不可避免的。因此图中的右边表示该层提供的是缺乏持续性的数据。第二层的数据响应来自缓存下一层（数据库服务）返回的结果，因此是半持续性的。在内部层，数据库管理系统扮演核心角色，因此是持续性的。

使用成千上万个普通硬件的系统比使用高端服务器在可伸缩性和可用性上要价廉物美得多。但是，如何分配面向Web应用的用户请求？在这样一个无共享环境里要得到事务负载均衡很不容易。为了在支撑数据库系统中提供读/写操作的可伸缩性，数据会被复制和分片，要保证ACID不容易。要保证分布式事务并行完成和原子执行也是面临的一个大挑战。

为了保证原子性，分布式提交协议-两阶段提交（2PC）会被广泛使用。完成一次2PC需要一段可观的时间，而且，协调节点如果出现故障，也会阻塞完整提交。单位时间内可完成的事务量（称为事务吞吐量），会大大受限。因此，是否一定强求ACID始终在讨论中。

当前云解决方案支持非常有效级别的一致性保证，因为系统需要高度的保障和安全。Eric Brewer发表的文章“CAP理论十二年回顾：‘规则’变了”阐述了CAP理论。按照CAP原则，系统设计员在网络分割（network partition）情况下必须在一致性和可用性间做一抉择。鱼和熊掌不能兼得。这个折中是因为在故障情况下保证“高可用性”，数据必须在多个物理计算机间复制。

近年来，由于负载加重和高可伸缩性要求，对系统吞吐量的要求越来越高，分布式数据库系统越来越受到计算机产业界的关注。然而，构建分布式数据库系统有其困难性和复杂性。采用CAP理论弱化了要求，采用折中方案，设计和实现起来也较容易。

BASE（basically available，soft state，eventually consistent）是这几个词首字母的缩写，其思想接收源自CAP论断。若考虑系统可能被分割（按功能将数据分组和跨数据库延展功能组，即shards^[10]），则可以将操作系列打碎，相应地，最终用户按流水线异步方式更新每个副本，无需等待其完成。(www.chuimin.cn)

ACID是一种悲观的方式，相比之下，BASE是一种乐观的方式。BASE系统接受部分分割，因而保证了可用性。令数据库的一个表（关系）“用户”被水平分割（sharded），并跨不同物理机器。例如，将用户的“last_name”作为shard key，如分割last_name首字母为A-H、I-P和Q-Z三个shard。假如一个shard突然不能用，则只影响33.33%的“用户”数据，其余仍然可以用。但是，不像ACID系统，保证一致性就不容易。这样，延迟一致性的想法就产生了。可以允许在一段时间内的不一致，只求最终一致。BASE中的E代表eventual consistent（最终一致性），从字面上理解就是保证最后一致。系统能够保证在没有其他更新操作的情况下，数据最终一定能够达到一致的状态，因此所有客户端对系统的数据访问最终都能够获取最新的值。BASE里的软状态是指相对于原子性而言，要求多个节点的数据副本都是一致的，这是一种“硬状态”。而软状态是指允许系统中的数据存在中间状态，并认为该状态不影响系统的整体可用性，即允许系统在多个不同节点的数据副本中存在数据延时。

简单来说，一致性可以分为以下几种不同的程度。

●强一致性。在数据更新完成后，对数据的任何后续访问都将返回更新过的值。

●弱一致性。系统不保证对数据的后续访问将返回更新过的值，在那之前要先满足若干条件。通常条件就是经过一段时间，也就是有一个不一致窗口。

●最终一致性。存储系统能保证如果对象没有新的更新，最终（在不一致窗口关闭之后）所有的数据访问都将返回最后更新的值。

亚马逊公司的Werner Vogels描述了各种最终一致性，它们可以组合起来，使之更强，以保证客户端的一致性。

●因果一致性。如果进程A通知进程B它已更新了一个数据项，那么进程B的后续访问将返回更新后的值，且一次写入将保证取代前一次写入。与进程A无因果关系的进程C的访问遵守一般的最终一致性规则。

●“读己之所写（read-your-writes）”一致性。这是一个重要的模型。当进程A自己更新一个数据项之后，它总是访问到自己更新过的值，绝不会看到旧值。这是因果一致性模型的一个特例。

●会话一致性。这是上一个模型的实用版本，它把访问存储系统的进程放到会话的上下文中。只要会话还存在，系统就能保证“读己之所写”的一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话。

●单调读一致性。如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。

●单调写一致性。系统保证来自同一个进程的写操作顺序执行。要是系统不能保证这种程度的一致性，就很难编程了。

关于服务器端一致性，Werner Vogels也有所讨论。重要考虑是“法定人数规则”（basic quorum protocols）。令N为保存数据副本的节点数，W为响应写请求的副本节点数，R为接收读请求的副本节点数。如果W+R＞N，则读写集交叠，系统提供较强的一致性。如果W＜（N+1）/2，则有一定写冲突可能。如果W+R≤N，则读写不交叠，系统会提供最终一致性的较弱形式，会读到陈腐数据。

当R=1且W=N，对读操作是最优的。当W=1且R=N，这样的优化可以得到非常快速的写操作。当然在后一例中，只要存在失败，就不能保证了；而且，如果W＜（N+1）/2有可能出现写冲突，因为写集合没有重叠。当W+R≤N时，就会出现弱一致性/最终一致性，即读集合与写集合没有重叠。如果故意要这么安排，又不是出于某种失败情形的考虑，那么只有把R设为1才是合理的。

如果W+R≤N，那么系统就存在缺陷，有可能从未收到更新的节点读取数据。

网络分割时，法定系统仍然可以处理读写请求，只要在独立客户群里，读写集仍能通信。一种调停算法可以用来管理副本间的冲突更新。

“读己之所写”一致性、会话一致性和单调一致性是否可以达成，取决于客户端对其执行分布式协议的服务器的“黏度”。如果每次都是同一台服务器，那么就比较容易保证“读己之所写”一致性和单调一致性。这样做会使管理负载平衡以及容错变得稍困难一些，但这是一种简单的方案。使用会话可使意图更加明确，且为客户端提供了适当的推理基础。

基于云计算的分布式数据库系统：《分布式数据库技术》的解析

相关推荐