RabbitMQ延时消息不准确，不是丢失，而是给延后了

以下内容来源于：
https://github.com/rabbitmq/rabbitmq-delayed-message-exchange/issues/72

Delay interval predictability

We have noticed a general issue with the reliability of delayed messages using the x-delay message header and x-delayed-type exchange. Specifically, as the size of the mnesia database grows, delayed messages become gradually more and more delayed.  The delayed message plugin does not respect the delay times in any predictable way. We have some messages that delay 2000 milliseconds, some that delay 900000 milliseconds (15 minutes), and a variety in between. We are seeing messages come through the system as much as 3 days after being queued with an x-delay header of 900000 This behavior is similar both inside a 2-node production cluster, and in our test environment which consists of only a single node. We are able to work around the issue by deleting the mnesia tables, and allowing it to be recreated by the system.

百度翻译：我们已经注意到使用x-delay消息头和x-delayed-type交换的延迟消息的可靠性的一般问题。具体来说，随着记忆数据库的大小增长，延迟的消息逐渐变得越来越延迟。  延迟消息插件不以任何可预测的方式尊重延迟时间。我们有一些延迟2000毫秒的消息，一些延迟900000毫秒（15分钟）的消息，以及介于两者之间的各种消息。我们看到消息在排队后3天就通过了系统，x延迟头为900000。这种行为在2节点的生产集群中以及在仅由单个节点组成的测试环境中都是相似的。我们可以通过删除记忆表来解决这个问题，并允许系统重新创建它。

I'd not expect this design to support millions of delayed messages. it wasn't created for heavy duty workloads and should not be used as a secondary (leave alone primary) data store for delayed operations.One day it may be more suitable for those tasks but not today.

百度翻译：我不希望这种设计能支持数百万条延迟的消息。它不是为繁重的工作负载创建的，不应该用作延迟操作的辅助（更不用说主）数据存储。
总有一天它可能更适合这些任务，但今天不行。