流 · XB 现场笔记

Redis 发布订阅与流是两样工具

Sun, 06 Feb 2028 00:00:00 +0000

Redis 发布订阅与流解决的是不同的投递问题。发布订阅面向当前生效的订阅广播，不保留供以后回放的消息；流保存条目，读者可以在它们仍被保留时重新访问。选择哪种机制，首先要回答谁必须收到事件，以及消费者缺席期间应该发生什么。

先确定每个事件交给谁

对于后续状态可以替代的实时看板更新，只向在线用户广播也许已经足够。但在假设新听众已经到场之前，应等待订阅确认。重连恢复的是未来投递，不是错过的发布。PUBLISH 返回正数，表示按 Redis 命令语义统计到了接收者，不等于应用确认业务处理已经完成。

流有两种不同的消费方式。普通 XREAD 让独立读者分别指定自己的起始 ID，双方可以收到同一份保留历史。它既不自动分担工作，也不替每个连接保管检查点。同一个消费组中的 XREADGROUP 则在具名消费者之间分配新投递，并在未启用 NOACK 时记录待处理条目。

不同消费组允许账单、分析等独立工作流在同一条流上分别推进。组内增加成员是在分担工作，新建一组则是增加一套投递历史。消费者名字不同、工作进程变多，都不承诺负载均分或业务按序完成。应先确定需要的是广播、独立回放还是竞争处理，再选择对应的读取命令，不能把三种模式混为一谈。

保留窗口不是持久化设置

XADD 把数据保存在 Redis 里，并不自动保证每个已接受的写入都能熬过崩溃或故障切换。RDB/AOF 设置、复制行为、键淘汰及恢复操作共同决定持久性。发布订阅也不会因为启用了持久化，就突然拥有可回放的日志。因此，把两者概括成时效性与持久性的取舍，会掩盖各自的真实契约。

MAXLEN 删除的是最旧的条目，不是裁掉最新队尾、同时让早期历史一直保留。近似裁剪可能留下额外记录，精确裁剪则遵循指定数量；两者都不提供无限回放。默认裁剪还可能删除待处理引用对应的载荷，因此应围绕允许的最长停机时间与恢复后的追赶过程设计保留策略和容量。

保留积压也有运行成本。需要控制增长，分别观察未读滞后和待处理任务，并定义无法正常处理的消息如何处置。发布订阅虽然不保存历史，却仍使用连接输出缓冲；慢听众触达相应限制后可能被断开。两种机制都不能让内存规划消失，只是占用与丢失发生的位置不同。

坏掉的样子

用发布订阅派发必须执行的任务，订阅者缺席时就会失去投递机会。能够重新加载权威状态的看板可能接受这点，必须执行的财务操作通常不能接受。合适的替代品可以是保留消息的流，也可以是其他持久队列，但恢复语义必须围绕业务操作设计，不能从产品名字直接推导出来。

流若没有恢复循环，会出现另一种失败：已经投递但未确认的条目停留在待处理列表，普通 > 读取却继续处理新消息。处理前确认可能丢工作，处理后确认则允许重试时重复副作用。如果重复执行不可接受，稳定的事件标识和幂等处理仍是必需的，不能仅靠建组和追加消息解决。

把同一事件分别 PUBLISH 和 XADD，也不是原子双写协议。执行若在两次操作之间中断，可能只有一边成功。下面的实验在隔离进程中有意比较两种机制，不是在推荐用这一串命令构成生产送达保证。比较实验里的执行顺序，不应被直接提升为跨系统一致性方案。

快速验证

原有实验记录使用 macOS、Python 3.14.4、Redis 8.10.1 和 redis-py 8.1.0；本轮审阅没有重新执行服务实验，下面的结果说明保留原有观察范围。准备 POSIX 环境、C 编译器、make、curl、tar 与 Python 3.10 或更新版本。安装步骤仅用 libc 构建 Redis 核心，并把客户端装入临时虚拟环境。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

