什么时候该用 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 不可用更“钝感”。
RabbitMQ：推荐用Polly包封装
IConnection.CreateModel()，对
BrokerUnreachableException做指数退避重连；不要依赖自动重连——它不恢复未确认消息状态 Kafka：
Confluent.Kafka会自动处理 broker 故障转移，但你要监听
consumer.OnError事件捕获
Local: TimedOut或
Local: AllBrokersDown，此时应记录告警而非 panic 退出 关键区别：RabbitMQ 的
channel.Close()是同步阻塞调用；Kafka 的
consumer.Close()是异步，必须 await
consumer.CloseAsync()才能确保 offset 提交完成
别被「都叫消息中间件」骗了：C# 代码里它们根本不是同一类东西
你写一个
OrderPlacedEvent类，在 RabbitMQ 里它是一条「待处理的任务」，发完就忘；在 Kafka 里它是一条「不可变事实」，会被多个下游系统反复读、聚合、归档。这种语义差异会直接决定你的 C# 类型设计和错误恢复策略。 例如：RabbitMQ 场景下，你可能在消息体里塞
RetryCount字段控制最大重试次数；Kafka 场景下，你绝不会在消息里加这个——重试由消费者自己管理，消息本身只存业务事实 序列化建议：RabbitMQ 推荐用
System.Text.Json直接序列化对象，简单高效；Kafka 更推荐 Avro + Schema Registry（尤其跨语言系统），否则字段增减容易引发
JsonSerializerException最容易被忽略的一点：Kafka 的 topic 是「先创建再用」，而 RabbitMQ 的 exchange/queue 可以 auto-declare。C# 启动时若没预创建 topic，
producer.ProduceAsync()会静默失败（除非显式配置
TopicMetadataRefreshIntervalMs并捕获
UnknownTopicOrPartition）
