redis在django中无需额外协议栈即可发消息，因其原生命令（如lpush/brpop、xadd/xreadgroup）通过redis-py一行调用即可实现，省去amqp等复杂抽象与初始化代码，且本地开发零配置、部署轻量、stream模式还可按需增强可靠性。
Redis 在 Django 里不用额外协议栈就能发消息
Django 本身不内置消息队列支持，但 Redis 的 LPUSH/BRPOP 或 XADD/XREADGROUP 操作，直接用 redis-py 就能调用，不需要理解 AMQP 协议、Exchange 类型、Binding 规则这些抽象概念。RabbitMQ 的 pika 库要求你显式声明 channel、queue、exchange，哪怕只是最简单的直连模式，也要写 5–6 行初始化代码；而 Redis 发一条任务，r.lpush('task_queue', json.dumps(payload)) 一行就完事。
没有消费者确认机制反而降低开发负担
对非关键路径任务（比如发通知、刷新缓存、轻量日志），你并不总需要“消息必须被且仅被处理一次”。RabbitMQ 的 basic_ack 流程强制你处理异常重试、手动确认、拒绝重入队等逻辑；Redis 的 BRPOP 是“取走即失”，没处理完崩溃就丢了——这反而是简化点：省去 ack 状态管理、死信队列配置、消费者心跳检测。列表模式下甚至不需要后台常驻消费者进程，用 manage.py 命令 + while True 轮询也能跑起来。
本地开发和测试几乎零配置
redis-server 启动后默认监听 localhost:6379，Django 只需配 REDIS_URL = 'redis://127.0.0.1:6379/0'，连密码、vhost、TLS 都可省；RabbitMQ 默认启用 guest/guest 认证，但生产环境必须改密码，且新版会禁用远程 guest 登录，amqp://guest:guest@localhost:5672/ 在 Docker 外经常连不上。更实际的是：Docker Compose 里起一个 Redis 容器比起 RabbitMQ（要配 Erlang 环境、3 个端口、management 插件）快 2–3 倍，CI 流程里也更稳定。
Stream 模式下想补可靠性也不难，但别默认开启
很多人以为 Redis 做 MQ 就是 PUB/SUB，其实那是广播、不存盘、无消费追踪——真正该用的是 Stream。它支持消费者组、消息 ID、ACK 和 XPENDING 查未确认项，功能上已接近 RabbitMQ。但注意：XGROUP CREATE 必须在首次 XADD 前执行，否则报错；且 XREADGROUP 不自动删除已确认消息，得手动 XACK + XDEL，否则 Stream 无限增长。这点容易被忽略，一跑两周就撑爆内存。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
