什么是分布式数据库？

分布式数据库将数据存储在多个远程节点上，而不是集中式的物理服务器中。分布式数据库在多区域运营、可扩展工作负载、高弹性运维和实时应用场景中日益普及。配置分布式数据库的方式多种多样，每种模型各具优势。

传统的集中式数据库将所有数据存储在单台服务器上。分布式数据库则将数据和工作负载分散到由多个独立服务器（称为“节点”）组成的网络中。对用户而言，分布式数据库的网络不可见。用户体验到的是一个单一、统一的数据库。

您可以使用分布式数据库管理系统（DDBMS）来管理分布式数据库。DDBMS 的主要功能之一是将数据库的应用层从底层的节点基础设施中抽象出来。通过这种方式，DDBMS 能够在后台管理跨节点的数据路由、查询执行和数据一致性，确保用户获得常规的数据库使用体验，而无需执行额外操作。

组织采用分布式数据库架构是为了满足以下几方面的运维需求：

管理现代应用程序对可扩展性的需求

单台服务器的硬件容量限制了集中式数据库的性能。分布式数据库能够更轻松地实现水平扩展，这意味着它们可以根据需要增加全新的服务器。这使得它们能够应对不断增长的存储和事务处理需求。

抵御单点故障的韧性

集中式数据库也受限于服务器的可用性。单个位置的硬件故障或网络中断会导致整个数据库离线。分布式数据库本质上避免了这个问题，因为它们将数据存储在多个服务器节点上，这些节点通常位于不同的地理位置，不太可能同时受到硬件、网络或环境事件的影响。

满足数据本地化要求

全球可访问的应用程序通常会通过在靠近区域用户的地方存储数据副本来降低网络延迟。延迟是指事务往返数据库所需的时间。许多国家和国际机构也强制执行数据主权法律，要求特定数据必须保留在特定地理边界内。

例如，欧盟的《通用数据保护条例》（GDPR）规定了如何使用和存储其公民的个人数据。管理员可以使用分布式数据库将包含此类受监管数据的数据节点放置在管辖范围内，同时仍然保持应用程序的全球可访问性。

了解网络延迟 »

了解数据主权 »

管理实时和高吞吐量工作负载

处理大量并发事务的、基于云的应用程序可以通过在其后端架构使用分布式数据库显著提升性能。负责管理的 DDBMS 有助于将事务路由到最优节点之一。这种方法在金融服务、电子商务和在线游戏领域很常见。

分布式数据库有多种类型。

同构分布式数据库

在同构分布式数据库中，网络中的每个节点都使用相同的数据模型存储相同的数据，并运行相同的 DDBMS。这种配置易于维护，因为它在所有节点上都是统一的。它是许多现代云原生部署的标准选择。

异构分布式数据库

异构分布式数据库中的网络节点各不相同。这些节点可能运行不同的操作系统、存储不同的数据，或者最常见的情况是使用不同的 DDBMS 软件。例如，您可能希望使用异构分布式数据库，将一个节点上的关系型数据库与另一个节点上的 NoSQL 文档存储连接起来。

由于底层数据库的运行方式各不相同，异构系统会利用转换层来抽象化各数据库节点在架构和查询语言上的差异，从而更轻松地作为一个统一系统进行交互。

最常见的异构配置之一是联合分布式数据库。联合数据库的节点既可以独立运行，也可以协同工作。当您向系统发出查询时，系统会确定哪个节点最适合响应，并相应地路由该查询。

关系型分布式数据库

关系型分布式 SQL 数据库实现了传统关系型系统所具备的熟悉的表结构、SQL 查询能力以及严格的 ACID（原子性、一致性、隔离性、持久性）合规性。它们采用水平分片策略，以便在去中心化模型中维持这些特性。

分布式系统不再使用单台服务器来管理关系型数据库，而是将表中的行分布到多个计算机节点上。每个节点（或称“分片”）存储数据的一个子集。为了实现这一点，每个分片都维护相同的模式。DDBMS 将 SQL 查询路由到不同的分片，并汇总查询结果。您可以根据需要对这种配置进行水平扩展，同时为用户保持一致且统一的体验。维持 ACID 合规性需要特定的协议，这可能会导致节点间出现延迟。

了解关系型分布式数据库 »

了解 ACID »

NoSQL 分布式数据库

