共计 1172 个字符，预计需要花费 3 分钟才能阅读完成。
- 前言
本文记录一下关于 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
