Web开发必知的八种隔离级别.docVIP

摘要:串行一致性是可用的最古老最高的隔离级别之一，它之所以倍受青睐是因为其提供的简单编程模型，即每次仅能有一个事务对给定的资源进行操作，这就避免了很多潜在的资源问题。 尽管如此，大部分应用程序（尤其是Web 应用程序）都不采用这种级别非常高的隔离，因 为从终端用户的角度来看这是不切实际的‐任何一个拥有大量用户群的应用程序在访问共 享资源时都将会有几分钟的延迟，而这会使得用户量迅速减少。弱一致性和最终一致性在大 规模分布式数据源中，例如Web 中， 随处可见。 正文： ACID 性质是数据库理论中的奠基石，它定义了一个理论上可靠数据库所必须具备的四个性 质：原子性，一致性，隔离性和持久性。虽然这四个性质都很重要，但是隔离性最为灵活。 大部分数据库都提供了一些可供选择的隔离级别，且现在许多库都增加了附加层来创建颗粒 度更细的隔离。隔离级别应用范围如此之广主要是因为放宽隔离约束往往会使得可扩展性 和性能提高几个数量级。 串行一致性是可用的最古老最高的隔离级别之一，它之所以倍受青睐是因为其提供的简单编程模型，即每次仅能有一个事务对给定的资源进行操作，这就避免了很多潜在的资源问题。 尽管如此，大部分应用程序（尤其是Web 应用程序）都不采用这种级别非常高的隔离，因 为从终端用户的角度来看这是不切实际的任何一个拥有大量用户群的应用程序在访问共 享资源时都将会有几分钟的延迟，而这会使得用户量迅速减少。弱一致性和最终一致性在大 规模分布式数据源中，例如Web 中， 随处可见。好几个成功的大型Web 应用（例如，eBay 和Amazon）都显示出乐观的（optimistic）弱一致性要比传统悲观的 （pessimistic）机制在 扩展性方面好得多。本文将一窥八种不同的隔离级别。学会适当的放宽数据一致性的约束， 你可以在自己的应用程序中使用这八 种隔离级别来获得更好的性能和可扩展性。 并发控制的主要目标是为了确保事务被隔离且不会影响到其他事务。要达到高级别的隔离需 以牺牲性能为代价。并发控制可以用悲观或者乐观的机制来实现。大部分关系型数据库都 使用了悲观机制来实现写入优化。悲观机制采用了锁，通过使用锁它可以阻塞一些操作或者 进行某些形式的冲突检测。当一个表格，页面或是行被修改后，悲观机制中的锁可以用来 阻塞其他潜在的访问修改资源的事务。然而，乐观机制并不采用任何锁，它仅仅依赖于冲突 检测来维护事务隔离。乐观机制采用的冲 突检测可以允许所有的读操作，并在事务结束时 检验其一致性。如果检测到冲突，那么事务会进行回滚或重做。大部分web 服务器都是读 入优化，因此使用了乐观 机制。通过允许所有的读入操作，乐观机制既可以保证很高的读 写吞吐量，也可以在资源不是一直改变的情况下保证数据的一致性。 下面列出的隔离级别是用来帮助Web 开发人员更好的理解他们编程模型中放置的约束，帮 助系统架构师和开发人员共同讨论如何在保持必要的数据完整性的同时选择最有效的隔离 级别。它们按照最少隔离（未提交读）到最多隔离（串行化）的顺序列出。 未提交读（Read Uncommitted） 未提交读隔离级别需要事务间很少的隔离。每一个读操作都能看到事务中等待的写操作（脏 读）。然而已经提交的写操作必须要有一个串行顺序来防止脏写。悲观机制会阻塞有冲突的 写操作直到其他写操作已经被提交或已经回滚。乐观机制不会锁住这些操作，它会允许所有 的操作都通过。如果一个连接进行了回滚，那么接下来修改同一块数据的其他操作也会被 回滚。在这种级别中，共享缓冲可以不加验证的进行使用。这种隔离级别最好在不需要事务 （比如只读的数据集），或者事务只在 独占数据库时才修改的情况下使用。 例子：一个只在离线情况下更新的档案数据库，或者不在事务中使用的审核/登陆 （audit/logging）表。 已提交读（Read Committed） 已提交读可以读取系统中任何已经提交的状态，并且可以不加验证（混合状态）的进行缓冲， 只需当前连接中发生的改变能够反映到结果中即可。悲观机制将其实现为单调视图。乐观 事务则隔离存储所有的改动，使得它们直到提交后才可用。读已提交使用一个非常乐观的机 制，它推迟写入所有的变化直到事务被提交为止。这种形式的乐观隔离可以在不阻塞读操 作的情况下实现复杂的写入操作，并且它没有验证模式。共享缓冲只能在已提交的状态中使 用。这种隔离级别最好在结果可以使用 旧值，且事务只能用于写入操作的情况下使用。 例子：一个不必显示当前最新帖子的在线论坛，且它的帖子间数据不相冲突。 单调视图（Monotonic View） 单调视图是对读已提交的一个扩展，它其中的事务在执行时会观察数据库中一个单调上升的 状态。在这种级别中，如果有明显的写入事务，那么悲观事务会在读入操作中被阻塞。乐 观事务会像在读