RabbitMQ消息发布的性能权衡

发布性能的权衡

在完美情况下，我们无需额外的配置或步骤，RabbitMQ就可以可靠的投递消息。但是，完美的情况是不存在的，我们在消息发布的时候总会出现各种问题，如网络或硬件带来的问题，使得消息可靠性降低。

而RabbitMQ又给我们提供了不同的保障机制：

使用这些机制会对性能产生一定的影响，我们只有执行过自己的性能基准测试，才能找到在性能于可靠投递之间的平衡点。

失败通知

mandatory标志是一个与Basic.PublishRPC命令一起投递的参数，它是用来告诉RabbitMQ如果消息不可路由，它应该通过Basic.ReturnRPC命令将消息返回给发布者。设置mandatory标志可以让RabbitMQ向你通知失败。

发布者确认

发布者确认作为事务的轻量级替代方法，发布任何消息之前，消息发布者必须向RabbitMQ发送Confirm.Select请求，并等待Confirm.SelectOk响应以获知投递确认已经被启动。在这一点上，对于发布者发送给RabbitMQ的每条消息，服务器会发送一个确认响应（Basic.Ack）或否定确认响（Basic.Nack）。

备用交换机

备用交换机是用来处理一些无法被交换机路由的消息，如果一些消息无法被路由，那么他将会被路由到这个新的备用交换机上。 如果将消息发送到具有备用交换器的交换器（设置了mandatory=true）上， 那么一旦预期的交换器无法正常路由消息，Basic.Return就不会发给发布者。因为消息成功的发布到了备用交换器

基于事务的批量处理

AMQP事务提供了一种机制，通过这种机制，消息可以批量发布到RabbitMQ，然后提交到队列或者回滚。
在协议层，当RabbitMQ由于错误而无法路由时，它将发送一个Basic.Return响应，希望终止事务的发布者应该发送TX.Rollback请求，并等待TX.RollbackOk响应，然后继续工作。
需要注意的是,如果使用事务或消息确认机制，则消息需要在HA队列中所有活动节点确定后，RabbitMQ才会发送成功响应。

HA队列

HA队列是RabbitMQ团队创建的一项增强功能，它允许队列在多个服务器上拥有冗余副本，但他需要集群环境。HA队列有一个主服务节点，其他节点都是辅助节点。

持久化

如果RabbitMQ代理服务器在消费消息之前因某种故原因发生宕机，那么消息将会永远丢失。但是设置delivery-mode为2将消息持久化到硬盘可以解决这一问题。但是对于没有足够的IO能力的服务器来说，消息持久化可能会导致严重的性能问题。

RabbitMQ的回推

发布者发送消息会对RabbitMQ造成一定压力，当RabbitMQ感受到压力时会发送Channel.FlowRPC方法来让你的发布者发生阻塞。从RabbitMQ3.2开始，RabbitMQ添加了在达到连接信用阈值发送通知的机制Connection.Blocked和Connection.Unblocked。我们可以使用rabbitpy来检测连接状态。