NoSQL 数据库不对存储的数据强制执行统一的模式，并且易于扩展。NoSQL 数据库以多种模型存储非结构化和半结构化数据，包括文档存储、键值存储、宽列存储和图数据库。

大多数 NoSQL 分布式数据库都基于最终一致性原则运行。这种方法以牺牲即时一致性为代价，最大限度地提高了系统可用性。写入任一节点的数据最终会在所有节点间同步，但不一定能立即完成。NoSQL 系统非常适合那些将高吞吐量作为首要需求（而非要求所有用户获得即时一致性体验）的应用场景，例如社交媒体的信息流。

了解 NoSQL »

NewSQL 分布式数据库

NewSQL 分布式数据库是一类关系型数据库系统，旨在将传统关系型数据库严格的 ACID 合规性与 NoSQL 的水平扩展能力结合起来。NewSQL 系统利用先进的共识协议和分布式事务路由技术，在对事务记录有严格要求的企业级系统中维护数据一致性。金融交易和订单处理系统通常属于这一类别。

分布式数据库依赖一套特定的数据管理技术来维护其节点网络的性能。

数据分发策略

分布式数据库系统可以根据具体的技术要求和用例应用多种不同的分发策略。

水平分区（分片）

分布式数据库中的水平分区（也称为分片）会将数据库表按行拆分到多个节点上。它们使用称为分片键的分区键来确定哪些数据位于哪个节点。两种主要的分片方法是：

• 基于范围的分片：根据分片键的连续范围划分数据。
• 基于哈希的分片：对分片键应用算法，使行更均匀地分布在各个节点上。

配置分片数据库时，管理员必须管理热分区风险。当分片键实施不当，导致大量流量涌向单个节点，从而造成性能瓶颈时，就会出现热分区。

垂直分区

垂直分区按列而不是按行将表拆分到各个节点上。例如，与其在每个节点上存储部分完整的客户记录，不如将所有客户的联系信息存储在一个节点上，将所有订单历史记录存储在另一个节点上。

垂直分区不如分片常见，但当用户访问的数据子集频率不同时，它非常有用。将频繁访问的数据分布在多个节点上，其余数据仅存储在少数节点上，可以提高系统整体性能。

复制

复制是指在多个节点上维护数据的精确副本。分片将数据集拆分到多个节点上，而复制则是复制整个数据集。当您需要较高的容错能力时，数据复制非常有用。如果一个节点发生故障，系统可以将用户引导到下一个最可用的副本。分片和复制策略通常结合使用，以提供更好的可扩展性和可用性。

复制模型

当分布式数据库系统应用复制时，它必须定义网络节点如何处理传入的读取和写入请求。有三个主要模型：

主副本

这也常被称为领导者-跟随者模型。DDBMS 指定一个节点作为主节点（或领导者），负责处理所有传入的写入操作。这些更改随后会传播到所有从节点（或追随者）。该模型结构简单，可提高数据一致性，但单个主节点在写入密集型工作负载下可能会成为性能瓶颈。

多主节点

也称为多领导者设置，该模型允许多个节点同时接受写入操作。与主副本模型相比，其优势在于更高的写入吞吐量。

但是，由于多个节点可以同时接受对同一数据集的冲突更新，因此多主节点系统需要可靠的冲突解决机制来维护数据完整性。常见的机制包括最后写入获胜（LWW）或应用层解决，在应用层解决冲突中，DDBMS 将如何解决冲突的决定权交给应用程序。但是，LWW 可能会导致合法写入的丢失。

无主节点

在无主节点模型中，不存在指定的主节点。任何节点都可以接受读取和写入操作。这些系统使用基于仲裁的协调机制来维护一致性。无主节点模型通常被称为 Dynamo 式协调。

为了确保读取操作返回最新的写入数据，必须对系统进行配置，使成功读取所需的节点数（R）加上成功写入所需的节点数（W）大于副本节点的总数（N）。这在数据库管理中以公式 R + W > N 表示，其中仲裁节点之间至少重叠一个节点。

分布式事务和共识

完成分布式数据库事务通常涉及多个节点的事务。系统需要以一致方式应用这些更新，否则会很快丢失完整性。系统需要相应的机制来确保所有参与的节点要么都提交事务，要么都不提交。

以下是管理分布式数据库事务的四种主要方法：

两阶段提交（2PC）

该协议使用中央协调进程来决定事务是应该完成还是中止。第一阶段是投票阶段。协调进程协调所有“工作”进程的活动，这些进程负责路由和提交事务。准备就绪后，协调进程会轮询所有工作进程，根据每个工作进程看到的本地情况，对事务是否完成进行“是/否”投票。

