基于IPC机制浅析Tuxedo及其应用

1、基于IPC机制浅析Tuxedo及其应用  摘 要:本文从底层IPC机制出发,结合UNIX核心系统参数和ATMI技术，借用ipcs观察Tuxedo所消耗的IPC系统资源状况，浅析了Tuxedo强大功能背后的工作原理，进一步加深对Tuxedo应用和ATMI编程的理解，提出了并解决实际工作中关键问题的思路和步骤。关键词:进程间通信 共享内存 信号量 消息队列 Tuxedo ATMI一、进程间通信IPC主要工作机制简介（目录）进程间通信IPC (Inter-process communication)是一个Unix标准通讯机制，提供在同一台主机不同进程之间可以互相通讯的方法。 由于

2、它是一种底层技术，因此具备了先天的灵活性。本文所涉及的IPC处理机制有3种：共享内存、信号量和消息队列。1.共享内存共享内存(Shared Memory)是一片指定的物理内存区域，这个区域通常是在存放正常程序数据区域的外面, 它允许两个或多个进程共享一给定的存储区，是针对其他通信机制运行效率较低而设计的。因为数据不需要来回复制，更不需要在客户机和服务器之间复制，进程可以直接读写内存，所以是最快的一种进程间通信机制。为了实现更安全通信，它往往与其它通信机制，如信号量结合使用，来达到进程间的同步及互斥。在Tuxedo中，就是利用这个特性，将共享内存空间变成一种公告牌，用来公告进程状态信息和需要在进

3、程间共享或传递的数据。2.信号量信号量(Semaphore)为那些访问相同资源的进程以及同一进程不同线程之间提供一个同步机制。它不是用于传输数据，而只是简单地协调对共享资源的访问。可以使用ipcs和ipcrm实现对信号量使用状态的查询和删除操作。信号量机制中，有一个概念是信号量组，它将相关信号量创建在同一个信号量组中，这样既便于逻辑上的清晰理解也便于管理。一个信号量必须属于一个信号量组，否则不能被系统所使用。信号量和信号量组，存储于内核系统区域，是随内核持续的，是不会被系统所自动清理的，所以当进程退出前，需要清理进程生成的那些信号量们。信号量可以包含一个增加或减小的值，用以指出什么资源正被访问

4、和访问的次数。它是一个记数器，用于控制多进程对共享数据的存储。一旦成功拥有了一个信号量，对它所能做的只有2种：请求、释放。当执行释放操作时, 系统将把该信号值减1。如果小于0，那就还设为0。而当执行请求操作时，系统将把该信号值加1，如果该值大于设定的最大值，那么系统将挂起你的处理进程，直到其他进程释放到小于最大值为止，这样能够保证多个进程不会造成互锁。3.消息队列消息队列(MessageQueue)是一个结构化的排序内存段表，这个队列是进程存放或检索数据的地方，是一个消息的链表，可以被多个进程所共享，而不管这几个进程是否具有“亲缘”关系。每个消息队列都有一个队列头，用来描述该消息队列的大量信息

5、，包括消息队列键值、用户ID、消息队列中消息数目等等，甚至记录了最近对消息队列读写进程的ID。消息可以看作一个记录，具有特定的格式以及特定的优先级。对消息队列有写权限的进程可以按照一定的规则添加新消息；对消息队列有读权限的进程则可以从消息队列中读走消息。消息队列与信号量一样的，是随内核持续的，只有在内核重起或者显示删除一个消息队列时，该消息队列才会真正被删除。二、IPC在Tuxedo中的使用（目录）1. Tuxedo及核心子系统简介BEA Tuxedo是在企业、Internet这样的分布式运算环境中，开发和管理三层结构的客户/服务器型关键任务应用系统的强有力工具。它具备分布式事务处理和应用通信

