1 安装 TIBCO Enterprise Message Service

安装 EMS ，需要在主机增加环境变量 TIBCO_HOME ，该变量指定 EMS 的配置文件保存的位置，如果没有该变量，则在安装过程中指定。安装 EMS 有以下三种方式。

可视化安装

控制台安装

Silent 模式安装

1.1 可视化安装

以下步骤介绍可视化安装的步骤：

解压安装介质到某个目录。

运行 TIBCOUniversalInstaller ，出现欢迎界面：

在 Welcome 界面下点击 Next ，出现以下界面：

LicenseAgreement 界面下，点同意， Next ：

Installation Home 界面下，为 TIBCO_HOME 指定环境变量，这个变量表示 ems 软件安装在哪里，点 Next ：

点 Next ：

TIBCO Configuration Directory 界面下，指定配置目录，这个目下保存 ems 运行时的各种配置文件，点 Next ：

TIBCO EMS Service Settings 界面下，选择是否自动启动 ems ，如果选“ Automatic ”，则开机后自动启动 ems 。指定启动 ems 所需的主配置文件所在的位置，点 Next ：

Pre-Install Summary 界面，点 Next ：

安装结束。

1.2 控制台安装

控制台模式安装，与可视化安装没有本质区别，只需运行以下命令

TIBCOUniversalInstaller -console

安装过程中所需指定的变量与可视化安装方式相同。

1.3 Silent 模式安装

Silent 模式安装，与之前两种安装方式也没什么区别，只是将安装过程中需要的参数，放在了 TIBCOUniversalInstaller.silent 文件中，如果需要，可以在安装之前修改 TIBCOUniversalInstaller.silent 文件中的参数，然后再运行以下命令即可

TIBCOUniversalInstaller -silent -V responseFile="myfilename.silent"

注： Linux 下的安装过程与 Windows 下基本相同。

1 概述

1.1 JMS 概述

Java Message Service 1.1 (JMS) 是用于应用程序间消息传输的 Java 框架规范。它是由 SUN 联合其他厂商如 IBM ， TIBCO 等一起制定的，实现了统一的企业应用消息传输接口。

使用消息服务，我们可以更容易的进行企业级应用集成。例如，我们有几个系统，一个是客户管理系统，一个是产品管理系统，还有一个是原材料采购系统。这三个系统，每一个都很重要，但更重要是的，三个系统如何协作，毕竟这才是生产活动的基础。

面向消息的中间件 (Message-oriented-middleware ， MOM) 使我们能够很轻松的将现存的或者新投产的系统集成起来。 JMS 框架不是指某一类中间件，更不是某一款 MOM 中间件产品，而仅仅是一个框架，一个规范，它的存在只是用于指导 MOM 系统的设计和开发。

TIBCO 的 Enterprise Message Service 是一款实现了 JMS 的 MOM （类似的， IBM 的 MQ 也是一款实现了 JMS 的 MOM ）， EMS 同时还可以与 TIBCO 的其他消息服务产品进行集成，比如 TIBCO Rendezvous （ RV ，另外一款强大的消息传输中间件，是 TIBCO 的起家产品，国外运用很广，国内有上交所和新华社在用，为了达到性能最大化，使用的是 UDP 协议）。这里只介绍 JMS 的概念以及 TIBCO EMS

1.2 JMS 消息模型

JMS 的基础是消息的创建和传输。消息一种应用程序间传输信息的结构化数据单元。 JMS 中，将消息的创建者称为 producer ，消息的接受者，称为 consumer 。 TIBCO EMS 服务器，充当消息传输的媒介，保证消息传输到正确的目的地。同时， TIBCO EMS 也提供一些企业级应用的功能，例如 fault-tolerance （故障切换，有的人叫失效备援），消息路由，与其他消息系统互联（如 TIBCO Rendezvous 和 TIBCO SmartSockets ），下图描述了消息的发送、传输和接收。

JMS 支持三种消息模型：

ü 点对点（队列）

ü 发布 / 订阅（主题）

ü 组播（主题）

1.2.1 点对点（队列）