在同一终端用 "$redis_lab/venv/bin/python" 运行下面的 Python 代码。程序在 /tmp 下创建私有 Unix socket，关闭 TCP、定时快照和追加日志，最后只终止自己启动的进程并清理运行目录。下载依赖需要网络，不会连接默认端口上的本机 Redis。

from contextlib import contextmanager
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance():
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", "noeviction",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()


def receive(subscription):
 deadline = time.monotonic() + 2
 while time.monotonic() < deadline:
 response = subscription.get_message(timeout=0.1)
 if response is not None:
 return response
 raise AssertionError("subscription response timed out")


with instance() as client:
 assert client.publish("updates", b"offline") == 0
 first_id = client.xadd("history", {"event": "offline"}, id="1-0")
 with client.pubsub() as first, client.pubsub() as second:
 for subscription in (first, second):
 subscription.subscribe("updates")
 assert receive(subscription)["type"] == "subscribe"
 assert client.publish("updates", b"live") == 2
 second_id = client.xadd("history", {"event": "live"}, id="2-0")
 for subscription in (first, second):
 response = receive(subscription)
 assert response["type"] == "message" and response["data"] == b"live"
 with client.client() as reader_one, client.client() as reader_two:
 one = reader_one.xread({"history": "0-0"})
 two = reader_two.xread({"history": "0-0"})
 assert one == two
 assert [entry[0] for entry in one[0][1]] == [first_id, second_id]
 print("Pub/Sub listeners get live only; both independent XREAD readers replay offline and live")

 client.xgroup_create("history", "workers", id="0-0")
 a = client.xreadgroup("workers", "a", {"history": ">"}, count=1)[0][1]
 b = client.xreadgroup("workers", "b", {"history": ">"}, count=1)[0][1]
 assert a[0][0] == first_id and b[0][0] == second_id
 assert client.xpending("history", "workers")["pending"] == 2
 assert client.xack("history", "workers", first_id, second_id) == 2
 assert client.xlen("history") == 2
 print("one group splits new entries between a/b; ACK clears pending state, not stored history")

 third_id = client.xadd("history", {"event": "later"}, id="3-0")
 assert client.xtrim("history", maxlen=2, approximate=False) == 1
 retained = client.xread({"history": "0-0"})[0][1]
 assert [entry[0] for entry in retained] == [second_id, third_id]
 assert client.xrange("history", first_id, first_id) == []
 print("exact MAXLEN removes the oldest entry; replay is limited to retained history")

没有听众时发布 offline 返回零，而 XADD 保留了同名事件条目。等两个订阅都确认后，每个听众收到的是 live，而非 offline。随后两个普通 XREAD 都返回两条已保存记录，说明它们在独立回放，不是在把工作分成互不重叠的两份。

创建一个消费组后，投递方式发生变化：a、b 两个消费者得到不同条目，二者都被记入待处理列表。确认它们不会改变流长度。追加第三条后，精确 MAXLEN 只删除最旧条目；此时即使从零开始读取，也找不回它已经被删除的载荷，回放能力受保留窗口约束。

三条输出摘要都来自对真实响应的断言，展示了订阅在场、独立回放、组内分配与有限保留。实验没有比较延迟和内存，没有复现真实崩溃，没有验证持久化或自动恢复。这些运行决策仍然属于应用的投递契约，不能用一次本机实验成功替代。

来源

Redis 发布订阅，实时投递、订阅确认与不提供回放的语义，已核验 2026-09-08。
Redis XREAD，独立读取与调用方指定的位置，已核验 2026-09-08。
Redis XREADGROUP，分担工作与待处理条目，已核验 2026-09-08。
Redis XTRIM，删除最旧条目与引用策略，已核验 2026-09-08。
Redis 客户端管理，发布订阅的输出缓冲与断连限制，已核验 2026-09-08。
Redis 持久化，RDB 与 AOF 的恢复取舍，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与分配器选择，已核验 2026-09-08。

重定向重新安排流向

Wed, 29 Sep 2027 00:00:00 +0000

重定向在命令执行前改变它的文件描述符。Shell 从左到右处理每一项，遇到打开文件或复制描述符的操作，就在那个位置完成相应变更。描述符零、一、二通常分别表示标准输入、标准输出和标准错误。把命令行读成对这些句柄的顺序操作，就能解释诊断为什么去了错误的位置，也能解释文件为什么还没有被程序读取就已经变空。

