KEEL · 龙骨 · A CURRICULUM FOR THE AI ERA
Redis 拔高：Stream、分布式锁与 ARQ — keel 龙骨
以一个 Agent 系统的 Redis 三重角色（队列/状态/事件日志）为地图：Stream 的 XADD/XREAD/ID 语义与断线复原地基、Pub/Sub vs List vs Stream 选型、分布式锁三件套（SET NX EX + UUID + Lua）逐行拆与诚实边界、工作流锁的业务封装套路、ARQ 任务队列与 Redis 的结合。
以一个 Agent 系统的 Redis 三重角色（队列/状态/事件日志）为地图：Stream 的 XADD/XREAD/ID 语义与断线复原地基、Pub/Sub vs List vs Stream 选型、分布式锁三件套（SET NX EX + UUID + Lua）逐行拆与诚实边界、工作流锁的业务封装套路、ARQ 任务队列与 Redis 的结合。
章节目录
- 00 · 一个 Redis，三种角色：全局地图 — 这章是地图。后面六章分别深入其中一条路。地图要回答一个核心问题：同一个 Redis，凭什么能同时当队列、状态库和事件日志，还互不干扰？
- 01 · Redis Stream 原生命令：消费者组是核心 — 这一章只做一件事：让你在 redis-cli 里把 Stream 的命令亲手敲一遍。不碰 Python、不碰 ARQ。理由很直接——ARQ 重度依赖 Stream 的消费者组，消费者组没吃透，ARQ 永远是一团谜。
- 02 · Stream vs Pub/Sub vs List：到底什么时候用哪个 — 上一章把 Stream 吃透了。这一章回答一个更实用的问题：Redis 里能「传消息」的结构至少有三种（List / Pub/Sub / Stream），我该选哪个？ 选型不是比参数，而是比语义对不对口——用错结构，后面的坑全是你自己挖的。
- 03 · 用 redis-py 手写最小消费组（先别碰 ARQ） — 第 1 章你在 redis-cli 里把命令敲熟了。这一章换 Python：用 redis-py 手写一个最小消费者组——生产者 + 消费者循环 + ack。做到能跑通「生产 → 消费 → ack → 故障重跑」全流程。这一步是理解 ARQ 的脚手架：等你手搓过一遍，第 6 章看 ARQ 源码会像看自己写的代码。
- 04 · 分布式锁：SET NX EX + UUID + Lua — 前面三章讲「队列」，是 Redis 当运行时的第一类问题。这一章讲第二类：多进程互斥。重点回答三个「为什么」——为什么 NX 和 EX 要一起用？为什么锁值要用 UUID？为什么释放要用 Lua 脚本？最后说清它到底保不保什么。
- 05 · 业务锁封装：把基础设施翻译成业务语言 — 第 4 章的分布式锁是通用的——key 你随便传、异常是通用的 Redis 异常。但业务代码想要的是：「锁住某次工作流运行（可选精确到节点）」「抢不到时抛的是业务认识的异常」。这一章讲清楚基础能力 → 业务能力的封装套路，套路本身和你用什么业务无关：key 规范化 + 异常翻译 + 组合而非继承。
- 06 · ARQ 源码与使用：看懂它在 Redis 里写了什么 — 第 3 章你手搓过最小消费组。这一章回到主线：ARQ（基于 Redis 的 Python 异步任务队列）到底在 Redis 里写了什么？它的 Worker 主循环是怎么跑的？重点不是会调 API，而是打开 redis-cli monitor，亲眼看到它发出的每一条 Redis 命令——那一刻 ARQ 就不再是黑盒。