点对点传输消息传输模型中，每个消息只有一个 producer 和一个 consumer 。这种方式的传输，使用 queue （队列）来存储消息。 Producer 将消息发送到 queue ， consumer 从 queue 中将消息收走，然后向 queue 发一个 acknowledgement （确认），表示消息已经收到了。多个 Producer 可以向同一个 queue 发消息，多个 consumer 也可以从同一个 queue 收消息。 Queue 可以被配置为 exclusive （互斥或者排外）模式，这意味着，如果某一个 consumer 正在从某个队列收消息，则此时其他 consumer 不能从该队列收消息，只有等第一个 consumer 断开之后，后来的 consumer 才能从该队列收消息。 Exclusive 模式的队列有时比较有用，例如我们同一时间只允许一个接受者接收消息的场景下。如果队列设置为 Non-Exclusive 模式，那么任意一个 consumer 都能从该队列收消息。无论队列是 Exclusive 还是 Non-Exclusive 模式，某一个消息，只能被一个 consumer 收走。下图描述了一个 non-exclusive 模式队列的消息传输。每个 consumer 接收一个消息，然后向服务器发送一个 acknowledgement ，然后这个消息从队列里被删除，如此，这个消息就不会再被其他 consumer 收走了。

1.2.2 发布 / 订阅（主题）

在发布 / 订阅消息模型中， producer 被叫做 publisher ， consumer 被叫做 subscriber 。多个 publisher 可向同一个 topic 发消息， publisher 发送的某一个消息，可被多个 subscriber 收走。这种消息模型类似于广播，消息通过网络发布出去，感兴趣的接受者会把消息收走。下图描述了发布 / 订阅消息模型。

默认情况下， subscriber 只有连到 topic 上的时候，才会接受消息。如果一个消息被 publisher 发送到 topic 上，而此时，没有 subscriber 与 topic ，则该消息会被自动丢弃。 EMS 服务器上可以创建 durable subscriber （持久化订阅者），以保证即使 subscriber 没有连接到 topic 上，消息仍然会保存在 topic 里，等到 subscriber 连到 topic 之后，消息再被收走。 durable subscriber 与 subscriber 相比，可以认为每个 durable subscriber 在服务器上，有一块内存，用于暂存消息（当然，实际上并非如此）。

1.2.3 多播

多播消息模型允许一个 producer 将一个消息同时发个多个 consumers 。在发布 / 订阅消息模型中， topic 会通过 TCP 协议给每一个 subscriber 发送一份消息的拷贝。而多播模型中， topic 通过 Pragmatic General Multicast (PGM) 协议发送消息。 subscriber 所在的机器上，有一个 daemon ，该守护进程会从 topic 接收消息，再传输给 subscriber 。多播节省了带宽，但是不能确保把消息发送给所有 subscriber 。下图描述了多播传输模型的过程。

1.3 EMS Destination 特点

什么是 Destination ？ EMS 中，服务器上的 queue 和 topic 都是 destination ，翻译为目的地，意思是要向哪个 queue 或者 topic 建立会话。 EMS 允许我们对每个 destination 的属性进行配置，以增强传输功能。

配置每个 destination 的访问权限。

限制每个 destination 可用来保存数据的存储空间。

对发往某个 destination 的流量进行控制。

不同服务器的队列之间配置路由（ route ）。

同一个服务器上的队列之间配置桥（ bridge ）。

将 queue 设置为 Non-Exclusive 或者 Exclusive 模式。

对进出某个 destination 的消息记录日志。

对每个 destination 的持久化存储进行设置。

配置 queue 是否允许 consumer 批量接收消息。

1.4 Client APIs

Java 程序可以使用 javax.jms 来发收消息。这是 JMS 规范的标准接口，可以用来创建连接，设置消息类型，创建 destination ，收发消息等。由于 EMS 实现了 JMS 的标准规范，因此可以在 www. java.sun.com/products/jms/index.html. 查阅资料

EMS 包含几个例子程序，这些例子演示了 EMS 的不同特性，例子代码位于安装目录中 samples 文件夹下，其中包含 TIBCO Rendezvous 连接 TIBCO EMS 服务器的例子。

1.5 Administration

EMS 提供了一整套机制来管理服务器以及服务器中的对象，例如 ConnectionFactories 、 Destinations 等。管理工作可以通过两种方式进行，一种是通过命令行模式的管理控制台，另一种是调用管理 API 。

1.6 安全

