25、高级事务处理：概念、架构与应用

高级事务处理：概念、架构与应用

1. 事务处理监视器（TP Monitors）

1.1 起源与发展

事务处理监视器（TP Monitors）起源于上世纪七八十年代，最初是为了满足从单台计算机支持大量远程终端（如航空公司预订终端）的需求而开发的，最初被称为远程处理监视器（Teleprocessing Monitor）。随着时间的推移，它们不断发展，如今已成为分布式事务处理的核心支持系统。常见的TP监视器包括IBM的CICS TP、BEA Systems的Tuxedo和Top End、IBM旗下Transarc的Encina以及Microsoft的Transaction Server。

1.2 TP监视器的架构

TP监视器的架构可分为以下几种：
- 客户端进程模型 ：为每个客户端创建一个服务器进程，服务器进行身份验证并执行客户端请求。但该模型存在内存需求高和上下文切换开销大的问题。
- 单服务器模型 ：所有客户端连接到一个服务器进程，服务器进程承担用户身份验证等任务。为避免阻塞其他客户端，服务器使用多个线程实现轻量级多任务处理，线程切换成本低。
- 多服务器单调度器模型 ：多个应用服务器进程访问一个公共数据库，客户端通过一个调度器进程与应用程序通信。该模型支持独立的服务器进程，每个应用程序可以有一组服务器进程，并且每个服务器进程可以有多个线程，以并发处理多个客户端请求。
- 多服务器多调度器模型 ：多个进程与客户端通信，这些进程与一个或多个调度器进程交互，调度器将请求路由到相应的服务器。这种架构由一个控制器进程启动和监控其他进程，如Tandem的Pathway。

1.3 TP监视器的功能

TP监视器不仅负责将消息传递给应用服务器，还具有以下功能：
- 消息队列管理 ：使用持久队列确保消息在系统故障时仍能被处理。
- 授权和服务器管理 ：包括服务器的启动和消息路由。
- 历史记录、恢复和并发控制 ：为应用服务器提供资源，使其能够直接实现事务的ACID属性。
- 持久消息传递 ：确保消息在事务提交时才被传递。

1.4 应用协调

现代应用程序通常需要与多个数据库、遗留系统和通信子系统进行交互，TP监视器可以协调这些访问并实现事务的ACID属性。TP监视器将每个子系统视为一个资源管理器，通过一组事务原语（如begin_transaction、commit_transaction等）与资源管理器进行交互。许多数据库系统支持X/Open标准，可以作为资源管理器与TP监视器连接。

TP监视器还可以用于管理复杂的客户端 - 服务器系统，包括协调检查点和系统关闭、提供安全和身份验证、管理服务器组以及控制故障范围。在复制数据库系统中，TP监视器可以隐藏数据库故障，将事务请求路由到备份站点。

2. 事务工作流

2.1 工作流的概念

工作流是一种多个处理实体协调执行多个任务的活动。任务可以通过多种方式定义，处理实体可以是人员或软件系统。常见的工作流示例包括电子邮件系统、贷款处理、费用报销处理等。

2.2 工作流的规范

工作流的规范可以分为静态和动态两种：
- 静态规范 ：在工作流执行之前定义任务及其依赖关系，例如费用报销的审批流程。
- 动态规范 ：任务的执行取决于其他任务的执行状态、结果或外部事件，例如电子邮件的路由。

2.3 工作流的原子性要求

工作流的设计者可以根据工作流的语义指定故障时的原子性要求。工作流的执行结果可以分为可接受的终止状态（包括提交和中止）和不可接受的终止状态。系统必须确保工作流在故障时达到可接受的终止状态。

2.4 工作流的执行

工作流的执行可以由人工协调器或工作流管理系统控制。工作流管理系统包括调度器、任务代理和系统状态查询机制。调度器负责处理工作流，将任务分配给任务代理，并确保任务达到可接受的终止状态。

工作流管理系统的架构可以分为集中式、部分分布式和完全分布式三种：
- 集中式架构 ：一个调度器负责所有并发工作流的任务调度。
- 部分分布式架构 ：每个工作流有一个调度器。
- 完全分布式架构 ：没有调度器，任务代理通过通信协调执行。

2.5 工作流的恢复

工作流恢复的目标是确保工作流在故障时达到可接受的终止状态。恢复过程需要恢复调度器的状态信息，并确保消息传递的准确性。持久消息传递可以确保任务的准确传递。

2.6 工作流管理系统

工作流通常作为应用系统的一部分手动编码，而工作流管理系统的目标是简化工作流的构建并提高其可靠性。市面上有许多商业工作流管理系统，包括通用系统和特定工作流系统。工作流管理联盟（Workflow Management Coalition）已经开发了工作流系统之间的互操作性标准。

