消息 · 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。

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。

Redis 发布订阅广播消息但不保留回放

Wed, 17 Feb 2027 00:00:00 +0000

Redis 发布订阅面向消息发布时已经生效的订阅广播，不会为断线的听众保留收件箱。它适合可以被后续状态替代的实时通知，但 PUBLISH 返回正数，并不证明某个工作进程完成了任务，也不表示离线消费者回来后能够补领消息。

订阅是一次握手

SUBSCRIBE 会先返回订阅确认，连接随后才能收到后续发布的消息。协调发布者与新听众时，应等待这份确认。仅仅把订阅请求发送出去还不够：Redis 处理请求之前，另一个连接就可能已经发布。重新连接和订阅只恢复未来的投递，不会填补之前的历史空白。

在持续在线的连接上，听众按发布顺序接收消息。这里的顺序反映 Redis 的处理顺序，不是多个独立生产者携带的业务时间戳。即使接收有序，把事件分发给并行处理器后，完成顺序仍可能改变。因此，声称发布订阅完全没有顺序是错误的；把有序接收扩大为业务副作用也必然有序，同样不成立。

多个听众各自收到广播，并不是竞争弹出同一个列表元素。频道订阅与匹配的模式订阅是两条独立投递路径。同时订阅 events 和 event*，一次发布就可能产生一份 message 和一份 pmessage；多个模式重叠也会如此。最多一次描述的是没有重试保证，不是跨订阅路径的业务去重承诺。

严格解释返回值

在本次验证的单机版本中，PUBLISH 分别统计频道和模式匹配的投递次数，因此两个客户端连接可以得到返回值三。固定版本的源码确实在两条路径分别递增计数。对于 Redis Cluster，官方说明计数只包含连接到发布节点的听众，因此它也不是整个集群的受众总数。

该响应不会等待处理器提交数据库事务、完成界面更新或确认业务完成。返回零只说明当时没有计入匹配接收者，返回正数不能证明处理成功。如果应用需要识别重叠订阅或生产者重复尝试造成的重复事件，应在消息中放入稳定的事件标识，不能用返回的数字替代业务确认。

坏掉的样子

订阅中断期间发布的消息会被错过。重连循环无法请求某个偏移之后的内容，因为发布订阅既无保留日志，也无回放游标。用于缓存失效时，一次通知丢失可能让旧值持续存在，直到另一个刷新机制介入；用于账单或任务派发时，则可能直接丢掉必须执行的工作。需要回放就应选择保留消息的队列或流，并明确恢复与持久化策略。

慢听众并不是一变慢就被随机丢掉几次读取。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 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:
 message = subscription.get_message(timeout=0.1)
 if message is not None:
 return message
 raise AssertionError("subscription response timed out")


with instance() as client:
 assert client.publish("events", b"before-subscribe") == 0
 with client.pubsub() as first, client.pubsub() as second:
 for subscription in (first, second):
 subscription.subscribe("events")
 response = receive(subscription)
 assert response["type"] == "subscribe"
 assert response["channel"] == b"events" and response["data"] == 1

 for value in (b"one", b"two"):
 assert client.publish("events", value) == 2
 for subscription in (first, second):
 messages = [receive(subscription) for _ in range(2)]
 assert [message["type"] for message in messages] == ["message"] * 2
 assert [message["data"] for message in messages] == [b"one", b"two"]
 print("before subscription: 0; two listeners receive one,two in order")

 second.unsubscribe("events")
 response = receive(second)
 assert response["type"] == "unsubscribe" and response["data"] == 0
 assert client.publish("events", b"missed") == 1
 assert receive(first)["data"] == b"missed"
 second.subscribe("events")
 assert receive(second)["type"] == "subscribe"
 assert client.publish("events", b"after-resubscribe") == 2
 for subscription in (first, second):
 assert receive(subscription)["data"] == b"after-resubscribe"
 print("resubscription receives the new marker, not the missed message")

 first.psubscribe("event*")
 response = receive(first)
 assert response["type"] == "psubscribe" and response["data"] == 2
 assert client.publish("events", b"overlap") == 3
 messages = [receive(first) for _ in range(2)]
 assert {message["type"] for message in messages} == {"message", "pmessage"}
 assert all(message["data"] == b"overlap" for message in messages)
 assert receive(second)["data"] == b"overlap"
 print("two clients, three matching deliveries; one client receives two copies")

第一个发布发生在两个听众订阅之前，返回零。等待双方确认后，连续发布的 one、two 都按相同顺序到达两个听众。断言同时检查消息类型和载荷，因此不会把订阅确认误当业务事件。响应等待有明确截止时间，不依靠随意休眠来猜测订阅何时生效。

第二个听众先显式退订，在这段空白中发布 missed，然后重新订阅。它收到的下一份载荷是 after-resubscribe，而非错过的事件。这里通过退订模拟订阅空白，并未声称复现真实网络故障。最后增加重叠的频道和模式订阅，两个连接产生三次计数，第一位听众收到同一次发布的两份副本。

三条输出摘要都以真实响应上的断言为前提。这些检查验证本机命令与重新订阅的语义，不验证过载阈值、集群传播、崩溃恢复或处理吞吐。应用仍需判断哪些通知可以丢弃，以及某条通知永不到达时，怎样重新取得权威状态。该判断应由数据用途决定，不能由一次成功的发布命令代替。

来源

Redis 发布订阅，订阅确认、顺序、最多一次投递与重叠订阅，已核验 2026-09-08。
Redis PUBLISH，命令返回值与集群计数范围，已核验 2026-09-08。
Redis 客户端管理，输出缓冲与断连限制，已核验 2026-09-08。
Redis 8.10.1 发布订阅实现，频道与模式匹配分别计数的源码，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与分配器选择，已核验 2026-09-08。