RocketMQ 队列、重试、事务回查与存储局部实验（U59）
公开入口，仓库根目录，JDK 21 / Maven 3.9 / Python 3；使用本机独立 RocketMQ 5.5.1（NameServer 9876 + 单 Broker 10911）：
实验代码sh
python3 labs/rocketmq-basics/run.py前置：RocketMQ 5.5.1 发行包解压在仓库外缓存 ~/.cache/software-engineering-study/tools/rocketmq-all-5.5.1-bin-release（来自 Apache 阿里云镜像）。缺失时脚本如实标记 rocketmq=BLOCKED 并以非零退出，不降级为 mock。
入口启动 NameServer 与 Broker（存储/日志在临时目录，ASYNC_MASTER + ASYNC_FLUSH），预创建 6 个 u59test-* 主题，运行 6 个测试后 mqshutdown 停止并确认端口释放。启动前检查 9876/10911，被占用即拒绝启动，不触碰其他 RocketMQ。
教材：RocketMQ：队列、顺序延时、事务回查与存储复制。Kafka 见 MQ 生产存储消费可靠性，RabbitMQ 见 RabbitMQ 路由、确认与恢复，事务消息通用协议见 Outbox、事务消息与最终一致性。
| 测试 | 真实观察 |
|---|---|
| normalMessageIsSentAndConsumedByClusteringConsumer | 集群消费收到普通消息，SendStatus=SEND_OK |
| tagFilterOnlyDeliversMatchingMessages | 订阅全量 + 按本轮唯一 tag 过滤，验证 tag 语义 |
| delayMessageIsInvisibleBeforeDeliverTime | delayTimeLevel=3 在 3s 内不可见，实际延迟约 11.6s |
| orderedMessagesStayInQueueOrder | 同一 selector 固定队列，6 条严格 FIFO |
| failedConsumptionGoesToRetryQueue | RECONSUME_LATER 进入 %RETRY% 队列，重投后成功 |
| transactionMessageCommitsAfterLocalTransaction | 半消息 → 本地事务 COMMIT → 消费者可见 |
边界
- 单 Broker、ASYNC_MASTER + ASYNC_FLUSH；主从切换、集群、同步刷盘/复制未运行。
- Broker 崩溃/断电恢复、ConsumeQueue 重建未运行。
- 事务回查的真实触发路径（提交 RPC 丢失、半消息后崩溃）未运行；只验证 COMMIT 主路径。
%DLQ%死信路径未触发；广播消费、批量消息、消息轨迹、ACL、管理控制台、任意定时消息未运行。- 测试对同 topic 跨运行残留按唯一 body/tag 过滤，这只影响测试断言，不改变 Broker 机制。
- 只使用 127.0.0.1、临时存储目录与合成消息；结束时停止自己启动的 NameServer 与 Broker。
已知未运行
主从切换与 DLedger、集群与跨机房复制、Broker 崩溃恢复、同步刷盘/复制性能、事务真实回查、DLQ、广播消费、批量/轨迹/ACL/控制台、任意定时消息均未运行。