Sun Java System Message Queue 3.7 UR1 管理指南

持久性服务

代理在发生故障后进行恢复时,需要重新创建消息传送操作的状态。 要执行此操作,代理必须将状态信息保存到持久性数据存储库中。代理在重新启动后,将使用保存的数据重新创建目的地和长期订阅,恢复持久性消息,回滚打开的事务,并为未传送的消息重新生成路由表。 然后它才能恢复消息传送。

Message Queue 既支持基于文件的持久性模块,也支持基于 JDBC 的持久性模块(请参见图 4–1)。基于文件的持久性存储使用单个文件来存储持久性数据;基于 JDBC 的持久性存储使用 Java 数据库连接 (Java Database Connectivity, JDBC™) 接口将代理连接到符合 JDBC 的数据存储库。虽然基于文件的持久性存储通常比基于 JDBC 的持久性存储快,但某些用户更希望使用 JDBC 存储库所提供的冗余和管理控制功能。代理配置属性 imq.persist.store(请参见表 14–4)指定使用两种持久性形式中的哪一种。

图 4–1 持久性数据存储库

该图显示了持久性服务使用基于平面文件的数据存储库,或使用基于 JDBC 的数据存储库。

基于文件的持久性

默认情况下,Message Queue 使用基于文件的持久性数据存储库,在这种存储库中使用单个文件来存储持久性数据,如消息、目的地、长期订阅和事务。 基于文件的持久性中列出了与基于文件的持久性相关的代理配置属性。

基于文件的存储库位于某个目录中,该目录使用数据存储库所属的代理实例的名称 (instanceName) 进行标识:

/instances/instanceName
/fs350/

(有关 instances 目录的位置,请参见附录 A, Message QueueTM 数据在特定平台上的位置。)代理中的每个目的地都有其自身的子目录,用于保存传送到该目的地的消息。


注 –

由于持久性数据存储库可能会包含敏感或专用的消息,因此应该保护 /instances/ instanceName/fs350/ 目录不受未经授权的访问;请参见保护持久性数据


消息以外的所有持久性数据都存储在单独的文件中:一个文件用于目的地,另一个文件用于长期订阅,第三个文件用于事务状态信息。 大多数消息都存储在由大小可变的记录组成的单个文件中。可以压缩此文件以减少添加和删除消息时产生的碎片(请参见压缩物理目的地)。此外,超过特定阈值大小的消息将存储在其各自的文件中,而不是存储在大小可变的记录文件中。可以使用代理属性 imq.persist.file.message.max_record_size 来配置此阈值的大小。

代理为这些单个的消息文件维护一个文件池:当不再需要某个文件时,并不会将其删除,而是重新放入目的地目录的空闲文件池中,以便日后其他消息可以重新使用该文件。 代理属性 imq.persist.file.destination.message.filepool.limit 指定池中的最大文件数。当某个目的地的单个消息文件数超过此限制时,将删除不再需要的文件,而不是将其重新放入文件池。

如果将文件重新放入文件池,则代理可以节省时间,但会占用存储器空间,因为它只是将文件标记为可重新使用,而没有删除文件以前的内容。 可以使用 imq.persist.file.message.filepool.cleanratio 代理属性来指定每个目的地的文件池中应保持“清除”(空)状态(而不是仅仅标记为可重新使用)的文件数百分比。 此值设置得越高,文件池所需的空间越少,但清空文件内容(当文件重新放入文件池时)所需的开销也越大。如果代理的 imq.persist.file.message.cleanup 属性为 true,则在代理关闭时将清空池中的所有文件,使其保持清除状态;这样可以节省存储器空间,但会减慢关闭过程。

将数据写入持久性存储库时,操作系统在以同步还是“延迟”(异步)方式写入数据方面存在一定的不准确性。 延迟存储可能会导致数据在系统崩溃时丢失(如果代理认为数据已经写入持久性存储库,但实际并未写入)。为了确保绝对的可靠性(以牺牲性能为代价),可以将代理属性 imq.persist.file.sync.enabled 设置为 true,以要求同步写入所有数据。 在这种情况下,当系统在崩溃后恢复运行时,可以保证数据是可用的,并且代理可以可靠地恢复运行。但请注意,虽然数据并未丢失,但却不能用于群集中的任何其他代理,因为群集中的代理当前并未共享该数据。

基于 JDBC 的持久性

可以不使用基于文件的持久性,而将代理设置为访问可通过 JDBC 驱动程序进行访问的任何数据存储库。 这需要设置适当的与 JDBC 相关的代理配置属性,以及使用数据库管理器实用程序 (imqdbmgr) 创建具有正确结构的数据库。有关详细信息,请参见配置基于 JDBC 的存储库

基于 JDBC 的持久性中列出了用于将代理配置为使用 JDBC 数据库的属性。可以在每个代理实例的实例配置文件 (config.properties ) 中指定这些属性,也可以使用代理实用程序 (imqbrokerd) 或数据库管理器实用程序 (imqdbmgr) 的 -D 命令行选项来指定这些属性。

imq.persist.jdbc.driver 属性提供了连接到数据库时使用的 JDBC 驱动程序的 Java 类名。 还有一些属性用于指定具有以下功能的 URL:连接到现有数据库 (imq.persist.jdbc.opendburl)、创建新的数据库 (imq.persist.jdbc.createdburl) 和关闭数据库连接 (imq.persist.jdbc.closedburl)。

imq.persist.jdbc.userimq.persist.jdbc.password 属性提供了用于访问数据库的用户名和密码;imq.persist.jdbc.needpassword 是用于指定是否需要密码的布尔标志。 为了安全起见,应该仅在通过 -passfile 命令行选项指定的密码文件中指定密码;如果未指定此类密码文件,则 imqbrokerdimqdbmgr 命令将以交互方式提示您指定密码。 同样,可以通过在命令行中使用 imqbrokerd 命令的 -dbuser 选项或 imqdbmgr 命令的 -u 选项来提供用户名。

在由多个代理实例共享的 JDBC 数据库中,配置属性 imq.persist.jdbc.brokerid 指定每个实例的唯一实例标识符,该标识符将被附加到数据库表名的后面。 (嵌入式数据库只存储一个代理实例的数据,因此通常不需要此属性。)与 JDBC 相关的其余配置属性用于自定义创建数据库结构的 SQL 代码,每个数据库表对应一个属性。 例如,imq.persist.jdbc.table.IMQSV35 属性提供用于创建版本表的 SQL 命令,imq.persist.jdbc.table.IMQCCREC35 属性提供用于创建配置更改记录表的 SQL 命令,imq.persist.jdbc.table.IMQDEST35 属性则提供用于创建目的地表的 SQL 命令,等等;有关完整列表,请参见表 14–6


注 –

由于各个数据库系统所要求的具体 SQL 语法不同,因此请务必查看数据库供应商提供的相应文档以了解详细信息。