11.12 分布式数据库系统中存在的问题 可以想象一下在简单的非分布式环境中发现的问题，如互斥、饿死和死锁等，它们都有可能出现在分布式环境中。实际上，后一种环境下出现这些问题的可能性更大，因为它涉及到很多的实体，它们会引起混乱。没有全局状态更是增加了其中的麻烦。 操作系统或参与的进程不可能知道所有进程的整个状态。它只能知道自己的状态(也就是本地进程)。为了获取远程进程的相关信息，它要获取来自其他进程的消息，或者和其他进程进行通信。更糟糕的是，这些信息反映了过去的状态。虽然过去的时间可能连1秒钟都不到，但它在商业和其他应用中会产生很严重的后果。 例如，假定进程A获取远程进程B的信息，B中账户上午11点59分结余2000美元。因此，当需要从中提取1500美元时，进程A认为该账户有很充足的结余，并做了提款处理。不幸的是，中午12点的时候，进程B也从相同账户提取1800美元。显然，这就是严重的并发问题。在本地系统中，可以借助数据库事务以某种方式控制该问题。在远程事务中如何实现这种控制呢？ 有很多种方法解决该问题，这里介绍其中的两种方法。 11.12.1 分布式快照算法 分布式快照算法用于记录一致的全局状态。这里的基本假设是消息可以被目的地正确接收，而不会出现任何失败(类似于TCP保证消息传输的方式--无损传输，按照消息发送的相同顺序，且没有任何副本)。发起者进程通过记录自己的状态，并向所有要经过的信道(例如所有其他进程)发送特殊的控制消息，从而在执行任何事务或发送其他消息之前调用该算法。所有其他进程都要进行相同的处理工作。因此，每个进程有一个标记(类似于提交点)，这样在后面遇到某些并发问题时可以回到该标识处。 chandy和lamport的快照算法 目的：捕获一致的全局状态。 假设： - 进程和通道不会出现故障 - 单向通道，提供FIFO顺序的消息传递 - 进程之间存在全联通的关系 - 任一进程可在任一时间开始全局拍照 - 拍照时，进程可以继续执行，并发送和接收消息。 算法基本思想： - 接入通道 + 外出通道 - 进程状态 + 通道状态 - 标记消息 标记发送规则: 强制进程在记录下自己的状态之后，但是在他们发送其他消息前，发送一条- - 标记。 标记接收规则: 在接收标记前，强制没有记录状态的进程记录自己的状态。 标志的作用是为各个局部状态的同步提供一个截止的参照物.
由于每个进程都可以自主地发起快照算法，因此发起者必须对标记进行标识，以便区分,否则不同进程发起的快照算法将无法区分，造成混乱。 发起者进程通过记录自己的状态，并向所有要经过的信道(例如所有其他进程)发送特殊的控制消息，从而在执行任何事务或发送其他消息之前调用该算法。所有其他进程都要进行相同的处理工作。因此，每个进程有一个标记(类似于提交点)，这样在后面遇到某些并发问题时可以回到该标识处。