消息队列选型：Kafka、RabbitMQ、NATS，先看消费模型再看吞吐

判断顺序：
先问消费模型：是需要多个消费者各自读到全量事件（Kafka 的消费组语义），还是任务分发给 worker 后删除（RabbitMQ 更自然），还是轻量服务间通知（NATS 够用）。再看吞吐和重放需求。最后看团队运维半径。

一个常见错配：
用 Kafka 做任务队列，结果每个任务需要独立确认和重试，分区位点管理变得很别扭；或者用 RabbitMQ 做事件流重放，消息消费完就没了。不是工具不好，是模型不匹配。

务实建议：
已有 Kafka 且团队熟悉，新需求优先复用，别为轻量任务再引入一套。没有强重放需求、任务队列为主，RabbitMQ 的学习和运维成本更友好。边缘、IoT、低延迟轻量消息可以看 NATS，但持久化和集群成熟度要按场景验证。选型的终点不是“哪个最强”，是“哪个消费模型和你的业务语义最接近”。