打开文件本身就可能改变数据

>output 打开输出文件，并且通常把已存在的普通文件截断为零长度；>>output 使用追加方式，<input 则打开文件供读取。这些动作由 Shell 完成，不是命令所指程序的内部行为。如果必须打开的目标失败，命令不会执行，但此前已经成功的重定向仍可能创建或截断其他文件。不能把“程序没有启动”理解成“整条命令完全没有副作用”。

因此，sed expression input >input 会在转换程序读取数据之前破坏原文件。即便先写 <input 打开输入，后续重定向截断同一个底层文件，也不能保住那些内容。应写入独立临时文件，检查转换状态与结果，再根据文件归属、权限和所在文件系统，明确执行替换步骤。输入输出恰好同名时，不能指望 Shell 自动替你实现安全的原地编辑。

复制记住的是当下的目标

>log 2>&1 先让描述符一指向日志，再让描述符二引用同一个已打开目标。2>&1 >log 则先复制原来的标准输出，之后只改变描述符一，因此标准错误仍留在原目标，例如终端或负责捕获输出的管道。这里复制的是描述符引用，不是文件内容，也不是给两个数字建立一个会随之后续变化的动态连接。

Bash 的 &>log 可以简写同时重定向两条流，而 >log 2>&1 也适用于可移植 Shell。不要把它写成 >log 2>log：后者分别打开同一个文件，两份打开状态拥有独立偏移量，输出可能相互覆盖。即使描述符共享一个目标，应用程序自身的缓冲仍会影响消息真正写出的时间，所以合并日志也不自动保证业务事件严格按发生顺序排列。

管道会先把标准输出连接到下一阶段，然后才应用命令自己的重定向。因此 producer >file | consumer 的生产者把输出交给了文件，消费者反而读不到那些数据。相反，producer 2>&1 | consumer 会把诊断也送进管道。如果下游要求机器可解析的记录，把面向人的错误文本混进去，就可能破坏原本合法的输入格式。

坏掉的样子

文件名来自变量时应加引号，避免空格让目标展开成多个词。描述符编号必须紧贴操作符：2>errors 重定向标准错误，2 >errors 却把数字二作为普通参数传给命令，并重定向标准输出。一个空格就可能同时改变程序收到的输入参数和输出位置，排查时不能只看目标文件名有没有拼对。

Bash 的 set -C 启用禁止覆盖模式，通常会拒绝用普通输出重定向覆盖已存在的普通文件。这有助于防止误操作，但不是备份机制，也不是对所有文件类型的统一保护；>| 会明确绕过这个选项。还要区分单条命令的临时重定向与 exec >log：后者修改当前 Shell 的描述符，可能把后续所有命令的输出一起转走，不能在交互验证时无意间让整个会话失声。

快速验证

下面的完整实验使用 Bash 和常见 Unix 工具，只会截断、删除刚创建的专用临时文件。它比较两种重定向顺序，演示输入输出同文件时的数据丢失，并验证目标无法打开时函数体确实没有运行。清理步骤逐个列出实验文件，不使用递归删除，也不会触碰原有文件。

bash --noprofile --norc <<'BASH'
set -eu
demo_dir=$(mktemp -d)
trap 'rm -f "$demo_dir/both" "$demo_dir/out" "$demo_dir/input"; rmdir "$demo_dir"' EXIT
emit() { printf 'out\n'; printf 'err\n' >&2; }
emit > "$demo_dir/both" 2>&1
demo_captured=$(emit 2>&1 > "$demo_dir/out")
[ "$(cat "$demo_dir/both")" = "$(printf 'out\nerr')" ]
[ "$(cat "$demo_dir/out")" = out ]
[ "$demo_captured" = err ]
printf 'both:\n'
cat "$demo_dir/both"
printf 'out-file=[%s] captured=[%s]\n' \
 "$(cat "$demo_dir/out")" "$demo_captured"
