Rabbitmq显示的发布速率低于交付/确认速率，没有可消耗的积压工作。这些统计数字准确吗？

我们使用rabbit已经有一段时间了，在最近部署创建一个新的扇出交换后，我们被一件非常奇怪的事情吓坏了：在管理控制台的实时图和REST API中，我们的队列始终发布的帖子比它们正在传递/确认的帖子要少，即使队列大小徘徊在0左右

RESTAPI中的示例统计信息：

    "message_stats": {
    "ack": 149063323,
    "ack_details": {
        "rate": 305.0
    },
    "deliver": 149089898,
    "deliver_details": {
        "rate": 318.8
    },
    "deliver_get": 149089898,
    "deliver_get_details": {
        "rate": 318.8
    },
    "disk_reads": 4058297,
    "disk_reads_details": {
        "rate": 0.0
    },
    "disk_writes": 149084451,
    "disk_writes_details": {
        "rate": 227.6
    },
    "publish": 142374350,
    "publish_details": {
        "rate": 129.6
    },
    "redeliver": 5379,
    "redeliver_details": {
        "rate": 0.0
    }
},

在我们担心的时间段内，队列已平铺为0

以下是web管理控制台显示的内容：

据我们所知，我们没有多次收到消息，因此我们目前认为这是统计数据收集或报告中的一个缺陷。我们还没有重新启动此节点的窗口，因为它是一个活动系统。我们还没有发现任何不良影响

血淋淋的细节：我们的队列在12个连接上有240个消费者，它通过绑定到两个队列的扇出交换发布到。这两个队列都表现出这种行为。队列的发布速率与exchange的发布速率相匹配。这两个队列都有一个死信交换/队列组合，需要确认。fanout exchange和其中一个队列是新的，这些消息的发布方式有一些更改（以前发布到路由到旧队列的默认exchange，现在我们发布到新的fanout exchange以同时命中旧队列和新队列）。旧队列的使用者代码没有太大变化（在postgres表中少插入一个），新队列运行的代码与旧队列极为相似（除了只插入一个postgres表）

---

这些统计数据是否可能在野外遇到车外的情况？这可能是由恶劣的地形造成的吗？这种状态会带来什么，会有什么副作用，以及什么类型的设置会造成这种情况？

您在这里找到解决方案/问题了吗？我们今天发现了这个问题，不知道发生了什么