为了保证服务器和客户端之间，服务器与服务器之间通信的安全，我们可以在服务器中配置 SSL 认证方式。 SSL 是一个在互联网或者局域网上传输加密数据的协议。 SSL 使用公钥和私钥来加密网络上传输的数据。 EMS 支持以下方式使用 SSL ：

ü 客户端与服务器之间

ü 管理端和服务器之间

ü 管理 API 和服务器之间

ü 存在路由的服务器之间

ü 主备服务器之间

1.7 Fault Tolerance

可以将 EMS 配置为主备模式，来实现故障切换。主机和备机成对的工作，主机接受客户端连接，负责处理消息，当主机发生故障，备机会接管主机的操作变成主机的角色。要使用 EMS 的 Fault Tolerance 特性，必须安装集群文件系统，这是一个限制。

1.8 路由

EMS 提供了在服务器之间路由消息的功能。 topic 的路由可以跨越多跳（并且不能存在回路）， queue 的路由只能跨越一跳。 EMS 的路由存在单点故障，因此高可用方面要求较高的系统，不建议采用路由，此外 ITBCO 号称通过路由实现负载均衡，也是不可靠的，这方面的内容后面会论述。

1.9 Transaction

EMS 提供的事务。类似于 Oracle 的事务，收发多个消息，必须进行提交。

1 消息

1.1 EMS 对 JMS 消息进行的扩展

JMS 规范定义的消息包含消息头，属性，消息体三部分。对消息的消息头和消息体格式 JMS 有详细的规定。而属性是用来存放用户定制的信息，以增强 JMS 的功能。 EMS 对 JMS 进行的一些扩展：

JMS 规定了两种传输模式，持久化传输（ PERSISTENT ）和非持久化传输（ NON_PERSISTENT ）， EMS 又增加了一种叫做可靠传输（ RELIABLE_DELIVERY ）。

通常 Consumer 接收消息之后必须向服务器发送针对消息的确认。我们可以在创建会话时指定回话使用 NO_ACKNOWLEDGE 模式，这样 Consumer 接收消息之后不需要向服务器发送针对消息的确认。此外， EMS 还提供 EXPLICIT_CLIENT_ACKNOWLEDGE 和 EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE 两种消息确认模式，后续章节会有描述。

EMS 扩展了 JMS 中的 MapMessage 和 StreamMessage 格式的消息体，以使 EMS 可以和 TIBCO Rendezvous 和 ActiveEnterprise 进行通信。具体请参见相应章节。

1.2 JMS 消息结构

JMS 规定，消息包含三部分，分别是消息头、属性、消息体。其中消息头是必须的，属性和消息体是可选的。

1.2.1 消息头

消息头包含 JMS 预定义了 10 个项，用以消息的传输。

JMSDestination	消息目的地。
JMSDeliveryMode	传输模式（ NON_PERSISTENT ， PERSISTENT 等）。
JMSExpiration	消息生存时间。单位为毫秒。该值如果为 0 ，则消息永不过期。客户端向服务器创建连接时，会与服务器进行时间同步，以此来保证消息的生存时间在客户端和服务器上是一致的。这里的时间同步，不是指二者的时间一致，二是二者的时间差保持恒定不变。生存时间涉及的问题较多，除非特别需要，否则不建议使用。
JMSPriority	消息优先级。范围是 0-9 ，值越高，优先级越高。
JMSMessageID	消息提供者为每个消息赋予唯一的消息 id 。
JMSTimestamp	一条消息被创建时会有一个时间戳，之后消息被交给 provider 发送，消息最终发出的时间，可能会晚于该时间戳。
JMSCorrelationID	通过这个 id 可以从业务层面，将几条消息关联起来。该项是可选的。例如 A 系统之前曾经发送过一条消息给 B 系统，其 ID 为 xxx ，该消息被 B 系统处理之后， B 系统将 JMSCorrelationID 设置为 xxx 发回 A 系统的队列，此时， A 系统可以通过筛选器指定只接受 JMSCorrelationID 为 xxx 的消息。
JMSReplyTo	消息的回复被发往的目的地。该域是可选的。
JMSType	消息类型标识。
JMSRedelivered	如果本域有值，则表示该消息因为某种原因，被多次接收。

1.2.2 属性

在属性部分，我们可以存在自己的信息。 JMS 规范规定了一些属性项，都是以 JMS_TIBCO 开头。无论是 JMS 预定义的属性，还是我们自己定义的属性，所有的属性都是选填的，可以空着。

