主题
第六章 数据库技术发展与新型架构
1. 分布式数据库系统
随着互联网应用规模的持续增长和企业全球化布局的深入，单台数据库服务器无论在存储容量还是计算能力上都已难以满足大规模数据管理的需求。分布式数据库系统 (Distributed Database System, DDBS) 通过在计算机网络上将数据分布存储在多个物理节点上，同时为用户提供逻辑上统一的数据访问接口，成为支撑现代大规模应用的核心技术方案之一。
1.1 分布式数据库的基本特征
分布式数据库系统具有以下三个基本特征。
第一是物理分布性。数据不集中存储在单一节点上，而是分散在网络中的多个节点上。各节点可能位于同一机房内的不同服务器上，也可能分布在不同城市甚至不同国家的数据中心中。
第二是逻辑整体性。尽管数据在物理上是分散存储的，但从用户的角度来看，整个系统呈现为一个逻辑统一的数据库。用户在提交查询时无需指定数据存储在哪个节点，系统会自动将查询路由到相应的节点执行并合并结果。
第三是场地自治性。每个参与分布式系统的节点都具备独立的数据处理能力，可以独立执行本地事务。每个节点运行着自己的局部 DBMS，能够管理本地数据并处理本地查询。
1.2 数据分片
为了将关系合理地分布到多个节点上，需要对关系进行分片处理。分片是将一个全局关系分割为若干片段（子集）的过程，每个片段存储在一个或多个节点上。
水平分片 (Horizontal Fragmentation) 按行将关系分成若干不相交的子集。每个子集中的元组满足某个选择条件。例如可以按照地区将订单表分片，华东地区的订单存储在上海节点，华南地区的订单存储在广州节点。水平分片在逻辑上等价于对关系执行若干次选择操作，每次选择的结果构成一个片段。
垂直分片 (Vertical Fragmentation) 按列将关系分成若干子集。每个子集包含原关系的一部分属性，但必须包含主键列以保证后续能够通过自然连接重构原关系。垂直分片在逻辑上等价于对关系执行投影操作。例如可以将员工表的基本信息（编号和姓名和部门）和薪资信息（编号和基本工资和绩效奖金）分别存储在不同的节点上。
混合分片则是水平分片和垂直分片的组合，先进行一种分片再对结果进行另一种分片。
无论采用哪种分片方式，都需要满足三个条件。完备性条件要求原关系中的每一条数据都必须能在某个片段中找到，不能有数据遗漏。可重构性条件要求通过对各片段执行相应的操作（水平分片用并操作重构，垂直分片用自然连接重构）能够精确还原出完整的原关系。不相交条件（对于水平分片）要求各片段之间没有重叠的元组。
分片设计最常见的误区，是只从“能不能把数据拆开”来思考，而没有从“最常怎样访问数据”来思考。事实上，分片方案一旦确定，就会长期影响查询路由、跨节点通信、热点分布和后续扩容成本。若按地区分片，但大量查询都跨地区汇总，就会频繁发生跨分片聚合；若按时间分片，但新写入都集中在最近时间段，就可能形成写热点。因此，分片不是单纯的存储拆分问题，而是访问模式、增长模式和治理策略的综合设计问题。
1.3 分布透明性
分布透明性是衡量分布式数据库系统对用户隐藏数据分布细节程度的重要指标。按照透明程度从高到低依次为以下三个层次。
分片透明性是最高层次的透明性。具有分片透明性的系统使用户完全不需要知道数据是否被分片以及如何分片。用户可以直接使用全局关系名进行查询，就像操作一个普通的集中式数据库一样。系统自动将用户的全局查询分解为针对各个片段的子查询并合并结果。
位置透明性是次一级的透明性。用户需要知道数据被分成了哪些片段，但不需要知道每个片段具体存储在哪个物理节点上。用户在查询时需要使用片段名而不是全局关系名，但系统负责将片段名映射到具体的存储位置。
局部数据模型透明性是最低层次的透明性。用户不仅需要知道数据的分片方案，还需要知道各片段的存储位置，但不需要了解各个节点上使用的具体 DBMS 类型和数据模型。
从更高层看，分布式数据库的发展其实一直围绕三个长期问题展开：数据规模变大后如何继续扩展，系统节点变多后如何继续保持正确，组织协作复杂后如何继续保持治理。分布透明性之所以重要，不只是为了让用户“少写几行定位语句”，更是为了避免业务逻辑被底层部署细节绑死。透明性的层次越高，应用越容易把系统当作统一数据库使用；但透明性越高，数据库内核需要承担的路由、重写、合并与故障处理责任也越重。这说明分布式能力从来不是白得的，它本质上是在把复杂性从应用侧转移到数据库系统内部。
2. 分布式事务处理
分布式环境下的事务可能涉及多个节点上的数据操作，这使得保证事务原子性的难度大大增加。
2.1 两阶段提交协议 (2PC)
2PC 是分布式事务中最经典的原子提交协议，由一个协调者和多个参与者共同执行。
在第一阶段（称为投票阶段或准备阶段），协调者向所有参与者发送准备提交的请求。每个参与者在收到请求后执行事务操作，将修改写入本地的日志文件，但并不真正提交。如果参与者的本地操作一切正常，它向协调者反馈同意投票。如果本地操作出现问题，则反馈中止投票。
在第二阶段（称为执行阶段），协调者根据收集到的投票结果做出全局决策。如果所有参与者都投了同意票，协调者向所有参与者发出提交指令。如果有任何一个参与者投了中止票或超时未响应，协调者向所有参与者发出回滚指令。参与者收到指令后执行相应的提交或回滚操作，并向协调者发送确认。
2PC 虽然概念清晰，但存在两个主要问题。一是同步阻塞问题：在等待协调者发出最终决策的过程中，所有参与者都必须保持其已加锁的资源处于锁定状态，无法被其他事务使用，这会降低系统的整体并发能力。二是协调者单点故障问题：如果协调者在发出准备请求之后、发出最终决策之前崩溃，所有参与者将无限期地处于不确定状态，不知道应该提交还是回滚。
2.2 三阶段提交协议
三阶段提交协议在两阶段提交的基础上引入了一个额外的预提交阶段，形成 canCommit、preCommit 和 doCommit 三个阶段。同时在各阶段引入了超时机制。当参与者在等待协调者指令时超时，可以根据当前所处的阶段做出默认决策（例如在预提交阶段超时则默认提交），在一定程度上缓解了协调者单点故障导致的参与者无限期阻塞问题。但三阶段协议增加了一轮网络通信的开销。
2.3 CAP 定理
CAP 定理由 Eric Brewer 于 2000 年提出，指出在一个分布式系统中，一致性 (Consistency)、可用性 (Availability) 和分区容忍性 (Partition Tolerance) 三个特性不可能同时完全满足，最多只能同时保证其中两个。
一致性要求所有节点在同一时刻看到的数据完全相同。可用性要求系统对每一个请求都能够在有限时间内给出非错误的响应。分区容忍性要求系统在网络分区（即节点之间的通信链路发生中断）的情况下仍能继续提供服务。
由于网络分区在分布式系统中是不可避免的，因此系统设计者必须在一致性和可用性之间做出选择。传统的关系型分布式数据库通常选择保证一致性和分区容忍性（即 CP 系统），在网络分区时牺牲可用性。而许多 NoSQL 系统选择保证可用性和分区容忍性（即 AP 系统），允许数据在短时间内不一致。
2.4 BASE 理论
BASE 理论是针对 CAP 定理中 AP 选择的一种具体实践指导。它是 Basically Available（基本可用）、Soft state（软状态）和 Eventually Consistent（最终一致性）的缩写。基本可用是指系统在出现故障时允许在响应时间和功能范围上有所损失。软状态是指系统中的数据允许在一段时间内处于不同步的中间状态。最终一致性是指经过一段不确定的时间后，系统中所有数据副本最终将达到一致。
学习分布式事务时，最需要建立的是边界意识。2PC 等协议能够在理论上保证全局原子性，但它们会带来阻塞、协调超时、链路复杂和故障恢复困难等代价。因此，工程上越来越强调“缩小强事务边界”：把必须强一致的动作限制在核心链路中，把外围链路交给幂等重试、补偿流程、对账任务和事件驱动去完成。这样做并不是降低质量，而是把一致性要求按业务重要程度分层处理。真正成熟的系统设计，不是隐含地假设处处都能强一致，而是明确哪些地方必须强一致，哪些地方可以接受延迟一致。