以下是一个简单的工作流示例：

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A([开始]):::startend --> B(提交贷款申请):::process
    B --> C(贷款专员审核):::process
    C --> D{审核通过?}:::process
    D -->|是| E(高级员工批准):::process
    D -->|否| F(拒绝申请):::process
    E --> G(发放贷款):::process
    F --> H([结束]):::startend
    G --> H

3. 主内存数据库

3.1 主内存数据库的优势与限制

为了实现高事务处理速度，需要使用高性能硬件和并行处理技术。然而，磁盘I/O操作仍然是提高响应时间的瓶颈。主内存数据库通过增加数据库中间内存的大小，减少对磁盘的依赖，从而提高事务处理速度。

主内存数据库的优势包括：
- 快速处理 ：数据驻留在内存中，减少了磁盘I/O时间。
- 优化机会 ：可以设计更高效的数据结构，减少内存使用。

但主内存数据库也存在一些限制：
- 日志记录瓶颈 ：在提交事务之前，需要将历史记录写入稳定存储，这可能成为瓶颈。
- 磁盘写入需求 ：需要将修改的中间内存块写入磁盘，以减少恢复时需要重新执行的历史记录数量。
- 系统故障恢复 ：系统故障时，主内存数据丢失，恢复后需要重新加载数据。

3.2 主内存数据库的优化

主内存数据库可以通过以下方式进行优化：
- 数据结构设计 ：设计内部数据结构以减少内存需求，同时允许指针跨越多个页面。
- 页面锁定优化 ：不需要在访问数据之前锁定中间内存页面。
- 处理技术优化 ：设计处理技术以最小化空间开销，避免分页。
- 并发控制优化 ：消除磁盘I/O瓶颈后，需要优化锁定和闩锁操作。
- 恢复算法优化 ：由于很少需要删除页面，恢复算法可以得到优化。

3.3 组提交技术

组提交技术是一种减少历史记录开销的方法。系统不是在事务完成时立即提交，而是等待多个事务完成或经过一定时间后，将这些事务作为一个组一起提交。这样可以确保写入稳定存储的历史记录块几乎是满的，平均每个提交的事务减少了输出操作。

以下是主内存数据库的优缺点对比表格：
| 优点 | 缺点 |
| — | — |
| 快速处理事务 | 日志记录可能成为瓶颈 |
| 可设计高效数据结构 | 需要磁盘写入以减少恢复工作量 |
| 减少页面锁定需求 | 系统故障后恢复时间长 |
| 优化处理技术 | |
| 并发控制优化 | |
| 恢复算法优化 | |

4. 实时数据库事务管理

4.1 实时系统的概念

在某些应用中，如工厂管理、交通控制和规划，事务执行的正确性不仅取决于数据库的一致性，还取决于是否满足时间限制。这些系统被称为实时系统，时间限制可分为严格、固定和灵活三种类型。

4.2 实时事务管理的挑战

实时事务管理需要考虑时间限制。并发控制协议可能导致事务等待，从而超过时间限制。事务执行时间的可变性也是一个挑战，特别是当数据存储在磁盘上时，磁盘I/O操作的时间差异很大。因此，实时系统通常使用主内存数据库来减少执行时间的可变性。

4.3 实时数据库的并发控制

研究人员对实时数据库的并发控制进行了大量研究。他们扩展了锁定协议，为时间限制更近的事务分配更高的优先级。乐观并发协议在实时数据库中表现良好，能够减少超过时间限制的情况。

4.4 实时系统的设计挑战

实时系统的设计目标是确保有足够的处理能力来满足时间限制，而不需要过多的硬件资源。然而，由于事务管理导致的执行时间可变性，实现这一目标仍然是一个未解决的问题。

以下是时间限制类型的表格说明：
| 时间限制类型 | 描述 |
| — | — |
| 严格时间限制 | 若任务未在时间限制前完成，可能导致系统故障等严重问题 |
| 固定时间限制 | 任务在时间限制后完成则无价值 |
| 灵活时间限制 | 任务在时间限制后完成价值递减，延迟越大价值越接近零 |

5. 长事务处理

5.1 长事务的特点

长事务通常涉及与人员的交互，具有以下特点：
- 长时间运行 ：由于人员响应时间较慢，事务可能持续很长时间。
- 未提交数据暴露 ：用户可能会看到未提交的数据，并且多个用户之间可能需要在事务提交前交换数据。
- 子任务 ：每个交互式事务可以由多个子任务组成，用户可能希望单独中止子任务。
- 可恢复性 ：系统故障时，长事务应恢复到故障前的状态，以减少人工工作量的损失。
- 性能要求 ：交互式系统的性能要求是快速响应时间，而不是高吞吐量。