JMS_TIBCO_CM_PUBLISHER	RVCM sender 的名字，该 RVCM sender 从 TIBCO Rendezvous 导入消息。
JMS_TIBCO_CM_SEQUENCE	RVCM 消息的队列号。
JMS_TIBCO_COMPRESS	消息在发送时是否允许被压缩。
JMS_TIBCO_DISABLE_SENDER	消息发送者名字是否出现在消息中。
JMS_TIBCO_IMPORTED	从 Rendezvous or SmartSockets 导入消息时，本域由服务器赋值。
JMS_TIBCO_MSG_EXT	扩展了 MapMessage 和 StreamMessage 消息体的类型以包含自消息和数组。
JMS_TIBCO_MSG_TRACE	消息从 producer 到 consumer 的过程中，是否被跟踪。
JMS_TIBCO_PRESERVE_UNDELIVERED	如果消息必须被移除，该消息是否被放在未传输队列里。
JMS_TIBCO_SENDER	消息发送者名称。
JMS_TIBCO_SS_SENDER	当 ems 服务器从 TIBCO SmartSockets 导入消息时，服务器把 SmartSockets 消息发送者消息头的值放在本域。

Undelivered 消息队列的说明

如果某个消息的生存时间到了，或者该消息的重传次数超过了队列的 maxRedelivery 设置，则该消息就要从队列里删除了。此时，服务器会检查消息的 JMS_TIBCO_PRESERVE_UNDELIVERED 属性，如果属性被设置为 true ，则服务器把这个消息转移到 Undelivered 消息队列 $sys.undelivered 中（这个队列是系统队列，不能被删除）。如果 JMS_TIBCO_PRESERVE_UNDELIVERED 被设置为 false ，那么消息会直接从队列里删除。

使用 undelivered 队列，必须将 JMS_TIBCO_PRESERVE_UNDELIVERED 设置为 true 。这个属性对某一个消息进行设置，不能对某个队列进行设置。我们可以创建一个 consumer 专门接收 undelivered 队列的消息。如果想删除 undelivered 队列的消息，在控制台中执行 purge queue 命令或者调用 administrative API 即可。 undelivered 队列不能创建路由。

Message Sender

当客户端创建一个到服务器的连接时，客户端必须使用一个用户名。队列中 sender_name 和 sender_name_enforced 属性决定消息中 JMS_TIBCO_SENDER 属性是否必须存放用户名。当队列的 sender_name 属性为 true ，而 ender_name_enforced 为 false ，则 producers 可以不提供用户名。 Producers 可以将 JMS_TIBCO_DISABLE_SENDER 设置为 true ，以是消息中不包含用户名，但是如果队列的 sender_name_enforced 为 true ，则服务器会忽略 JMS_TIBCO_DISABLE_SENDER ，用户名必须出现在属性中。

1.2.3 消息体

JMS 的消息，可以有消息体，也可以没有。消息体有下面几种格式：

Message	Message 格式的消息，没有消息体。
TextMessage	字符串格式的消息体
MapMessage	A set of name/value pairs. Name 是字符串对象， value 是 java 的内置类型。
BytesMessage	字节类型消息体。可以用传输二进制数据。
StreamMessage	流类型消息体。
ObjectMessage	可序列化的对象消息体。

消息体的最大长度

EMS 最大支持 512M 的消息体。不过最好别这么干。

1.1 消息优先级

JMS 规范在消息头中定义了个优先级的域，消息发送者可以以此来设置消息的优先级，优先级在 0-9 中取值。 EMS 支持消息优先级（这个域可选），其他厂商的中间件没有都实现。当 consumer 有多个消息需要接收时，先接收优先级高的消息。

1.2 消息传输模式

消息头中的 JMSDeliveryMode 域指定了消息传输模式。对主题和队列这两种 destination ， JMS 支持 PERSISTENT 和 NON_PERSISTENT 两种消息传输模式。 EMS 扩展出第三种传输模式， RELIABLE_DELIVERY 模式。在创建 producer 的时候，可以指定该 producer 发送消息使用的默认的传输模式，也可以在每个消息的消息头中指定该消息通过哪种传输模式发送，此时将忽略 producer 默认的传输模式。

1.2.1 PERSISTENT 模式

