异步消息传递系统，在分布式智能体系统中实现 AI 智能体与服务之间的解耦通信
Loading technique guide…
消息队列通过持久化队列在生产者与消费者之间实现异步、解耦的通信。Broker 提供投递保证 (至少一次、至多一次，有时为恰好一次)、排序选项 (按分区/组)、确认、重试与死信处理。常见实现包括 Apache Kafka (基于日志的分区、消费者组)、RabbitMQ/AMQP (队列、交换机、绑定)、AWS SQS 与 Google Pub/Sub 等云队列、NATS JetStream 以及 Redis Streams。
超低延迟的同步请求/响应路径中，队列开销会突破 SLO → 优先直接 RPC (gRPC/REST)。
高吞吐流上要求严格全局有序，而 broker 无法在不严重损失吞吐的情况下保证。
简单且紧耦合的集成，引入队列只会增加运维复杂度而无明显收益。
依赖跨分区/队列的隐式顺序；消息键设置不一致。
重试时的非幂等副作用 → 重复与数据损坏。
由于缺少背压或扩容不足，队列无限增长且消费滞后加剧。
重试风暴与惊群效应；缺少熔断器与带抖动的退避。
broker 中承载大载荷；缺少模式演进策略导致消费者失效。
资源画像：序列化/压缩与 broker 协调消耗 CPU；缓冲区消耗内存；持久化日志消耗磁盘 I/O；复制与客户端流量消耗网络。
通过批处理与压缩优化；合理设置分区数与消费者并发；限制消息大小 (例如 SQS 256 KB、Pub/Sub 10 MB、Kafka 可配置)。
避免内嵌大 blob；存于外部并发送引用；按租户施加配额与限流。
微服务解耦；异步工作流；后台任务处理。
事件驱动架构与扇出处理；审计/事件日志。
削峰填谷与突发平滑；下游背压控制。
跨区域缓冲与间歇性连接下的韧性。