|
|
知识路径： > 数据库主流应用技术 > 数据库主流应用技术 > 数据库主流应用技术 > 分布式数据库 >
|
被考次数：1次
被考频率：低频率
总体答错率：70%
知识难度系数： 
|
由 软考在线 用户真实做题大数据统计生成
|
|
考试要求：了解
相关知识点：23个
|
|
|
|
|
|
|
一个事务是访问数据库的一个逻辑工作单位，它是一个操作序列，执行这个操作序列，使数据库从一种一致状态转换到另一种一致状态，以实现特定的业务功能。
|
|
|
|
分布式事务是传统事务的扩充，在分布式数据库系统中，任何一个应用的请求最终都将转化成对数据库的存取操作序列，所以分布式事务从外部特征来看，继承了传统事务的定义。但是，在分布式数据库系统中，数据是分布的，一个事务的执行可能涉及多个站点上的数据，这使得分布式事务的执行方式与传统事务的执行方式不同，传统集中式事务只在一台计算机上执行，而分布式事务将在多个站点上的多台计算机上执行，即分布式事务的执行也是分布的。
|
|
|
|
在分布式数据库系统中，用分布式事务表明一个要求访问多个站点上数据库中数据的事务，但不关心存放数据的具体地点。分布式数据库管理系统的事务优化器实现把一个分布式事务转变为若干个与相应站点有关的操作序列，这些操作序列也称为“子事务”。所以，在分布式数据库系统中，可以把一个分布式事务看成是由若干个不同站点上的子事务组成。
|
|
|
|
|
|
分布式事务和集中式数据库中的事务一样具有下面的特性：
|
|
|
|
（1）原子性：事务的操作要么全部执行，要么全部不执行。当事务非正常终止时，其中间结果将被取消。事务的原子性保证数据库的状态总是从一个一致的状态变化到另一个一致的状态，而不会出现不一致的中间状态。
|
|
|
|
（2）可串行性或一致性：并发执行的几个事务，其操作的结果应与以某种顺序串行执行这几个事务所得出的结果相同，因此称为可串行性。这种可串行化的并行调度是由数据库系统的并发控制机制来完成，以保证并发事务执行时的数据库状态的一致。所以这种性质也称为事务的一致性。
|
|
|
|
（3）隔离性：一个没执行完的事务不能在其提交之前把自己的中间结果提供给其他的事务使用。因为未提交事务的结果不是最终结果，它有可能在以后的执行中被迫取消，如果其他的事务用到了它的中间结果，那么该事务也要夭折。
|
|
|
|
（4）持久性：当一个事务正常结束后，即提交后，其操作的结果将永久化，提交后发生的故障不会影响提交结果。即使发生了故障，系统应能够保证可以把事务的操作结果恢复过来。
|
|
|
|
人们常把事务的原子性（Atomicity）、可串行性（Serializability）或一致性（Consistency）、隔离性（Isolation）和持久性（Durability），称为事务的四个特性，简写为ASID或ACID。
|
|
|
|
由于分布式数据库系统的分布特性，分布式事务的四性更带有分布执行时的特性。例如，在分布式数据库系统中，为了保证事务的原子，组成这个分布式事务的各个子事务，要么全部都提交（成功结束），要么全都撤销（不成功结束），这就需要对各子事务进行协调和控制。此外，在分布式事务中，除了需要考虑访问数据互斥的存取操作序列外，还必须考虑大量的数据传送、通信原语和控制报文等，这些都是分布式事务所特有的性质。因此分布式事务与集中式数据库中的事务相比，在下面几个特性有所区别：
|
|
|
|
（1）执行特性：由于分布式事务执行时被分解成多个子事务执行，而各子事务间的操作需要进行协调，因此每一个分布式事务必须创建一个控制进程（亦称协调进程），以协调各子事务的操作，协调数据及控制报文的收发，决定事务的提交与夭折。而集中式事务的执行由并行调度算法调度，不必产生一个控制进程，也不必分解为子事务。
|
|
|
|
（2）操作特性：在分布式事务中，除了应用对数据的存取操作序列之外，还必须加入大量的通信原语，负责协调进程和代理进程（负责完成子事务）之间的数据传送，以及代理进程之间的数据传送。此外，为了协调子事务的执行，还要加入大量的控制原语。因此，分布式事务比集中式事务的组成要复杂，而且执行的方式也要复杂得多。
|
|
|
|
（3）控制报文：分布式数据库系统中，除了数据报文外，更增加了控制报文。因为除了要对数据进行存取操作外，还要对各子事务的操作进行协调，这样就有了大量的控制报文要在网上传输。
|
|
|
|
|
|
在集中式数据库系统中，故障分为事务故障、系统故障和介质故障。
|
|
|
|
在分布式数据库系统中，除了上述故障外还有因网络引起的故障。一般，把网络上各站点可能出现的故障称为站点故障，它们包括集中式系统中可能发生的故障，而把站点之间通信出现的故障称为通信故障。
|
|
|
|
通信故障可分为报文故障和网络分割故障。而报文故障又可分为报文错、报文失序、报文丢失和长时间的延迟。对报文错和报文失序现今网络都可检测和处理，所以通信故障主要是报文丢失、报文延迟和网络分割。下面我们对每一种故障逐一解释：
|
|
|
|
（1）介质故障：存放数据的介质发生的故障，如磁带、磁盘的损坏等。
|
|
|
|
（2）系统故障：CPU错、死循环、缓冲区满、系统崩溃等。
|
|
|
|
（3）事务故障：计算溢出、完整性被破坏、操作员干预、输入输出错等。
|
|
|
|
（4）网络分割故障：系统中一部分的节点和另外一部分节点完全失去了联系，两组节点无法通信。
|
|
|
|
（5）报文故障：收到的报文格式或数据错误、报文先后次序不正确、丢失了部分报文和长时间收不到报文。
|
|
|
|
|
|
|
|
|
|
|
|
（1）是系统发生故障，还是性能不好，还是网络流量过大？
|
|
|
|
（2）如果是系统发生故障，是站点故障，还是报文故障，还是网络分割？
|
|
|
|
（3）如果是报文故障，是报文丢失还是应答丢失？等等。
|
|
|
|
处理网络分割故障要比处理站点故障和报文故障困难得多，但其发生频率也低于站点故障和报文故障。按照故障处理难度的升序排列，则为：
|
|
|
|
|
|
|
|
|
|
|
|
故障的发生会影响数据库中数据的正确性，甚至破坏数据库，从而影响数据库系统的可靠性和可用性。因此，数据库管理系统都对故障恢复机制很下功夫，认真地做了研究和开发。研究数据库系统中故障的恢复，主要是指如何恢复因故障而破坏的数据库，使数据库恢复到正确状态。在分布式数据库系统中，当发生事务故障时，保证事务原子性的措施称为事务故障恢复，简称为事务恢复。事务本身的故障和系统的故障是造成数据库完整性和一致性破坏的主要原因。事务恢复主要是依靠日志来实现的。恢复应遵循的原则如下所述。
|
|
|
|
|
|
对于不影响其他事务的可排除性局部故障，例如事务操作的删除、超时、违反完整性规则、资源、限制、死锁等，应令某个事务孤立地和逐步地退出，将其所做过的修改复原，即做UNDO。
|
|
|
|
|
|
成功结束事务所做过的修改应超越各种故障，当故障发生时，应该重做（REDO）事务的所有操作。
|
|
|
|
|
|
若发生了非局部性的不可排除的故障，例如系统崩溃，则撤销全部事务，恢复到初态。这有两种做法：一种是利用数据库的备份实现；另一种是按反向顺序操作，复原其启动以来所做过的一切修改。
|
|
|
|
从集中式事务恢复可以了解事务恢复的一般过程，对分布式事务来说，由于处于网络环境，其恢复处理远比集中式事务恢复要复杂得多。在分布式事务恢复中，本地事务的恢复和集中式事务的恢复相同，由本地事务管理器（Local Transact Management，LTM）具体执行；而整个分布式事务的恢复由分布式事务管理器（Distribute Transact Management，DTM）与LTM协同完成。
|
|
|
|
|
|
两阶段提交协议（Two Phase Commitment Protocol，2PC）既简单又精巧，它把本地原子性提交行为的效果扩展到分布式事务，保证了分布式事务提交的原子性，并在不损坏日志的情况下，实现快速故障恢复，提高分布式数据库系统的可靠性。
|
|
|
|
在两阶段提交协议中，把分布式事务的某一个代理指定为协调者（Coordinator），所有其他代理称为参与者（Participant）。这里的代理是指完成各个子事务的进程。只有协调者才拥有提交或撤销事务的决定权，而其他参与者各自负责在其本地数据库中执行写操作，并向协调者提出撤销或提交事务的意向。一般一个站点唯一地对应一个子事务，如果某一参与者与协调者在同一站点，虽然它们不需要使用网络来通信，但仍逻辑地认为它与协调者不在同一站点。下图描述了协调者和参与者的关系。
|
|
|
|
|
|
|
|
2PC保证分布式事务提交的原子性，这是通过在分布式事务的结果生效以前，所有参与执行分布式事务的站点都同意提交而做到这一点的。这种同步的必要性有很多理由，如果某个事务正在读一项由另一个还未提交的事务更新的数据项的值时，相应的参与者就不会同意马上提交该事务。另一种参与者不同意提交的可能的原因是发生了死锁，这要求某一个参与者撤销事务。注意，参与者不需要任何其他进程来通知就可以撤销一个事务，这种能力相当重要，我们称之为单方面撤销。
|
|
|
|
2PC把事务的提交过程分为两个阶段：第一阶段是表决阶段，目的是形成一个共同的决定。开始时，协调者在它的日志中写入一条开始提交的记录，再给所有参与者发送“准备提交”消息，并进入等待状态。当参与者收到“准备提交”消息后，它检查是否能提交本地事务。如果能提交，参与者在日志中写入一条就绪记录，并给协调者发送“建议提交”消息，然后进入就绪状态：否则，参与者写入撤销记录，并给协调者发送“建议撤销”消息。如果某个站点做出“建议撤销”提议，由于撤销决定具有否决权（即单方面撤销），发出“建议撤销”的站点就可以直接忽略这个事务。协调者收到所有参与者的回答后，它就做出是否提交事务的决定。只要有一个参与者建议撤销，协调者就必须从整体上撤销整个分布式事务，因此它写入一条撤销记录，并给所有参与者发送“全局撤销”消息，然后进入撤销状态；否则，它写入提交记录，给所有的参与者发送“全局提交”消息，然后进入提交状态。
|
|
|
|
第二阶段是执行阶段，目的是实现这个协调者的决定。根据协调者的指令，参与者或者提交事务，或者撤销事务，并给协调者发送确认消息。此时，协调者在日志中写入一条事务结束记录并终止事务。上图描述了两阶段提交协议的参与者和协调者的交互。
|
|
|
|
请注意协调者做出事务的全局终止决定的方式，该决定受两条规则的支配，这两条规则称为全局提交规则：
|
|
|
|
（1）只要有一个参与者撤销事务，协调者就必须做出全局撤销决定。
|
|
|
|
（2）只有所有参与者都同意提交事务，协调者才能做出全局提交决定。
|
|
|
|
从下图中可以看出以下关于两阶段提交协议的一些重要之处：
|
|
|
|
|
|
|
|
（1）两阶段提交协议允许参与者可以单方面撤销事务。
|
|
|
|
（2）一旦参与者确定了提交或撤销提议，就不能再更改它的提议。
|
|
|
|
（3）当参与者处于就绪状态时，根据协调者发出的消息的种类参与者可以转换为提交状态或撤销状态。
|
|
|
|
|
|
（5）注意协调者和参与者可能进入某些相互等待对方发送消息的状态。为了确保它们能够从这些状态中退出并终止，要使用定时器。每个代理进程进入一个状态时都要设置超时器。如果所期待的消息在定时器超时之前没有到来，定时器向代理进程报警，进程根据超时协议执行相应动作。
|
|
|
|
|
|
|
|
.当一参与者在写入“建议提交”前发生故障时，该参与者无法向协调者发回答信息，因此，当协调者等待超时后，将决定终止事务。当该故障恢复后，该参与者无须收集其他场地的信息即可终止事务。
|
|
|
|
.参与者进程在写入“建议提交”后发生故障，这时其他的参与者可以正常结束该事务，“提交”或“撤销”，因为协调者可以根据收到该参与者的应答决定“提交”或“撤销”。因此，故障恢复后，该参与者要访问协调者或其他参与者，以了解协调者对事务做出的决定，然后执行相应的操作“提交”或“撤销”。这里我们假设在日志中写入“建议提交”记录和发送“建议提交”信息给协调者这两个动作具有原子性，要么都执行，要么都不执行。
|
|
|
|
.协调者在日志中写入“准备提交”记录后，写入“全局提交”或“全局撤销”前发生故障，这时已发出“建议提交”信息的参与者等待协调者恢复。协调者的重启动过程从头恢复提交协议，从“准备提交”记录中读出参与者的标识符，重发“准备提交”报文给参与者，重新执行提交过程。
|
|
|
|
.协调者在写入“全局提交”或“全局撤销”记录以后，在写入“事务结束”记录以前发生故障。在这种情况下，协调者恢复时必须给所有的参与者重发其决定，未收到信息的参与者不得不等待协调者的恢复。
|
|
|
|
|
|
.至少有一个参与者的回答报文（“建议提交”或“建议撤销”）丢失了。在这种情况下，协调者将等待回答而超时，整个事务被撤销。这种情况只由协调者发现，但它无法决定是场地故障还是通信故障，而参与者能够正确执行，它不会启动恢复过程。
|
|
|
|
.丢失“准备提交”报文，由于至少有一个参与者收不到“准备提交”命令，因此参与者处于等待状态，而协调者也等待参与者的回答，所以协调者会因为等待超时而撤销事务。这种情况和上述一样。
|
|
|
|
.丢失“全局提交”或“全局撤销”报文，这种情况下参与者处于等待协调者命令的状态下，当参与者未收到命令时，会因等待而超时，这时向协调者请求重发该命令的信息。
|
|
|
|
.丢失了“确认”报文，当协调者未收到全部参与者的“确认”报文时，协调者会因等待而超时，这时协调者重发命令报文给参与者，这时参与者必须给予“确认”报文回答，即使此时相应的子事务已不在活动也要重发。
|
|
|
|
|
|
假设在出现网络分割时，整个网被分为两个组，包含协调者的组称为协调者组，其他的则组成参与者组。这种情况对于协调者来说相当于参与者组中的多个参与者同时发生故障，这时协调者可以做出决定，然后把命令发给协调者组中的参与者，因此这些场地上的子事务可以结束。而对于失去联系的参与者，它们则认为协调者出现故障，根据它们所缺少的回答信息，进行相应的故障处理。
|
|
|
|
|
|
所谓事务的阻塞是指一个场地的子事务本来是可以执行结束的，然而由于分布式数据库的故障，它必须等待故障恢复以后得到需要的信息后才可以做出决定，而故障情况是不可以预料的，该子事务又占有一些系统资源不能释放，无法继续执行，这时称之为事务进入阻塞状态。
|
|
|
|
事务出现阻塞的原因可能很多，例如：当参与者等待协调者的回答时，可能因为网络故障或协调者故障使之收不到回答信息而出现等待超时，这时事务进入阻塞状态，重发“建议提交”信息，要求协调者给予回答，直到网络故障或协调者恢复并给予回答，参与者才做出决定继续执行（提交或撤销），若一直收不到回答，则事务一直处于阻塞状态而挂在相应的场地上，因此，阻塞降低了事务的可用性。
|
|
|
|
如何使一提交协议成为非阻塞的提交协议呢？在2PC协议中，参与者的提交是在它知道了其他所有的参与者均发出了“建议提交”的报文以后进行的。若在2PC中增加一段使得参与者的提交不仅要等到它知道所有的参与者均发出了“建议提交”的报文，而且还知道所有参与者的状态（如它们是处于故障状态，还是已经恢复）以后才执行。这时2PC即变成3PC协议，即三阶段提交协议。在3PC协议中，报文有三次接收和发送，协调者第二次向参与者发出的报文不是“全局提交”报文，而是提交前的“全局预提交”报文，告诉所有的参与者均可以进入准备提交状态，而参与者的回答也不是提交子事务，而是发出“准备就绪”报文。在第三阶段中，当协调者收到全部的“准备就绪”的回答时才向所有的参与者发“全局提交”报文。此时，所有的参与者均知道其他的参与者已经进入“准备提交”状态。达到这一点，每个参与者均可以自己做出决定，撤销或提交，而不必因等待协调者的回答而进入阻塞状态，因为即使此时发生故障，系统的恢复机制迟早会恢复到故障前一刻的状态，即各参与者的子事务总会提交。因此，参与者可以自行决定先执行下去而不是处于等待状态，从而减少了阻塞。3PC协议的提交过程为：
|
|
|
|
第一阶段，协调者向所有的参与者发“准备提交”报文，由每个参与者据自己的情况进行投票，只有所有的参与者回答“建议提交”才进入第二阶段。
|
|
|
|
第二阶段，协调者向所有的参与者发“全局预提交”报文，参与者收到该报文后若已经准备好提交，则回答“准备就绪”报文，否则进行撤销处理。
|
|
|
|
第三阶段，协调者收到所有的参与者“准备就绪”回答后，就向所有的参与者发“全局提交”报文，此时每个参与者都知道其他的参与者赞成提交，因此它可以收到“全局提交”报文后进行提交。
|
|
|
|
3PC可以避免阻塞是基于一定的故障模型的，如果发生了网路分割故障，采用3PC协议同样存在问题，没有一种协议能够解决所有的故障，3PC协议仅仅是降低了阻塞发生的可能性，但不是完全的非阻塞协议。
|
|
|
|
|
|
由于系统的故障，报文可能没有收到。与2PC一样，3PC也采用超时方法处理。
|
|
|
|
第一种情况是协调者没能及时发出“准备提交”报文，导致参与者等待超时，这时参与者决定撤销。
|
|
|
|
第二种情况是协调者等待参与者投票结果超时，这时协调者决定撤销。
|
|
|
|
第三种情况是参与者处于“赞成”提交状态，等待“全局预提交”命令时出现超时，这时进入恢复处理过程。
|
|
|
|
第四种情况是参与者处于“准备就绪”状态等待协调者的“全局提交”命令出现超时，也进入恢复处理，这时只要有至少一个参与者处于活动状态，子事务就不会阻塞。因为恢复后的参与者可以从活动子事务得到有关提交处理的信息，从而得知协调者的决定，依据协调者的决定确定自己应做的处理。
|
|
|
|
|
|
（1）一个参与者在其他任何一个活动的参与者处于赞成提交状态时，不可能进入“提交”状态。
|
|
|
|
（2）一个参与者在另一个参与者进入提交状态或任何一个参与者都进入准备就绪状态时不能进入撤销状态。
|
|
|
|
因此，恢复时参与者可以根据活动事务的状态决定相应的处理。在3PC协议中，恢复机制唯一可以做的是就近访问一个活动的参与者，确切地说是访问在它进入恢复处理前最近的活动参与者。如果所有的参与者处于“赞成”提交或“撤销”状态，则肯定没有一个参与者已提交，因此可以通知全部参与者“撤销”。如果已经有一个参与者“准备就绪”或“提交”，则肯定没有一个参与者被“撤销”，所以可以通知全部参与者提交，在通知“全局提交”前应先将仍处于“赞成”提交的参与者进入“准备提交”状态，然后再进入“提交”状态。因为在通知提交前，任何一个参与者均可能再发生故障，所以应避免其中一个参与者处于“赞成”提交状态而另一个处于“提交”状态。
|
|
|