当 producer 发送一个 PERSISTENT 消息时， producer 必须等待服务器返回一个确认。消息被持久化到服务器的磁盘上。这种传输模式保证消息能成功的保存到服务器上。然而这种方式也是有代价的，首先消息 producer 到 server ，要经过一个双向的网络传输，其次， server 要先将消息写入磁盘，才向 producer 返回确认，这导致每秒传输的速率降低。

1.2.2 NON_PERSISTENT 模式

当 producer 发送一个 NON_PERSISTENT 消息时，没有将消息写入磁盘的过程，这样可以提高性能。

如果主配置文件中的 authorization 参数设置为 disable ，服务器不会给 producer 返回确认；如果该参数设置为 enable ，默认情况下， producer 会像发送 PERSISTENT 消息时一样等待确认，此时，可以通过 npsend_check_mode 来制定服务器是否给 producer 发送确认。

1.2.3 RELIABLE_DELIVERY 模式

EMS 扩展了一种 RELIABLE_DELIVERY 模式，此时，无论 authorization 是否 enable ，服务器都返回确认，以此提高性能。但这种模式有个缺点，如果 authorization 被设置为 enable ，而 producer 向某个 destination 发送消息失败（也许是因为 destination 写错了，些许访问 destination 的权限不足，或者其他原因），但由于 producer 不会收到任何返回，所以 producer 总是认为发送成功了。所以除非特别需要，一般不建议使用这种方式。

1.1 EMS 如何持久化消息

NON_PERSISTENT 和 RELIABLE_DELIVERY 两种传输模式的消息是不会持久化到磁盘的，只有 PERSISTENT 模式消息才会持久化到磁盘。

1.1.1 队列的持久化

发送到队列的持久化消息，总是被写入磁盘。 consumer 接收到消息之前，一旦服务器挂掉，不用担心，待服务器重启之后， consumer 重新建立连接，仍然能收到消息。

1.1.2 主题的持久化

发送到主题的持久化消息，只有当主题拥有 durable subscriber 或者某个 subscriber 有 fault-tolerant 方式的连接时，消息才会被持久化到磁盘，否则，无论消息本身是否持久化的，服务器都不会将消息写入磁盘。这种方式与 JMS 规范是一致的。一个没有 fault-tolerant 连接的非持久化订阅者，在服务器挂掉之后重新连到 topic 上，它被认为是一个新的订阅者，因此它不会受到服务器挂掉之前的消息。

1.1.3 持久化消息和同步文件存储

当进行持久化时，消息是被异步写入磁盘的。其过程是 producer 向 server 发送持久化消息， server 并不等待写入磁盘的动作结束，就向 producer 返回确认。这样是存在问题的，例如， producer 收到了确认，而此时某个消息正在被写入硬盘，就在这时，服务器挂掉了，这就造成了 producer 认为消息发送成功，而 server 实际上没有保存数据的不一致状态。我们可以强制指定服务器使用同步方式来持久化数据，即只有在数据写入硬盘之后，再向 producer 返回确认。具体如何使用同步方式，后续会有描述。

1.1 多种存储方式

发送到服务器上的消息，被存储到磁盘里， EMS 支持三种 store 方式，分别是文件、数据库和 mstores 方式。默认情况下， EMS 使用文件存储消息，创建 EMS 服务器时，系统有三个默认的用以存储消息的持久化文件。我们可以创建自己的 store （ EMS 中我把 store 称为持久化方式），并且可以将这个 store 与一个数据文件关联，这个数据文件可以放到我们想放的任何位置。关于 store 的配置信息，都保存在 stores.conf 配置文件中。在创建队列是，我们可以为每个队列都指定一个 store 。每种 store 都有自己的属性，例如，文件 store 具有下面三个属性，其他的属性没有列出来，后面会有描述。

ü 预分配磁盘空间

ü 定时 truncate 磁盘空间

ü 持久化是同步的还是异步的

在实际的部署过程中，我们可以按不同需求，为不同的队列指定不同的 store ，例如，为 A 队列指定一个叫做 SA 的 store ，这个 store 采用同步持久化；为 B 队列指定一个叫做 SB 的 store ，这个 store 采用异步持久化；为 C 队列指定一个叫做 SC 的 store ，这个 store 采用数据库 store 。这三个 store 都位于一个 EMS 服务器中，对用户是透明的。

