ActiveMQ常用的三种持久化存储方案：KahaDB、LevelDB、关系型数据库。其中KahaDB和LevelDB的工作原理基本类似，都采用内存+磁盘介质的方案：内存用于存放信息的位置索引，磁盘介质上存放消息内容。而关系型数据库的方案，ActiveMQ将完全通过JDBC对数据库进行操作完成消息的存储和修改。某种存储方案的性能，除了这种存储方案的工作原理以外对其有直接影响外，还要考虑它的工作环境。只有根据软件团队预估的系统压力、综合建设方案、考虑后续扩容方式，来确定采用哪一种存储方案，才是科学的。
组播（multicast）基于UDP协议，它是指在一个可连通的网络中，某一个数据报发送源向一组数据报接收目标进行操作的过程。在这个过程中，数据报发送者只需要向这个组播地址（一个D类IP）发送一个数据报，那么加入这个组播地址的所有接收者都可以收到这个数据报。组播实现了网络中单点到多点的高效数据传送，能够节约大量网络带宽，降低网络负载。
ActiveMQ集群Master-Slave模式不支持负载均衡，但可以通过消息的实时备份或共享保证消息服务的可靠性，Broker Cluster模式支持负载均衡，可以提高消息的消费能力，但不能保证消息的可靠性。所以为了支持负载均衡，同时又保证消息的可靠性，我们可以采用Msater-Slave+Broker Cluster的模式。
类似于ActiveMQ、RabbitMQ这样的消息队列中间件，其目的并不是一味地追求单位时间内消息数据的吞吐量/并发量的处理能力。它们的功能中涵盖了诸多功能：事务机制、确认机制、重试机制、热备机制等等，都是为了一个更重要的功能目的：保证消息完整可达。所以您和您的团队一定要按照业务特性来确定是否适合使用这样的中间件服务，并且您需要在预算范围内为您的消息服务中间件配置多个服务节点、多个存储单元，以便保证消息队列中间件能够完成它的任务——消息完整可达。
调用与被调用的关系，是无法被MQ取代的。比如用户登录场景，登录页面调用passport服务，passport服务的执行结果直接影响登录结果，此处的“登录页面”与“passport服务”就必须使用调用关系，而不能使用MQ通信。
Apache Kafka最初由LinkedIn贡献，目前它是Apache下的一个顶级开源项目。Apache Kafka设计的首要目标是解决LinkedIn网站中海量的用户操作行为记录、页面浏览记录，后继的Apache Kafka版本也都是将“满足高数据吞吐量”作为版本优化的首要目标。为了达到这个目标，Apache Kafka甚至在其他功能方面上做了一定的牺牲，例如：消息的事务性。如果您的系统需要进行单位时间内大量的数据采集工作，那么可以考虑在您的系统设计方案中加入Apache Kafka。