printf 'seed\n' > "$demo_dir/input"
sed 's/seed/replaced/' "$demo_dir/input" > "$demo_dir/input"
[ ! -s "$demo_dir/input" ]
printf 'input truncated\n'
if (set -C; emit > "$demo_dir/both") 2>/dev/null; then
 printf 'unexpected overwrite\n' >&2
 exit 1
else
 printf 'noclobber rejected overwrite\n'
fi
demo_ran=no
mark_run() { demo_ran=yes; }
if mark_run 2>/dev/null > "$demo_dir/missing/output"; then
 printf 'unexpected redirection\n' >&2
 exit 1
else
 [ "$demo_ran" = no ]
 printf 'function-ran=%s\n' "$demo_ran"
fi
BASH

合并文件应打印 out 和 err。交换顺序后，输出文件只含 out，变量单独捕获到 err。转换实验报告输入已经变空，因为截断先于程序读取。最后两行分别证明禁止覆盖选项拒绝了替换，以及目标打开失败时仍为 function-ran=no，函数中的赋值没有执行。

明确比较与失败分支让异常结果以失败状态退出，不会只打印意外信息后继续成功结束。这些检查同时观察文件内容与命令是否真正执行，而不是只依赖最后一条打印命令成功。在真实脚本中，还要把生产者退出状态与日志一起保留下来：错误消息即使准确进入了日志，也不能把失败操作变成成功。只有分别保留流向和状态两类证据，后续恢复判断才有可靠依据。

来源

Bash 参考手册：重定向，从左到右的描述符变更及禁止覆盖行为，已核验 2026-09-07。
POSIX Shell 重定向，可移植的重定向运算符及文件打开语义，已核验 2026-09-07。

Redis 流消费组记录投递位置

Tue, 13 Jul 2027 00:00:00 +0000

Redis 流不会自动为每个连接维护独立游标。普通 XREAD 使用应用提供的位置；消费组则在服务端保存一份组级最后投递位置，加上待处理记录。混淆这两类进度，可能让重启后的消费者跳过未完成任务，也可能重新执行早已完成的业务操作。

消费组在投递时推进位置

XGROUP CREATE 使用 0-0 时从保留历史之前开始，使用 $ 则从当前末端之后开始。每个组在同一份流记录上维护独立投递状态：账单组可能已投递两条，分析组却只投递一条。同一组内的具名消费者分担新工作，并不是每人都得到每一条消息。

在未启用 CLAIM 或 NOACK 的普通 XREADGROUP 中，> 请求组投递位置之后的条目，并把新投递加入待处理列表 PEL。这一位置在业务处理和确认之前就已经前移。XACK 只移除某一组里指定的待处理 ID，不删除流记录，也不推进该组最后投递 ID。

确认可以乱序到达。第二条完成，不代表第一条已经完成；组的投递位置也可以到达流末端，同时仍有旧条目处于待处理状态。除非应用契约确实保证连续完成，否则不能用最大的已投递 ID 或已确认 ID，反推它之前所有业务都已成功执行。

待处理历史属于具名消费者

XREADGROUP 使用 0-0 时，请求的是当前名字对应的待处理历史，不是随意回放整条流。一个新名字看不到另一位消费者名下的待处理条目。重启时换个名字，只读 >，不会恢复之前遗留的投递；服务可能不断处理新任务，看起来正常运行，旧任务却再也没有推进。

恢复需要读取原消费者的待处理历史，或显式转移符合条件的任务，例如使用 XAUTOCLAIM。空闲阈值必须考虑正常处理时长。当前 Redis 也支持可选的 XREADGROUP CLAIM，本实验未启用。转移归属无法阻止迟到的旧工作进程重复外部动作，因此仍需要与业务风险匹配的去重策略。

可以用 XINFO GROUPS 对比 last-delivered-id、pending 和 lag。lag 估计从组当前位置起仍待投递的条目，不是尚未完成的业务动作。某些重设位置或删除操作后，该指标可能无法计算；空值不等于零。lag 为零而 pending 非零，表示新消息已投递到末端，但仍有投递等待确认。

