RabbitMQ消息中间件常见问

RabbitMQ (有几种消息模式自己去看,这里不做解释)1. 使用RabbitMQ的一些经验

1. consume时预取参数的大小对consume性能影响很大，具体可参见官方博客；

 

 

2. 队列HA的代价非常高，特别是对带宽的占用，有限制的使用HA，且只提供两备份即可；

 

3. 磁盘也可能形成瓶颈，如果单台机器队列很多，确认只在必要时才使用duration，避免把磁盘跑满；

 

 

4. 队列的消息大量累积后，发送和消费速度都会受到影响，导致服务进一步恶化，采用的方法是，额外的脚本监控每个队列的消息数，超过限额会执行purge操作，简单粗暴但是有效的保证了服务稳定；

 

5. 限制单条消息大小，我们的限制是128k，消息队列只走消息，其他交由存储去做；

 

 

6. 用iptables适当的限制连接；

 

 

2. RabbitMQ队列超长导致QueueingConsumerJVM溢出

我们的服务器使用RabbitMQ作为消息中转的容器,一般RabbitMQ进程占用内存不过100M-200M，这些队列超长的RabbitMQ进程可以占用超过2G的内存。

 

显然消息队列的消费者出现了问题。开发查看日志发现作为该队列消费者的Java服务的日志也卡住了，重启服务后（这点做得不对，应该用jstat、jstack进行排查，而不是直接重启）又很快卡住。

 

通过jstat发现JVM内存都耗尽了，之后进入无尽的Full GC，所以当然不会处理队列消息和输出日志信息了。

 

使用jmap导出这时候的Java堆栈，命令：jmap -dump:format=b,file=29389.hprof  29389。将得到的dump文件放到MAT（Eclipse Memory Analyzer）里进行分析，发现很明显是QueueingConsumer持有大量对象导致JVM内存溢出

 

解决方案将basicQos设置为16后重启服务，队列终于开始消化了。用jstat 观察JVM内存使用情况，也没有再出现剧增溢出的现象。

      

总结：使用RabbitMQ的时候，一定要合理地设置QoS参数。RabbitMQ的默认做法其实是很脆弱的，容易导致雪崩。

 

3. RabbitMQ数据速率问题

在边读边写的情况下：速率只与网络带宽正相关，网络使用率最高能达到接近100%，并且数据使用率很高（90%以上）。

 

        在千兆网下，以500KB一条数据为例，读写速率均能达到200条/s，约为100MB/s。

 

在只写不读的情况下：写入速率瓶颈在于硬盘写入速度。

 

 

 

4. RabbitMQ数据存储路径变更到D盘方法

Windows环境下，在安装前设置环境变量：RABBITMQ_BASE=D:\RabbitMQ_Data

 

 

 

5. RabbitMQ磁盘写满重启后数据丢失问题

表现：磁盘写满后发送、读取程序均不能连接服务。

 

解决方法：将Queue、Exchange设置为Durable即不会发生数据丢失问题。

 

通过a.关闭服务；b.删除占位文件、erl_crash.dump；c.重启服务 三步操作后，磁盘会清理出10M左右空间，此时读取数据程序便可正常工作。

 

正确设计的架构，应确保RabbitMQ不会发生磁盘写满崩溃的情况。