1.7. 关于事务服务量


在选择实施交易系统的产品时,有很多数据库产品和交易经理,免费收费和一些商业。所有这些都对交易处理有突出支持,但这些产品支持的服务质量有显著的变化。本节概述了比较不同事务产品的可靠性和复杂性时需要考虑的功能类型。

1.7.1. 资源提供的服务质量

以下功能决定了资源服务质量:

1.7.1.1. 事务隔离级别

ANSI SQL 定义四个 事务隔离级别,如下所示:

SERIALIZABLE
事务完全相互隔离。也就是说,在交易提交前,一个事务不会影响任何其他事务。这种隔离级别被描述为 可序列化 的,因为当所有事务在另一个事务后执行一样(尽管在实践中,资源通常会优化算法,因此一些事务可以同时进行处理)。
REPEATABLE_READ
每次事务读取或更新数据库时,都会获得读取或写入锁定,直到事务结束为止。这提供了几乎完全的隔离。但在一种情况下,隔离是不完美的。考虑使用 WHERE 子句读取一系列行的 SQL SELECT 语句。如果另一个事务在第一个事务运行时添加一个行到这个范围,如果第一个事务正在运行,则第一个事务可以看到这个新行,如果它重复 SELECT 调用(一 E phantom 读取)。
READ_COMMITTED
写入锁定在事务结束前进行。在事务结束前,读取锁定 不会被保留。因此,重复读取可能会提供不同的结果,因为由其他事务提交的更新对持续事务可见。
READ_UNCOMMITTED
在事务结束前,读取锁定或写入锁定都不会被保留。因此,脏的读量也有可能。脏系统就绪是未提交由其他事务所做的更改对持续的事务可见时。

数据库通常不支持所有不同的事务隔离级别。例如,一些空闲数据库只支持 READ_UNCOMMITTED。此外,一些数据库以与 ANSI 标准微小的方式实施事务隔离级别。隔离是一项复杂的问题,它涉及数据库性能的权衡(例如,请参阅 Wikipedia 中的隔离)。

1.7.1.2. 支持 XA 标准

若要让参与涉及多个资源的事务的资源,需要支持 X/Open XA 标准。务必检查 XA 标准的资源实施是否受到任何特殊限制。例如,Accli 标准的一些实施仅限于单一数据库连接,这意味着一次只有一个线程可以处理涉及该资源的事务。

1.7.2. 事务管理器提供的服务数量

以下功能决定了事务管理器的服务质量:

1.7.2.1. 支持挂起/恢复和附加/缓冲

某些事务管理器支持操作事务上下文和应用程序线程之间的关联,如下所示:

  • 挂起/恢复当前事务- 允许您暂时暂停当前事务上下文,同时应用程序会在当前线程中执行一些非事务工作。
  • attach/detach 事务上下文- 允许您将事务上下文从一个线程移动到另一个线程,或扩展事务范围以包含多个线程。

1.7.2.2. 支持多个资源

事务管理器的一个关键区别是能够支持多个资源。这通常支持 XA 标准,其中事务管理器为资源提供了注册其 XA 交换机的方法。

注意

严格说来,Alan standard 不是您可使用它来支持多个资源的唯一方法,而是最实用的方法。另一种方法通常涉及编写繁琐(和关键)自定义代码,以实施通常通过 XA 交换机提供的算法。

1.7.2.3. 分布式事务

某些事务管理器能够管理其范围包括分布式系统中的多个节点的事务。使用特殊协议(如 WS-AtomicTransactions 或 CORBA OTS),将事务上下文从节点传播到节点。

1.7.2.4. 事务监控

高级事务管理器通常提供视觉化工具来监控待处理事务的状态。这样的工具在系统失败后特别有用,它可以帮助识别和解决处于不确定状态(高流例外)的事务。

1.7.2.5. 从失败中恢复

在出现系统故障(崩溃)时,交易经理对交易经理有显著的区别。事务管理器使用的关键策略是在执行事务的每个步骤之前将数据写入持久日志。如果出现故障,日志中的数据可用于恢复事务。某些事务管理器比其他事务者更仔细实施此策略。例如,高端事务管理器通常重复持久性事务日志,并允许将每个日志存储在单独的主机机器上。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.