第二阶段是提交阶段。如果所有进程都投“是”，则事务提交。如果任何进程投“否”，则事务停止。协调进程将结果通知所有工作进程，它们尝试回滚并恢复各自的本地状态。2PC 能够应对许多故障情况，因此得到了广泛应用。但是，2PC 无法轻松处理某些故障情况。2PC 的主要缺点是它是一个阻塞式协议。如果某些本地进程投票提交事务，而协调器停止运行，则这些本地节点将被阻止完成任何其他事务，直到协调器成功回滚该事务或管理员手动清除该事务为止。

三阶段提交（3PC）

为了解决 2PC 中存在的阻塞问题，3PC 方法增加了一个中间的“预提交”阶段。在投票阶段之后的这一额外步骤允许参与节点在最终提交之前就事务状态达成一致，从而降低协调器无响应时发生阻塞的风险。两阶段提交和三阶段提交协议都具有很强的 ACID 合规性。

共识协议

现代分布式数据库通常依赖于数学共识算法，以确保在大多数节点仍然可用的情况下数据库能够继续运行。Paxos 和 Raft 是两种最受欢迎的算法。CockroachDB、Amazon Aurora、etcd 和 Spanner 等系统使用这些协议来管理其分布式系统的状态。

Saga 模式

Saga 模式不会同时锁定多个节点上的数据，而是会将大型事务拆分成一系列较小的本地事务。如果任何步骤失败，系统会运行一系列补偿事务来撤销之前的步骤并恢复数据。这种方法非常适合采用微服务的分布式系统。

CAP 定理指出，分布式数据库在任何时刻最多只能同时满足以下三个特性中的两个：

• 一致性：系统中的所有节点在同一时间反映完全相同的数据。
• 可用性：每个请求都能收到成功的响应（而非错误响应），即使某些节点不可用。
• 分区容错性：即使分布式网络发生分区或节点间通信中断，系统仍能继续运行。

在现实的分布式网络中，网络分区不可避免；这意味着分区容错性是一项必备能力，而非可选项。因此，在实践中，CAP 定理要求数据库架构师必须做出抉择：是优先保证一致性（即在网络修复前拒绝请求并返回错误），还是优先保证可用性（即返回现有数据，即使该数据可能已过时）。

PACELC 是 CAP 定理的扩展，它描述了所有操作（而不仅仅是网络故障情况）的权衡。PACELC 规定了在发生网络分区时，系统必须在可用性和一致性之间做出选择（即标准的 CAP 定理）。而在网络正常运行的情况下，系统则必须在延迟和一致性之间做出选择。

如果数据库要求一致性，则必须等待数据在多个节点间完成复制后才能确认写入操作，这会增加延迟。如果优先考虑低延迟，则必须接受网络中数据在短时间内存在不一致的情况。

一个高效运行的分布式数据库应具备以下几个具体特征：

抽象

分布式架构应当是抽象的，其复杂性对分布式数据库的用户是隐藏的。用户无需了解节点的具体位置，也不必关心数据如何在系统中存储及跨网络复制。对用户而言，该系统仍作为一个统一的数据库运行。

自主

网络中的每个节点都可以在一定程度上独立运行。

容错能力

即使个别节点发生故障，整个系统仍能继续运行并处理请求。

并发控制

该系统利用两阶段提交和多版本并发控制（MVCC）等机制来管理跨网络的并发事务。

查询优化

分布式数据库管理系统（DDBMS）应该采用能够考量数据多物理位置及检索所需网络成本的查询规划器，以便高效运行查询。

分布式数据库具有许多重要优势。

• 水平可扩展性：分布式数据库使组织能够通过增加更多节点来实现水平扩展。
• 高可用性：分布式数据库通过跨多个节点存储数据，降低了单点故障的风险。
• 地理分布：分布式架构允许管理员将数据物理部署在更靠近最终用户的位置，从而降低读写操作的网络延迟。
• 数据主权：分布式数据库有助于组织将受监管的数据集隔离在实施数据主权法规的区域内。
• 吞吐量：将数据分布在多个节点上，可以实现并行查询和写入操作。

尽管分布式架构在许多应用场景中极具优势，但也可能带来工程和运维方面的挑战。

一致性与延迟的权衡

