高级事务处理：概念与技术解析

# 高级事务处理：概念、架构与应用 ## 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 工作流管理系统 工作流通常作为