坏掉的样子

XGROUP SETID 是对组投递位置的主动修改，不是无害的确认修复。完成工作后回退，会让仍保留的已确认条目再次成为新投递候选；向前跳则可能越过未读条目。它不会自动清空既有 PEL，前移或后退也都不会改变另一消费组的位置，必须把这些状态分别检查。

执行重设位置前，需要协调消费者，并理解重新处理会造成哪些业务副作用。用新消费组做回放，隔离的是投递账本；如果调用同一个业务处理器，外部副作用并不因此隔离。确认不是永久禁止再次读取记录的删除标记，不应靠回退位置代替诊断真实的待处理条目。

不同组拥有独立位置，不代表拥有独立保留空间。删除或裁剪共享载荷，会影响所有还需要该内容的组。默认 KEEPREF 裁剪可能留下 ID，却移除对应数据。服务器故障后的持久性也与游标机制分开决定。位置被记录，既不能证明载荷仍可恢复，也不能证明对应业务已处理成功。

快速验证

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

from contextlib import contextmanager
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance():
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", "noeviction",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()


def groups(client):
 return {group["name"]: group for group in client.xinfo_groups("events")}


with instance() as client:
 for entry_id in ("1-0", "2-0", "3-0"):
 client.xadd("events", {"event": entry_id}, id=entry_id)
 for name in ("billing", "analytics"):
 client.xgroup_create("events", name, id="0-0")
 billing = client.xreadgroup("billing", "b1", {"events": ">"}, count=2)[0][1]
 analytics = client.xreadgroup("analytics", "a1", {"events": ">"}, count=1)[0][1]
 assert [entry[0] for entry in billing] == [b"1-0", b"2-0"]
 assert [entry[0] for entry in analytics] == [b"1-0"]
 state = groups(client)
 assert state[b"billing"]["last-delivered-id"] == b"2-0"
 assert state[b"analytics"]["last-delivered-id"] == b"1-0"
 assert state[b"billing"]["pending"] == 2 and state[b"analytics"]["pending"] == 1
 assert state[b"billing"]["lag"] == 1 and state[b"analytics"]["lag"] == 2
 print("two groups read overlapping records but retain independent positions and PELs")

 assert client.xack("events", "billing", "2-0") == 1
 state = groups(client)
 assert state[b"billing"]["last-delivered-id"] == b"2-0"
 assert state[b"billing"]["pending"] == 1 and state[b"analytics"]["pending"] == 1
 assert client.xreadgroup("billing", "b2", {"events": "0-0"}) == [[b"events", []]]
 own = client.xreadgroup("billing", "b1", {"events": "0-0"})[0][1]
 assert [entry[0] for entry in own] == [b"1-0"]
 next_entry = client.xreadgroup("billing", "b2", {"events": ">"})[0][1]
 assert [entry[0] for entry in next_entry] == [b"3-0"]
 assert groups(client)[b"billing"]["lag"] == 0
 assert groups(client)[b"billing"]["pending"] == 2
 assert client.xack("events", "billing", "1-0", "3-0") == 2
 assert groups(client)[b"billing"]["pending"] == 0
 assert client.xpending("events", "analytics")["pending"] == 1
 assert client.xlen("events") == 3
 print("ACK affects only one group's PEL; a new consumer sees no other owner's pending history")

 client.xgroup_setid("events", "billing", "0-0")
 replay = client.xreadgroup("billing", "b3", {"events": ">"}, count=1)[0][1]
 assert [entry[0] for entry in replay] == [b"1-0"]
 assert groups(client)[b"analytics"]["last-delivered-id"] == b"1-0"
 assert client.xack("events", "billing", "1-0") == 1
 client.xgroup_setid("events", "analytics", "$")
 state = groups(client)
 assert state[b"analytics"]["last-delivered-id"] == b"3-0"
 assert state[b"analytics"]["pending"] == 1
 assert state[b"analytics"]["lag"] == 0
 assert client.xreadgroup("analytics", "a1", {"events": ">"}) == []
 own = client.xreadgroup("analytics", "a1", {"events": "0-0"})[0][1]
 assert [entry[0] for entry in own] == [b"1-0"]
 assert client.xack("events", "analytics", "1-0") == 1
 print("SETID rewinds acknowledged data for replay; moving forward skips unread data but keeps PEL")

