分布式数据库技术：原子性和一致性

2023-10-28 理论教育版权反馈

【摘要】：如果考虑可容错系统，则原子性意味着在副本处提交事务后系统发生故障，其余可用副本处也需要提交事务，让事务不被“丢失”。存在故障的原子性只能由积极协议实现，所有副本保证能收到写集信息和所有在本地副本提交事务前决定事务命运的其他信息。与原子性比较，强一致性有差别，因为它指的一致是数据项的值而非事务的结果，这意味着所有的副本用相同的序实施冲突更新。

复制环境下的原子性意味着，如果更新事务在副本处提交，那么其他副本处也应提交该更新事务，以保证其更新在所有副本处都被执行。如果事务夭折，则不会有更新事务反映在数据库副本处。如果只考虑无故障环境，则意味着本地副本和并发控制系统必须保护每个副本对每个事务采取相同的提交/夭折措施。例如，在前面提及的主本协议里，通过FIFO组播（先进先出组播）写操作或写集，通过严格的2PL实现。

如果考虑可容错系统，则原子性意味着在副本处提交事务后系统发生故障，其余可用副本处也需要提交事务，让事务不被“丢失”。注意，这里说的“可用副本”可以继续提交事务，而有些副本可能已经下线，无法提交事务。恢复机制必须保证重新启动的下线副本能收到已经错过的更新。概括起来，可用副本提交相同的事务集，故障副本提交了这些事务的一个子集。

存在故障的原子性只能由积极协议实现，所有副本保证能收到写集信息和所有在本地副本提交事务前决定事务命运的其他信息。这样，可用副本将最终提交事务。在懒惰协议里，可用副本可能不知道后来短期故障的副本处的一个事务的存在。懒惰主本协议里，如果当前主本故障时没有选出新的主本，则原子性可以被保证。然后，主本恢复时，丢失的写集可以最终被传播出去。不过，这会严重减少系统的可用性。如果发生故障时切换到一个新主本，或者在懒惰随处更新方法里，恢复后始终可以试着发送写集，补上丢失的更新。然而，事务可能和故障期间其他的提交事务冲突，因此，“丢失”事务非平滑集成（no smooth integration）进入事务历史是可能的。

总的来说，积极协议可以提供原子性，懒惰方法可看成是非原子性的。(www.chuimin.cn)

文献中，大家可以看到积极协议与强一致性这个词相关，弱一致性与懒协议这个词相关。这些词的使用通常还是含糊的。定义强一致性的一种方式也是虚拟一致性（virtual consistency），要求所有数据副本在事务提交时有相同的值。只有使用2PC或类似约定的积极协议才提供虚拟一致性。与原子性比较，强一致性有差别，因为它指的一致是数据项的值而非事务的结果，这意味着所有的副本用相同的序实施冲突更新。理论上，可以有一个副本控制协议，提供原子性（保证所有副本提交相同的事务集），但在不同副本处冲突事务的执行序可能不同。

弱一致性意味着数据拷贝可以是陈旧的或暂时不一致的。陈旧性产生在懒惰主本拷贝方式里。只要主本没有把写集传播给次级副本，次级的数据拷贝就会过时。如果次级按主本相同的串行序实施更新，那么次级的数据拷贝除了数据过时以外，不包含任何不正确的数据。可以将系统设计成对次级上的陈旧数据实施的读操作给定一个限制。例如，对数值型数据，可以规定在次级上读出的值和主本的值间的差异阈值为100，小于该阈值，读出的值都是合法的。当然，也可规定次级上漏掉的写操作限制在4次以内等。

分布式数据库技术：原子性和一致性

相关推荐