Tuxedo 初学必知

  Tuxedo学习摘记 收藏
Tuxedo Summary

1. 强大的C/S通信功能

       不仅支持请求/应答，还支持保持交易状态的会话模式、基于发布/订阅的事件代理模式、基于消息通知的单播/多播模式、基于消息队列的可靠消息存储和转发方式

2. 强大的联机交易功能

       通信传输的只是较少的客户请求服务名和服务结果，不再是大量繁琐的SQL请求应答，有异步RPC机制实现扇出并行、利用MSSQ实现多处理并行、利用转发机制实现流水线并行

3. 强大的分布式协调能力

       作为一个TP Monitor，Tuxedo使用全局事务跟踪参与者，使用两阶段提交来协调完成事务

4. 完善的负载均衡机制

       Tuxedo支持主机级和系统级的负载均衡，使得更多的请求被发送到计算能力较强的计算机上，默认会自动的负载均衡，也可以通过配置负载因子来干预调度。

5. 数据依赖路由

       数据依赖路由根据请求缓冲区中指定字段的取值范围，来把请求映射到某服务器组上的负载均衡算法

6. 请求优先权

7. 容错和透明故障迁移

 

ATMI的消息通信方式

Tuxedo使用IPC消息队列来实现请求/应答式通信，消息队列是面向无连接通信的关键技术，Tuxedo系统会给每一个服务进程分配一个IPC消息队列，称为请求队列，给每个客户机分配一个响应队列，这样客户机和服务器之间就不需要建立通信连接，客户机把请求消息放入服务器的请求队列中，然后从自己的响应队列中检查响应结果。

 

在ATMI编程环境中，客户机和服务器之间使用消息缓冲区来进行数据交换，由于ATMI消息缓冲区具有格式化和自描述的特点，因此又称之为类型缓冲区(Typed Buffers)，类型缓冲区克服了平台差异，为不同系统下的数据表示提供了一个统一的展现

 

Tuxedo客户机使用tpalloc()分配一个请求缓冲区，然后往里面放入请求消息，在执行tpcall()去调用一个服务，客户机Tuxedo系统会根据tpcall()指定的服务名称进行命名映射(name mapping)，找出实现这个服务的后台进程IPC消息队列入口，然后进行类型判别(type validation)，以检查请求消息和缓冲区是否符合服务参数的要求，如果符合，就从Tuxedo服务器的运行时系统中取出服务的优先级，并把它绑定到请求消息上(service prioritization)。

 

在数据依赖路由处理中，客户机Tuxedo系统根据路由标准决定把请求消息发送到哪一个后台进程IPC消息队列，客户机系统接下来还可以对请求消息进行编码、压缩、事务上下文设置、安全设置等。这种无连接的通信不仅减少了建立连接的额外开销，还提高了网络的使用效率

 

Tuxedo大量使用了操作系统的IPC资源，UNIX System V提供了3类IPC资源：消息队列(MSG)、共享内存(SHM)和信号量(SEM)，只有极少数操作系统如AIX的IPC资源是自适应的，不需要手工进行调整。

 

编译Server端和Client端

buildserver [-s {@ filename|service [,service…] [:func]|:func}] [-v] [-o outfile] [-f firstfiles] [-l lastfiles] [{-r|-g} rmname] [-k] [-t]

buildclient [-v] [{-r rmname | -w}] [-o name] [-f firstfiles] [-l lastfiles]

 

工作站客户端(WorkStation)

工作站客户端通过WSNADDR环境变量连接到WSL，再有WLS分配WSH作为请求代理来调度服务，决定客户机是哪一种类型是在链接时不是在设计时决定的，链接了TUXEDO本地库(libtux.lib)生成的就是本地客户端，链接了W/S库(libwsc.lib以及wtuxws32.lib)生成的客户端就是工作站客户端，编译时加上-w选项就可以指示编译器链接/WS库。

 

WSL是Tuxedo系统提供的工作站监听服务器，在应用程序启动时，它开始监听服务器上的某个端口，并根据配置指令自动启动若干个WSH，形成(WSH Pool)，当客户机执行链接服务器时，WSL从WSH Pool中取出一个负载最小的WSH，并把客户机请求放到它的请求队列中，WSH代表客户机负责把请求放到服务器的请求队列中，服务器处理完成请求之后，把响应结果传给WSH，WSH再把它返回给客户机。Tuxedo会根据配置指令和并发压力的大小，动态调整WSH Pool中WSH进程数量

 

类型缓冲区是一块格式化了的内存区域，它是Tuxedo分布式应用程序之间交互数据的一种渠道。

Buffer Type
 描述
 长度
 编码
 DDR
 效率
 
CARRAY
 字符数组，NULL字符有效
 定长
 不支持
 不支持
 高
 
STRING
 同CARRAY，但NULL字符被认为是字符串的结尾，在不同字符集的主机间转换会自动进行数据转换
 变长
 不支持
 不支持
 高
 
VIEW(32)
 使用C语言的结构组织数据
 定长
 支持
 支持
 高
 
