选型需按业务类型区分：任务型选RabbitMQ（强可靠、灵活路由），流数据型选Kafka（高吞吐、可回溯），Azure生态优先Service Bus（免运维但吞吐较低）；CAP集成需针对性配置可靠性参数，延迟与可靠性可通过精细调优兼顾。
看业务类型：任务型还是流数据型？
这是选型的第一道分水岭。如果你的场景是「用户下单→扣库存→发短信→写积分」这类有明确起点终点、需要可靠投递和灵活路由的任务链，RabbitMQ 是最稳的选择；它用 Exchange + RoutingKey 实现精准分发，支持 DLX（死信交换机）、PriorityQueue、TTL 等关键能力，适合金融、电商等对语义强要求的系统。
如果是日志采集、用户行为埋点、实时风控规则匹配这类持续高吞吐、需回溯历史、常与 Spark/Flink 对接的流式场景，Kafka 的分区日志模型和 offset 机制天然适配，单节点轻松扛住 50w+ QPS。
若整个系统已深度绑定 Azure 生态（比如用了 Azure AD、App Service、Logic Apps），且团队不想操心集群运维，Azure Service Bus 提供开箱即用的 Session、Message Locking 和自动伸缩，但要注意它的吞吐上限比 Kafka 低一个数量级，且不支持消息重放（Replay）。
CAP 集成时配置差异很关键
.NET 生态下用 CAP 框架集成三者非常方便，但配置不当会踩坑：
-
UseRabbitMQ("host")默认不开启PublisherConfirms，高并发下丢消息风险高，必须显式启用：options.UseRabbitMQ(x => { x.Host = "localhost"; x.PublisherConfirms = true; }); -
UseKafka("localhost:9092")默认EnableAutoCommit为true，消费者崩溃可能导致重复消费；生产环境建议关掉，手动调用CommitAsync()控制 offset 提交时机。 -
UseAzureServiceBus("connstr")要注意TransportType：默认AmqpTcp，若走公网连接可能被防火墙拦截，内网推荐AmqpWebSockets；另外MaxConcurrentCalls不设限会导致线程池耗尽，建议按 CPU 核数 × 2 设置。
延迟与可靠性不是非此即彼，而是取舍组合
很多人以为「Kafka 延迟高所以不适合订单」，其实错在忽略配置粒度：
-
RabbitMQ在开启publisher confirms+queue.durable=true+delivery_mode=2后，平均延迟升至 8–15ms，但能保证磁盘落盘不丢； -
Kafka把acks=all+min.insync.replicas=2+retries=Int32.MaxValue配齐后，P99 延迟可压到 20ms 内，同时满足强一致性； -
Azure Service Bus的LockDuration默认 30 秒，若消费者处理超时未续锁，消息会被其他实例抢走——这在长事务中极易引发重复执行，必须配合幂等表或SessionId控制。
别忽略本地开发与监控成本
高并发系统上线前必须能压测、可观测：
-
RabbitMQ用 Docker 起单节点极快（docker run -d --name rabbit -p 5672:5672 -p 15672:15672 rabbitmq:management），自带 Web 管理页查队列积压、连接数、内存告警，但集群镜像队列模式下扩容麻烦； -
Kafka本地启动要连ZooKeeper或用KRaft模式（2.8+），推荐直接用confluentinc/cp-kafka镜像；监控依赖JMX+Prometheus，kafka-consumer-groups.sh查 lag 是每日必做动作； -
Azure Service Bus本地只能用azurite模拟，功能阉割严重（不支持Session、DeadLetter等），真实行为必须上云验证；所有指标走Azure Monitor，ActiveMessages和DeadLetterMessageCount这两个指标漏看一次就可能线上告警。
真正卡住多数团队的，从来不是吞吐数字，而是消息堆积后怎么快速定位是生产慢、消费卡、还是序列化失败——RabbitMQ 的 Get-Queue PowerShell 命令、Kafka 的 describe consumer group、Azure Portal 的「消息跟踪」功能，得提前练熟，而不是等报警了再 Google。