6、功能，并提供完善的各种服务来建立、运行和管理关键任务应用系统。它提供了一个开放的环境，支持各种各样的客户、数据库、网络、遗留系统和通讯方式，使得开发人员能够利用它建立跨硬件平台、数据库和操作系统的交互应用系统。Tuxedo的应用程序是以业务逻辑服务、由这些逻辑服务组织成的高层服务器组件和在服务器结点环境中的组件分布为特征的。支持这种虚拟主机环境的Tuxedo元素，包括配置信息库和实现运行时应用管理的核心子系统。限于篇幅的限制，这里只对核心子系统作简单介绍。1.1公告牌Tuxedo应用配置文件被映射到一个运行时数据结构:公告牌（BB）。BB 作为一个从配置文件中派生出来的共享信息库，驻留在每个参

7、与到由配置文件指定的应用程序的Tuxedo的服务器结点上。BB不仅作为分布式应用的名字服务数据库，提供分布式环境下的应用对象的位置信息，还作为应用统计数据的运行时仓库。BB由Tuxedo核心例程（对应用开发者透明）访问，由核心例程读/修改BB库。这个信息库提供Tuxedo完成动态客户/服务器映射所需的信息，同时也提供完成诸如负载平衡、 安全性和事务协调等功能的信息。1.2 事务管理器事务管理器既是Tuxedo 体系结构的中心，也是每个Tuxedo服务器的核心 ，提供重要的分布式应用服务、命名、 消息路由、 负载平衡、配置管理、事务管理和安全性。它也包含BB结构，使用维护和访问BB信息的服务。换

8、句话说，BB内包含有执行和管理大规模的基于组件的应用程序所需的所有信息，它将对事务管理器进程起作用。图1显示了事务管理器的基本操作，客户请求 到达驻留在服务器上的客户代理进程 ，服务器通过注册参加到该应用中。作为客户方通讯的一部分，事务管理器访问BB，然后选择服务器，接着，服务器消息队列的地址被返回，客户方的请求被马上传送到合适的队列等待服务为它进行处理。图1： 事务管理器工作流程示意图1.3 工作站工作站把Tuxedo ATMI API扩展到客户应用程序中，使得平台透明化。使用ATMI的客户端程序，可以访问在Tuxedo分布式环境中任何地方的服务。一个多路网关进程，称为工作站处理进程（WSL

9、），驻留在Tuxedo应用服务器上，配合Workstation Handler(WSH)，处理工作站客户和事务管理器应用服务之间的通讯。工作站处理进程把来自大量客户应用程序的请求，会聚到Tuxedo事务管理器，以便完成所管辖的服务。1.4 服务器及其队列Tuxedo提供了一个简单的可选机制，用于给应用请求和回答进行进队和出队。 Tuxedo队列服务使下列应用变得可能：工作流应用 提交和完成要求确保完成的事务 提交时间敏感型请求 与Tuxedo MIB和GUI的集成 出队请求的事务控制 利用简单的服务镜向和数据镜向进行软件容错2.影响Tuxedo IPC的系统参数在UNIX系统，Tuxedo大量

10、使用IPC资源，然而通常系统默认的参数值远远低于Tuxedo应用程序的要求。因此，在安装Tuxedo应用程序前,必须合理地设置其参数值。这不仅决定应用程序能否正常操作，还将影响日后投入运行时的性能。以下就是系统V影响Tuxedo IPC资源的可调整系统参数。表1. 系统V IPC参数名字描述取值共享内存SHMMAX单个共享内存段的最大尺寸（以字节为单位）越大越好，取决于可分配的系统内存SHMSEG一个进程可用的共享内存段的最大可用数目取决于可分配的系统内存SHMMNI系统范围内允许的共享内存段最多数目取决于可分配的系统内存SHMMIN单个共享内存段的最小尺寸（字节）1信号量SEMMNS系统范围

11、的最大信号量数量至少需满足MAXACCESSERS-MAXWSCLIENTS+13SEMMNI可被创建的信号集的数目通常等于SEMMNSSEMMSL每套信号集允许的最大信号量数量通常等于SEMMNS，因为Tuxedo不直接对信号集，但它对每个信号集分配尽可能多的信号量SEMMAP控制映射表里用于管理信号量的记录数量SEMMNI+2SEMMNUUndo 结构的数目Default 30至少>SEMMNSSEMUMEUndo 结构中记录数量1消息队列MSGTQL系统核心中能够存储的系统消息头的最大数量应足够大MSGMNB消息队列最大尺寸（字节）至少等于MSGMAX，当消息长度大于75%的MSG