FML(32)
 字段缓冲区，使用字段标识FLDID，出现顺序OC，长度FLDLEN和字段值VAL来标识字段
 变长
 支持
 支持
 一般
 
XML
 使用XML文件作为输入/输出缓冲区
 定长
 支持
 支持
 一般
 
MBSTRING
 同STRING，支持多字节字符集，仅适于8.1以后的版本
 定长
 支持
 不支持
 高
 

 

FML缓冲区：

ATMI Header
 FML Header
 FLDID1
 Values1
 FLDID2
 FLDLEN
 Value2
 Unused space
 Index
 

 

FML字段缓冲区由4个部分组成，ATMI头部信息、FML头部信息、FML字段空间和Index，其中ATMI和FML头部长度是固定的，与TCP报文头部类似，起到控制缓冲区传输访问的作用，Index字段则保存了FLDID的索引，便于快速访问字段值。FML缓冲区的变长的，当使用tpalloc()分配时，如果不指定长度，默认分配大小是1024KB。

 

FML缓冲数据只能通过FML函数来读取，Tuxedo支持的FML函数在fml.h和fml32.h中定义，在FML描述文件中，每个字段都有一个Number编号，编译器将使用这个编号来生成相应的FLDID值。

 

FML缓冲区具有灵活性强，可扩展性好，效率高的特点。在FML缓冲区中同一个字段重复出现多次，当添加一个新字段时，不需要重新修改现有的应用程序，在网络传输中，无效或空值字段将被忽略。FML缺点是难以使用，在实际编程中客户机可以使用VIEW缓冲区接收用户输入，然后转换成FML，通过网络传输到服务器端，再把FML转换成VIEW

 

Tuxedo8.1之后通过使用MBSTRING缓冲区对中、日、韩等其他亚洲语种提供多字节的支持，这就有效避免了以往必须把这些多字集字符串包装到CARRAY缓冲区的做法。

Tuxedo系统通信方式

n      请求/应答方式

       同步调用

       异步调用

       嵌套调用

       转发调用

n      会话通信方式 (唯一支持的有状态通信方式，半双工模式即同一时刻只有一方具有控制权)

n      消息通告方式 (4种通知检测方式：DIPIN、SIGNAL、THREAD、IGNORE)

n      事件代理方式 (通过EventBroker服务器来实现)

n      队列通信方式 (TUXEDO/Q)

 

Tuxedo事务规范

DTP（Distributed Transaction Processing）分布式事务处理，指的是在分布式式计算中，管理和协调多个用户和多个数据库等共享资源之间的交互过程，DTP是TP的一种形式，它的工作流程如下：

1)      AP通过TM提供的TX接口向TM发出请求，以开始一个全局事务，这时TM会分配一个GTRID来对这个事务进行标识

2)      AP在事务上下文中使用ESQL来访问RM，以处理业务逻辑

3)      TM与每一个参与全局事务的RM交换事务信息，当收到AP发出的结束事务指令时，TM会通过XA接口向各个RM发出指令，并通过两阶段提交协议来结束全局事务

注：AP-Application Program        TM-Transaction Manager     RM-Resource Manager

其中TX接口规范为AP和TM之间定义了通信接口，由TM实现，供AP调用；而XA接口是RM和TM之间的双向接口，由RM实现，供TM调用

 

Tuxedo除了支持标准的TX接口之外，还提供了自己一套XATMI接口，用于界定全局事务，可根据编程习惯自行选择，但不能混合使用。

 

系统管理员必须为每一种用到的RM创建专用的TMS，以便在UBBCONFIG中配置使用，buildtms命令用于创建TMS，它需要从一个名为RM的文件中读取RM信息，包括RM名、XA Switch名以及XA支持库，RM文件位于udataobj下，格式如下(分三段)：

RM_NAME: XA_SWITCH_NAME: XA_LIBS

TMS使用TLOG记录事务日志以便恢复全局事务，每台Tuxedo主机上只需创建一个TLOG文件，被所有TMS共享使用，如果一个全局事务还没有完成，那么它在TLOG文件中将占用一个分页的空间即512KB，全局事务完成之后，在TLOG记录中的记录将被自动删除。

 

TUXEDO/SQL是Tuxedo自带的一个演示数据库系统，支持XA，可以和Tuxedo的事务系统很好的协同工作，使用一个VTOC(Volume table of Contents)磁盘设备来存储数据，VTOC是Tuxedo一种通用的文件格式，它按照磁盘分页来保存数据，除了TUXEDO/SQL之外，还有TUXCONFIG、BDMCONFIG和TLOG也会使用它来保存数据。

 

TUXEDO/Q是Tuxedo的一个重要的子系统，它为分布式联机事务处理应用程序提供了一种准实时的异步通信方式，支持持久和非持久的消息存储机制，提供面向事务的消息存取和转发机制，以及多样化的出队机制。TUXEDO/Q由队列空间、队列管理服务器、转发服务器和事务管理服务器组成，它为每一个消息提供了一个控制块，以便TUXEDO/Q和应用程序对消息的传输方式和过程进行控制跟踪。原则：Exactly-Only-Once

 

