RabbitMq杂记

• 前言

本文记录一下关于Rabbitmq的一些优化选项的设置，当然优化配置有挺多的，目前收集的是一些常用的优化选项，后续有空再深入研究一波。

• 确认机制

Rabbitmq的发布者确认机制是AMQP的增强功能，对于发布者发送的每条消息，服务器都会发送一个ack命令确认响应或者nack否定确认信息。该功能可以作为一种轻量级的事务功能，当然rabbitmq有select命令开启基于事务的批量处理，但是这种会造成阻塞。

• 使用HA队列避免节点故障

在设置HA队列的时候，需要设置参数x-ha-policy为all，当然也可以指定集群中的几台服务器为一批独立节点，设置x-ha-policy为nodes，再加上x-ha-nodes配置节点位置信息。
HA队列允许多个服务器上拥有冗余副本，当发布消息到设置为高可用的队列时，该消息会被发送到集群中的每台服务器，该集群管理着HA队列。一旦消息在集群中的任何节点都完成消费，那么消息的所有副本将立即从其他节点中删除。
HA队列有一个主节点，其他的为辅助节点，如果主节点发生故障，其他节点切换为主节点。

• 消息持久化

设置参数delivery-mode为2（默认为1，消息保存在内存中，不开启持久化），同时设置queue的属性为durable。
消息持久化就像一把双刃剑，一方面可以保证消息的安全，能在消息被消费前发生宕机防止丢失消息。另外一方面开启消息持久化消耗服务器的io资源，可能会导致严重的性能问题，导致大大降低消息发布速度。
当然io性能问题如果能在硬件上提供支持的话是可以解决的，比如增加内存，增加写入的硬盘，增加合适大小、带有备用电池的raid卡，并配置大量的读写缓存。

• 消息回推

写过RxJava的人应该知道背压这个概念，或者netty的高水位设置，消息回推也是相同场景下的概念，回推是消息生产者发送消息太快到mq服务器了，造成mq服务器压力太大，mq服务器将发送 Channel.FlowRPC让消息生产者进行阻塞。
当然如果生产者忽视了Channel.FlowRPC这个命令，消息回推就无效了，rabbitmq为了应对这种情况，扩展了amqp，在rabbitmq内部，使用信用的概念来管理回推发布消息的时机。在建立新的连接时，连接会被分配一个预订数量的信用值，rabbitmq每接受一个rpc命令时，会扣除一个点的信用值，rpc请求处理完后，再返回被扣除的信用值，如果连接的信用值不足时会跳过连接指导有足够的信用值。

• 消息的推拉模型

Rabbitmq提供了get和consume两种命令来获取消息，通过名称可以很容易的推测出对应的推拉模型。get是一种拉模型，通过轮询来或许消息，可见效率会比较低，同时也可能因为无法判断当前消息的负载情况，造成消费者荷载过重的情况。consume是推模型，类似于消息回调的方式，性能会好很多。

• 1
• 1