12、MNB时，消息将被存到文件中去，这将大大降低总体性能。MSGMAX每条消息的最大尺寸（字节）应足够大来处理应用程序的请求。MSGSEG系统拥有消息段数目取决于可分配的系统内存MSGSSZ每个消息段的尺寸（字节）一条消息可使用多个消息段，取决于可分配的系统内存MSGMNI最多可被创建的消息队列数目至少要大于MAXACCESSERS + 7 +（number of servers with REPLYQ) +（number of MSSQ sets) - （number of servers in MSSQ sets)MSGMAP控制映射表里用于管理消息段的记录数量等于MSGSEG在程序开发的过程

13、中，如果系统参数无法满足最小的要求，就会导致种种奇怪的问题。例如：（1）收到来自shmget的类似“Invalid argument” 这样的错误信息，那么很有可能是超过了当前共享内存SHMMAX的限制；（2）信号量集的最大数目SEMMNI以及系统范围内信号量的最大数目SEMMNS：超过这两个限制将返回ENOSPC错误。在消息队列参数中，MSGTQL，MSGMNB，MSGMAX，MSGSEG，MSGSSZ这五个参数将决定队列空间、队列个数、消息尺寸。从表1中，我们发现UBBCONFIG 文件中的参数：MAXACCESSERS，MAXWSCLIENT影响着IPC资源的使用情况。MAXACCESS

14、ERS： 在本系统的一个节点(一台服务器)上，同时可以访问公告板的进程数。它包括本地客户端进程、SERVER进程、WSL和WSH，但不包括管理进程如:BBL,DBBL等。MAXWSCLLINET：定义了需要在MAXACCESSERS专为远程客户端保留的记录数目。这就可以解释很多初学者遇到的问题，启动失败：因为系统默认的值没有符合最小要求。3.关于Tuxedo IPC资源的实验和观察为加深对IPC资源和Tuxedo的了解，笔者借助UNIX命令ipcs等对多个实验作出的观察。研究平台配置如下：操作系统：HP-UNIX 11i：数据库数目：Oracle, 3个服务程序：40个Service数目：12

15、75种IPCKEY值：34268PERM值：0666 客户端类型：Workstation Client编程接口：ATMI3.1 关于共享内存的实验devt/tuxedo/appdir> ipcs -am |grep tuxedoIPC status from /dev/kmem as of Fri Oct 15 17:46:05 2004Shared Memory:T ID KEY MODE OWNER GROUP CREATOR CGROUP NATTCH SEGSZ CPID LPID ATIME DTIME CTIMEm 12311 0x000085dc -rw-rw-r

16、w- tuxedo gtux tuxedo gtux 42 2835444 8041 2090 11:26:36 11:29:21 14:03:10m 16408 0x00000000 -rw- tuxedo gtux tuxedo gtux 2 352 8176 8325 14:04:16 no-entry 14:03:41 devt/tuxedo/appdir> ps -efx |egrep "8041|2090"tuxedo 8041 1 0 Oct 14 ? 0:04 BBL -C dom=KFX -g 30002 -i 0 -u devt -U /tuxed

17、o/appdir/log/ULOG -m 0 -Atuxedo 22733 1362 0 17:22:04 pts/tv 0:00 egrep 8041|2090devt/tuxedo/appdir> ps -efx |egrep "8176|8325"|grep ?v grep tuxedo 8325 8176 0 Oct 14 ? 0:00 WSH -c 11 -d /dev/tcp -i 0 -s 16408 -p 2048 -P 65535tuxedo 8176 1 0 Oct 14 ? 0:02 WSL -C dom=KFX -g 8 -

18、i 705 -u devt -U /tuxedo/appdir/log/ULOG -m 0 -e/tuxedo/appdir/log/WSL.err -o /tuxedo/appdir/log/WSL.out -A -r - -d /dev/tcp -n /devt:5035devt/tuxedo/appdir> ps -ef |grep tuxedo |grep -v grep |grep 8176tuxedo 8325 8176 0 Oct 14 ? 0:00 WSH -c 11 -d /dev/tcp -i 0 -s 16408 -p 2048 -P 65535tuxedo 817

