TUXEDO培训

TUXEDO 补充培训资料架构，三层架构， 事务管理， 一、 CS 架构，三层架构，XA 事务管理，TUXEDO 简介传统的 CS 体系结构简介1.1 C/S 结构的数据库应用与 C/S 体系形成对比，传统的数据库应用体系结构，例如基于主机-多终端的系统，或 基于 LAN 上文件服务器运做的多用户系统，数据库是属于应用程序“私有的”，即使它也可 以将数据文件放置在某台机器上供不同的用户共同访问（这种情形，称为“文件服务器”） ， 但所有的操作、规则，都是在一个包罗万象的应用程序内部实现的。

应用程序因此具有最大 的复杂性，即使是原班开发人马，要想对已有功能加以扩充也是很困难的，当数据库稍具复 杂性（比如有稍多相互关联的表与规则） ，其他的人员开发另外的程序共同操作这个数据库 的数据，几乎不具可行性。

C/S 又称 Client/Server 或客户/服务器模式。

服务器通常采用高性能的 PC、工作站或小 型机，并采用大型数据库系统，如 Oracle、Sybase、Informix 或 SQL Server。

客户端需要安 装专用的客户端软件。

最简单的 C/S 体系结构的数据库应用， 由两部分组成， 即客户应用程序和数据库服务器 程序。

二者可分别称为前台程序与后台程序。

运行数据库服务器程序的机器，称为应用服务 器，一旦服务器程序被启动，就随时等待响应客户程序发来的请求；客户程序运行在用户自 己的机器上， 对应于服务器机器， 可称为客户机。

当需要对数据库中的数据进行任何操作时， 客户程序就自动地寻找服务器程序， 并向其发出请求， 服务器程序根据预定的规则作出应答， 送回结果。

在典型的 C/S 数据库应用中，数据的储存管理功能，是由服务器程序独立进行的，并且 通常把那些不同的（不管是已知还是未知的）前台应用所不能违反的规则，在服务器程序中 集中实现，例如访问者的权限，帐号不准重复、必须有客户才能建立定单这样的规则。

所有 这些，对于工作在前台程序上的最终用户，是“透明”的，他们无须过问（通常也无法干涉） 这背后的过程，就可以完成自己的一切工作。

在客户服务器架构的应用中，前台程序可以变 的非常“瘦小”，麻烦的事情，都交给了服务器和网络。

在 C/S 体系的下，数据库真正变成了 公共、专业化的仓库，受到独立的专门管理。

C/S 的优点是能充分发挥客户端ＰＣ的处理能力，很多工作可以在客户端处理后再提交 给服务器。

对应的优点就是客户端响应速度快。

C/S 系统各功能层用户接口 ：表示管理、表示逻辑 业务逻辑 ：应用程序的逻辑/规则 数据管理 ：数据访问逻辑 (SQL) 、数据库管理最基本的C/S模型••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••客户端 模型 Call Service服务 请求服务器端 模型 Process Service应答6缺点主要有以下几个： 缺点主要有以下几个：1、难以维护。

客户端/服务器(Client/Server)结构用户界面、业务逻辑和数据逻辑相互交错， 通常在难以升级或改进，而且经常基于某种专有的协议(通常是某种数据库协议)。

它使得重 用业务逻辑和界面逻辑变得非常困难。

2、难以扩展。

随着系统的升级，系统复杂程度大大增加，难以扩展，另外，它是一个封闭 的系统，很难与其他的应用系统实现互操作。

3、安全性差。

客户端程序可以直接访问数据库，可通过编程语言或数据库提供的工具字接 对数据库进行操作，不安全。

4、性能不好。

客户端字接与数据库建立连接，当有大量的并发用户存在时，会使数据库不 堪重负，性能迅速下降，甚至死机。

二、 XA 事务管理XA 基础在谈到 XA 规范之前， 必须首先了解分布式事务处理 （Distributed Transaction Processing， DTP）的概念。

Transaction，即事务，又称之为交易，指一个程序或程序段，在一个或多个 资源如数据库或文件上为完成某些功能的执行过程的集合。

分布式事务处理是指一个事务可能涉及多个数据库操作， 分布式事务处理的关键是必须 有一种方法可以知道事务在任何地方所做的所有动作， 提交或回滚事务的决定必须产生统一 的结果（全部提交或全部回滚） 。

X/Open 组织（即现在的 Open Group）定义了分布式事务处理模型。

X/Open DTP 模型 （1994） 包括应用程序 （AP） 事务管理器 、 （TM） 资源管理器 、 （RM） 通信资源管理器 、 （CRM） 四部分。

一般，常见的事务管理器（TM）是交易中间件，常见的资源管理器（RM）是数据 库，常见的通信资源管理器（CRM）是消息中间件。

为表述方便起见，在本文中直接以其 常见表现形式进行描述。

通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。

数据库的 事务处理对象是本地事务，而分布式事务处理的对象是全局事务。

所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作， 这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。

对数据库的操 作发生在系统的各处但必须全部被提交或回滚。

此时一个数据库对自己内部所做操作的提交 不仅依赖本身操作是否成功， 还要依赖与全局事务相关的其它数据库的操作是否成功， 如果 任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。

一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个 DTP 环境中， 交易中间件是必需的， 由它通知和协调相关数据库的提交或回滚。