1.1.1 文件 store

EMS 可以使用文件保存消息，我们可以使用服务器默认的三个文件，也可以创建自己的文件。 EMS 服务器会直接将需要持久化的消息，保存到与队列关联的 store 所对应的的文件中去。

1.1.2 mstores

mstores 这种 store ，比较特殊，它的设计，是为了应对发生故障切换时，备机能够立刻启动而准备的。但是这种方式虽然可以是的故障切换可以立即完成，但是在正常使用时，它的性能是非常差的，其传输消息的速度几乎只有文件 store 的百分之一，因此一般不建议使用。后面会有专门内容描述 mstores 的原理，这里不再赘述。

1.1.3 数据库 store

EMS 也可以将消息持久化到数据库中。但是这种方式的 store 性能也非常滴，仅仅比 mstores 好一点，因此实际生产中也不建议使用。后面会有专门的内容描述如何配置数据库 store 。

1.1.4 默认的 store

EMS 定义了三个默认的 store ：

ü $sys.nonfailsafe ，异步持久化方式的 store

ü $sys.failsafe ，同步持久化方式的 store

ü $sys.meta ， EMS 将 durable subscribers 、 fault-tolerant connections 、以及其他的一些元数据的信息，写入到这个 store 中

这三个 store 以及他们关联的数据文件，都是在服务器启动时自动创建的，不需要任何配置的步骤。如果我们将这三个 store 对应文件删掉了，服务器在下次启动时，还是会自动创建。我们可以修改这三个 store 的属性已经更改三个 store 关联的数据文件的位置。

1.1.5 配置 store

下面介绍配置文件 store 和 mstores 的步骤，数据库 store 后面会有专门的介绍。

ü 打开 stores.conf 文件，每个 store 都有唯一的名字。

ü 修改参数。文件 store 有 type 和 file 两个参数。 type 指定 store 的方式必， file 参数指定与该 store 关联的数据文件。另外， store 还有些可选的参数，例如消息是同步持久化还是异步持久化，文件的最小大小， EMS 服务器是否定期的 truncate 数据文件以释放空间。 Mstores 同样也有两个参数 type 和 file 。可选的参数包括 scan interval 等。

ü 为每个队列指定关联的 store ，队列的 store 参数，可以在 topics.conf 和 queues.conf 文件中设置，多个 destination 可以关联到同一个 store 中。

ü 也可以在控制台，通过命令行的方式修改文件 store 的属性。

1.1.6 针对 mstores 的特别说明

如果某个队列的 store 属性被关联到了一个 mstores ，那么它是不能在控制台通过命令行的方式来修改的。必须先停止服务器，然后把 mstores 关联的数据文件删掉，再到 topics.conf 和 queues.conf 文件中，修改队列的 store 属性，最后重启服务器。

Mstores 的方式，其设计初衷，是为了在发生故障切换时，使备机能够立刻启动，而不用像普通的 store 那样，先把持久化到磁盘的数据恢复到备机，然后再使备机处于启动状态。

为了实现这种性能， EMS 服务器必须持续的对已经保存的消息进行镜像， EMS 服务器采用渐进式的方式进行数据镜像，对于已经被接受走的消息、或者已经过期的消息、或者被从控制台 purge 的消息，也采用渐进的方式进行删除。

采用渐进式的方式检查和删除数据，为了防止影响服务器的性能。每次更新数据的数据量，受两个参数的控制，这两个参数都可以在 stores.conf 中进行设置。

默认的参数已经是经过优化的了。然后如果保存在磁盘中的数据量如果很大，这时每次镜像读写数据就会影响服务器的性能了。为了减缓这种影响，可以适当镜像读写的间隔时间。

scan_target_interval 参数，这个参数表示所有的数据被镜像读写一次，所允许的最大间隔时间，也就是说，要求服务器，必须在这个总的时间内，把所有的数据都处理一遍。例如，如果 scan_target_interval 设置为 24 小时，服务器会在最多 24 小时的时间内，处理服务器中的每一条消息。由于被 purge 的或者已经过期的消息，只有被镜像一遍之后，才会真正的被 purge 掉或者被当做真正过期的消息，这意味，即使某个时刻我在命令行中运行了 purge 命令，但有可能最多要过 24 小时的时间，这种消息才会被从服务器中删除掉。

scan_iter_interval 参数，每次渐进式检查所间隔的时间。比如将 scan_iter_interval 设定为 10 秒，那么每隔 10 秒钟， EMS 服务器就要执行以此渐进式检查。每次检查的数据量，取决于总的数据量，同时也与 scan_target_interval 与 scan_iter_interval 的比值有关。总的原则是服务器必须在 scan_target_interval 设定的时间内，检查完所有的数据。

比如， scan_iter_interval 设定为 10 秒， scan_target_interval 设定为 1 天，也就是 86,400 秒，同时数据总量为 9G 。那么每间隔十秒， EMS 服务器要一次性检查 1M 左右的数据，这样比每秒检查 100k 的数据，对性能影响小些。如果即便如此，数据库的性能还是降低了，我们可以调大 scan_target_interval 。

渐进式的镜像和清理数据会影响一些关键数据统计的准确性。在某一个完整的扫描检查完成之前，某些统计数据不一定是真实的，因为 purge 的过期消息并有真的从服务器中删除。例如，运行 info 命令，会报告 Pending Messages" 和 "Pending Message Size" ，但此时的显示数据是不准的，因为此时的统计，只包含在运行 info 命令之前所有扫描到的数据，并不是所有的数据。同样的， show store 命令会显示 "Message Count" 和 "Message Size" 的数据，而这个数据，也许是要比实际的保存在 store 中的消息量。直到扫描完整的执行，上面的统计数量才是准确的，此时执行 show store 命令时，返回的结果中有一项 "First scan finished" ，当这一项的值为 true 是，所得的统计数据才是准确的。如果我们想尽快的得到准确的统计数据，可以将 scan_target_interval. 参数的值降低，而这又会影响性能。矛盾吧。

总之， mstores 的方式，本人不建议使用。

TIBCO Enterprise Message Service 是一个消息服务器产品，它采用C语言编写，完全支持JMS的通讯协议，在运行速度和消息吞吐量上表现非常出色，对于Windows、Linux、Mac、AIX平台都提供支持，关于这个产品，我也是刚刚接触不久，以下是本人一段时间使用的一个小结：1、将 EMS 设置为控制访问模式默认安装好的 EMS 对于消息队列（Queue）或者消息主题 1.show connections type=q 相关属性说明。 tcp://localhost:7222> show connections type=q L ID FSXT S Host User ClientID Sess Uptime C 2 ---A + gl-huang admin 1 0:04:55 J 7 ---Q + gl-huang anonymous 1 0:03:1... 面向消息的中间件随着系统变大变复杂，一个大的系统，开始向着领域模型和微服务架构演进。而各个子系统之间的通信开始变得复杂、重要。不过总的来说还是分两类：同步通信和异步通信。对于同步通信，现在通俗的做法有REST、RPC、SOAP等。对于异步，现在用的最多就是面向消息的中间件（ Message Oriented Middleware，MOM）。我们知道异步通信一般有两个问题，一是发送方进程与消息服务端进... 我们公司的SECS/GSM通讯软件是单独一套的CS结构系统，在系统里结合了许多其它系统的业务逻辑和卡控，使得RMS系统越来越来臃肿，所以能否将公司的RMS系统打造成EAP，让整个系统的结构清晰，各个系统的职责分明，不想什么逻辑都加在RMS系统里。提示：以下是本篇文章正文内容，下面案例可供参考一、EAP是什么？ EAP（Equipment Automation Programming）控制半导体设备进行自动化生产教程：使用 TIBCO EMS 消息描述符06/08/2017本文内容概述本教程演示如何使用 BizTalk Server 上下文属性在您的业务流程中设置 TIBCO Enterprise Message Service ( EMS ) 消息描述符字段。本教程假定你具有一个业务流程从接收端口接收消息并将消息发送到 TIBCO Enterprise Message Service 的绑定到的 Micr... TIBCO Enterprise Message Service功能介绍 Java Message Service 1.1（JMS）是用来定义应用之间消息传递的Java框架规范。Sun公司与 TIBCO 公司等多家公司合作开发了这个规范，用来定义企业应用之间统一的消息传递接口。消息传递服务用来集成企业内部的应用。例如，您可能拥有多个应用系统：一个是客户关系管理、一个是产品库存管理，另外一个是生产物料...