19、6 1 0 Oct 14 ? 0:02 WSL -C dom=KFX -g 8 -i 705 -u devt -U /tuxedo/ap从上述实验中，不难观察到：（1）CPID指出了这两个共享内存的所有者是：公告牌和WSL进程。WSH并不创建共享内存。（2）LPID指出了最后一次访问WSL的共享内存段的是WSH。（3）共享内存Id不是固定得,每次由系统分配指定。但BB公告牌的共享内存的十六进制KEY值x000085dc 转换成十进制，就是UBBCONFIG中设定的IPCKEY值34268，（4）注意到公告牌和WSL进程的访问模式是不同的。BB的访问模式等于与UBBCONFIG中PERM的值06

20、66。3.2关于信号量的实验devt/tuxedo/appdir> ipcs ?as |grep tuxedo |grep -v grepIPC status from /dev/kmem as of Fri Oct 15 17:46:21 2004T ID KEY MODE OWNER GROUP CREATOR CGROUP NSEMS OTIME CTIME Semaphores:s 60035 0x000085dc -ra-ra-ra- tuxedo gtux tuxedo gtux 3 17:49:50 14:03:10s 140036 0x00000000 -ra-

21、ra-ra- tuxedo gtux tuxedo gtux 816 no-entry 14:03:10从上述实验中，不难观察到：（1）有两个信号集，其中一个KEY值是公告牌的。（2）在两个信号集内，分别容纳了3和816个信号量。（3）最后一次对ID 为60035信号集中的信号量的操作时间是17:49:50。另从从创建的时间和访问模式都一样来推测，另一个信号集也是属于BB的。它们的具体作用有待进一步深入研究。3.3关于消息队列的实验3.3.1 实验1：关于应用程序的队列devt/tuxedo/appdir> ipcs ?aq |grep tuxedo |grep -v grepIPC s

22、tatus from /dev/kmem as of Fri Oct 15 18:07:04 2004T ID KEY MODE OWNER GROUP CREATOR CGROUP CBYTES QNUM QBYTES LSPID LRPID STIME RTIME CTIME Message Queues:q 12556 0x00000000 -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8151 8325 13:54:27 13:54:27 14:04:16q 10523 0x000085dc -Rrw-rw-rw- tuxed

23、o gtux tuxedo gtux 0 0 1048560 8163 8041 16:48:06 16:48:06 14:03:13q 6430 0x00000000 -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8151 8043 13:54:21 13:54:21 14:03:13q 6431 0x00000000 -rw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8041 8042 14:03:13 14:03:13 14:03:13q 4395 0x00000000 -rw-rw-rw- t

24、uxedo gtux tuxedo gtux 0 0 1048560 8041 8050 14:03:15 14:03:15 14:03:15q 2563 0x00000000 -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8151 8162 10:48:07 10:48:07 14:03:36q 6666 0x00000000 -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 8165 8172 14:16:36 14:16:36 14:03:39q 2571 0x00000000 -rw-rw-

25、rw- tuxedo gtux tuxedo gtux 0 0 1048560 8160 8172 14:16:36 14:16:36 14:03:39q 2643 0x00000000 -rw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 0 0 no-entry no-entry 14:03:41*共70个队列，限于篇幅不一一列出从上述实验中，不难观察到：（1）对于多服务器单队列的服务器（MSSQ），都有一个队列用来接收请求，访问模式为-rw-rw-rw- 。另一个队列用来回复，访问模式为-Rrw-rw-rw-。（2）KEY值：只有一个是属于公告牌的

26、（值为0x000085dc），其余都为0x00000000。（3）ipcs告诉我们更多关于消息队列的信息：所有者、创建者、创建者组别、消息队列字节数、正在排队的消息数、队列的最大字节容量、最近一次的发送者和接收者以及时间和创建时间。（4）另逐个shudown服务程序，经比较发现：对于每个资源上的事务管理器，每个进程都有自己独立的请求队列，但回复队列只有一个。3.3.2 实验2：关于tmadmin会话的队列devt/tuxedo/appdir/temp> ipcs -aq |grep tuxedo |wc -l70devt/tuxedo/appdir/temp> ipcs -aq |

