04 - 选型：RabbitMQ 还是 Kafka 还是 Redis

概念都懂了，现在面对现实问题：到底用哪个？ 市面上消息队列一大堆，但对你（Python + FastAPI 后端）来说，真正需要在意的就三个：RabbitMQ、Kafka、Redis。这一章帮你彻底理清它们的定位差异，并解释为什么本教程给你定了 RabbitMQ。

4.1 一句话认清三者的定位

框架	一句话定位	打个比方
RabbitMQ	专业、灵活的消息队列，擅长复杂的任务分发与路由	一个训练有素的邮局：能按各种规则把信精准投递到对应信箱
Kafka	高吞吐的事件流平台，为海量数据流、日志而生	一条永不停歇的传送带：数据像流水一样源源不断地过
Redis	内存数据库顺便能当轻量队列	一个身兼数职的便利店：主业卖东西，也能帮你临时寄存包裹

核心区别：RabbitMQ 是”为消息队列而生”，Kafka 是”为数据流而生”，Redis 是”为缓存而生，队列是副业”。

4.2 三者详细对比

维度	RabbitMQ	Kafka	Redis
本质	专业消息中间件	分布式事件流平台	内存数据库（兼职做队列）
吞吐量	万级/秒（够绝大多数业务用）	百万级/秒（为海量而生）	高（受内存与实现限制）
消息可靠性	很强（持久化、确认、死信队列）	很强（消息持久化到磁盘，可回溯重放）	一般～较强（Stream 类型较可靠，List 简单）
路由能力	⭐ 极强（交换机支持多种灵活路由）	弱（按 Topic 分区，路由简单）	弱
消息保留	被消费确认后即删除	按时间/大小保留，可反复重放历史	看用法，通常消费即走
学习/运维成本	中等	较高（概念多：分区、副本、消费组、offset）	低（你已经学过 Redis）
典型场景	异步任务、服务解耦、削峰、复杂路由	日志收集、大数据管道、埋点、实时流处理	轻量异步任务、简单通知

4.3 什么时候用谁：给你一张决策图

你的需求是什么？
│
├─ 是"处理业务任务"（发邮件、下单后置处理、服务解耦、削峰）？
│     │
│     ├─ 项目很轻、任务简单、又不想多装一个 Broker，
│     │  而且已经在用 Redis？
│     │        → 【Redis】 够用，简单省事
│     │
│     └─ 想要正经、可靠、能灵活路由的消息队列？
│              → 【RabbitMQ】 ✅ 本教程主线，最标准的选择
│
└─ 是"处理海量数据流"（每秒几十万条日志、埋点、需要回放历史数据、
   接大数据/实时计算）？
          → 【Kafka】 专为此而生

一句话记忆：

做业务、要可靠、要灵活 → RabbitMQ

搞大数据流、超高吞吐、要回放 → Kafka

场景简单、想省事、已经有 Redis → Redis

4.4 为什么本教程给你定 RabbitMQ

结合你的现状（正在学后端、已掌握 FastAPI + PostgreSQL + Redis + Docker），选 RabbitMQ 是最优解：

它是最好的”消息队列教材” 生产者、消费者、队列、交换机、路由、确认、死信……消息队列该有的核心概念，RabbitMQ 全都清晰完整。学会它，你就掌握了通用的 MQ 思维，以后看 Kafka 也能快速上手。
和 Python / FastAPI 生态最贴合 中小型 Web 系统做异步任务，主流就是 RabbitMQ（常配合 Celery）。你学完能直接用在真实项目里。
比 Kafka 轻，负担小 Kafka 的分区、副本、消费组、offset 等概念是为”大数据流”设计的，对你现在”建立架构直觉”这个阶段是额外负担。等你真要处理海量数据流时再学它，不迟。
比 Redis 更”正经” Redis 当队列是”副业”，可靠性和功能都有限，适合轻量场景。而 RabbitMQ 是专业选手，能让你完整体会消息队列的全套机制。

结论：先用 RabbitMQ 把”消息队列”这件事彻底学明白。它是理解一切 MQ 的基石。至于 Kafka，把它当成”以后处理大数据流时的专用武器”，用到再学。

4.5 顺带一提：Celery 是什么？

学 Python 消息队列时你一定会听到 Celery，别搞混：

Celery 不是消息队列，它是一个 Python 的**“分布式任务队列”框架**。
它自己不存消息，而是架在 RabbitMQ（或 Redis）之上，帮你把”定义任务、发任务、后台执行任务”这套流程封装得很好用。

┌─────────────┐     ┌──────────────┐     ┌─────────────┐
│  FastAPI    │────▶│ Celery + Broker│────▶│ Celery Worker│
│ 调用任务      │     │ (RabbitMQ/Redis)│     │ 执行任务      │
└─────────────┘     └──────────────┘     └─────────────┘
                     ↑ RabbitMQ 在这里当"底层运输工"

简单说：RabbitMQ 是底层的”运输管道”，Celery 是上层帮你好用的”任务管理工具”。本教程聚焦讲清楚底层的 RabbitMQ 原理；等你理解了它，再用 Celery 会非常顺。

本章小结

知识点	要点
三者定位	RabbitMQ=专业消息队列；Kafka=海量事件流；Redis=缓存兼职做队列
选型主线	做业务用 RabbitMQ；大数据流用 Kafka；轻量省事用 Redis
为什么选 RabbitMQ	最标准的 MQ 教材、贴合 FastAPI 生态、比 Kafka 轻、比 Redis 正经
Celery 的关系	Celery 是上层任务框架，RabbitMQ 是它底下的运输管道，两者常搭配

下一章预告：正式认识 RabbitMQ 的内部架构——交换机（Exchange）、队列、绑定、路由键，看它是怎么把消息精准送到对的地方的。

上一章 ← 03 - 解决的三大问题｜下一章 → 05 - RabbitMQ 的架构与工作原理