5.2 并发控制的挑战

传统的并发控制协议（如两阶段锁定、基于图的协议、时间戳协议和验证协议）在长事务处理中存在问题。这些协议可能导致长时间等待、长事务中止或两者兼而有之。因此，需要考虑替代的并发控制技术，以确保正确性而不要求可串行性。

5.3 嵌套和多级事务

长事务可以被视为一组相关的子事务。嵌套事务或多级事务由一组子事务和一个偏序关系组成。子事务可以独立中止，而不会导致整个事务中止。如果事务是多级事务，子事务完成时可以释放锁定；如果是嵌套事务，子事务的锁定会自动分配给上级事务。

5.4 补偿事务

为了减少长时间等待的频率，未提交的更新可以暴露给其他并发事务。补偿事务用于处理这种情况下可能出现的级联回滚问题。当外部事务需要中止时，补偿事务用于撤销已提交的子事务的影响。

5.5 实现问题

长事务处理的实现面临一些挑战，包括确保事务在系统故障后恢复、处理大型数据元素的日志记录以及减少日志记录的开销。可以使用操作日志记录或影子分页技术来减少大型数据元素的日志记录开销。

以下是传统并发控制协议在长事务处理中的问题列表：
- 两阶段锁定 ：可能导致长时间等待和死锁的可能性增加。
- 基于图的协议 ：可能需要锁定比实际需要更多的数据，并且可能导致长时间锁定。
- 时间戳协议 ：可能导致长事务中止，造成大量工作丢失。
- 验证协议 ：通过中止事务来实现可串行性，可能不适合长事务。

6. 多数据库事务管理

6.1 多数据库系统的概念

多数据库系统创建了一个逻辑集成的数据库环境，其中本地数据库系统可以使用不同的逻辑数据模型、定义和操作语言，以及不同的并发控制和事务管理机制。多数据库系统支持本地事务和全局事务。

6.2 并发控制的挑战

确保每个本地数据库系统的局部可串行性并不足以保证全局可串行性。不同本地数据库系统的并发控制行为可能导致全局调度不可串行。因此，需要额外的机制来确保全局可串行性。

6.3 两级可串行性

两级可串行性（S2N）确保系统在两个级别上的可串行性：每个本地数据库系统确保其本地事务的局部可串行性，多数据库系统确保全局事务之间的可串行性。S2N采用了比可串行性更弱的正确性要求，称为强正确性。

6.4 全局可串行性的保证

可以使用一些方案来确保全局可串行性，例如在每个本地数据库系统中创建一个特殊的数据元素（称为票据），每个全局事务必须写入该票据。这样可以确保全局事务在每个访问的站点上直接冲突，从而可以控制全局事务的顺序。

以下是两级可串行性协议的表格说明：
| 协议名称 | 描述 | 确保强正确性的条件 |
| — | — | — |
| 全局 - 读协议 | 全局事务可以读取本地数据元素，但不能更新；本地事务不能访问全局数据 | 1. 本地事务仅访问本地数据元素
2. 全局事务可以访问全局数据元素并读取本地数据元素
3. 本地和全局数据元素之间无一致性约束 |
| 本地 - 读协议 | 本地事务可以读取全局数据，但不能访问本地数据；引入值依赖概念 | 1. 本地事务可以访问本地数据元素并读取全局数据元素
2. 全局事务仅访问全局数据元素
3. 任何事务都无值依赖 |
| 全局 - 写 - 读/本地 - 读协议 | 全局事务可以读写本地数据，本地事务可以读取全局数据 | 1. 本地事务可以访问本地数据元素并读取全局数据元素
2. 全局事务可以访问全局和本地数据元素
3. 本地和全局数据元素之间无一致性约束
4. 任何事务都无值依赖 |

6.5 总结

高级事务处理涵盖了多个重要领域，包括事务处理监视器、事务工作流、主内存数据库、实时数据库、长事务处理和多数据库事务管理。这些领域各自面临着不同的挑战和问题，需要采用相应的技术和策略来解决。通过合理设计和应用这些技术，可以提高事务处理的性能、可靠性和正确性，满足不同应用场景的需求。

graph LR
    classDef startend fill:#F5EBFF,stroke:#BE8FED,stroke-width:2px;
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px;

    A([开始]):::startend --> B(事务处理监视器):::process
    B --> C(事务工作流):::process
    C --> D(主内存数据库):::process
    D --> E(实时数据库):::process
    E --> F(长事务处理):::process
    F --> G(多数据库事务管理):::process
    G --> H([结束]):::startend

以上总结了高级事务处理的各个方面，展示了它们之间的关系和整体架构。在实际应用中，需要根据具体需求和场景选择合适的技术和方案，以实现高效、可靠的事务处理。