账单组读取两条、分析组读取一条，得到不同投递位置和待处理数量。确认账单组第二条只改变其 PEL。b2 无法读取 b1 的待处理历史，却能接到下一条新记录。账单组的新条目全部投递后，lag 已经是零，但此时还有两条投递等待确认，直接说明两类计数不能互相替代。

在账单组任务全部确认后，显式回退位置，b3 又拿到了 1-0。分析组状态并未随之改变。把分析组前移到 $，会跳过它的未读记录，但原有待处理 1-0 仍然存在，原消费者还可以读出并确认。这个行为同时展示了位置重设与确认不是同一操作。

所有状态比较都基于 Redis 的实际响应，不需要假设精确时序或启动并发工作进程。实验验证组间隔离、投递位置、待处理归属与显式重设位置，没有实现崩溃检测、恢复调度、持久化测试或具有事务安全性的业务处理。读者应先确定希望修复哪一类状态，再决定操作哪一个命令。

来源

Redis XREAD，独立读者提供的读取位置，已核验 2026-09-08。
Redis XREADGROUP，组投递位置与消费者待处理历史，已核验 2026-09-08。
Redis XACK，仅作用于指定组的待处理确认，已核验 2026-09-08。
Redis XINFO GROUPS，最后投递 ID、待处理计数及滞后统计的限制，已核验 2026-09-08。
Redis XGROUP SETID，显式重设组位置，已核验 2026-09-08。
Redis XAUTOCLAIM，显式恢复符合条件的待处理条目，已核验 2026-09-08。
Redis XTRIM，载荷保留与消费组引用，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与分配器选择，已核验 2026-09-08。

Redis 流按顺序保管事件供消费

Thu, 06 May 2027 00:00:00 +0000

Redis 流把条目保存在有序 ID 下，读者可以重新读取尚未删除的历史。与发布订阅不同，生产者追加时读者不必在线。这个差别提供的是回放能力，不是无条件持久性：条目删除、保留限制及持久化设置仍决定延迟或故障后究竟还剩下什么。

区分写入顺序与事件时间

XADD 使用 * 时生成包含毫秒部分和序列部分的 ID。在同一条流内，ID 单调递增，Redis 必要时会补偿本机时钟回退。显式提供的 ID 也必须大于这条流最后生成的 ID。比较时应比较两个数值部分，不能把任意长度的字符串字典序当成数值顺序。

ID 排定的是写入该流的顺序，不会建立多条独立流之间的全局顺序，也不证明外部事件真正发生的时间。需要业务时间时，应单独保存相应字段。两次普通 XADD 即使字段完全相同，也会创建两个不同条目：自动 ID 标识记录，并不自动识别重复业务操作。

保存最后处理的位置

XRANGE 默认包含起止两端。把已经处理过的最后一个 ID 作为起点，会再次返回该条目；在边界前加左圆括号可以排除它。XREAD 则返回严格大于指定 ID 的条目。配合 COUNT 分批读取时，应保存最后返回的 ID，下次从这个位置继续。

普通 XREAD 不会替每个读者维护服务端偏移，也不会移除已投递条目。独立读者可以读取同一范围，重复请求也会重复返回仍被保留的数据。检查点由应用负责：副作用之前保存位置，故障后可能跳过尚未执行的工作；副作用之后保存，故障后可能重复已经完成的工作。不能接受这类差异时，需要把位置推进与幂等处理协调起来。

美元符号 ID 表示从 Redis 处理这次调用时的流末端之后开始。它适合首次进入实时订阅，不适合恢复已有进度。每次响应后继续用 $，会跳过两次调用之间追加的条目。收到数据后应使用真实的最后一个 ID。消费组另行增加投递与确认状态；XACK 并不是普通 XREAD 的偏移提交命令。

坏掉的样子