27、grep tuxedo >ipcs_q_noclient.txt#在另一个SHELL开了一个tmadmin进程devt/tuxedo/appdir/temp> ipcs -aq |grep tuxedo |wc -l 71devt/tuxedo/appdir/temp> ipcs -aq |grep tuxedo >ipcs_q_1client.txt devt/tuxedo/appdir/temp> diff ipcs_q_noclient.txt ipcs_q_1client.txt1c1,2< q 18700 0x000085dc

28、-Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 427 371 20:07:38 20:07:38 20:07:15-> q 24676 0x00000000 -rw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 371 14981 16:11:54 16:11:54 16:11:42> q 18700 0x000085dc -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 14981 371 16:11:54 16:11:54 20:07:15de

29、vt/tuxedo/appdir/temp> grep 24676 ipcs_q_noclient.txt |wc -l0devt/tuxedo/appdir/temp> ipcs -aq |grep tuxedo |wc -l 71#退出tmadmin进程devt/tuxedo/appdir/temp> ipcs -aq |grep tuxedo |wc -l70此实验告诉我们，针对每个新的tmadmin会话，Tuxedo都会为它创建一个新的消息队列。此实验中，ID为24676就是为tmadmin会话创建的。3.3.3 实验3：关于WSL/WSH的队列在本地Win

30、dows PC，开启一个远程客户端程序后。devt/tuxedo/appdir/temp> ipcs -aq |grep tuxedo |wc ?l71devt/tuxedo/appdir/temp> tmadmin> pcltLMID User Name Client Name Time Status Bgn/Cmmt/Abrt- - - - - -FX tuxedo WSH 0:04:28 IDLE 0/0/0FX tuxedo tmadmin 0:00:01 IDLE 0/0/0> quitdevt/tuxedo/appdir/temp> ipcs -aq

31、|grep tuxedo |wc -l71devt/tuxedo/appdir/temp> ipcs -aq |grep tuxedo > pcs_q_feclient.txtdevt/tuxedo/appdir/temp> diff ipcs_q_noclient.txt ipcs_q_feclient.txt1c1,2< q 18700 0x000085dc -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 427 371 20:07:38 20:07:38 20:07:15-> q 26724 0x0000000

32、0 -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 414 15288 16:21:27 16:21:27 16:21:08> q 18700 0x000085dc -Rrw-rw-rw- tuxedo gtux tuxedo gtux 0 0 1048560 15133 371 16:16:32 16:16:32 20:07:15此实验告诉我们，除了WSL本身有自己的回复队列，针对每个新的WSH，Tuxedo都会为它创建一个新的回复消息队列。此实验中，WSH的消息队列ID为24724。因为在0个远程客户端接入之前，WSL是不会自动启动WS

33、H。在这之后的另一个实验是将WSL关闭之后,发现WSL和WSH的消息队列同时，跟着进程的关闭而关闭。3.4 关于PERM的实验上述3个实验中，UBBCONFIG中*RESOURCES段的PERM值为0666，*SERVERS段的RQPERM和RPPERM均为0666。将*RESOURCES段的PERM改为将PERM 设为0660后，重新创建TUXCONFIG。devt/tuxedo/appdir/log> ipcs -as|grep tuxedos 80035 0x000085dc -ra-ra- tuxedo gtux tuxedo gtux 3 19:58:13 19:51:10s

34、180036 0x00000000 -ra-ra- tuxedo gtux tuxedo gtux 816 no-entry 19:51:10devt/tuxedo/appdir/log> ipcs -am|grep tuxedom 16407 0x000085dc -rw-rw- tuxedo gtux tuxedo gtux 43 2835444 28873 28932 19:51:53 no-entry 19:51:10m 20504 0x00000000 -rw- tuxedo gtux tuxedo gtux 1 352 28922 28922 19:51:39 no-entr

