之前遇见过的生产事故大多数是：CPU过高、项目假死、幂等类等，今天发生了一个一开始让自己摸不住头脑问题，之前也总结过解决问题的思考，欢迎大家多拍砖。
现象：客户收不到验证码、支付状态得不到翻转等，没有错误日志，项目正常，第三方服务也正常。唯一看到表象有问题的是：Message rates有点问题。
后来运维同学发来一篇文章：Memory Alarms — RabbitMQ
rabbitmqctl set_vm_memory_high_watermark fraction is executed. By default, when the RabbitMQ server uses above 40% of the available RAM, it raises a memory alarm and blocks all connections that are publishing messages. Once the memory alarm has cleared (e.g. due to the server paging messages to disk or delivering them to clients that consume and acknowledge the deliveries) normal service resumes.
默认情况下，当 RabbitMQ 服务器使用超过 40% 的可用 RAM 时，它会发出内存警报并阻止所有发布消息的连接。
RabbitMQ内存与磁盘相关的配置主要分为三种：
限制最大可用内存：默认情况下，当生产者将消息发送到RabbitMQ的时候，队列中的消息会尽可能的存储在内存之中，这样可以更加快速的将消息发送给消费者。即使是持久化的消息，在被写入磁盘的同时也会在内存中驻留一份备份。设置分为绝对值和相对值设置。
内存换页：当RabbitMQ使用的内存量快到达我们配置的极限之前，它会尝试将队列中的消息从内存中换页到磁盘以释放内存空间。持久和非持久的消息都会被换页到磁盘中，其中持久化的消息本身在磁盘中就有一个副本，所以在换页转移的过程中持久化的消息会先从内存中被清除。这就是所谓的内存换页。当RabbitMQ进行内存换页的时候，会耗费较长的时间，也会阻塞队列的操作，进而无法接收新的消息。
磁盘相关配置：可以配置rabbitmq的磁盘空间预警，当剩余磁盘空间低于某个阈值时，rabbitmq将会阻塞生产者继续发送消息，并且触发预警。具体见：Free Disk Space Alarms — RabbitMQ。
最后一个步骤还是要验证这些配置是否起作用。将者，如果不经历几次败仗，如何能够知道怎么去打胜仗。这世界上从来就没有百战百胜的将军。只有败而不殆，败而亦勇，并且最终取得胜利的人。
精进自省：反馈机制很重要，好的反馈机制是高效的必要条件。
