京公网安备11010502063487号在 RabbitMQ 4.3.6 上对比客户端的断线行为:pika 的 BlockingConnection 被强制关闭后抛 ConnectionClosedByBroker 且不恢复;aio-pika 的 connect_robust 在 broker 重启(6 秒中断)后自动重连并恢复消费者,728 条无重复无丢失,但停机期间发布端有 510 次失败要自己重试;队列被删时只收到 Basic.Cancel。
在 RabbitMQ 4.3.6 上验证 consumer_timeout:默认 1800000 ms,rabbitmq.conf 改成 10000 后 eval 读到 {ok,10000};x-consumer-timeout 队列参数经典队列返回 406、quorum 队列成功,policy consumer-timeout 可设;但把超时配成 10 s、消费者收到消息不确认,等 7 分钟 channel 没有被关——原因没查清,如实记录。
在 RabbitMQ 4.3.6 上复现两种重复来源:消费者 ack 前崩溃导致重复处理(redelivered=True)、发布端因 Ack 丢失而重发导致队列里 2 份(都是 redelivered=False);broker 不会按 message_id 去重;用 message_id 唯一约束 + 同事务让 1100 次投递只执行 1000 次,余额 1000;100 万个 message_id 约 28.3 MiB。
在 RabbitMQ 4.3.6 上实测保序:单队列单消费者严格有序;多消费者并发会打乱完成顺序(2/4/8 个消费者总逆序对 68/298/468);prefetch=10 下被 nack 并 requeue 的消息会被推迟到已预取的之后;按 key 分区到 8 个队列后,100 个账户内部顺序 0 个乱序。
在 RabbitMQ 4.3.6 上对比事务模式与确认模式:事务提交前消息不可见、可跨队列原子提交、可回滚;5000 条持久化消息,事务每条提交 4436 条/秒、每 100 条提交 29985 条/秒,confirm 同步 5712 条/秒、异步窗口 51929 条/秒;单次延迟 p50 事务 0.193 ms 对 confirm 0.162 ms。
在 RabbitMQ 4.3.6 上实测消息大小的影响:10 B~1 KiB 约 5~6 万条/秒,100 KiB 起带宽到约 1.4 GiB/秒;classic 与 quorum 在单节点上几乎重合;300 KiB 消息拆成 3 个 ContentBody 帧(frame_max 131072);max_message_size 16 MiB,17 MiB 被 406 拒绝;1000 条 1 MiB 消息只让 RSS 涨 15 MiB、磁盘涨 1000 MiB。
在 RabbitMQ 4.3.6 上实测 RPC 模式:reply_to + correlation_id 的线上帧;两个速度不同的服务端使响应乱序到达,靠 correlation_id 对应;每次新建回复队列 p50 3.317 ms,复用回复队列 0.257 ms,direct reply-to 0.237 ms;服务端不在线时客户端要自己超时,带 expiration 的请求会被队头挡住。
在两个 RabbitMQ 4.3.6 节点上实测 Shovel 和 Federation:动态 shovel 把 1000 条消息从 A.src 搬到 B.dst,三种 ack-mode 约 2 万条/秒;目的端宕机时 shovel terminated、消息留在源队列,恢复后 0.4 s 搬完;交换机联邦按下游绑定复制消息(5/6 条);队列联邦只在下游有消费者时才把消息搬过来。
在 RabbitMQ 4.3.6 上实测监控接口:管理 API 的统计每 5000 ms 收集一次,发布 1000 条后 7.7 秒才在 API 里看到(rabbitmqctl 立即可见);publish rate 稳定显示 200.0 但 messages 滞后数秒;Prometheus /metrics 一次 1689 行、抓取 16 ms;macOS 上 fd/socket/disk_free 读不到;管理插件的开销在噪声内。
在 RabbitMQ 4.3.6 上复现消息积压:发布 800 条/秒、消费约 444 条/秒时 ready 每秒增长约 438 条,consumer_capacity≈0.005 表示消费者是瓶颈;无消费者 / 慢消费者 / 卡住消费者的快照对比;加消费者 1→8 个吞吐 159→1273 条/秒线性增长;purge 50000 条只要 20 ms。
在 RabbitMQ 4.3.6 上实测 TTL:1000 ms 的消息约 1 秒整批过期;队头没过期时后面过期的 10 条变成“僵尸”(ready 仍是 11);队列 TTL 与消息 TTL 取较小;expiration=0 表示立即投递否则丢弃;x-expires 的队列无人使用约 3 秒后删除,passive 声明也算使用;TTL 按发布时刻计,重启后已过期的消息不再出现。
在同一台机器上对比 RabbitMQ 4.3.6 与 Kafka 4.3.1:发布 10 万条 100 字节,RabbitMQ 异步 confirm 61155 条/秒,Kafka 150 万~210 万条/秒(客户端不同,仅看数量级);低速率 p50 延迟 0.60 vs 0.34 ms;扇出给 3 个下游时磁盘 174 vs 49 MiB;RabbitMQ 经典队列读完即删而 Kafka 可从头重放。