将数据分布在地理位置相距遥远的节点上，可能会迫使管理员在一致性（等待数据在所有节点间同步）和延迟（追求快速响应）之间做出取舍。PACELC 模型便突显了这一决策问题。

网络分区

分区容错性是现代分布式数据库系统的必备能力，因为通信中断是常态。工程师在构建分布式架构时，必须专门针对数据分区进行设计，而不能将其视为一种边缘情况（极少发生的特例）。

运维复杂性

执行架构变更和数据重平衡需要周密的规划。在分布式环境中升级软件需要进行仔细的协调。

事务开销

由于基础设施经过抽象处理，因此所有分布式环境在运行过程中都会产生一定的开销。诸如“两阶段提交”之类的协议会增加延迟。Saga 模式等替代方案则将管理事务的复杂性转移到了应用层。

监控和可观测性

与单机数据库相比，在分布式架构中跟踪系统性能和调试错误往往更为困难。运维团队通常需要部署分布式追踪工具来监控请求流转。

数据热点

如果分片键实施不当，可能会产生热点分区（即数据热点），导致某个节点处理的事务量不成比例地过高。这可能会导致局部的性能瓶颈。

当单节点系统的能力无法满足需求时，各行各业的组织都会采用分布式数据库。

金融服务

金融机构有多种分布式数据库应用场景。它们利用分布式数据库进行高吞吐量、时效性高的交易处理。它们还利用分布式数据库进行欺诈检测。

电子商务

在线零售商利用分布式系统来管理产品目录、跟踪库存以及大规模处理订单。底层的分布式架构即使在流量激增期间也能保持高性能。

游戏

现代多人游戏利用分布式数据库来管理会话和玩家数据。将这些数据的多个实例分布在不同地理位置，有助于降低不同地区玩家的延迟。

IoT（物联网）

IoT 网络会产生大量连续的信息流。分布式数据库非常适合处理来自工业物联网传感器等众多并发设备的高写入吞吐量。

SaaS 应用程序

软件即服务（SaaS）提供商利用分布式架构来支持需要特定区域数据隔离的多租户应用程序。这使得 SaaS 公司既能服务全球客户群，又能遵守各地区的数据主权要求。

媒体内容分发和个性化

媒体平台利用分布式数据库，结合地理分布式缓存技术来管理电影、电视和音乐等内容的读取密集型工作负载。将数据部署在更靠近最终用户的位置，使这些平台能够更高效地提供定制化内容。

在分布式数据库和集中式数据库之间进行选择时，需考虑应用程序的规模、地理分布情况以及运营需求。

何时选择集中式数据库

对于工作负载可预测且单台服务器即可满足需求的应用程序，集中式架构通常是最佳选择。如果用户群集中在特定区域，数据量在可控范围内，且您希望尽可能降低运维复杂度和基础设施成本，那么集中式系统是一个行之有效的方案。

何时选择分布式数据库

当需要保证高可用性、跨多个区域处理海量并发事务，或必须遵守严格的地理数据主权法规时，分布式架构是更好的选择。

亚马逊云科技提供一系列数据库服务，助您构建分布式架构，从而实现卓越的性能与可用性：

• Amazon Aurora 是一项与 MySQL 和 PostgreSQL 完全兼容的关系型数据库服务，使现有应用程序和工具无需修改即可运行。Amazon Aurora 旨在提供高达 MySQL 五倍、PostgreSQL 三倍的吞吐量。Aurora 支持跨区域只读副本。
• Amazon DynamoDB 是一项无服务器、NoSQL 且完全托管的数据库服务，在任何规模下均能提供个位数毫秒级的性能。DynamoDB 全局表由多个副本表组成。每个副本表存在于不同的区域中，但所有副本共享相同的主键和架构。当数据写入任何副本表时，DynamoDB 会自动将该数据复制到全局表中的所有其他副本表。
• Amazon Keyspaces（Apache Cassandra 兼容）是一项可扩展、高可用的托管型 Apache Cassandra 兼容数据库服务。Amazon Keyspaces 采用无服务器架构，支持需要近乎无限吞吐量和存储容量的应用程序。
• Amazon RDS 是一项易于管理的关系型数据库服务，已针对总拥有成本进行优化。Amazon RDS 多可用区部署为数据库实例提供增强的可用性和持久性，SLA 高达 99.95%，非常适合生产环境的数据库工作负载。

立即创建免费账户，开始在 Amazon Web Services 上使用分布式数据库。