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