📄 207002.htm
字号:
<html><body><span id=Layer1><a name=207002><font color=#3e70d7 face=arial size=5><b>二阶段交付（Two-Phase Commit）</span><span id=Layer2></b></font><p><font size=2 color=#3c3c3c face=arial>不管沟通的媒介是藉由OLE Transactions或XA，DTC交易管理员主要的工作都是相同的：首先它必须确保每个参加交易的资源管理员知道该做什麽事 确认或者取消交易 然後回报客户端真正发生的事。举例来说，有可能客户端即使已指明要确认交易，而包含在此交易内其中一个RM因个人理由决定取消这个交易。不管发生何事，DTC交易管理员需负责回报交易的结果给它的客户端。</span><span id=Layer3></font></p><p><font size=2 color=#3c3c3c face=arial>对於ADO来说，「客户端」这个字眼代表的是DTC的客户端，不是使用者的桌上型电脑。虽然桌上型电脑也可能扮演DTC客户端的角色，不过最常见的还是指执行在中间层的软体。</span><span id=Layer4></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>对於ADO来说，「客户端」这个字眼代表的是DTC的客户端，不是使用者的桌上型电脑。虽然桌上型电脑也可能扮演DTC客户端的角色，不过最常见的还是指执行在中间层的软体。</span><span id=Layer5></font></p><hr><p><font size=2 color=#3c3c3c face=arial>一旦客户端告诉DTC交易管理员某个交易应该确认或是取消後，交易管理员必须将这个要求传送到参与此交易的RM。你可以想像成交易管理员应该只通知每一个RM进行确认或取消动作，然後告诉客户端发生的事情。不过确定一下每一个RM都做了相同的事，全部确认，或全部取消需要比这个工作还要更为复杂的机制。DTC交易管理员不只仅告诉RM要做什麽事，还得依赖一个广被使用的演算法，称二阶段交付（有时简称2PC）。</span><span id=Layer6></font></p><p><font size=2 color=#3c3c3c face=arial>DTC使用众所周知的二阶段交付演算法来结束一个交易</span><span id=Layer7></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>DTC使用众所周知的二阶段交付演算法来结束一个交易</span><span id=Layer8></font></p><hr><p><font size=2 color=#3c3c3c face=arial>二阶段交付基本的概念并不困难。为了要理解它运作的情形，假设客户端告诉单机的DTC交易管理员结束一个交易，要求交易中所有的工作进行确认。为了达到这个目的，交易管理员开始2PC演算法的第一个阶段，传送一个准备（Prepare）讯息到包含在交易中的每一个RM，询问它们是否准备要进行客户端要求的工作。实际上传送这个讯息的方式有很多，将於下个章节描述，不过有可能会建立起交易管理员之间的阶层状关系，所有的动作将由存在於DTC客户端的机器之根交易管理员全盘掌控。接着每个RM便回应一个讯息通知：「是的！我准备要确认了！」或「没有！我还没有准备好！」当交易管理员接收到交易中任一个所有的RM回传上述任一个答案後，二阶段交付演算法的第一个阶段就结束了。</span><span id=Layer9></font></p><p><font size=2 color=#3c3c3c face=arial>在第一个阶段，DTC询问每一个RM是否准备要确认了</span><span id=Layer10></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>在第一个阶段，DTC询问每一个RM是否准备要确认了</span><span id=Layer11></font></p><hr><p><font size=2 color=#3c3c3c face=arial>在演算法的第二个阶段，交易管理员会真正告诉RM他们应该要做的事。若在第一阶段，交易管理员接收到交易中每个RM发出「YES」讯息，交易管理员便传送一个确认（Commit）讯息给每一个RM。然後每一个RM再确认这个交易，进行交易中永久的变动动作，然後将这个行动指示回传到交易管理员。然而若在第一阶段交易管理员接收到「NO」的讯息，这代表交易中所有RM做的工作都必须取消。（记住，交易的定义是，不是全部成功就是全部失败）在这个案例中，第二阶段包含了交易管理员传送给每一个RM一个取消（Abort）的讯息，跟随着从RM接收到一个回应，指明已取消了这个交易。在任一种情况，都会进行正确的事：交易中所有的工作永久改变，或者是什麽事都没有发生。</span><span id=Layer12></font></p><p><font size=2 color=#3c3c3c face=arial>在第二阶段，DTC通知每个RM该做何事：确认或取消</span><span id=Layer13></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>在第二阶段，DTC通知每个RM该做何事：确认或取消</span><span id=Layer14></font></p><hr><p><font size=2 color=#3c3c3c face=arial>这是一个相当可爱的问题，大部份的时间它运作的方式就如上述描述。不过不用花太多脑袋去理解，即使使用二阶段交付，还是有运作不正确的可能性。举例来说，假设在第一阶段交付完成而在未接收到第二阶段交付的讯息之前，交易中其中一个RM所在的机器与根交易管理员之间的网路连线断了，那会发生什麽事？交易的结果该怎麽决定呢？</span><span id=Layer15></font></p><p><font size=2 color=#3c3c3c face=arial>若机器或网路在错误的时间点发生故障，问题就会产生了。</span><span id=Layer16></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>若机器或网路在错误的时间点发生故障，问题就会产生了。</span><span id=Layer17></font></p><hr><p><font size=2 color=#3c3c3c face=arial>为了要协助解决这类的问题，每个DTC交易管理员会维护一个日志档案。交易管理员加入的每个交易都会记录在这个日志中。同时每个RM都会维护一个日志，储存目前自己牵涉到的所有交易之资讯。在系统毁损或重新启动时，交易管理员与RM便检查不同的日志档案以便判断该采取何种行动来确保每件事都正确地解决。</span><span id=Layer18></font></p><p><font size=2 color=#3c3c3c face=arial>DTC与每个RM维护着日志档案以便从故障中回复</span><span id=Layer19></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>DTC与每个RM维护着日志档案以便从故障中回复</span><span id=Layer20></font></p><hr><p><font size=2 color=#3c3c3c face=arial>举例来说，假设某些RM执行所在的机器故障了，则RM牵涉到的任何正在运行中的交易，以及客户端尚未结束的交易都会被取消。因为这些交易内其中一个RM已失败了，这些交易没有成功的可能。不过当此RM运作失败时，这个RM与正在进行二阶段交付的交易又会如何呢？此RM存在的机器可能会重新启动，因此当RM重新执行时，它将会察看这些交易的日志。不过该怎麽处理这个交易呢？当RM所在机器关机时，这些交易该确认或是取消呢？</span><span id=Layer21></font></p><p><font size=2 color=#3c3c3c face=arial>从RM的观点来看，这些交易处於不确定状态，因为它自己无法判断应该做什麽。 为了要解决这个问题，RM会与一个DTC交易管理员连系，询问每一个处於不确定状态的交易最终的结果。接着这个RM就会执行交易管理员交付的事，在这个RM缺席的期间中确认交易，或在此期间复原取消的交易。这个过程实际上相当地复杂，RM正在查询的DTC交易管理员本身需要与交易阶层中，上层的其它交易管理员连系，以便判断该做什麽事，同时这个交易管理员可能需要查询更高层的交易管理员。无论状况如何，一旦任何系统故障，或网路问题解决後，DTC就会与RM一起运作以确保所有处於不确定状态的交易，所有的RM都做一样的事情：全部确认或全部取消。幸运地，根交易管理员从来不会对交易的结果产生不确定的情况，它永远都知道结果应该为何。</span><span id=Layer22></font></p><p><font size=2 color=#3c3c3c face=arial>重新启动的RM会查询DTC以得知如何对待任一个不确定的交易</span><span id=Layer23></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>重新启动的RM会查询DTC以得知如何对待任一个不确定的交易</span><span id=Layer24></font></p><hr><p><font size=2 color=#3c3c3c face=arial>不过这不能满足所有的情况。没错，如果你等待时间够久的话，DTC与RM会一起运作，来确保即使在系统或网路故障时，事情还是能够圆满完成。不过回忆之前所提，每个参加交易的RM同样会锁定正在处理的资料。假设在等待置换硬碟或重新安装的等待过程中，让资料保持在锁定的状态（其它交易将无法存取这个资料）是完全无法令人接受的。不用怀疑，顾客一定不怎麽愉快的。举例来说，假设顾客的支票帐户在几天之内都无法存取。类似这样的情形，系统管理者可以使用Windows 2000中的元件服务管理工具强制一个处於不确定状态的交易进行确认或取消。这些手动介入的情况并不是吸引人的作法，不过将交易中所有的资料锁定，直到牵连到的系统再次运行并不是合适的作法，但它是你唯一的选择。</span><span id=Layer25></font></p><p><font size=2 color=#3c3c3c face=arial>对於某些类型的错误，需要以人为的方式来正确地结束一个交易</span><span id=Layer26></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b></b></font><p><font size=2 color=#3c3c3c face=arial>对於某些类型的错误，需要以人为的方式来正确地结束一个交易</span><span id=Layer27></font></p><hr><p><font size=2 color=#3c3c3c face=arial>增进DTC适用性（availability）的其中一个方法便是使用Microsoft Cluster Server （MSCS）。当你在两台电脑丛集上使用MCS，DTC交易管理员只会在丛集中其中一个节点上执行。不过它的日志是储存在丛集中两台电脑都可以存取到的硬碟内。若正在执行的交易管理员所在之电脑发生故障， 丛集中另一台电脑将会自动地启动。因为这两台电脑共享同样的硬碟，新的交易管理员便可以使用同一个交易日志继续工作。</span><span id=Layer28></font></p><hr><font face=Arial Black color=#3e77d7 size=3><b> 附注</b></font><p><font size=2 color=#3c3c3c face=arial>增进DTC适用性（availability）的其中一个方法便是使用Microsoft Cluster Server （MSCS）。当你在两台电脑丛集上使用MCS，DTC交易管理员只会在丛集中其中一个节点上执行。不过它的日志是储存在丛集中两台电脑都可以存取到的硬碟内。若正在执行的交易管理员所在之电脑发生故障， 丛集中另一台电脑将会自动地启动。因为这两台电脑共享同样的硬碟，新的交易管理员便可以使用同一个交易日志继续工作。</span>
</body></html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -