消息服务--摘抄

一、消息传送步骤
1、消息从生成方客户端传送到代理。
2、代理读取消息。
3、消息被放置到持久性存储库当中（出于可靠性的考虑）。
4、代理确认收到消息（出于可靠性的考虑）。
5、代理确定消息的路由。
6、代理写出消息。
7、消息从代理传送到使用方客户端。
8、使用方客户端确认收到消息（出于可靠性的考虑）。
9、代理处理客户端确认（出于可靠性的考虑）。
10、代理确定已经处理客户端确认。
因为这些步骤是连续的，所以任何步骤都可能成为消息从生成方客户端到使用方客户
端的传送过程的瓶颈。这些步骤中的大多数都取决于消息传送系统的物理特征：网络
带宽、计算机处理速度和消息服务体系结构等等。但是，有一些步骤还取决于消息传
送应用程序的特征和该应用程序要求的可靠性级别。

二、影响性能的应用程序设计因素
1、传送模式（持久性/非持久性消息）
     对于队列和具有长期订户的主题而言，代理处理非持久性消息的性能要高大约40%。
这些结果是在使用10k 大小的消息和AUTO_ACKNOWLEDGE 模式的情况下得到的。

2、使用事务
事务是一种保证，保证在一个事务会话中生成和使用的所有消息将作为一个单元进行
处理或不进行处理（回滚）。
Message Queue 支持本地事务和分布式事务。
消息在事务会话中的生成或确认比在非事务会话中要慢。

3、确认模式
确保可靠传送JMS 消息的一种机制是，客户端确认使用了由Message Queue 代理传送给
它的消息。
如果在客户端尚未确认消息之前就关闭了会话，或者如果代理在处理确认之前发生了
故障，代理将重新传送该消息，并设置一个JMSRedelivered 标志。
对于非事务会话，客户端可以选择三种确认模式之一，这三种模式有其各自的性能特
性：
■ AUTO_ACKNOWLEDGE。使用方处理消息后，系统会自动确认该消息。此模式可确保在
提供者发生故障后至少重新传送一次消息。
■ CLIENT_ACKNOWLEDGE。应用程序控制确认消息的时间点。该会话中自上次确认以来
处理的所有消息都将被确认。如果代理在处理一组确认时发生故障，则该组中的一
个或多个消息将被重新传送。
■ DUPS_OK_ACKNOWLEDGE。此模式指示系统以一种惰性方式确认消息。在提供者发生故
障后，可以重新传送多条消息。
（CLIENT_ACKNOWLEDGE 模式的用法与事务的用法类似，不同之处在于：它不能保证当
提供者在处理过程中发生故障时，所有确认都将一起处理。）

确认模式影响性能的原因如下：
■ AUTO_ACKNOWLEDGE 和CLIENT_ACKNOWLEDGE 模式需要在代理与客户端之间有额外的控
制消息。额外的控制消息会带来额外的处理开销，并干扰JMS 有效负荷消息，从而
导致处理延迟。
■ 在AUTO_ACKNOWLEDGE 和CLIENT_ACKNOWLEDGE 模式中，客户端必须等到代理确认它已
处理客户端的确认后，才能使用其他消息。（这种代理确认可确保代理不会无意地
重新传送这些消息。）
■ Message Queue 持久性存储库必须用使用方收到的所有持久性消息的确认信息进行更
新，因而降低了性能。

4、长期订阅与非长期订阅
长期订阅的可靠性较高，但吞吐量较低。：10k 大小的持久性和非持久性
消息。两种情况下都使用AUTO_ACKNOWLEDGE 确认模式。我们发现只有在持久性消息情
况下，才会有性能影响，使长期订阅减慢了大约30%。

5、使用选择器（消息过滤）
   选择器是一种只请求特定消息的字符串，这些消息的属性值应该与传送到特定使用方
的字符串匹配。使用选择器，则必须对它进行解析，以使它与将来
的消息匹配。另外，路由每个消息时，都必须检索该消息的属性，并与选择器进行比
较。但是，使用选择器为消息传送应用程序提供了更大的灵活性。

6、消息大小
   在我们的消息管理控制台中，将最大消息数设置为unlimited（不受限制），有时由于特殊情况，系统发送了6万条甚至10万条以上的信息，可导致消息服务失效。这种情况发生在长期多个用户订阅的情况。因而需对消息大小进行控制。

7、消息主体类型
JMS 支持五种消息主体类型，下面大致按复杂性顺序显示这些类型：
■ BytesMessage 包含一组字节，格式由应用程序确定。
■ TextMessage 是一种简单的Java 字符串。
■ StreamMessage 包含Java 基元值流。
■ MapMessage 包含一组名称/值对。
■ ObjectMessage 包含Java 序列化对象。
尽管通常情况下消息类型是由应用程序的需要所决定的，但较复杂的类型
（MapMessage 和ObjectMessage）会增加性能成本：对数据进行序列化和反序列化的成
本。性能成本取决于数据的简单或复杂程度。

三、影响性能的消息服务因素
1、硬件
对于Message Queue 代理和客户端应用程序而言，CPU 处理速度和可用内存都是消息服
务性能的主要决定因素。大多数软件限制都可以通过增加处理能力来消除，而添加内
存则可以同时提高处理速度和容量。但是，仅通过升级硬件来克服瓶颈通常过于昂
贵。
2、操作系统
由于不同操作系统的效率不同，因此即使硬件平台相同，性能也会各不相同。例如，
操作系统使用的线程模型会对代理可以支持的并发连接数产生重要影响。在所有硬件
都相同的情况下，Solaris 通常比Linux 快，而后者通常又比Windows 快。
3、Java 虚拟机(JavaVirtual Machine, JVM)
代理是受主机JVM 支持并运行在其中的一种Java 进程。因此，JVM 处理是决定代理路
由和传送消息的速度和效率的重要因素。
特别是JVM 的内存资源管理至关重要。必须为JVM 分配足够的内存以适应不断增大的
内存负载。另外，JVM 将定期回收未使用的内存，而这种内存回收会延迟消息的处
理。JVM 内存堆越大，内存回收过程中可能遇到的延迟就越长。
4、连接
客户端和代理之间的连接数和速度可能影响消息服务可以处理的消息数以及消息的传
送速度。

5、代理连接限制
   与代理的连接数通常受可用线程数的限制。可以对Message Queue 进行配置以支持专用
线程模型或共享线程模型。
   专用线程模型的速度非常快，因为每个连接都有专用的线程，但是连接数目受可用线
程数的限制（每个连接都有一个输入线程和一个输出线程）。共享线程模型对连接数
不加任何限制，但是在大量连接之间共享线程会导致明显的开销和吞吐量延迟，特别
是当这些连接都很繁忙时。

6、传输协议
    Message Queue 软件允许客户端使用各种低级别的传输协议与代理进行通信。
    协议的选择基于应用程序的要求（加密、可通过防火墙访问等），但是所作的选择会
影响总体性能。
    https << http << ssl << tcp (由慢到快)
   总的说来，在高可靠性情况下协议具有较小影响。这可能是因为在高可靠性情况下所需的持久性开销在限制吞吐量方面是比协议速度更重要的因素。另外：
■ TCP 提供与代理通信的最快方法。
■ SSL 在收发消息时比TCP 要慢50% 到70%（对于持久性消息是50%，对于非持久性
消息则接近70%）。另外，SSL 在建立初始连接时比较慢（可能需要数秒钟），因
为客户端和代理（在使用HTTPS 的情况下则为Web 服务器）需要建立私钥，以供
加密要传输的数据时使用。性能的下降源自于加密和解密每个低级别TCP 包时所需
的额外处理。
■ HTTP 比TCP 或SSL 都要慢。它使用Servlet，该Servlet 在Web 服务器上作为客户端
与代理之间的代理运行。封装HTTP 请求中的包以及消息经过两个跃点（客户端到
Servlet，Servlet 到代理）后才到达代理的要求均涉及性能开销。
■ HTTPS 比HTTP 慢是因为需要额外的开销以加密客户端和Servlet 之间以及Servlet 和
代理之间的包。

7、消息服务体系结构
   Message Queue 消息服务可以作为单个代理实现，也可以作为多个互相连接的代理实例
所组成的群集实现。
   通常，如果客户端（特别是消息生成方客户端）均匀地分布在群集中，则这种调整最
为有效。由于在群集中的代理之间传送消息涉及到开销，因此对于连接数有限或消息传送速率有限的群集而言，其性能可能会比单个代理要低。
   您也可以使用代理群集来优化网络带宽。例如，您可能希望在群集内的一组远程代理
之间使用低速的长途网络链路，而在客户端与其各自的代理实例之间使用高速链接进
行连接。

8、代理限制和行为
    处理消息吞吐量，代理在以下资源上有限：内存、CPU 周期等。因此，代理可能会在无响应或不稳定的位置发生崩溃。
   Message Queue 消息代理具有管理内存资源并防止代理用尽内存的内部机制。这些机制
包括可以配置代理或其各自物理目的地可以拥有的消息数或消息字节数的限制，以及
当达到物理目的地限制时可以实施的一组行为。
   通过仔细的监视和调整，这些可配置机制可以用于平衡消息的内流和外流，使得不会
发生系统过载。尽管这些机制会造成开销并限制消息的吞吐量，但它们可以维护操作
的完整性。

9、数据存储库性能
   Message Queue 既支持基于文件的持久性模块，也支持基于JDBC 的持久性模块。基于
文件的持久性使用单独的文件存储持久性数据。基于JDBC 的持久性使用Java 数据库连
接(JavaDatabase Connectivity, JDBCTM) 接口，并需要符合JDBC 的数据存储库。基于文件的持久性通常比基于JDBC 的持久性快；但是，某些用户对于符合JDBC 的存储库所
提供的冗余和管理控制更感兴趣。
   如果是基于文件的持久性，您可以通过指定让持久性操作将内存中的状态与数据存储
库同步，来最大限度地提高可靠性。这有助于消除因系统崩溃而导致的数据丢失，但
代价是性能的下降。

10、客户端运行时环境配置
     Message Queue 客户端运行时环境提供客户端应用程序及其与Message Queue 消息服务的接口。它支持客户端向物理目的地发送消息以及接收来自这些目的地的消息所需的
所有操作。客户端运行时环境是可配置的（通过设置连接工厂属性值），您可以控制
其行为的各个方面（例如连接流度量、使用方流限制和连接流限制），从而提高性能
和消息吞吐量。

四、调整配置以提高性能
1、系统调整
    Solaris 调整：CPU 利用率、分页/交换/磁盘I/O；

2、Java 虚拟机调整
    默认情况下，代理使用大小为192MB 的JVM 堆。这对于较大的消息负载来说通常太
小，应该增大。
     当代理快要耗尽Java 对象使用的JVM 堆空间时，它将使用各种技术（如流控制和消息
交换）来释放内存。在极端情况下，代理甚至关闭客户端连接以释放内存并减少消息
内流。所以最好将最大JVM 堆空间设置得足够大，以避免这种情况。
     但是，与系统的物理内存相比，如果最大Java 堆空间设置过大，代理将继续增大Java
堆空间，直至整个系统耗尽内存。这会导致性能的降低、不可预计的代理崩溃和/或影
响系统中运行的其他应用程序和服务的行为。通常，需要有足够的物理内存以供操作
系统和其他应用程序在计算机上运行。
总的说来，好的方法是：估算正常和峰值系统内存容量，并配置Java 堆大小，使其足
以提供良好性能，但同时不应过大，以免引起系统内存问题。
要更改代理的最小和最大堆大小，请在启动代理时使用-vmargs 命令行选项。例如：
   /usr/bin/imqbrokerd -vmargs "-Xms256m -Xmx1024m"
   此命令将启动Java 堆大小设置为256MB，将最大Java 堆大小设置为1GB。

■ 在Solaris 或Linux 上，如果通过/etc/rc*（即/etc/init.d/imq）启动代理，请在
/etc/imq/imqbrokerd.conf (Solaris) 或/etc/opt/sun/mq/imqbrokerd.conf (Linux) 文件中指定代理的命令行参数。有关详细信息，请参见该文件中的注释。
■ 在Windows 上，如果将代理作为Window 服务启动，请使用imqsvcadmin install 命
令的-vmargs 选项指定JVM 参数。请参见第13 章中的第233 页中的“服务管理器实
用程序”。
在任何情况下，都应当通过检查代理的日志文件或通过使用imqcmd metrics bkr -m
cxn 命令来验证设置。

3、调整传输协议
   
4、调整基于文件的持久性存储库

5、代理调整
   内存管理：提高代理在负载下的稳定性内存管理可以分别在各个目的地上配置，也可以在系统范围级别内（对于所有目的地）配置。
   使用物理目的地限制
   使用系统范围的限制
   多使用方队列性能
      多队列使用方处理队列目的地中的消息的效率取决于下列可配置的队列目的地属性：
   ■ 活动使用方数(maxNumActiveConsumers)
   ■ 可以在一批中传送给使用方的消息的最大数量(consumerFlowLimit)
         要达到最优的消息吞吐量，必须有足够数量的活动使用方以适应队列的消息生成速率，并且队列中的消息必须以最大化使用速率的方式路由和传送给活动使用方。Sun   Java SystemTMMessage Queue TechnicalOverview中介绍了在多个使用方之间平衡消息传送的一般机制。
           如果消息在队列中堆积，这可能是因为没有足够的活动使用方来处理消息负载。也可能是每批传送给使用方的消息太多，导致消息在使用方堆积。例如，如果每批的大小
(consumerFlowLimit) 太大，某个使用方就可能会收到一个队列中的所有消息，而其他
活动使用方则一个也没有收到。如果使用方速度特别快，这也不会成为问题。
           但是如果使用方相对较慢，而您又希望将消息均匀地分配给它们，则需要将每一批的大小减小。每一批的大小越小，将消息传送到使用方所需的开销就越多。但是，对于
较慢的使用方，使用较小的批大小通常能获得网络性能的提升。
 
6、客户端运行时环境消息流调整
    消息流度量
    消息流限制
    使用方流限制
    连接流限制

五、理解和解决常见问题
1、客户端无法建立连接
2、连接的吞吐量太低
3、客户端无法创建消息生成方
4、消息的生成过程延迟或速度减慢
5、消息堆积
6、代理吞吐量呈间歇性
7、消息无法到达使用方
8、停用消息队列包含消息

六、命令行参考
1、命令行语法
    Message Queue 命令行实用程序是shell 命令。实用程序的名称是命令，其子命令或选项是传递给该命令的参数。不需要使用单独的命令来启动或退出实用程序。
    子命令和命令级别的参数（如果有）必须放在所有选项及其参数之前；而选项自身可
以按任何顺序显示。所有子命令、命令参数、选项和选项参数都是以空格分隔的。如
果选项参数的值包含空格，则必须将整个值置于引号中。（将所有属性-值对置于引号
中通常是最安全的做法。）
以下命令用于启动默认代理，它是不带子命令子句的命令行的示例：
imqbrokerd

下面是更完整的示例：
imqcmd destroy dst -t q -n myQueue -u admin -f -s
此命令销毁名为myQueue 的队列目的地（目的地类型为q）。验证是针对用户名admin
执行的；此命令将提示用户输入密码。执行此命令时不提示用户进行确认（-f 选
项），并且处于无提示模式，而不显示任何输出（-s 选项）。

2、代理实用程序
■ imqbrokerd（代理实用程序）
■ imqcmd（命令实用程序）
■ imqobjmgr（对象管理器实用程序）
■ imqdbmgr（数据库管理器实用程序）
■ imqusermgr（用户管理器实用程序）
■ imqsvcadmin（服务管理器实用程序）
■ imqkeytool（密钥工具实用程序）
    代理实用程序(imqbrokerd) 用于启动代理。命令行选项将覆盖代理配置文件中的值，
但仅对当前代理会话有效。

3、命令实用程序
    命令实用程序(imqcmd) 用于管理代理、连接服务、连接、物理目的地、长期订阅和事
务。
   所有imqcmd 命令都必须包含一个子命令（使用-v 或-h 选项显示产品版本信息或使用
帮助的命令除外）。下面列出了一些可用的子命令，并在后面的相应章节中进行了详
细介绍。在任何情况下，如果子命令接受代理地址（-b 选项），并且未指定主机名或
端口号，则默认情况下都将采用值localhost 和7676。

4、数据库管理器实用程序

5、用户管理器实用程序

6、服务管理器实用程序

7、密钥工具实用程序

七、度量参考
1、JVM 度量
2、代理范围内的度量
3、连接服务度量
4、目的地度量