而一个数据库只将其自己 所做的操作（可恢复）影射到全局事务中。

XA 就是 X/Open DTP 定义的交易中间件与数据库之间的接口规范 （即接口函数） 交易 ， 中间件用它来通知数据库事务的开始、结束以及提交、回滚等。

XA 接口函数由数据库厂商 提供。

XA 与两阶段提交协议通常情况下，交易中间件与数据库通过 XA 接口规范，使用两阶段提交来完成一个全 局事务，XA 规范的基础是两阶段提交协议。

在第一阶段，交易中间件请求所有相关数据库准备提交（预提交）各自的事务分支，以 确认是否所有相关数据库都可以提交各自的事务分支。

当某一数据库收到预提交后， 如果可 以提交属于自己的事务分支， 则将自己在该事务分支中所做的操作固定记录下来， 并给交易 中间件一个同意提交的应答， 此时数据库将不能再在该事务分支中加入任何操作， 但此时数 据库并没有真正提交该事务，数据库对共享资源的操作还未释放（处于上锁状态） 。

如果由 于某种原因数据库无法提交属于自己的事务分支， 它将回滚自己的所有操作， 释放对共享资 源上的锁，并返回给交易中间件失败应答。

在第二阶段， 交易中间件审查所有数据库返回的预提交结果， 如所有数据库都可以提交， 交易中间件将要求所有数据库做正式提交， 这样该全局事务被提交。

而如果有任一数据库预 提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚。

以一个全局事务为例， 首先通知交易中间件开始一个全局事务， AP 交易中间件通过 XA 接口函数通知数据库开始事务，然后 AP 可以对数据库管理的资源进行操作，数据库系统记 录事务对本地资源的所有操作。

操作完成后交易中间件通过 XA 接口函数通知数据库操作完 成。

交易中间件负责记录 AP 操作过哪些数据库（事务分支） 。

AP 根据情况通知交易中间件提交该全局事务，交易中间件会通过 XA 接口函数要求各个数据库做预提交，所有数据库返 回成功后要求各个数据库做正式提交，此时一笔全局事务结束。

XA 规范对应用来说，最大好处在于事务的完整性由交易中间件和数据库通过 XA 接口 控制，AP 只需要关注与数据库的应用逻辑的处理，而无需过多关心事务的完整性，应用设 计开发会简化很多。

具体来说，如果没有交易中间件，应用系统需要在程序内部直接通知数据库开始、结束 和提交事务， 当出现异常情况时必须由专门的程序对数据库进行反向操作才能完成回滚。

如 果是有很多事务分支的全局事务，回滚时情况将变得异常复杂。

而使用 XA 接口，则全局事 务的提交是由交易中间件控制， 应用程序只需通知交易中间件提交或回滚事务， 就可以控制 整个事务（可能涉及多个异地的数据库）的全部提交或回滚，应用程序完全不用考虑冲正逻 辑。

两阶段提交协议的一种变例在一个涉及多个数据库的全局事务中， 为保证全局事务的完整性， 由交易中间件控制数 据库做两阶段提交是必要的。

但典型的两阶段提交，对数据库来说事务从开始到结束（提交 或回滚）时间相对较长，在事务处理期间数据库使用的资源（如逻辑日志、各种锁） ，直到 事务结束时才会释放。

因此，使用典型的两阶段提交相对来说会占用更多的资源，在网络条 件不是很好，如低速网、网络颠簸频繁，情况会更为严重。

当一个全局事务只涉及一个数据库时，有一种优化方式，即一阶段提交。

当 AP 通知交 易中间件提交事务时， 交易中间件直接要求数据库提交事务， 省去两阶段提交中的第一阶段， 可以缩短处理一个事务的时间，以提高事务处理的效率。

作为两阶段提交的一种特例，与两 阶段一样，一阶段提交也是标准的。

三、中间件的引入三层架构三层客户机/服务器模式的核心概念是利用交易中间件将应用的业务逻辑、表示逻辑和 数据分为三个不同的处理层。

表示逻辑(客户层)为第一层。

它的主要功能是实现用户交互和 数据表示，为以后的处理收集数据，向第二层的业务逻辑请求调用核心服务处理，并显示处 理结果。

业务逻辑(服务器组件)为中间层。

这些组件由中间件管理，实现核心业务逻辑服 务并将这些服务按名字广播、管理并接受客户的服务请求，向资源管理器提交数据操作，并 将处理结果返回给请求者---客户或其他服务器。

数据(资源管理器)构成模型的第三层。

比如 关系数据库，负责管理应用系统的数据资源，完成数据操作。

服务器组件在完成服务的过程 中通过资源管理器存取它管理的数据，或者说请求资源管理器的数据服务。

什么是中间件中间件（middleware）是基础软件的一大类，属于可复用软件的范畴。

顾名思义，中间 件处于操作系统软件与用户的应用软件的中间。

中间件在操作系统、网络和数据库之上，应 用软件的下层， 总的作用是为处于自己上层的应用软件提供运行与开发的环境， 帮助用户灵 活、高效地开发和集成复杂的应用软件。

在众多关于中间件的定义中，比较普遍被接受的是 IDC 表述的：中间件是一种独立的 系统软件或服务程序， 分布式应用软件借助这种软件在不同的技术之间共享资源， 中间件位 于客户机服务器的操作系统之上，管理计算资源和网络通信。