TMQUEUE是TUXEDO/Q的队列管理器，即RM，Tuxedo为它提供的事务管理器是TMS_QM。在一个VTOC上可以创建多个队列空间，在一个队列空间上又可以创建多个队列。TMQFORWARD的作用类似于EJB2.0规范中的Message Driven Bean。

 

TUXEDO/Q两种通信模式：

1、  点对点通信模式

两个对等实体通过一个独立的消息系统来实现消息的交换，它们发送和接收的都是消息本身，而不再是服务请求应答。点对点通信模式具有离线、异步、松耦合的特点，即使一方离线仍然可以通信。

2、  存储转发模式

对联机交易的有效补充，当网络中断或不可用的时，客户机可以把消息放到一个与服务同名的队列中，让TMQFORWARD去转发调用请求

 

在数据传输方面，Tuxedo只能算一个半成品，简而言之是一个基于消息的短事务交易平台，虽然能够保证单个ATMI调用中把消息可靠的传给对方，但没有为批量数据和大块数据的传输提供成型的解决方案，如数据分割和断电续传等特性

 

Tuxedo 包含了5个主要的安全服务：

n      Authentication（验证）

n      Authorization（授权）

n      Auditing（审计）

n      Link-Level Encryption（LLE链路级加密，BEA有自己私有的）

n      Public Key Security（PKI）

 

除了LLE，其他4个安全服务都可以通过插件接口来外挂用户自定义模块

 

ACL和MANDATORY_ACL可以提供访问授权服务，在ACL模式下未经过授权的资源是可以被任何用户访问的，授权过的资源只能被授予权限的用户访问；在MANDATORY_ACL模式下只有经过授权的资源可以被授权用户访问，其他资源不能被任何用户访问

 

从8.1开始，Tuxedo提供了和BEA WebLogic Server安全集成的解决方案，使得TUXEDO Domain和WebLogic Domain之间可以实现SSO，具体而言，Tuxedo可以利用WebLogic内置的LDAP服务器提供的目录服务来作用户验证

 

多机模式MP应用的启动流程

1)      管理员在Master节点上执行tmboot来启动应用程序【Machine-1】

2)      tmboot在Master上启动DBBL进程【Machine-1】

3)      tmboot在Master上启动BBL进程，并初始化公告板【Machine-1】

4)      tmboot在Master节点上启动BRIDGE进程【Machine-1】

5)      tmboot连接到第一个Non-Master节点上的tlistener监听进程，给它发送一个指令，让它启动BSBRIDGE进程【Machine-2】

6)      BSBRIDGE进程与Master节点上的BRIDGE进程通信，把配置文件的主拷贝从Master节点复制到Non-Master节点【Machine-2】

7)      tmboot给tlistener进程发送一条指令，让它启动BBL进程

8)      tmboot给tlistener进程发送一个指令让它启动BRIDGE进程，当BRIDGE进程启动起来之后，BSBRIDGE进程就会被杀死【Machine-2】

9)      如果没有其他的节点，tmboot就又会从Master节点开始依次启动各个节点上的系统进程(例如WSL、TMQUEUE和TMUSREVT等)和用户进程(例如simpserv等)

 

MP应用程序最常见的故障就是节点分离，节点分离指的是Non-Master节点失去了和Master节点的连接，主要归纳起来无非是几点原因：

n      网络暂时中断

n      Master节点当机

n      Non-Master当机

n      BRIDGE进程崩溃

可以通过ULOG、printnetwork命令、pcl命令、reconnect命令、migm备份迁移等手段解决问题。

 

TDOMAIN网络是基于TCP/IP设计的，进程名是GWTDOMAIN，常用于连接其他TUXEDO域和WebLogic域，每个域都有一个域管理进程DMADM，它管理着域的配置文件BDMCONFIG和网关组，每个组有一个网关管理进程GWADM和一个网关进程GWTDOMAIN，网关进程负责域之间的通信，可以把远程域的服务导入到本地并在BB中公告它们，这样本地客户端就可以调用它们

 

GWADM是运行时网关管理服务器，从DMADM上获取信息，并定期报告Live状态

域网关使用DMTLOG文件记录跨域事务的状态，并在必要时用它来恢复失败的事务，域网关还支持数据压缩，管理员可以通过CMPLIMIT来限制网关访问点的上限阀值

 

多域和多机两种模式的比较——

模式
 管理模式
 适应性
 成本
 
多域
 分散式管理模式，协同处理客户请求，只通过网关交换业务数据，对整体网络的响应要求不高
 可以很容易的满足业务增长添加新的模块
 每个域都需要独立的安装有效的License

每个域的管理程序也会占用并发座席数，域数量越多，占用的也越多
 
多机
 集中式管理，所有的管理工作都是Master上完成，所以主机除了业务数据之外，还需要传递配置文件和管理指令，节点最好不要超过5个，否则整体网络的响应和起停会很慢
 对数据路由、负载均衡、容错的适应性较差，很难满足业务模块的变动和动态增长的需求
 只有Master节点需要安装有效的License