消息中间件的可靠性是指对消息不丢失的保障程度；而消息中间件的可用性是指无故障运行的时间百分比，通常用几个 9 来衡量。不存在绝对的可靠性只能尽量趋向完美。并且通常可靠性也意味着影响性能和付出更大的成本，因此实际应用时还要根据业务需求，对真正关键的信息来做可靠性保证，并要从生产者、消息队列、消费者三个维度来努力。
如果在发送消息时采用了事务机制或者publisher confirm机制的话，服务端的返回是在消息落盘之后执行的，这样可以进一步的提高了消息的可靠性。但是即便如此也无法避免单机故障且无法修复（比如磁盘损毁）而引起的消息丢失，这里就需要引入镜像队列。镜像队列相当于配置了副本，绝大多数分布式的东西都有多副本的概念来确保HA。在镜像队列中，如果主节点（master）在此特殊时间内挂掉，可以自动切换到从节点（slave），这样有效的保证了高可用性，除非整个集群都挂掉。虽然这样也不能完全的保证RabbitMQ消息不丢失（比如机房被炸。。。），但是配置了镜像队列要比没有配置镜像队列的可靠性要高很多，在实际生产环境中的关键业务队列一般都会设置镜像队列。
一个软件（程序库）可支持多种协议（例如ActiveMQ实现了多种消息协议），某一种协议（尤其是开放协议）也可被多种软件（程序库）实现（例如能够支持webservice协议的程序库就有Codehaus XFire、Apache CXF、Jboss RESTEasy等）
分布式系统中常用通讯模型主要是“请求-应答”模型和“发布-订阅”模型。前者常见如RPC通讯，常用HTTP REST或Thrift等协议；后者多指消息队列MQ通讯。
RPC大多属于请求-应答模式，也包括越来越多响应式范式，对于需要点对点交互、强事务保证和延迟敏感的服务/应用之间的通信，RPC是优于消息队列的。那么消息队列（下文也简称MQ，即Message Queue）可以看做是一种异步RPC，把一次RPC变为两次或多次，进行内容转存，再在合适的时机投递出去。消息队列中间件往往是一个分布式系统，内部组件间的通信仍然会用到RPC。
通过JMS规范，开发人员可以忽略各种消息协议的细节，只要消息在同一队列中，就能够保证各种消息协议间实现互相转换。
如果您不特别指定ActiveMQ的网络监听端口，那么这些端口都将使用BIO网络IO模型。所以为了首先提高单节点的网络吞吐性能，我们需要明确指定Active使用NIO网络模型。
比起消息生产者来说消息消费者的性能更能影响ActiveMQ系统的整体性能，因为要成功完成一条消息的处理，它的工作要远远多于消息生产者。默认情况下ActiveMQ服务端采用异步方式向客户端推送消息。也就是说ActiveMQ服务端在向某个消费者会话推送消息后，不会等待消费者的响应信息，直到消费者处理完消息后，主动向服务端返回处理结果。
ActiveMQ中设置的各种默认预取数量一般情况下不需要进行改变。但是非必要情况下，请不要设置prefetchSize=1，因为这样就是一条一条的取数据；也不要设置为prefetchSize=0，因为这将导致关闭服务器端的推送机制，改为客户端主动请求。