RabbitMQ适用于需可靠交付、事务性任务及微服务同步的场景，如订单确认、支付回调；Kafka适用于日志采集、事件溯源、实时流计算及消息重放。
什么时候该用 RabbitMQ：需要可靠交付、事务性任务、微服务间同步语义
如果你的 C# 项目涉及订单确认、支付回调、邮件/短信通知这类「必须成功一次」的业务，RabbitMQ 是更稳妥的选择。它原生支持消息持久化 + 手动 ACK + 死信队列（DLX），配合 IBasicConsumer 和 IModel.ConfirmSelect()，能轻松实现「发出去 → 被消费 → 显式确认 → 失败进死信」闭环。
- 常见错误：没调用
channel.BasicAck()就直接 return，导致消息重复投递；或忘了设deliveryMode = 2，重启后消息全丢 - C# SDK 推荐用官方
RabbitMQ.Client（NuGet 包名同名），避免用封装过深的第三方抽象层——它们常隐藏重连逻辑和 channel 生命周期问题 - 性能影响：单节点 RabbitMQ 在默认配置下吞吐约 3–5k msg/s；若需更高，得开镜像队列 + 多消费者 + 预取值（
basicQos(prefetchSize: 0, prefetchCount: 10)）调优，否则容易堆积
什么时候该用 Kafka：日志采集、事件溯源、实时流计算、需消息重放
如果你在写一个 .NET 6+ 的实时风控服务，要消费上游所有用户点击流、按 session 聚合、再推给 Flink 做异常检测，那就选 Kafka。它的分区（partition）模型天然支持水平扩展，且每条消息带 offset，允许任意时间点 rewind 重播——RabbitMQ 做不到这点。
- 常见错误：用
Confluent.Kafka的ConsumerBuilder时忽略AutoOffsetReset设置，导致新消费者启动后「看不见历史数据」或「从头疯狂刷旧消息」 - 使用场景：C# 中适合搭配
Microsoft.Extensions.Hosting.IHostedService封装 Kafka 消费者，但注意别在Consume()里做耗时 IO（如 DB 写入），否则会卡住 poll 循环，触发 rebalance - 参数差异：
EnableAutoCommit = false必须关掉，改用手动consumer.Commit()控制 offset 提交时机；否则网络抖动可能造成「消息已处理但 offset 未提交→重复消费」
RabbitMQ 和 Kafka 在 C# 里的连接与错误处理差异
两者底层容错机制完全不同：RabbitMQ 的 connection/channel 是短生命周期、易断连需重试；Kafka 的 consumer 是长连接、靠心跳保活，但对 broker 不可用更“钝感”。