35、y 19:51:39从此实验中，观察到除了*SERVERS段中另有制定访问模式外，共享内存和信号量均使用*RESOURCES中的PERM值。4. 关于ATMI的理解Tuxedo提供了一个基于C语言的编程接口，即应用程序事务监控接口ATMI，这套接口使得创建Tuxedo的客户程序与在C和C+编程语言中创建其它应用程序一样容易，方便了开发客户程序和服务程序。4.1 ATMI简介4.1.1 客户程序的任务客户程序一般执行如下任务： 调用tpchkauth()决定加入一个应用程序所需的安全级别。 调用tpinit()来连接到一个Tuxedo应用程序，所需的安全信息作为tpinit()的参数传给了应用程

36、序； 执行服务请求；调用tpterm()来断开和Tuxedo应用程序的连接。图2： 客户程序的工作流程4.1.2 服务程序的任务尽管开发者使用ATMI编程接口来创建Tuxedo客户程序和服务程序，但服务程序不全部由开发者来编写，开发者只需写一些称为服务的商业逻辑函数，然后和Tuxedo的一些二进制程序，联合编译成一个可执行的服务程序。其任务包括： 在Tuxedo服务程序启动时，执行tpsvrinit()函数，可以在里面打开一些如数据库之类的资源供以后使用； 在Tuxedo服务程序关闭时，执行tpsvrdone()函数，可以在里面关闭tpsvrinit()中打开的资料； Tuxedo服务程序以服

37、务的形式来响应客户程序的请求，客户程序不是通过名字来调用服务程序的，而是调用服务，客户程序不知道处理它请求的服务程序的位置；服务程序调用tpreturn()函数来结束服务请求，并返回一个缓冲区，必要时，将它传给客户程序；图3： 服务程序的工作流程 4.1.3 类型缓冲区在Tuxedo系统中的所有通信过程都是通过类型缓冲区来完成的，Tuxedo系统提供了大量的类型缓冲区来供开发者使用。所有类型缓冲区都必须通过Tuxedo的tpalloc(), tprealloc(), tpfree()这些ATMI来分配回收，它们都有特定的头部。4.1.4 通信模式在和客户端程序的通信过程中，Tuxed

38、o系统提供多达9种的多种通信模式，其中包括基于队列的通信和基于事务的通信。4.1.5 事务要使用事务，应用程序开发者需要使用如下ATMI函数： tpbegin()，用于开始一个事务； tpcommit()，开始一个二阶段提交处理； tpabort()，产即终止事务。在下面的例子中，客户程序打开了一个事务，请求了两个服务，并且提交了事务。因为服务请求是在事务开始和提交之间完成的，所以两个服务的行为都被了事务记录。图4： 事务流程图4.2 对ATMI的理解从上面对ATMI的简介，笔者认为Tuxedo通过ATMI，实质上是对IPC资源本身API的再次封装，从而提供了更高一层的API以建立分布式应用组

39、件，包括服务程序、客户程序和事务管理器等。这些组件在执行时以消息相互通讯，由Tuxedo的内部服务机制统一管理。这些服务机制实现了复杂的分布式事务控制和广泛的分布式应用管理。而在通信过程中，所有的过程都是通过类型缓冲区来完成的。这实际上就是对消息队列的操作，从而获得相应的IPC资源。统一定义的类型缓冲区、更高一层的API，使得它们在跨越不同网络、不同协议、不同CPU构架以及不同操作系统之间，得到统一的处理。在加上编译程序builderserver和builderclient的再次封装，开发者在分布式计算环境中，完全可以有效地避开了异构网络和异构计算机系统带来的差异，而把精力集中在商业逻辑的开发上。通过调用ATMI的API，开发基于ATMI的客户端程序，编写普通的c程序相当。理解了这些含义，我们可以理直气壮地说：ATMI已经超越了字面上“监控接口”的含义，它是一种高度封装的Tuxedo 应用编程接口。它是一个真正的事务处理和消息传递中间件。下图有助于我们更好地理解整个体系架构。图5： Tuxedo体系架构5. Tuxedo与IPC的关系从上文对IPC资源的介绍中，我们知道了Tuxedo应用程序的工作原理。然而这些底层技术的背后，是离不开复杂的数据结构和API。下表是笔者将IPC资源及其数据结构和API、核心