关于性能及优化

RabbitMQ 持久化

默认情况下，重启 Broker 时，那些非持久化(not durable and persistent)的 Messages 、 Exchanges 和 Queues 会丢失。

如果你不想丢失任何信息，请确保你的 Queues 是声明为 durable 的，并且你的 Messages 的分发模式(delivery mode) 为 persistent 的( transient 为短暂模式，也即内存模式)

注意，声明 Queues 为 durable 并不表示 Messages 也是 persistent 的，你必须显式地声明 Messages 为 persistent 才行。

占用高 CPU/内存 常见原因

这一段是看了 英文原文 时做下的简要翻译和笔记的。

  1. 排队的消息太多
  2. 长时间的高速率消息
  3. 频繁地打开和关闭连接

排队的消息太多

占用比较高的内存，可能说明队列里的消息增长过快。当这种情况发生时，RabbitMQ 为了释放内存，就会开始刷盘，而当开始刷盘时，队列的速度就会再恶化。对条消息的 CPU 成本将会比当队列为空时的成本更高（因为消息现在必须排队）。然后 CPU I/O Wait 很可能会增高，这个说明了该百分比的 CPU 时间必须等待刷盘。

优化

你应该将你的队列消息，一直保持在 0 。即最好不要堆积消息。

太多未确认的消息

所有未确认的消息，都必须居住在服务器的内存中。如果你有太多的未确认消息，你将会用尽你的内存。一个有效的方式来限制未确认消息就是限制你的客户端的 prefetch 参数。

太高的消息吞吐量

CPU User time 表明你的程序在 CPU 中花费在执行指令的百分比时间，在这情况下，就是花费在运行 RabbitMQ 的时间。如果你的 CPU User time 太高，它可能是由于太高的消息吞吐量了。

频繁地打开和关闭连接

如果 CPU System time 比较高，你应该检查一下你是如何处理你的连接了。RabbitMQ 中的连接要比 Channel 更耗资源，即所谓比较重。连接应该长时间存活，并且 Channel 可以更频繁地打开和关闭。

最佳实践是，在线程与 Channel 之间重用连接，换句话说，如果你的连接与 Channel 一样多，那你就可能需要看一下你的架构了。

理想情况下，每个进程里应该仅有一条连接，然后在你的应用程序里，每条线程各自使用自己的 Channel（Channel并不是线程安全的）。

连接或 Channel 泄漏

如果大量的 Channel 或 连接失去控制的话，它可能是由于你客户端代码的 Channel 或 Connection 泄漏了。请尝试去发现导致泄漏的原因并确保你不再使用 Channel 时记得及时关闭它们。

RabbitMQ 3.6.0 版本

这不是一个好的 RabbitMQ 版本——它有大量的问题，并且在新的版本中被修复了。

RabbitMQ 默认启动参数

版本为 3.6.9 ，Erlang版本为 Erlang/OTP 18

erlang erl man

-W w :
-A 128 
-P 1048576 
-t 5000000 
-stbt db 
-zdbbl 32000 
-K true

RabbitMQ 添加交换机的性能

今天测试了下，将不同的队列，绑定到不同的交换机，有没有能提高性能。结果是：No

测试的情况是，使用2个交换机(hello-exchange, hello-exchange2)和两个队列(hello-queue-name, hello-queue-name2)分别一一对应，然后再使用一个队列 hello-queue 绑定到默认的交换机(default)。它们入队的消息数分别为 2000,2000,4000。测试结果是它们的总耗时是差不多的。