分布式数据库

分布式数据库系统（Distributed Database System，DDBS），是数据库系统和计算机网络相结合的产物。

分布式数据库基本概念

分布式数据库是面向地理上分散，管理上有需要不同程度集中的需求而提出的一种数据库管理系统。

通常，分布式数据库系统需要满足下列条件：

分布性：数据存储在多个不同节点
逻辑相关性：系统内的数据在逻辑上具有互相关联
场地透明性：使用时，不需指明数据所在的位置
场地自治性：每一个单独的节点能够执行局部的应用请求。

分布式数据库系统的特点

数据的集中控制性。即具有传统集中式数据库的特点。
数据独立性
数据冗余可控性：数据可能有多个副本
场地自治性
存取的有效性

分布式数据库的模式结构

即分布式数据库抽象为四层模式结构：

全局外层：针对特定的全局用户的
全局概念层
局部概念层
局部内层

分布式数据库的数据分布

数据分布是分布式数据库的特征，解决数据分布的策略一般有一下几种：

集中式：所有全局数据片段都安排在一个节点上。
分割式：全局数据有且仅有一份，被分割成若干个逻辑片段，每个逻辑片段分派到特点的节点上。
复制式：全局数据有多个副本，每个节点都有一个完整的数据副本。
混合式：全部数据被分为若干个数据子集，每个子集放在不同的节点。

数据分片

数据分片也称数据分割，是分布式数据库的特征之一。

在分布式数据库中，数据存放的单位是数据的逻辑片段。

对关系数据库来说，一个数据库的逻辑片段是关系的一部分，数据分片有三种基本方法，通过关系代数的基本运算来实现：

水平分片： 按特定条件把全局关系所有元组，划分成若干个互不相交的子集，每个子集为一个逻辑片段。
垂直分片：按属性分成若干子集，即对全局关系做投影运算。
水平和垂直集合的分片。

数据分片是应遵守以下规则：

完备性条件
可重构条件
不相交条件

分布透明性

所谓数据分布透明性，是指用户或用户程序使用分布式数据库如同使用集中式数据库那样，不必关系全局数据的分布情况。

分布式管理系统

略

P510：分布式数据库系统的12条规则

分布式查询处理和优化

略

分布式事务

⭐ 重点

分布式事务有这一篇就够了！ - 知乎 (zhihu.com)

分布式数据库的分布式事务？ - 知乎 (zhihu.com)

一个事务是访问数据库的一个逻辑工作单位，是一个操作序列，执行这个操作序列，使数据库从一种状态转换到另一种一致状态。

分布式事务，是传统事务的扩充。

在分布式数据库系统中，数据是分布的，一个事务的执行可能涉及多个站点上的数据，即分布式事务的执行也是分布。

可以把一个分布式事务看成是由若干个不同站点上子事务组成。

分布式事务特征

和传统集中式数据库的事务一样，分布式事务同样具备ACID特征：

原子性，Atomicity，要么执行，要么不执行，原子性保证总数据库状态是从一个一致的状态到另一个一致的状态，不存在中间状态。
一致性：Consistency，事务的执行不能破坏数据库数据的完整性和一致性**，事务在执行之前和之后**，数据库都必须处于一致性状态。
隔离性：Isolation，据库中的事务一般都是并发的，隔离性是指并发的两个事务的执行互不干扰，一个事务不能看到其他事务的运行过程的中间状态。
持久性：Durability，事务完成之后，该事务对数据的更改会持久到数据库，且不会被回滚。

同时，分布式事务与集中式数据中事务相比，在以下几个特征有所区别：

执行特性，分布式事务执行时被分解成多个子事务执行，各个子事务间需要协调
操作特性, 为了协调子事务的执行，要加入大量的控制原语
控制报文，分布式数据库系统中，除了数据报文，更增加了控制报文

分布式数据库故障

在集中式数据库系统中，故障分为事务故障、系统故障和介质故障。

在分布式系统中，除了上述故障外，还有因网络引起的故障。

分布式数据库的恢复原则

事务恢复主要是依靠日志来完成的。

恢复应遵循的原则如下：