慢读者可能落后于保留窗口。XTRIM MAXLEN 删除最旧、ID 最小的条目，留下较新的内容，不是裁掉最新的一端。使用默认引用策略时，精确 MAXLEN 执行数量限制；近似裁剪可能为了效率多保留条目。ACKED 策略还可能为了保留未确认条目而超过这个数量。redis-py 的 xtrim 默认使用近似模式，因此实验显式将其关闭。

XDEL 可以删除指定记录。不能因为某个消费者还没有确认，就认为删除或很短的保留窗口不会丢数据。默认 KEEPREF 裁剪可能留下待处理引用，却删除对应载荷。Redis 8.2 新增了包括 ACKED 在内的显式引用策略，但保留策略仍由应用决定。已经保存的 ID 不能重建被删除的数据。

流也是 Redis 数据，会受 RDB/AOF 设置、复制行为、键删除及可能的内存淘汰影响。一次追加成功，不能证明故障切换无损或业务恰好执行一次。应结合消费者可能离线的时间和追赶能力设置保留范围，监控滞后，并用实际持久化配置演练恢复。本实验特意关闭持久化，不承诺重启后数据仍然存在。

快速验证

需要 POSIX 环境、C 编译器、make、curl、tar，以及 Python 3.10 或更新版本。此前记录的执行环境是 macOS、Python 3.14.4、Redis 8.10.1 和 redis-py 8.1.0；本轮审阅没有重新运行。它们使用 libc 构建 Redis 核心，并把客户端安装到临时虚拟环境，不构建可选模块，也不做系统级安装。

redis_lab=$(mktemp -d)
curl --fail --location --output "$redis_lab/redis.tar.gz" https://download.redis.io/releases/redis-8.10.1.tar.gz
tar -xzf "$redis_lab/redis.tar.gz" -C "$redis_lab"
make -C "$redis_lab/redis-8.10.1" build redis -j2 MALLOC=libc
export REDIS_SERVER="$redis_lab/redis-8.10.1/src/redis-server"
python3 -m venv "$redis_lab/venv"
"$redis_lab/venv/bin/python" -m pip install redis==8.1.0

from concurrent.futures import ThreadPoolExecutor

from contextlib import contextmanager
import os
from pathlib import Path
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.retry import Retry


@contextmanager
def instance():
 with TemporaryDirectory(prefix="redis-lab-", dir="/tmp") as directory:
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--save", "", "--appendonly", "no", "--dir", directory,
 "--maxmemory-policy", "noeviction",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False,
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 deadline = time.monotonic() + 5
 while True:
 assert process.poll() is None, "Redis exited during startup"
 try:
 if client.ping():
 break
 except redis.ConnectionError:
 if time.monotonic() >= deadline:
 raise
 time.sleep(0.02)
 yield client
 finally:
 client.close()
 if process.poll() is None:
 process.terminate()
 try:
 _, errors = process.communicate(timeout=5)
 except subprocess.TimeoutExpired:
 process.kill()
 process.communicate()
 raise
 assert process.returncode == 0, errors.decode()


def ids(entries):
 return [entry[0] for entry in entries]


