复制消息存储
如果消息存储在代理的硬盘驱动器上或单个数据库内，那么你就有一个关于消息持久性的单点故障。如果你丢失了整台机器、磁盘或数据库，你就丢失了消息。
对于一些高端用户，消息永远不应该丢失，因为它们可能会对业务造成重大影响。这些类型的用户通常需要某种类型的DR策略来支持消息复制，这样他们就可以丢失整个数据中心，而不会丢失任何消息。
解决消息丢失几率问题有多种方案。
使用 RAID 磁盘
如果你使用足够条带化的 RAID 磁盘，你可以重新启动机器，或者将磁盘移动到新机器上并重新启动代理。如果你是一家小型企业，这可能就足够了，但如果你有严格的DR要求，那么如果你丢失了数据中心，RAID 选项就不是解决方案。
SAN 或共享网络驱动器
如果你使用基于文件的持久性机制之一，比如默认的高性能日志和 Apache Derby，你可以写入 SAN 或共享网络驱动器，并在出现故障时，使用失败代理中的文件启动新的代理。
此外，4.1 允许你启动多个代理从同一个共享文件系统读取，以通过共享文件系统主从功能支持高可用性。
主从
另一种方法是使用主从功能将代理配对，以便所有消息都复制到两个代理（主代理和从代理），以确保有两个物理副本，以便能够处理灾难性的硬件故障（例如整个数据中心的丢失）。
集群 JDBC 数据库
Oracle 和 MySQL 等各种数据库支持集群数据库；因此，我们可以将这些数据库与 JDBC MessageStore 配合使用，以获得集群消息存储。注意，如果使用此选项，则必须禁用高性能日志（这会严重影响性能）。
使用 C-JDBC
如果你没有或无法负担集群数据库，那么你可以使用C-JDBC 将状态复制到多个物理数据库，以避免单点故障并提供DR解决方案。如上所述，使用复制的 JDBC 方法非常慢，因为它需要我们禁用高性能日志。