孤立和逐步退出事务的原则
成功结束事务原则
夭折事务的原则

整个分布式事务的恢复，由**分布式事务管理器（DTM，Distribute Transact Management）和本地事务管理器（LTM，Local Transact Management）**协同完成。

两阶段提交协议2PC

2PC，即 Two Fhase Commitment Protocol，两阶段提交协议，即简单有精巧。

把本地原子性提交行为的效果扩展到分布式事务，保证了分布式事务提交的原子性，并在不损坏日志的情况下，快速实现故障恢复，提高分布式数据库系统的可靠性。

协调组与参与者

把分布式事务的某一个代理指定为协调者（coordinator）。

所有其他的代理称为参与者（Participant）。

这里的代理是指完成各个子事务的进程。

只有协调者才有提交或撤销事务的决定权，参与者负责在其本地数据库执行写操作，并向协调者提出撤销或提交事务的意向。

参与者不需要任何其他进程来通知就可以撤销一个事务，称之为单方面撤销。

事务提交的两个阶段

表决阶段

目的是形成一个共同的决定。

1）在请求阶段，协调者写入一条开始提交的日志，并通知事务参与者准备提交或取消事务，然后进入表决过程。

2）在表决过程中，参与者检查能否提交本地事务，写入一条就绪记录或撤销记录，并告知协调者自己的决策：同意（事务参与者本地作业执行成功）或取消（本地作业执行故障）。

3）如果某一个站点做出“建议撤销”提议，则该站点就可以直接忽略这个事务（单方面撤销权利）

4）协调者收到所有参与者的回答后，做出是否提交事务的决定。

5） 只要有一个参与者建议撤销，协调者必须从整体上撤销整个分布式事务，写入撤销记录，发送所有参与者“全局撤销”消息，进入撤销状态。

6）否则，写入提交提交，发动“全局提交”消息，进入提交状态。

执行阶段

即实现这个协调中的决定。

根据协调者的指令，参与者或者提交事务，或者撤销事务，并给协调者发送确认消息。

此阶段，协调者在日志中写入一条事务结束记录并终止事务。

协调者做个事务的全局终止决定的方式，受两条规则的支配，即全局提交规则：

只有有一个参与者撤销事务，协调者必须做出全局撤销决定。
只有所有参与者都同意提交事务，协调者才能做出全局提交决定。

两阶段提交协议对故障的恢复

场地故障
报文丢失故障
网络分割故障

P517页

三阶段提交协议3PC

所谓事务的阻塞是指一个场地的子事务本来是可以执行的，然而由于分布式数据库的故障，它必须等待故障恢复以后的得到需要的信息后才可以做出决定。

此时，如果子事务又占有一些系统资源不能释放，无法继续执行，称之为事务进入阻塞状态。

在2PC中，参与者的提交是在它知道了其他所有的参与者均发出了“建议提交”的报文以后进行的。

若在2PC中增加一段使得参与者的提交不仅要等到他所知道所有的参与者均发出了“建议提交”的报文，而且，还知道所有参与者的状态（处于故障、还是已经恢复）以后才执行，这时2PC即变为3PC协议，即三阶段提交协议。

在3PC中，报文有三次接收和发送，协调者第二次向参与者发出的报文不是“全局提交”报文，而是提交前的“全局预提交”报文。

⭐ 即3PC的提交过程为：

第一阶段

协调者向所有的参与者发**“准备提交”**报文，由每个参与者根据自己的情况进行投票，如果所有的参与者回答“建议提交”，则进入第二阶段。

第二阶段

协调者向所有的参与者发**“全局预提交”**报文，参与者收到该报文后，若已经准备好提交，则回答“准备就绪”报文，否则进行撤销处理。

第三阶段

协调者收到所有参与者**“准备就绪”回答后，就向所有的参与者发“全局提交”报文，此时每个参与者都知道其他的参与者赞成提交，因此它可以在收到“全局提交”报文后进行提交**。

因此：
3PC可以避免阻塞是基于一定的故障模型的。
如果发生了网络分割故障，3PC同样存在问题。

三阶段提交协议对故障的恢复

P519页