with instance() as client:
 for entry_id in ("1-0", "1-1", "2-0"):
 assert client.xadd("events", {"value": entry_id}, id=entry_id) == entry_id.encode()
 try:
 client.xadd("events", {"value": "duplicate"}, id="1-1")
 except redis.ResponseError as error:
 assert "equal or smaller" in str(error)
 else:
 raise AssertionError("XADD must reject an ID below the stream's last ID")
 generated = [client.xadd("auto", {"value": "same"}) for _ in range(2)]
 assert tuple(map(int, generated[0].split(b"-"))) < tuple(map(int, generated[1].split(b"-")))
 assert client.xlen("auto") == 2
 print("explicit IDs advance; duplicate/lower ID rejected; equal payloads get distinct auto IDs")

 assert ids(client.xrange("events", "1-1", "+")) == [b"1-1", b"2-0"]
 assert ids(client.xrange("events", "(1-1", "+")) == [b"2-0"]
 first = client.xread({"events": "0-0"}, count=2)
 second = client.xread({"events": "0-0"}, count=2)
 assert first == second and ids(first[0][1]) == [b"1-0", b"1-1"]
 saved = first[0][1][-1][0]
 remaining = client.xread({"events": saved})
 assert ids(remaining[0][1]) == [b"2-0"]
 saved = remaining[0][1][-1][0]
 print("XRANGE includes its start; XREAD excludes the saved ID; independent reads replay")

 client.xadd("events", {"value": "between-calls"}, id="3-0")
 assert client.xread({"events": "$"}, block=100) == []
 assert ids(client.xread({"events": saved})[0][1]) == [b"3-0"]

 def read_live():
 with client.client() as connection:
 connection.client_setname("stream-lab-reader")
 return connection.xread({"events": "$"}, block=1000)

 with ThreadPoolExecutor(max_workers=1) as worker:
 future = worker.submit(read_live)
 deadline = time.monotonic() + 1
 while not any(
 entry["name"] == "stream-lab-reader" and "b" in entry["flags"]
 for entry in client.client_list()
 ):
 assert time.monotonic() < deadline, "reader never blocked"
 time.sleep(0.01)
 client.xadd("events", {"value": "live"}, id="4-0")
 assert ids(future.result(timeout=2)[0][1]) == [b"4-0"]
 print("$ skips existing entries; a saved ID catches up; observed blocking receives a new entry")

 assert client.xdel("events", "2-0") == 1
 assert client.xrange("events", "2-0", "2-0") == []
 assert client.xtrim("events", maxlen=2, approximate=False) == 2
 assert ids(client.xrange("events")) == [b"3-0", b"4-0"]
 assert ids(client.xread({"events": "0-0"})[0][1]) == [b"3-0", b"4-0"]
 print("XDEL removes a record; exact MAXLEN keeps the newest two; old IDs cannot restore deleted data")

显式 ID 形成可预测的三条记录。再次提交更旧的 ID 会失败，而两次自动追加相同载荷仍得到递增且不同的 ID。边界断言展示 XRANGE 会包含 1-1，XREAD 则严格从它之后继续。两个从零开始的独立读取返回完全相同的数据，没有任何一方把数据从流里消费掉。

在 $ 调用之前追加的条目被跳过，该调用最终超时；从已保存 ID 读取则可以找回它。实时读取部分先等待 CLIENT LIST 报告具名读者确实处于阻塞状态，再追加 4-0。断言检查收到的记录，而不是要求调度器在某个精确毫秒内完成唤醒。

最后，XDEL 删除 2-0，精确 MAXLEN 只保留 3-0 和 4-0。此时再从零读取，也只能取得这两条仍然存在的记录。结果说明了 ID 顺序、游标边界、实时等待以及保留策略导致的丢失；没有验证崩溃持久性、消费组恢复、跨流顺序或生产吞吐。读取能够成功，不代表历史仍然完整。

来源

Redis XADD，条目 ID 与单调递增顺序，已核验 2026-10-15。
Redis XREAD，排除已保存位置、阻塞与美元符号 ID，已核验 2026-10-15。
Redis XRANGE，包含及排除范围边界，已核验 2026-10-15。
Redis XTRIM，保留限制与待处理引用策略，已核验 2026-10-15。
Redis XDEL，显式删除保留的条目，已核验 2026-10-15。
Redis 持久化，RDB 与 AOF 的持久性取舍，已核验 2026-10-15。
Redis 8.10.1 构建说明，仅构建核心与分配器选择，已核验 2026-10-15。

流 · XB 现场笔记

Redis 发布订阅与流是两样工具

先确定每个事件交给谁

保留窗口不是持久化设置

坏掉的样子

快速验证

来源

重定向重新安排流向

打开文件本身就可能改变数据

复制记住的是当下的目标

坏掉的样子

快速验证

延伸阅读

来源

Redis 流消费组记录投递位置

消费组在投递时推进位置

待处理历史属于具名消费者

坏掉的样子

快速验证

来源

Redis 流按顺序保管事件供消费

区分写入顺序与事件时间

保存最后处理的位置

坏掉的样子

快速验证

来源