Redis · XB 现场笔记

Redis hash 用一个键装多个字段

Thu, 24 Feb 2028 00:00:00 +0000

Redis hash 是一个键下面可按字段访问的记录，不是自动校验模式的对象，也不是天然支持嵌套路径的文档。当调用方只需要部分属性、又不想替换整条记录时，它很有用。但是否划算取决于访问模式、字段大小和返回值语义，而不是只要选择 hash 类型，就自动得到廉价读写或完整业务一致性。

只读取调用方真正需要的字段

HGET 获取一个字段，HMGET 按请求顺序获取选定字段，HGETALL 则返回整个映射。在 redis-py 的二进制响应模式下，缺失字段表示为 None，存在但为空的值表示为空字节串。直接判断真假会把这两种情况错误地合并；对不存在的键执行 HMGET，同样得到对应位置的缺失值，并不会自动创建 hash。

字段名和字段值本质上都是字节。名字中含点号仍是字面名称，Redis 不会把 name.first 解释为进入嵌套对象再找 first。同样，包含 JSON 文本的字符串键还是字符串，HGET 不会替你解析 JSON。序列化和内容校验属于应用职责，“没有提供属性”和“明确写入空值”也应保留区别。

更新操作有精确的返回语义

HSET 只修改指定字段，未指定的字段保持不变。一次多字段 HSET 是一个命令，但其整数回复统计新增字段数量，而不是成功修改的总数。替换已有 name 完全可能成功返回零；如果把零视为失败，就会制造多余重试、错误告警，甚至触发不必要的补偿动作。

HINCRBY 在一个命令内完成整数递增，字段不存在时从零开始，拒绝非整数值以及超出有符号六十四位范围的结果。它避免的是这一项递增的读改写竞争，并不把外围的业务检查也变为原子操作。分别执行 HGET、在客户端计算、再执行 HSET，仍可能覆盖其他客户端已完成的修改。

HDEL 的返回值统计实际删除的字段，删除最后一个字段会让整个键消失。因此，不能靠空 hash 长期占位，表示某条实体存在。键级过期同样会删除其字段；当前 Redis 还支持字段级截止时间，不能沿用“hash 字段绝对不能单独过期”的旧结论。下面的实验没有设置任何过期时间，也不把结果作为生命周期验证。

紧凑编码是实现选择

小 hash 可以用 listpack 表示，而不是普通哈希表。Redis 8.10.1 的标准阈值是五百一十二个字段，以及每个字段名或值六十四字节；实际部署可能改过这些设置。触发适用限制后，内部表示会改变，但公开的 hash 操作和已经存储的内容不会因此变成另一种数据类型。

紧凑存储用内部扫描工作换取更少的管理开销及较好的局部性。大幅提高阈值前需要测量，不能把命令说明中的复杂度理解为“任意长字段、任意配置下都没有额外成本”。排查时可用 OBJECT ENCODING 观察编码，但应用正确性不应依赖这个内部标签，也不能预设每个对象都必定节省相同倍数的内存。

坏掉的样子

HGETALL 的工作量随整个 hash 增长，响应还要携带字段名和值。调用方只需要两项，却每次读取数千项，即使它们都在同一个键里，也是在浪费传输和处理资源。HMGET 的工作量随请求字段数增长，同样不是免费操作；返回映射的迭代顺序更不应成为应用的排序约定。

WRONGTYPE 表示该键存放了另一种 Redis 类型，并不是普通的字段缺失。非整数计数器也需要明确的数据处理决定，而不是不断重试。一个巨大的 hash 仍只是一个键，不会自动把字段分散到多个集群节点。应围绕真实的访问边界和归属划分记录，不要为了减少键名数量而把无关数据都塞到一起。

快速验证

原有实验记录使用 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

在同一个 shell 中，用 "$redis_lab/venv/bin/python" 执行下面代码。它创建私有 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-hash-", 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,
 "--hash-max-listpack-entries", "4", "--hash-max-listpack-value", "8",
 ], 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()


with instance() as client:
 assert client.hset("profile", mapping={"name": "Ada", "visits": "0", "empty": b""}) == 3
 assert client.hset("profile", "name", "Ada L") == 0
 assert client.hmget("profile", ["visits", "name", "missing", "empty"]) == [
 b"0", b"Ada L", None, b"",
 ]
 assert client.hmget("absent", ["a", "b"]) == [None, None]
 assert client.hgetall("profile") == {b"name": b"Ada L", b"visits": b"0", b"empty": b""}
 assert client.hincrby("profile", "visits", 1) == 1
 assert client.hget("profile", "name") == b"Ada L"
 print("HSET counts new fields; HMGET preserves order and distinguishes missing from empty")

 client.set("json", '{"name":"Ada"}')
 try:
 client.hget("json", "name")
 except redis.ResponseError as error:
 assert "WRONGTYPE" in str(error)
 else:
 raise AssertionError("a JSON string is not a hash")
 client.hset("literal", "name.first", b"Ada")
 assert client.hget("literal", "name") is None
 assert client.hget("literal", "name.first") == b"Ada"
 client.hset("invalid", "counter", "3.5")
 try:
 client.hincrby("invalid", "counter", 1)
 except redis.ResponseError as error:
 assert "integer" in str(error)
 else:
 raise AssertionError("an integer counter cannot contain 3.5")
 assert client.hget("invalid", "counter") == b"3.5"
 client.hset("overflow", "counter", 2**63 - 1)
 try:
 client.hincrby("overflow", "counter", 1)
 except redis.ResponseError as error:
 assert "overflow" in str(error)
 else:
 raise AssertionError("signed 64-bit integer overflow must fail")
 assert client.hget("overflow", "counter") == str(2**63 - 1).encode()
 print("wrong types and invalid or overflowing counters fail; dotted fields are literal")

 assert client.object("ENCODING", "profile") == b"listpack"
 assert client.hset("profile", "fourth", "ok") == 1
 assert client.object("ENCODING", "profile") == b"listpack"
 assert client.hset("profile", "fifth", "ok") == 1
 assert client.object("ENCODING", "profile") == b"hashtable"
 client.hset("value-limit", "field", b"abcdefgh")
 assert client.object("ENCODING", "value-limit") == b"listpack"
 client.hset("value-limit", "field", b"abcdefghi")
 assert client.object("ENCODING", "value-limit") == b"hashtable"
 assert client.hget("profile", "visits") == b"1"
 assert client.hget("value-limit", "field") == b"abcdefghi"
 print("private 4-field and 8-byte thresholds each trigger listpack to hashtable conversion")

 assert client.hdel("value-limit", "absent") == 0
 assert client.hdel("value-limit", "field") == 1
 assert client.exists("value-limit") == 0
 print("deleting the last field removes the hash key")

断言区分了新增字段与替换字段，确认 HMGET 保留请求顺序，也保留缺失与空值的区别，并检查未修改的相邻字段。JSON 字符串触发 WRONGTYPE，点号字段名仍按字面查找；非整数和溢出递增都被拒绝，原来的计数器内容没有改变。

profile 有四个短字段时仍为 listpack，加入第五个后变为 hashtable；另一个 hash 在值从八字节增长到九字节时也发生转换。转换后的读取结果依旧正确，最后一个字段被删除后，其键不再存在。这些结果展示的是受控配置下的编码转换和命令语义，不是生产内存节约比例、延迟、并发负载或集群分布的测试。

来源

Redis hash，字段操作与当前版本的过期能力，已核验 2026-09-08。
Redis HSET，局部更新和新增字段计数，已核验 2026-09-08。
Redis HMGET，请求顺序与缺失字段响应，已核验 2026-09-08。
Redis HGETALL，完整 hash 读取及其复杂度，已核验 2026-09-08。
Redis HINCRBY，整数递增与支持范围，已核验 2026-09-08。
Redis HDEL，删除计数和最后一个字段的处理，已核验 2026-09-08。
Redis OBJECT ENCODING，内部表示及其转换，已核验 2026-09-08。
Redis 内存优化，紧凑编码阈值和测量建议，已核验 2026-09-08。
Redis 8.10.1 配置，hash 默认阈值，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与选择分配器，已核验 2026-09-08。

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

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

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

先确定每个事件交给谁

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

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

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

保留窗口不是持久化设置

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

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

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

坏掉的样子

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

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

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

快速验证

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 Streams 让一个消费组分担工作

Sat, 05 Feb 2028 00:00:00 +0000

Redis Streams 消费组把新条目分配给具名消费者，并记录尚未确认的投递。它不保证业务副作用恰好发生一次，不会阻止保留策略删除数据，也不会自行恢复被遗弃的任务。将其用作工作队列前，应区分组的读取位置、待处理条目与流里实际保留的数据。

读取位置与待处理任务不同

XGROUP CREATE jobs workers 0-0 从现有历史之前起步；使用 $ 则从当前末端之后开始。同组成员分担新投递，不同消费组拥有各自独立的投递状态。并发工作进程应使用不同的消费者名字。最后投递位置属于整个组，并不是每个消费者分别提交一个偏移。

未使用 CLAIM 或 NOACK 的普通 XREADGROUP 以 > 请求新条目，投递后将它们记入待处理列表 PEL。组的位置在新条目投递时就推进，发生在 XACK 之前。XPENDING 统计的是已经投递但尚未确认的条目，不是从来没有投递过的积压。因此，待处理计数为零时，组里仍可能有大量未读工作。

XACK 把指定 ID 从该组 PEL 移除，不删除流里的记录，也不推进最后投递位置。确认可以乱序完成，其他组依然可以读取保留下来的条目。XREADGROUP 使用 0-0 时读取的是这个具名消费者自己的待处理历史，不是在请求新工作，也不会把另一位消费者名下的待处理消息交给它。

恢复需要显式决策

反复执行普通 > 读取，不会重试被遗弃的 PEL 条目。XAUTOCLAIM 能把满足条件的待处理条目转给请求方，参数必须包含流、组、消费者、最小空闲毫秒数和起始 ID。之后应使用返回游标继续扫描，直到返回 0-0。某一批认领结果为空，并不代表扫描已经完成；过一段时间再次扫描，原来尚未达到空闲阈值的条目也可能变得可认领。

Redis 8.4 还引入了 XREADGROUP CLAIM，可以显式把认领恢复与读取组合起来，本实验没有启用它。这里将 XAUTOCLAIM 空闲阈值设为零，只为得到确定的本地观测；生产阈值必须结合正常处理时长与存活判断策略。转移归属无法让仍在运行的旧工作进程停止，更不能撤回它已经产生的外部副作用。

坏掉的样子

如果外部操作成功后、确认之前发生崩溃，消息仍可能被重新投递，再次处理就会重复副作用。提前确认又可能丢掉必须执行的工作。应使用稳定业务标识，在条件允许时通过事务完成去重；投递计数反映投递尝试，不是数据库成功提交的次数。需要限制重试，并在结束失败任务的跟踪前保留其载荷，便于后续处理。

PEL 引用不会锁住流里的载荷。XDEL 和默认 KEEPREF 裁剪都可能删除内容，同时留下待处理 ID。Redis 7 及更新版本的 XAUTOCLAIM 会报告并清理这种缺失条目，但这是清理记录，不是恢复原文。保留策略必须考虑消费者停机窗口，流的持久化与复制也需要单独作出可靠性决策。

应同时观察未读滞后、待处理数量、空闲时间和重复投递。任何单个计数都不足以说明队列健康。NOACK 会让新投递跳过待处理跟踪，需要依赖该跟踪恢复时就不适合使用。即使流 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()


with instance() as client:
 for entry_id in ("1-0", "2-0", "3-0"):
 client.xadd("jobs", {"job": entry_id}, id=entry_id)
 client.xgroup_create("jobs", "workers", id="0-0")
 client.xgroup_create("jobs", "tail", id="$")
 assert client.xpending("jobs", "workers")["pending"] == 0
 assert client.xreadgroup("tail", "observer", {"jobs": ">"}) == []
 first = client.xreadgroup("workers", "w1", {"jobs": ">"}, count=1)[0][1]
 second = client.xreadgroup("workers", "w2", {"jobs": ">"}, count=1)[0][1]
 assert first[0][0] == b"1-0" and second[0][0] == b"2-0"
 assert client.xpending("jobs", "workers")["pending"] == 2
 group = next(item for item in client.xinfo_groups("jobs") if item["name"] == b"workers")
 assert group["last-delivered-id"] == b"2-0"
 print("backlog starts with PEL=0; new deliveries split 1-0/2-0 and advance the group position")

 effects = [first[0][0]]
 assert client.xack("jobs", "workers", "2-0") == 1
 assert client.xlen("jobs") == 3
 group = next(item for item in client.xinfo_groups("jobs") if item["name"] == b"workers")
 assert group["last-delivered-id"] == b"2-0"
 assert client.xreadgroup("workers", "w2", {"jobs": "0-0"}) == [[b"jobs", []]]
 assert client.xreadgroup("workers", "w1", {"jobs": "0-0"})[0][1] == first
 third = client.xreadgroup("workers", "w2", {"jobs": ">"})[0][1]
 assert third[0][0] == b"3-0"
 assert client.xack("jobs", "workers", "3-0") == 1
 assert client.xreadgroup("workers", "w2", {"jobs": ">"}) == []
 print("XACK keeps stream data and read position; 0-0 reads own pending; > does not recover w1")

 cursor, claimed, deleted = client.xautoclaim(
 "jobs", "workers", "w2", min_idle_time=0, start_id="0-0", count=10,
 )
 assert cursor == b"0-0" and claimed == first and deleted == []
 pending = client.xpending_range("jobs", "workers", "-", "+", 10)
 assert len(pending) == 1 and pending[0]["consumer"] == b"w2"
 assert pending[0]["times_delivered"] >= 2
 effects.append(claimed[0][0])
 assert effects.count(b"1-0") == 2
 assert client.xack("jobs", "workers", "1-0") == 1
 assert client.xack("jobs", "workers", "1-0") == 0
 assert client.xpending("jobs", "workers")["pending"] == 0
 assert client.xlen("jobs") == 3
 print("explicit claim changes owner; simulated side effect repeats; ACK clears PEL, not the stream")

 client.xadd("jobs", {"job": "4-0"}, id="4-0")
 assert client.xreadgroup("tail", "observer", {"jobs": ">"})[0][1][0][0] == b"4-0"
 assert client.xreadgroup("workers", "w1", {"jobs": ">"})[0][1][0][0] == b"4-0"
 assert client.xdel("jobs", "4-0") == 1
 assert client.xpending("jobs", "workers")["pending"] == 1
 cursor, claimed, deleted = client.xautoclaim(
 "jobs", "workers", "w2", min_idle_time=0, start_id="0-0", count=10,
 )
 assert cursor == b"0-0" and claimed == [] and deleted == [b"4-0"]
 assert client.xpending("jobs", "workers")["pending"] == 0
 print("a $ group starts after old entries; XDEL loses pending payload; claim reports deleted ID")

workers 组开始时有三个未读条目，待处理数量却是零。两次读取分别分配 1-0 和 2-0，在任何确认之前，组位置已经到达 2-0。确认第二条后，流长度与该位置保持不变。读取待处理历史可以区分两个消费者；再次请求新消息得到的是 3-0，不会替第一位消费者重试 1-0。

effects 列表模拟已经完成操作但未确认的情况。显式认领把 1-0 交给 w2，再处理一次就记录了两次副作用。这是在模拟重复业务处理，不是具有事务安全性的实现。随后确认清空 PEL，流中的三条原始记录仍然存在，说明待处理状态与消息内容不是同一份生命周期。

tail 组只会看到后来追加的 4-0。该条目仍处于待处理时将其删除，之后认领返回的是已删除 ID 列表，没有载荷可供重试。检查覆盖命令层面的状态变化，没有验证进程崩溃检测、自动重试调度、持久化去重或故障切换恢复。这些边界决定了它不能被直接当成一套完整的生产消费协议。

来源

Redis XGROUP CREATE，消费组起始位置，已核验 2026-09-08。
Redis XREADGROUP，新消息与待处理读取、NOACK 和可选 CLAIM 行为，已核验 2026-09-08。
Redis XPENDING，待处理归属与投递次数，已核验 2026-09-08。
Redis XACK，确认与待处理列表移除，已核验 2026-09-08。
Redis XAUTOCLAIM，恢复游标、空闲阈值与已删除条目，已核验 2026-09-08。
Redis XTRIM，保留与消费组引用策略，已核验 2026-09-08。
Redis 持久化，RDB 与 AOF 的持久性取舍，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与分配器选择，已核验 2026-09-08。

Redis 按距离处理地理位置

Tue, 25 Jan 2028 00:00:00 +0000

Redis 地理命令为带名称的位置建立索引，可以直接回答附近有哪些点，不必把全部坐标传回应用。它适合能够接受球面距离模型的场景，但不会提供道路路线、考虑海拔的空间距离、任意多边形分析，也不会保证查询到的每个位置仍然新鲜。这些不是查询速度更快就能顺带解决的问题。

经度必须放在纬度前面

GEOADD 按经度、纬度、成员名的顺序接收参数。有效经度从负一百八十度到正一百八十度，纬度则限制在大约负 85.05112878 度到正 85.05112878 度之间，极区不属于该索引支持的范围。如果把两个各自仍合法的数值交换位置，命令可能正常成功，却把成员放到完全不同的地方。

索引底层是有序集合，分数保存五十二位地理哈希编码，不能用普通排行榜分数覆盖这些位置编码。成员是唯一的：更新同名成员只会改变位置，不会增加一份记录。GEOADD 默认统计新增成员数，加 CH 才统计新增及实际变化。删除位置使用 ZREM，读取存储坐标则使用 GEOPOS；不要把一次更新返回零当成更新失败。

坐标编码具有有限精度，因此 GEOPOS 不一定原样返回输入的小数。GEODIST 使用理想球面地球计算表面距离，不是穿过地球内部的直线弦长，更不是驾车路线。默认单位为米，也可以选择公里、英尺和英里。任何一个端点缺失时，返回空结果，而不是把不存在的位置当作距离为零的重合点。

把查询条件写成明确契约

Redis 6.2 开始提供 GEOSEARCH，可以围绕已有成员或显式经纬度查询。BYRADIUS 指定圆形范围，BYBOX 则按所选单位指定轴向对齐矩形的宽和高。新的查询应使用该命令，而不是已弃用的 GEORADIUS 系列。请求中的单位与结果解释必须一致，否则正确的数值也会被应用解读成错误的距离。

ASC 按距离从近到远排列，COUNT 限制返回数量。要找最近的若干个结果，应使用 ASC 和 COUNT，避免 ANY；ANY 允许找到足够数量后提前结束，不能保证拿到查询区域内全局最近的那些点。另外，返回数量少不代表查询一定便宜：范围巨大且点位密集时，即使只要求少量结果，也可能需要检查很多候选。

FROMMEMBER 查询可以包含作为中心的成员自身。如果业务要找“附近的其他人”，就需要处理这个结果，而不是直接把第一条当作别人。WITHDIST 返回所选单位下的距离，WITHCOORD 返回坐标。结果反映的是查询时索引里存放的数据，并不等于已经独立确认某台设备或某个商户此刻就在该位置。

坏掉的样子

文档说明，在边界情况下，球面近似与地球实际形状之间的误差可以达到约百分之零点五。因此，“城市尺度”并不自动意味着误差小于一米。应用应明确可接受误差及距离边界如何判定；测绘、安全关键接近判断、道路规划或严格地理围栏，可能需要更合适的空间模型，不能只凭一次示例距离看起来合理就验收精度。

GEOSEARCHSTORE 把查询结果写进另一个有序集合，形成一次结果快照。默认保留地理位置分数，STOREDIST 则改为保存成员到查询中心的距离分数。后者是按距离排列的集合，不能继续作为地理索引使用。源索引随后更新或删除成员，都不会自动刷新已经存下来的任一种结果。

GEOADD 不会自动为每个位置添加过期时间或新鲜度时间戳。键级过期会删除整个索引，单个成员则需要通过 ZREM 等明确的成员管理操作清理。因此，一个很快的查询完全可能正确返回陈旧位置。位置何时上报、多久失效、何时移除，需要与空间查询本身分开设计和验证，不能把“还能搜到”当成位置仍然有效。

快速验证

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" 执行下面代码。实验只通过 /tmp 下的私有 Redis Unix socket 通信，与任何已有实例隔离；TCP、定时快照和追加日志均关闭。程序结束时停止自己的进程并删除本次运行目录。只有下载依赖需要网络，查询的两个城市坐标已经明确写在代码里。

import math

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()


with instance() as client:
 palermo = (13.361389, 38.115556)
 catania = (15.087269, 37.502669)
 assert client.geoadd("places", [
 *palermo, b"Palermo", *catania, b"Catania",
 ]) == 2
 assert client.type("places") == b"zset"
 position = client.geopos("places", "Palermo")[0]
 assert all(abs(actual - expected) < 0.00001
 for actual, expected in zip(position, palermo))
 distance = client.geodist("places", "Palermo", "Catania", unit="km")
 assert math.isclose(distance, 166.2742, abs_tol=0.001)
 assert client.geodist("places", "Palermo", "missing") is None
 print(f"longitude first; decoded coordinates are approximate; distance {distance:.4f} km")

 query = dict(longitude=15, latitude=37, radius=200, unit="km", sort="ASC")
 results = client.geosearch("places", **query, withdist=True)
 assert [item[0] for item in results] == [b"Catania", b"Palermo"]
 assert results[0][1] < results[1][1] < 200
 assert client.geosearch("places", **query, count=1) == [b"Catania"]
 assert client.geosearch(
 "places", member="Palermo", radius=1, unit="km", sort="ASC",
 ) == [b"Palermo"]
 print("ASC COUNT 1 selects Catania; FROMMEMBER also includes the center member")

 assert client.geosearchstore("subset", "places", **query) == 2
 assert client.zscore("subset", "Catania") == client.zscore("places", "Catania")
 assert client.geosearchstore("distances", "places", **query, storedist=True) == 2
 assert math.isclose(client.zscore("distances", "Catania"),
 results[0][1], abs_tol=0.001)
 assert client.zscore("distances", "Catania") != client.zscore("places", "Catania")
 print("default GEOSEARCHSTORE preserves position scores; STOREDIST stores kilometers")

 try:
 client.geoadd("places", [0, 90, b"pole"])
 except redis.ResponseError as error:
 assert "invalid longitude,latitude pair" in str(error)
 else:
 raise AssertionError("latitude 90 must be rejected")
 assert client.zcard("places") == 2
 assert client.geoadd("swapped", [
 *palermo, b"correct", palermo[1], palermo[0], b"reversed",
 ]) == 2
 assert client.geodist("swapped", "correct", "reversed", unit="km") > 1000
 print("polar coordinates are rejected; swapped but valid coordinates are not detected")

 assert client.geoadd("places", [13.4, 38.1, b"Palermo"]) == 0
 assert client.zcard("places") == 2
 assert client.geoadd("places", [13.5, 38.2, b"Palermo"], ch=True) == 1
 assert client.zrem("places", b"Catania") == 1
 assert client.geopos("places", "Catania") == [None]
 assert client.zcard("subset") == 2
 print("updates reuse members; ZREM removes locations; stored subsets are snapshots")

Palermo 与 Catania 之间得到约 166.2742 公里，坐标比较允许编码带来的精度差异。围绕指定坐标查询时，Catania 排在前面；以成员为中心的查询则包含 Palermo 自身。默认存储的结果分数与源索引一致，STOREDIST 的结果分数对应返回的公里距离，而不是位置编码。

纬度九十度会被拒绝，且没有插入成员；经纬度颠倒但仍落在两个合法区间时，却可以成功存储，表示远离原位置的另一点。同名成员更新不增加成员数量，删除 Catania 也不会修改先前存储的子集。这些结果验证命令语义与数据解释，没有证明真实定位精度、道路距离、陈旧位置防护或生产规模下的查询性能。

来源

Redis GEOADD，坐标限制、编码、更新及球面模型误差，已核验 2026-09-08。
Redis GEOPOS，存储坐标返回和缺失成员，已核验 2026-09-08。
Redis GEODIST，球面距离、单位及缺失端点，已核验 2026-09-08。
Redis GEOSEARCH，范围形状、排序、数量限制与 ANY 语义，已核验 2026-09-08。
Redis GEOSEARCHSTORE，结果快照与距离分数存储，已核验 2026-09-08。
Redis 8.10.1 构建说明，只编译核心及分配器选择，已核验 2026-09-08。

测量 Redis 流水线的实际收益

Thu, 20 Jan 2028 00:00:00 +0000

流水线减少的是发送 Redis 命令之间的等待，实际收益必须放到具体负载里测量。远程同步循环可能主要等待网络延迟，本地循环也可能主要消耗在客户端处理、进程调度和套接字读写。两种情形都不能直接推出“任何环境都会快几倍”的结论，更不能用一次本机数字替线上系统承诺容量。

比较等价的工作

对于 N 条命令、每批 B 条，简单同步模型把约 N 次请求响应等待减少为向上取整的 N/B 次批次等待。但命令执行、响应字节、编码和解析并没有消失；一批数据仍可能跨越多次套接字写入和多个网络包。因此模型中的等待次数，不是抓包数量，也不是对真实链路 RTT 的测量。

改变 B 时，要固定命令、键分布、负载大小、连接数、客户端版本和持久化设置。否则看起来更快，可能只是做了更少工作、关掉了持久性，或者增加了并发客户端。若要测普通流水线，应显式使用 transaction=False，因为 redis-py 默认流水线还会加入 MULTI/EXEC。

下面批量一使用普通同步客户端循环，不是每次只装一条命令的流水线包装器。这样比较回答的是“应用当前请求响应循环能否从批处理受益”，而不是测出 Redis 的最大可持续吞吐，更不是剥离客户端后得到服务器的固有命令成本。

计入应用实际支付的成本

计时应覆盖命令准备，直到最后一个结果收齐。忽略构建请求或解析响应，会低估大批次给应用带来的成本。示例把缓冲、执行和结果收集都放进计时区间，而把重置数据与正确性断言放在外面；两种路径遵守相同的计时边界，才方便比较。

每个配置先预热，再变换测试顺序并重复测量，同时报告波动。这里的三次正式运行只是一个容易复现的小型比较，不是严谨的容量研究。笔记本上的调度和其它工作仍会影响结果，单次中位数不能直接升级成服务等级目标。

吞吐量也不是单条请求延迟。总耗时除以命令数，得到的是平均完成成本，不是百分之九十五或九十九请求的延迟分布。等待凑满一批，可能让最早到达的请求在执行前就排队；本例立即构造批次，没有测量真实到达节奏带来的积攒延迟。

坏掉的样子

巨型批次可能提高每秒命令数，却同时带来难以接受的停顿和内存增长。应限制条数、请求与响应字节，以及等待成批的时间；这些上限应来自代表性负载，而不是不分命令类型就照搬几百或几千条。

如果继续增大批量已经没收益，要检查客户端 CPU、响应解码、服务端命令成本、带宽和竞争负载。流水线能够通过分摊读写开销提高实际服务吞吐，但并不消除所有瓶颈。分片是可能的架构选择之一，不是曲线变平之后唯一合理的答案。

计速度也必须检查失败。丢掉回复或把错误当成功，可以轻易制造漂亮但无意义的速率。下方关闭网络自动重试，并核对每一个递增结果的完整序列。真实断连可能留下不确定的执行范围；从最后一条已知回应之后重发，对递增也不是天然安全的恢复方式。

测试负载只应留在它自己的实例中。代码会反复重置并递增一个计数器，若把目标改成共享生产库，操作风险就发生了变化。这里使用本地 Unix 套接字，也有意排除了 TCP、TLS 和远程网络路径，所以读数不能冒充跨机房链路测量。

快速验证

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" 运行下方代码。它在 /tmp 启动只用私有 Unix 套接字的 Redis，关闭 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()


from statistics import median


TOTAL = 2048
SIZES = (1, 8, 64, 256)


def measure(client, size):
 client.set("bench:counter", 0)
 started = time.perf_counter()
 responses = []
 if size == 1:
 for _ in range(TOTAL):
 responses.append(client.incr("bench:counter"))
 else:
 for offset in range(0, TOTAL, size):
 with client.pipeline(transaction=False) as batch:
 for _ in range(min(size, TOTAL - offset)):
 batch.incr("bench:counter")
 responses.extend(batch.execute())
 elapsed = time.perf_counter() - started
 assert responses == list(range(1, TOTAL + 1))
 assert client.get("bench:counter") == str(TOTAL).encode()
 return elapsed


with instance() as client:
 for size in SIZES:
 measure(client, size)
 measurements = {size: [] for size in SIZES}
 for repetition in range(3):
 order = SIZES[repetition:] + SIZES[:repetition]
 for size in order:
 measurements[size].append(measure(client, size))
 for size in SIZES:
 samples = measurements[size]
 duration = median(samples)
 waits = (TOTAL + size - 1) // size
 print(f"batch={size:3d} waits={waits:4d} median_ms={duration * 1000:.2f} "
 f"commands_per_second={TOTAL / duration:.0f} "
 f"range_ms={min(samples) * 1000:.2f}-{max(samples) * 1000:.2f}")
 print("all replies and final counters checked; no speedup threshold is asserted")

每种配置都在同一个计数器上执行二千零四十八次递增，并复用连接。批量一、八、六十四和二百五十六，对应的逻辑阻塞调用次数分别是二千零四十八、二百五十六、三十二和八。这些是应用等待次数，不是捕获到的数据包数；每轮都会核对完整返回序列和最后的存储值。

原有记录的中位完成时间依次为 35.24、9.40、5.61 和 5.00 毫秒。批量越大，后续收益逐步缩小，展示了该本地负载上的边际变化。脚本打印的是运行者自己的测量及实际范围，刻意没有设置“必须达到某种加速比”的断言，环境不同就应得到不同数字。

四种配置各先预热一次，再以轮换顺序完成三次正式运行。每秒命令数用二千零四十八除以计时结果计算，不能解读为不同并发、负载大小和网络条件下远程应用的预测性能。

实验验证的是等价工作都确实成功，并测量本地整批完成时间，没有测生产到达率、尾延迟、TCP 或 TLS、持久化开销、连接故障和集群扩展。部署前的基准应分别覆盖这些维度，不用一个快速测试代替完整容量判断。

来源

Redis 流水线，分摊往返与输入输出开销，已核验 2026-09-08。
Redis 基准测试指南，负载控制、并发与测量局限，已核验 2026-09-08。
redis-py 8.1.0 客户端实现，非事务批次与错误处理，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅编译核心及选择分配器，已核验 2026-09-08。

Redis Lua 脚本执行时不被穿插

Tue, 11 Jan 2028 00:00:00 +0000

Redis Lua 脚本可以先读取数据、判断条件，再更新数据，而不让另一个客户端的命令插进这些步骤之间。但这不意味着每个语句都会成功，也不意味着后面发生错误时会撤销前面的写入，更不意味着执行结果自动具备持久性。原子执行与失败回滚，是必须拆开理解的两个问题。

把判断放在数据旁边

例如，仅当令牌仍属于当前持有者时才删除它。客户端先 GET、稍后再 DEL，中间可能已经被新持有者替换了值；随后删除就误伤了别人。脚本可以在同一次执行中比较当前值，匹配才删除。因此旧持有者即使带着之前读到的令牌来操作，也不会直接删除新持有者的值。

脚本应通过 redis.call 访问 Redis 数据，这正是脚本接口的用途。沙箱不提供普通文件系统或网络访问，不能把邮件、支付或文件读写搬进脚本。所有会访问的键都应通过 KEYS 传入，普通值用 ARGV，不要根据数据库里读出的内容临时拼接键名。Redis Cluster 中的常规多键使用还要求相关键位于同一哈希槽。

如果原生原子命令已经表达了条件，应优先使用它。Redis 8.4 新增的 DELEX 配合 IFEQ 就能按字符串值比较后删除。下方 Lua 版本用于理解分支与响应，不代表需要用自定义代码替换原生命令。删除所有权令牌本身也不是完整的分布式锁协议，无法单独阻止过期工作者继续修改外部资源。

坏掉的样子

没有被捕获的 redis.call 错误会让脚本停止。例如先 SET 一个标记，再对字符串键执行 LPUSH，后者失败时，前面的 SET 仍然保留，而失败语句之后的代码不会继续运行。这又与 MULTI/EXEC 有区别：事务中单条命令发生运行期错误，通常不会阻止后面的排队命令继续执行。两者都不提供先前成功写入的自动回滚。

redis.pcall 会把 Redis 命令错误作为包含 err 字段的表交回脚本，由脚本显式判断并决定是否继续。捕获错误既没有撤销旧写入，也不能把失败的业务操作自动变成成功。应尽可能在第一条写入之前校验参数和预期类型，并明确剩余失败路径如何收场，而不是依赖脚本名义上的原子性掩盖部分结果。

调用方超时也不等于取消，更不能证明服务器什么都没做。直接重发递增脚本，可能把计数增加两次。对于不允许重复效果的业务，需要结果确认或幂等机制。SCRIPT KILL 只能中断尚未修改数据集的脚本；一旦已经产生写入，它就不是可以安全使用的撤销按钮。

保留源码，限制工作量

EVALSHA 用摘要标识缓存中的脚本，不等于安装了永久保存的存储过程。脚本缓存是易失的，重启、故障切换或 SCRIPT FLUSH 都可能让它消失；通过 EVAL 加载的脚本，还可能受到 Redis 7.4 引入的脚本缓存淘汰策略影响。应用要保留参数化源码，并通过客户端支持的加载机制处理明确的 NOSCRIPT 响应。

不要为每个输入值拼出一份不同脚本文本，变化应放进参数。明确收到 NOSCRIPT，表示这次调用没有执行那个缺失的脚本；重新加载或发送 EVAL 解决的是“代码不在缓存里”，不是之前一次业务动作执行结果未知的问题。这两种失败不能共用盲目重试结论。

有界不仅指循环次数，还包括单条命令处理的数据量。脚本只有几行，却读取一个没有规模限制的集合，仍可能长时间占用服务端。把逻辑移到 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" 运行下方代码。它在 /tmp 创建私有 Unix 套接字，关闭 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()


compare_delete = """
if redis.call('GET', KEYS[1]) == ARGV[1] then
 return redis.call('DEL', KEYS[1])
end
return 0
"""

with instance() as client, client.client() as rival:
 client.set("lease", "owner-a")
 assert client.get("lease") == b"owner-a"
 rival.set("lease", "owner-b")
 assert client.eval(compare_delete, 1, "lease", "owner-a") == 0
 assert client.get("lease") == b"owner-b"
 assert client.eval(compare_delete, 1, "lease", "owner-b") == 1
 assert client.eval(compare_delete, 1, "lease", "owner-b") == 0
 print("compare-and-delete preserves a new owner's token and removes only a match")

 client.set("wrong-type", "string")
 fails_after_write = """
redis.call('SET', KEYS[1], 'before')
redis.call('LPUSH', KEYS[2], 'item')
redis.call('SET', KEYS[3], 'after')
return 1
"""
 try:
 client.eval(fails_after_write, 3, "written", "wrong-type", "not-reached")
 except redis.ResponseError as error:
 assert "WRONGTYPE" in str(error)
 else:
 raise AssertionError("script should fail on the string key")
 assert client.mget("written", "wrong-type", "not-reached") == [
 b"before", b"string", None,
 ]
 print("redis.call error stops the script but keeps the earlier write")

 catches_error = """
local reply = redis.pcall('LPUSH', KEYS[1], 'item')
if type(reply) == 'table' and reply.err then
 redis.call('SET', KEYS[2], 'handled')
 return reply.err
end
return reply
"""
 response = client.eval(catches_error, 2, "wrong-type", "handled-error")
 assert response.startswith(b"WRONGTYPE")
 assert client.get("handled-error") == b"handled"
 assert client.eval(catches_error, 2, "new-list", "unused-marker") == 1
 assert client.lrange("new-list", 0, -1) == [b"item"]
 assert client.get("unused-marker") is None
 print("redis.pcall exposes errors for handling and preserves successful command replies")

 digest = client.script_load(compare_delete)
 assert client.script_exists(digest) == [True]
 client.set("lease", "owner-c")
 assert client.evalsha(digest, 1, "lease", "owner-c") == 1
 client.set("lease", "owner-d")
 assert client.script_flush(sync_type="SYNC") is True
 assert client.script_exists(digest) == [False]
 try:
 client.evalsha(digest, 1, "lease", "owner-d")
 except redis.exceptions.NoScriptError:
 pass
 else:
 raise AssertionError("flushed script remained available")
 assert client.get("lease") == b"owner-d"
 assert client.eval(compare_delete, 1, "lease", "owner-d") == 1
 print("SCRIPT FLUSH causes NOSCRIPT; EVAL with retained source can run it again")

第一组先把 owner-a 替换成 owner-b，再让旧持有者运行脚本。旧令牌得到零且保留 owner-b，匹配令牌得到一并删除键；再次执行则因为键不存在而返回零。脚本以当前存储值为准，没有信任先前在客户端读取的旧结果。

下一段脚本先写标记，再对字符串做列表操作。断言证明错误之前的写入保留，而最后一个标记没有执行到。随后使用 pcall 处理同一种错误，并写入 handled 标记；对正常列表执行时，则返回整数结果，不写错误标记。类型判断区分数字与错误表，避免在成功响应上读取 err 字段时再次报错。继续执行是代码显式选择的行为，不是自动回滚。

最后 SCRIPT LOAD 返回摘要，EVALSHA 能据此执行；然后只对这个私有实验实例调用 SCRIPT FLUSH 清空脚本缓存。NOSCRIPT 发生后，令牌仍存在；再使用保存的源码调用 EVAL，就能删除它。不要把清缓存的步骤复制到多人共用的实例上，它会影响其它应用依赖的缓存脚本。

四条输出摘要均放在返回值和存储状态断言之后。本次没有测吞吐量、运行长时间脚本或复现网络故障，也不验证完整分布式锁、跨分片或持久性保证。它验证的是条件分支、错误后的实际状态，以及源码缓存缺失与执行失败的区别。

来源

Redis Eval 脚本简介，执行隔离与易失的脚本缓存，已核验 2026-09-08。
Redis Lua API，沙箱、命令调用与错误转换，已核验 2026-09-08。
Redis EVAL，键参数及 EVAL 加载脚本的淘汰，已核验 2026-09-08。
Redis SCRIPT KILL，脚本已经写入后的限制，已核验 2026-09-08。
Redis SCRIPT FLUSH，显式清空脚本缓存，已核验 2026-09-08。
Redis DELEX，Redis 8.4 起提供的原生条件删除，已核验 2026-09-08。
Redis Cluster 规范，多键操作的哈希槽边界，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅编译核心及选择分配器，已核验 2026-09-08。

Redis 列表与有序集合，一字之差用途不同

Tue, 04 Jan 2028 00:00:00 +0000

Redis 列表保存允许重复值的有序序列；有序集合保存唯一成员，并按数值分数排序。真正有用的区别不是谁总是更快或更省内存，而是应用需要按位置处理序列、维持唯一成员、查询分数范围，还是需要另一种数据模型才能表达的组合语义。

先定义什么算不同条目

使用 RPUSH 时，列表按追加顺序保留值，也保留重复项。随后 LPOP 移除最旧值，RPOP 则移除最新值。换一种推入与弹出端的组合，顺序也会变化，因此不能不看生产者命令就断言列表天然是先进先出。多个工作进程并行执行时，移除顺序也不保证业务完成顺序。

ZADD 为每个成员关联一个分数。再次加入同名成员，是更新分数，不是增加第二条记录。默认返回值统计新增成员数量，所以返回零也可能是成功更新。如果直接拿重复的事件载荷当成员名，多次出现会合并成同一个成员；当每次出现都代表独立任务时，这样建模就会丢掉业务区别。

分数允许并列，同分时按成员字节排序，不按到达顺序，也不是本地化文字排序；REV 同时反转同分成员的先后。排行榜可能接受这个规则，时间索引则可能需要独立事件标识和明确的并列处理方式。分数使用浮点数，因此还要选择能够保留所需数值精度的单位，不能把排序正确等同于任意精度都能表达。

位置和分数选择的是不同内容

列表不只支持两端访问。LINDEX 可以读取一个位置，LRANGE 返回包含边界的位置区间。到达内部位置需要遍历；两端访问便宜，不代表返回大量元素也无需付出相应成本。对只读取头尾、长度受控的短列表来说，保留一个小窗口完全可能是适合的方案。

ZRANGE 默认解释为从零开始的排名位置，结束位置也包含在内。BYSCORE 才把两个边界解释为数值分数，在分数前加左圆括号则排除该边界。官方给出的范围读取复杂度是 O(log N + M)，其中 N 为成员数，M 为返回数量。因为有索引，就认为大结果集或很深的偏移扫描没有成本，是不成立的。

持续变化的两种结构都不会让按排名分页变成快照。插入或分数更新可能移动后续页的位置，分开的请求就可能重复或遗漏。选择容器之前应先决定读取契约。内存开销也没有普遍相近的保证：底层表示、成员数量、载荷长度和配置都会改变结果。容量是决策因素时，应测量具有代表性的数据，而不是根据类型名字推断。

坏掉的样子

时间戳分数不是成员的过期截止时间。ZREMRANGEBYSCORE 显式删除数值区间，LTRIM 显式保留按位置选择的窗口；两者都不会因为时间过去或有人读取而自动清理。追加与清理如果分成两个命令，就是两个操作，保留逻辑仍然需要自己的触发与并发策略。

有序集合也不是完整的延迟任务调度器。ZPOPMIN 会立即移除最低分成员，即使分数表达的是未来时刻。先查到期成员、再用另一条命令删除，可能让多个工作进程选到同一任务。原子认领、处理确认以及遗弃任务恢复都是额外要求，不会因为分数放了时间戳就自然具备。

列表弹出同样发生在业务处理完成之前。移除后消费者失败，若没有合适的处理协议，任务就可能丢失。需要序列操作时选列表，需要按分数索引唯一成员时选有序集合；不能从任何一种排序方式推导出送达保证。数据结构选择与业务处理协议应分别判断，避免用容器替代完整语义。

快速验证

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()


with instance() as client:
 client.rpush("arrival", b"b", b"a", b"b")
 assert client.lrange("arrival", 0, -1) == [b"b", b"a", b"b"]
 assert client.lindex("arrival", 1) == b"a"
 assert client.llen("arrival") == 3
 client.zadd("ranked", {"b": 10})
 client.zadd("ranked", {"a": 10})
 assert client.zadd("ranked", {"b": 20}) == 0
 assert client.zcard("ranked") == 2
 assert client.zrange("ranked", 0, -1, withscores=True) == [(b"a", 10.0), (b"b", 20.0)]
 client.zadd("ranked", {"b": 10})
 assert client.zrange("ranked", 0, -1) == [b"a", b"b"]
 assert client.zrange("ranked", 0, -1, desc=True) == [b"b", b"a"]
 print("lists retain duplicates and positions; sorted sets update unique members and order ties by bytes")

 assert client.lpop("arrival") == b"b"
 assert client.rpop("arrival") == b"b"
 assert client.lrange("arrival", 0, -1) == [b"a"]
 client.rpush("fifo", b"old", b"new")
 client.rpush("lifo", b"old", b"new")
 assert client.lpop("fifo") == b"old"
 assert client.rpop("lifo") == b"new"
 print("RPUSH with LPOP removes oldest first; RPUSH with RPOP removes newest first")

 client.zadd("times", {"at-10": 10, "at-20": 20, "at-30": 30})
 assert client.zrange("times", 0, 1) == [b"at-10", b"at-20"]
 assert client.zrange("times", 10, 20, byscore=True) == [b"at-10", b"at-20"]
 assert client.zrange("times", "(10", 20, byscore=True) == [b"at-20"]
 assert client.zremrangebyscore("times", "-inf", "(20") == 1
 assert client.zrange("times", 0, -1) == [b"at-20", b"at-30"]
 assert client.ttl("times") == -1
 client.rpush("window", b"old", b"middle", b"new")
 client.ltrim("window", -2, -1)
 assert client.lrange("window", 0, -1) == [b"middle", b"new"]
 print("rank selects positions; score selects values; score cleanup and list trimming are explicit")

 now = 100
 client.zadd("schedule", {"future-job": now + 50})
 assert client.zrange("schedule", "-inf", now, byscore=True) == []
 assert client.zpopmin("schedule") == [(b"future-job", 150.0)]
 assert client.exists("schedule") == 0
 print("ZPOPMIN removes the minimum immediately even when its score represents a future deadline")

列表保留 b、a、b 三个条目，并允许用 LINDEX 读取中间位置。有序集合只有两个成员；更新 b 的分数返回零，分数却确实发生改变。并列后顺序变为 a、b，而非按原来插入顺序排列，REV 再把它反过来。

独立的先进先出和后进先出示例展示了弹出端的作用。范围检查区分排名与分数，也区分包含和排除边界。按分数清理只移除低于二十的值，列表裁剪则保留最新两个值；有序集合对应的键依然没有过期时间，说明分数与键过期是两套独立含义。

最后，数值测试时钟是一百，唯一任务的分数是一百五十。到期区间查询为空，但 ZPOPMIN 仍立即移除这个未来任务。这里验证的是命令语义，不是一套调度器，也没有执行内存对比、崩溃恢复协议或吞吐基准。不能把这段确定性的行为检查解释成性能结论。

来源

Redis RPUSH，向列表追加值，已核验 2026-09-08。
Redis LINDEX，按位置读取与遍历成本，已核验 2026-09-08。
Redis LRANGE，包含边界的位置范围与成本，已核验 2026-09-08。
Redis LTRIM，保留按位置选择的窗口，已核验 2026-09-08。
Redis ZADD，唯一成员、更新与数值分数，已核验 2026-09-08。
Redis ZRANGE，排名与分数查询、边界及同分排序，已核验 2026-09-08。
Redis ZPOPMIN，立即移除最低分成员，已核验 2026-09-08。
Redis ZREMRANGEBYSCORE，显式按分数清理，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与分配器选择，已核验 2026-09-08。

Redis 的过期是截止时间，逐出是容量策略

Sun, 26 Dec 2027 00:00:00 +0000

过期与逐出都可能让一次成功查找变成未命中，但它们回答的是不同问题。过期服从键的截止时间，逐出则在内存压力下移除符合条件的键。延长 TTL 不能阻止容量驱动的逐出，扩大内存也不能纠正应用写错的截止时间。必须先确定实际发生了哪种变化，才能判断应该检查写入协议、调整容量，还是重新设计缓存用途。

时间与容量是两个独立维度

带有过期设置的键在 Redis 中称为 volatile。Redis 会在访问和主动清理过程中检查过期键，但这不承诺键一定存活到截止时间。显式删除、替换以及适用的逐出策略，都可能提前改变结果。因此，不管最初设定的期限还有多久，缓存客户端都必须能处理未命中，不能把较长 TTL 当作某条数据不会丢失的保证。

maxmemory 是 Redis 进行内存管理决策时使用的统计上限，不是操作系统 RSS 的硬上限。复制与追加日志缓冲区可能包含不计入逐出判断的内存，进程开销、分配器行为和持久化任务也需要容量余量。大型命令还可能短暂超过配置值。规划时既要考虑缓存预算，也要考虑运行整个进程的环境，不能把两者设成同一个数字就认为足够。

先确定候选范围，再讨论排序

allkeys 类策略不管键有没有 TTL，都会把它纳入候选；volatile 类策略则只考虑带过期设置的键。在各自候选范围内，LRU 偏向最久未访问的键，LFU 使用访问频率信息，random 类策略随机选择。Redis 的 LRU、LFU 是近似算法，不保证全局精确的受害键顺序。volatile-ttl 偏向剩余寿命较短的条目，也不是只清除已经到期的数据。

noeviction 在无法满足内存限制时拒绝增长内存的命令，而不是为了腾空间丢键；已有数据仍可能正常读取。但它不是持久性保证，普通过期、显式删除、进程故障和持久化配置仍然分别起作用。应检查当前实例实际配置，不能根据某种部署形式或集群名称，推断所有环境都使用相同默认策略。

volatile 策略如果找不到带 TTL 的候选键，在这种场景下就表现得像 noeviction。选了 volatile-lru，不会自动把持久键变成可丢弃数据。反过来，把会话或权威记录与可重建缓存混放在 allkeys 策略之下，它们也会成为候选。键名前缀只是命名约定，不会给逐出算法建立独立的数据保护边界。

坏掉的样子

未命中突然增加，可能来自过期、逐出、主动失效或键构造变化。需要把 expired_keys、evicted_keys 的增量，与同期请求负载和写命令结果一起看。这些是累计计数，应比较有限时间区间，并考虑重启或重置；仅看到逐出数上升，还不能知道哪个应用功能失去了哪些数据。

除了读取，也要监控被拒绝的写入。热缓存可能继续返回看似合理的值，而写入方已经不断收到内存错误。忽略这些错误，会把容量问题变成应用一致性缺陷。此时延长 TTL 可能只会让旧值保留更久，却不能恢复替换能力；重试策略也不能把内存压力进一步放大成无上限的请求风暴。

将权威状态和可丢弃缓存分开，是架构选择，不是事故中可以直接执行的数据迁移命令。改变现有实例策略之前，应确认可恢复性、持久化和数据归属。下面的实验只修改自己创建的进程，用三个独立候选策略验证行为，不切换生产实例的配置，也不操作现有键空间。

快速验证

准备 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

使用 "$redis_lab/venv/bin/python" 执行 Python 代码。每种策略都创建自己的 Unix socket、空数据集和进程，并关闭 TCP 及持久化。内存限制设置为测得的初始分配量再加两个 MiB，有限次写入使用六十四 KiB 的值，启用 TTL 的分支统一设置一小时。结束时关闭每个实验进程，仅清理自己的临时运行目录。

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(policy="noeviction"):
 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", policy,
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=True,
 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()


for policy, expiring in [("allkeys-lru", True), ("noeviction", True),
 ("volatile-lru", False)]:
 with instance(policy) as client:
 baseline = client.info("memory")["used_memory"]
 client.config_set("maxmemory", baseline + 2 * 1024 * 1024)
 payload = "x" * 65536
 written, rejected = 0, False
 for index in range(128):
 try:
 client.set(f"item:{index}", payload, ex=3600 if expiring else None)
 except redis.exceptions.OutOfMemoryError:
 rejected = True
 break
 written += 1
 stats = client.info("stats")
 remaining = client.dbsize()
 assert stats["expired_keys"] == 0
 if policy == "allkeys-lru":
 assert written == 128 and not rejected
 assert stats["evicted_keys"] > 0 and remaining < written
 assert client.ttl("item:127") > 0
 else:
 assert rejected and 0 < written < 128
 assert stats["evicted_keys"] == 0 and remaining == written
 assert client.get("item:0") == payload
 if not expiring:
 assert client.ttl("item:0") == -1
 print(policy, {"written": written, "remaining": remaining,
 "evicted": stats["evicted_keys"],
 "expired": stats["expired_keys"], "rejected": rejected})

本次 allkeys-lru 接受一百二十八次写入，留下二十三个键，报告一百零五次逐出和零次过期；最新保留键仍有正的 TTL。这说明丢失发生在期限到来之前，原因是容量逐出，但不把这次观察夸大成对精确 LRU 受害顺序的证明，也不要求另一台机器得到相同的键数。

noeviction 接受二十三次写入后拒绝下一次分配，原有键仍能读取，逐出计数保持为零。没有任何带期限键的 volatile-lru 也出现同类拒绝。实际数量受分配开销和构建影响，因此断言检查的是关系，不是强制匹配这组数字。它不是吞吐基准，也不覆盖复制、故障切换、持久化峰值或操作系统级内存限制。

来源

Redis 键逐出，maxmemory 统计、候选策略与近似排序，已核验 2026-09-08。
Redis EXPIRE，键级截止时间及过期行为，已核验 2026-09-08。
Redis INFO，内存统计及逐出、过期计数，已核验 2026-09-08。
Redis 8.10.1 编译说明，独立核心构建与分配器选择，已核验 2026-09-08。

Redis Cluster 把键分到不同的槽位

Fri, 26 Nov 2027 00:00:00 +0000

Redis Cluster 把键的落点与机器身份分成两层：键先映射到一万六千三百八十四个固定槽之一，再由集群元数据描述各槽的主节点和副本。增加机器不会改变槽哈希函数，运维需要重新分配槽，客户端则发现当前拓扑并处理路由变化。槽、分片、主节点与副本不是可以相互替代的概念。

键选择槽，不要求机器持有连续区间

普通映射使用键的 CRC16/XMODEM 值对一万六千三百八十四取模。如果第一个左花括号与其后第一个右花括号之间存在非空标签，则只哈希这部分。例如 profile:{42} 和 quota:{42} 的完整键名不同，却位于同一个槽。标签只是数据放置规则，不是权限控制或租户隔离机制。

一个主节点可以拥有多个不连续的槽段。拓扑稳定时，一个槽有权威主节点；整个键属于该槽，大 hash 或有序集合不会被自动拆到多台机器。CLUSTER SHARDS 能显示分片成员及其槽段。尤其不能把“同一主节点”误当成“同一个槽”：前者是当前机器分配关系，后者才是多键操作需要的条件。

客户端也参与路由

支持集群的客户端维护槽映射，并连接拓扑中公布的节点。访问错误的主节点可能收到带目标地址的 MOVED，而不是得到键不存在。MOVED 要求更新路由；ASK 是迁移期间的临时重定向，需要先向目标发送 ASKING 再发送被重定向的命令，不能因此把该槽永久改归目标节点。

迁移也不是所有参与方瞬间同步更新地图。不同客户端可能暂时持有不同拓扑，多键涉及的数据在迁移期间分散到两端时，还可能得到 TRYAGAIN。应使用维护中的集群客户端，不能假设随便连一个入口就会自动代理所有命令。公布的地址不仅要让 Redis 节点互相可达，也必须能从应用所在网络访问。

放置关系不等于事务范围

MSET 这类服务端多键命令要求所有键属于同一个槽，仅仅处在同一物理主节点上仍不够。哈希标签可以满足同槽条件，但把所有租户都放进同一个标签又会集中负载，削弱分布能力。某个客户端方法如果拆成多个独立命令执行，也不能被当成一个原子的多键命令。

分片分配数据归属，复制则为一个分片提供副本。复制是异步的，所以副本读取可能落后。故障转移提升的是受影响分片的副本，并不是把整个集群作为不可分割的一组一起切换。发生故障时仍可能丢失已经确认的写入；连接中断也可能让调用者无法确定某条写操作最终有没有执行。

坏掉的样子

槽覆盖不完整或可达主节点不足，都可能阻止服务。在 cluster-require-full-coverage yes 下，一个分片不可用会使其他仍健康的主节点也拒绝键命令。三个没有副本的主节点能够展示数据分布，却没有能力从根本不存在的副本中恢复故障节点的数据，不能据此宣布已经具备高可用。

应一起检查槽覆盖、集群状态、副本健康、地址通告和客户端重定向错误。只增加节点不会自动搬迁已有数据，也不会自动拆开单个热键；重新分片、副本放置与客户端重试语义分别需要设计。应测试准备容忍的具体故障，而不是把节点握手成功当成高可用验收结果。

快速验证

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

在同一个 shell 中，用 "$redis_lab/venv/bin/python" 执行 Python 代码。它以临时目录启动三个隔离主节点，分配六个仅监听回环地址的端口，分别用于数据连接与集群总线。配置前通过私有 Unix socket 核对进程身份；关闭持久化，最后只杀死自己创建的第一个主节点，清理时再停止其余进程并移除临时文件。

from contextlib import contextmanager, ExitStack
import os
from pathlib import Path
import signal
import socket
import subprocess
from tempfile import TemporaryDirectory
import time

import redis
from redis.backoff import NoBackoff
from redis.crc import key_slot
from redis.exceptions import ClusterCrossSlotError, ClusterDownError, MovedError
from redis.retry import Retry


def until(check):
 deadline = time.monotonic() + 15
 while not check():
 assert time.monotonic() < deadline, "cluster state did not converge"
 time.sleep(0.05)


@contextmanager
def node(directory, port, bus):
 directory.mkdir()
 endpoint = str(directory / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--bind", "127.0.0.1", "--port", str(port),
 "--protected-mode", "yes", "--unixsocket", endpoint,
 "--unixsocketperm", "700", "--dir", str(directory),
 "--save", "", "--appendonly", "no", "--cluster-enabled", "yes",
 "--cluster-config-file", "nodes.conf", "--cluster-port", str(bus),
 "--cluster-announce-ip", "127.0.0.1", "--cluster-node-timeout", "1000",
 "--cluster-require-full-coverage", "yes",
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=False, protocol=2,
 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:
 assert time.monotonic() < deadline, "Redis did not start"
 time.sleep(0.02)
 assert client.info("server")["process_id"] == process.pid
 yield client, process
 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 in (0, -signal.SIGKILL), errors.decode()


with TemporaryDirectory(prefix="redis-cluster-", dir="/tmp") as directory, ExitStack() as stack:
 leases = [stack.enter_context(socket.socket()) for _ in range(6)]
 for lease in leases:
 lease.bind(("127.0.0.1", 0))
 ports = [lease.getsockname()[1] for lease in leases]
 nodes = []
 for index in range(3):
 leases[2 * index].close()
 leases[2 * index + 1].close()
 nodes.append(stack.enter_context(node(
 Path(directory) / str(index), ports[2 * index], ports[2 * index + 1],
 )))
 clients = [item[0] for item in nodes]
 ranges = [[(0, 4095), (8192, 12287)], [(4096, 8191)], [(12288, 16383)]]
 for client, owned in zip(clients, ranges):
 bounds = [value for interval in owned for value in interval]
 assert client.execute_command("CLUSTER", "ADDSLOTSRANGE", *bounds) == b"OK"
 for index in (1, 2):
 assert clients[0].execute_command(
 "CLUSTER", "MEET", "127.0.0.1", ports[2 * index], ports[2 * index + 1],
 ) == b"OK"
 until(lambda: all(b"cluster_state:ok" in client.execute_command("CLUSTER", "INFO")
 for client in clients))
 shards = [dict(zip(item[::2], item[1::2], strict=True))
 for item in clients[0].execute_command("CLUSTER", "SHARDS")]
 assert len(shards) == 3
 assert sorted(interval for shard in shards
 for interval in zip(shard[b"slots"][::2], shard[b"slots"][1::2])) == [
 (0, 4095), (4096, 8191), (8192, 12287), (12288, 16383),
 ]
 first_id = clients[0].execute_command("CLUSTER", "MYID")
 first_shard = next(shard for shard in shards
 if first_id in [dict(zip(item[::2], item[1::2]))[b"id"]
 for item in shard[b"nodes"]])
 assert first_shard[b"slots"] == [0, 4095, 8192, 12287]
 print("16384 slots are covered; one primary owns two noncontiguous ranges")

 keys = [b"profile:{42}", b"quota:{42}"]
 slot = key_slot(keys[0])
 assert key_slot(keys[1]) == slot
 assert clients[0].execute_command("CLUSTER", "KEYSLOT", keys[0]) == slot
 owner = next(index for index, owned in enumerate(ranges)
 if any(start <= slot <= end for start, end in owned))
 wrong = clients[(owner + 1) % 3]
 try:
 wrong.get(keys[0])
 except MovedError as error:
 assert error.slot_id == slot
 assert error.node_addr == ("127.0.0.1", ports[2 * owner])
 else:
 raise AssertionError("a plain client on the wrong primary must receive MOVED")

 routed = redis.RedisCluster(host="127.0.0.1", port=ports[0],
 socket_timeout=2, retry=Retry(NoBackoff(), 0))
 try:
 assert routed.mset({keys[0]: "Ada", keys[1]: "10"})
 assert routed.mget(keys) == [b"Ada", b"10"]
 print("MOVED names the owner; a cluster client routes a same-slot MSET and MGET")
 other = b"unrelated:2"
 assert key_slot(other) != slot
 assert any(start <= key_slot(other) <= end for start, end in ranges[owner])
 try:
 clients[owner].execute_command("MSET", keys[0], "bad", other, "bad")
 except ClusterCrossSlotError:
 pass
 else:
 raise AssertionError("cross-slot MSET must fail")
 assert routed.get(keys[0]) == b"Ada"
 assert routed.get(other) is None
 print("cross-slot MSET fails even on the same primary, without changing either key")
 finally:
 routed.close()

 assert nodes[0][1].poll() is None
 nodes[0][1].kill()
 assert nodes[0][1].wait(timeout=5) == -signal.SIGKILL
 until(lambda: all(b"cluster_state:fail" in client.execute_command("CLUSTER", "INFO")
 for client in clients[1:]))
 try:
 clients[1].get(b"any-key")
 except ClusterDownError:
 print("without replicas, a missing primary stops key service under full coverage")
 else:
 raise AssertionError("an uncovered cluster must reject key commands")

CLUSTER SHARDS 确认所有槽都有覆盖，而且同一个主节点确实持有两个分离区间。普通客户端在错误节点收到 MOVED，集群客户端则能读写带相同标签的键。另一个键虽然也归同一主节点，却位于不同槽，让 MSET 失败且两边值都没有被改动。杀死一个主节点后，集群进入失败状态，后续键命令被拒绝。

为了明确解析结构，直接检查拓扑回复的连接使用 RESP2，并为本地总线显式设置端口。该实验验证的是本机路由与故障检测，不是生产拓扑：这里没有副本，也没有独立机器。ASK 迁移、真实重新分片、副本提升、网络分区、持久化、TLS、认证和生产吞吐都不在本实验的覆盖范围内。

来源

Redis Cluster 规范，槽哈希、哈希标签、路由、迁移与写入安全，已核验 2026-09-08。
Redis Cluster 扩展指南，分片、复制与部署边界，已核验 2026-09-08。
Redis CLUSTER SHARDS，分片成员与不连续槽段，已核验 2026-09-08。
Redis CLUSTER ADDSLOTSRANGE，在空测试实例中分配槽段，已核验 2026-09-08。
redis-py 8.1.0 集群客户端，路由与客户端配置，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与选择分配器，已核验 2026-09-08。

Redis AOF 用速度换持久性

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

AOF 记录 Redis 的数据变更，供启动时恢复，但选择 AOF 并不等于承诺任何已确认写入都绝不会丢失。持久性取决于 fsync 策略、实际生效的配置、底层存储，以及讨论的是进程退出、操作系统崩溃还是整块磁盘损坏。应该先明确恢复目标，再决定日志策略，不能仅凭“追加日志”这个名称推导保证。

执行、记录与确认不是同一步

Redis 先在内存数据集上执行命令，再把需要持久化的效果传播到 AOF。它不是“每条命令必须先落盘才能修改内存”的执行模型。使用 appendfsync always 时，Redis 在发送回复前同步追加的数据；一起处理的命令可以共用一次写入和 fsync，并不必然每个客户端命令都对应一个独立系统调用。

执行成功、完成同步、客户端收到回复仍是不同的时刻。连接在回复到达前断开，客户端不能据此判断操作没有发生，也不能因为配置了 always 就放心重复执行扣减或计数操作。持久化协议并没有替业务提供重试去重。

AOF 是用于重建状态的表示，不是永久保存所有原始请求的审计流水。Redis 可以转换用于持久化的命令，重写也只保留重建当前数据所需的信息，而非完整历史。因此，已经删除的值并不保证还能从重写后的文件中找回来。

按确认语义选择同步策略

appendfsync everysec 大约每秒安排同步，通常以约一秒的写入暴露窗口换取性能，但不能把它当成任意存储阻塞下都成立的严格丢失上界。appendfsync no 则把刷盘时机交给操作系统；它表示 Redis 不主动请求 fsync，不表示数据永远不会落到磁盘。这两种策略下，一条成功回复都不等于该写入已经进入稳定存储。

appendfsync always 给出更强的本机写入确认约定，同时增加同步开销，影响延迟与吞吐。它仍不能保护磁盘整体丢失、存储栈失信或应用主动误删。还要检查 no-appendfsync-on-rewrite：如果将其打开，后台持久化工作期间会暂停通常的 fsync，即使主要策略写着 always，实际保证也会变弱。检查有效配置比只检查某一个配置项更重要。

重写产物是一组文件

Redis 7 起，AOF 使用 manifest 清单、基础文件和增量文件。启用 aof-use-rdb-preamble 时，基础文件采用 RDB 格式，其后的修改放在增量 AOF 中。这个基础文件属于 AOF 自己的文件集合，不是另外定期生成的 dump.rdb，二者不能因为扩展名相似就混为一谈。

BGREWRITEAOF 的成功回复只表示开始或安排了后台重写，不代表工作已经完成。应结合 INFO persistence 确认重写完成且状态成功。备份时不能只挑一个名字像日志的文件，也不能在重写切换文件期间随意复制目录；要保存彼此一致的 manifest 及其引用的活动文件，才能沿正确顺序恢复。

坏掉的样子

磁盘写入错误、空间耗尽和重写失败都需要告警，配置了 appendonly yes 并不会让这些风险消失。应结合 aof_last_write_status、aof_last_bgrewrite_status、当前重写状态、剩余磁盘空间与应用错误判断健康度。后台任务仍会竞争磁盘，并因写时复制增加内存占用，“后台”不能解释为完全没有前台延迟影响。

日志末尾截断与中部字节损坏的处理语义也不同。检查或修复前应保留原始文件；修复可能丢弃损坏位置之后的命令，不能直接把修复成功当成数据完整。AOF 会忠实保留应用误操作的效果，所以仍需独立留存备份。进程重启成功并不能证明断电安全、复制确认或业务恰好执行一次。

快速验证

准备 POSIX 环境、C 编译器、make、curl、tar 和 Python 3.10 以上版本。本实验已在 macOS、Redis 8.10.1、redis-py 8.1.0、Python 3.14.4 上运行。安装步骤仅以 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

在同一个 shell 中，用 "$redis_lab/venv/bin/python" 执行下面的 Python 代码。它创建私有 Unix socket，不开放 TCP，不安排自动快照或自动 AOF 重写；AOF 使用 always，重写期间也不跳过同步。代码只杀死自己创建的子进程，持久化文件会在临时目录内保留到重启验证完成，最后清理该目录，不连接默认 Redis。

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

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


@contextmanager
def instance(directory, aof):
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--dir", directory, "--dbfilename", "dump.rdb", "--save", "",
 "--appendonly", "yes" if aof else "no", "--appendfsync", "always",
 "--appenddirname", "appendonlydir", "--appendfilename", "appendonly.aof",
 "--aof-use-rdb-preamble", "yes", "--no-appendfsync-on-rewrite", "no",
 "--auto-aof-rewrite-percentage", "0",
 ], 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, process
 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 in (0, -signal.SIGKILL), errors.decode()


def crash(process):
 assert process.poll() is None
 process.kill()
 assert process.wait(timeout=5) == -signal.SIGKILL


with TemporaryDirectory(prefix="redis-aof-", dir="/tmp") as directory:
 with instance(directory, aof=True) as (client, process):
 client.set("counter", 0)
 for expected in range(1, 5):
 assert client.incr("counter") == expected
 assert client.hset("profile", mapping={"name": "Ada", "level": "2"}) == 2
 client.set("deleted", "not retained")
 assert client.delete("deleted") == 1
 rewrites = client.info("persistence")["aof_rewrites"]
 assert client.bgrewriteaof()
 deadline = time.monotonic() + 5
 while True:
 state = client.info("persistence")
 if (state["aof_rewrites"] > rewrites
 and not state["aof_rewrite_in_progress"]
 and not state["aof_rewrite_scheduled"]):
 assert state["aof_last_bgrewrite_status"] == "ok"
 break
 assert time.monotonic() < deadline, "AOF rewrite did not finish"
 time.sleep(0.02)
 assert client.incr("counter") == 5
 assert client.info("persistence")["aof_last_write_status"] == "ok"
 assert not (Path(directory) / "dump.rdb").exists()
 print("rewrite completed; a later INCR returned 5; no standalone RDB")
 crash(process)

 aof_dir = Path(directory) / "appendonlydir"
 entries = []
 for line in (aof_dir / "appendonly.aof.manifest").read_text().splitlines():
 parts = line.split()
 entries.append(dict(zip(parts[::2], parts[1::2], strict=True)))
 active = [entry for entry in entries if entry["type"] in {"b", "i"}]
 assert {entry["type"] for entry in active} == {"b", "i"}
 for entry in active:
 assert (aof_dir / entry["file"]).is_file()
 base = next(aof_dir / entry["file"] for entry in active if entry["type"] == "b")
 assert base.read_bytes().startswith(b"REDIS")
 print("manifest references an RDB-format AOF base and an incremental AOF")

 with instance(directory, aof=True) as (client, process):
 assert client.get("counter") == b"5"
 assert client.hgetall("profile") == {b"name": b"Ada", b"level": b"2"}
 assert client.get("deleted") is None
 assert client.dbsize() == 2
 print("after SIGKILL and restart: counter=5, hash restored, deletion retained")

实验先等待一次确实完成且状态成功的重写，再执行一次额外递增。SIGKILL 之后，manifest 引用 RDB 格式的 AOF 基础文件和增量文件，目录内却没有独立 dump.rdb。重新启动同一目录的 Redis，计数器恢复为五，hash 的两个字段都在，已经删除的键仍不存在。验证字段值和数据类型比只比较键总数更有说服力。

清单检查只针对这里生成的简单文件名，不是通用备份解析器。SIGKILL 跳过正常关闭流程，但操作系统仍然运行，文件系统缓存也仍在。因此，该结果证明的是这条本地 AOF 恢复路径，而不是 everysec 或 no 的实测丢失上界，更不是底层硬件故障时的数据保证。

来源

Redis 持久化，同步策略、多文件 AOF、恢复与备份边界，已核验 2026-09-08。
Redis BGREWRITEAOF，安排重写与完成重写的区别，已核验 2026-09-08。
Redis INFO，持久化状态字段，已核验 2026-09-08。
Redis 8.10.1 配置，同步策略、重写期间的覆盖选项与文件布局，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与选择分配器，已核验 2026-09-08。

WATCH 保护 Redis 中依赖读取的更新决定

Thu, 22 Jul 2027 00:00:00 +0000

MULTI/EXEC 能阻止别的客户端命令插进队列的执行过程，却不会自动保护应用此前已经读到的值。如果两个购买方先读到相同库存，再各自写回计算结果，即使每次 SET 都放进事务，也仍然可能丢失一次更新。问题出在读取与提交之间的空隙，而不是 SET 执行得是否足够连续。

先监视，再读取依赖

WATCH 让 EXEC 变成有条件的执行：被监视的键从建立监视之后不能发生修改。因此，必须先 WATCH，再读取参与决策的数据。若键在提交前改变，Redis 拒绝整个队列并返回空响应；这只是不执行自己的队列，不会撤销竞争方已经完成的修改。

监视与事务状态都属于同一条连接。redis-py 流水线在 watch 之后保留连接，multi 之前的 GET 会立即发出，应用可以读取结果并做判断；multi 之后才转为缓冲命令，等待 execute。用上下文管理器包住一次尝试，可以在结束时重置流水线状态并释放专用连接。

凡是会影响决策的值或“不存在”条件，都要纳入监视范围。只监视库存，却忽略另一个键保存的额度，并不能保护额度判断。WATCH 也不只是比较最终字节：即便 SET 写回相同内容，也可以使监视失效；原来不存在的被监视键被创建，同样会导致冲突。本次版本中，由过期和内存淘汰引起的变化也计算在内。

重试整个决策，而不是旧计算结果

收到明确的冲突结果后，应建立新监视，重新读取依赖，再检查业务条件和计算写入值。继续使用旧库存，相当于把同一个错误判断再执行一次。EXEC 无论成功还是因监视冲突取消，都会清除监视；如果应用读完后决定放弃，也可以通过 UNWATCH 主动解除。

重试需要次数或时间上限，并让调用方知道何时已耗尽预算。热点键上的大量冲突会放大成本，即使最终没有丢数据也会增加延迟。退避可以缓和竞争，却补不上遗漏的监视键。若原生命令已经能表达所需的原子操作，应优先使用它；实验刻意拆开库存算术，是为了展示旧值覆盖问题。

监视检查通过，也不会让事务获得自动回滚能力。EXEC 内部某一条命令运行失败，其它成功命令仍可能已经生效。应校验相关数据模型并逐项检查响应，不要把数个互不相干的副作用放在一起，就称为业务上的全成全败。

坏掉的样子

先读后 WATCH，会漏掉建立监视前的那段竞争窗口。用一条连接监视、另一条连接提交，不会保护后者的队列。在重试循环中发邮件或发起支付，则可能在 Redis 拒绝本次尝试之前，就已经产生了无法随队列取消的外部效果。

还必须区分服务端明确报告的冲突与传输故障。redis-py 8.1.0 在监视期间遇到连接异常，也可能抛出 WatchError；仅凭异常类型，不能断言 EXEC 从未执行。提交之后应答丢失，需要核对业务结果或依赖幂等协议，不能无条件重新执行不可逆动作。

实验用第二条连接主动制造冲突，并断言固定版本客户端的冲突消息。这个消息比较是测试断言，不是生产错误分类方案。实验关闭网络自动重试，避免隐式重新提交干扰观察。Redis Cluster 中普通多键事务还要求相关键位于同一哈希槽，WATCH 不会额外提供跨分片事务协调器。

快速验证

需要具备 C 编译器、make、curl、tar，以及 Python 3.10 或更新版本的 POSIX 环境。此前记录在 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 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()


with instance() as client, client.client() as rival:
 client.set("stock", 2)
 stale = int(client.get("stock"))
 assert rival.decr("stock") == 1
 with client.pipeline(transaction=True) as transaction:
 transaction.set("stock", stale - 1)
 assert transaction.execute() == [True]
 assert client.get("stock") == b"1"
 print("a stale value written inside MULTI/EXEC still loses another decrement")

 client.set("stock", 2)
 conflicts = 0
 for attempt in range(2):
 with client.pipeline(transaction=True) as transaction:
 transaction.watch("stock")
 current = int(transaction.get("stock"))
 assert current > 0
 if attempt == 0:
 assert rival.decr("stock") == 1
 transaction.multi()
 transaction.set("stock", current - 1)
 transaction.set("reservation", "accepted")
 try:
 responses = transaction.execute()
 except redis.WatchError as error:
 assert str(error) == "Watched variable changed."
 conflicts += 1
 assert client.get("stock") == b"1"
 assert client.get("reservation") is None
 continue
 assert responses == [True, True]
 break
 else:
 raise AssertionError("both attempts conflicted")
 assert conflicts == 1 and attempt == 1
 assert client.get("stock") == b"0"
 assert client.get("reservation") == b"accepted"
 print("WATCH rejects the stale queue; the second attempt rereads 1 and commits 0")

 client.set("watched", "unchanged")
 with client.pipeline(transaction=True) as transaction:
 transaction.watch("watched")
 assert transaction.get("watched") == b"unchanged"
 rival.set("watched", "unchanged")
 transaction.multi()
 transaction.set("same-value-marker", "yes")
 try:
 transaction.execute()
 except redis.WatchError as error:
 assert str(error) == "Watched variable changed."
 else:
 raise AssertionError("same-value SET did not invalidate WATCH")
 assert client.get("same-value-marker") is None
 print("WATCH detects a SET even when the resulting bytes are unchanged")

 with client.pipeline(transaction=True) as transaction:
 transaction.watch("not-yet-created")
 assert transaction.get("not-yet-created") is None
 rival.set("not-yet-created", "now-present")
 transaction.multi()
 transaction.set("absent-marker", "yes")
 try:
 transaction.execute()
 except redis.WatchError as error:
 assert str(error) == "Watched variable changed."
 else:
 raise AssertionError("creating a watched key did not invalidate WATCH")
 assert client.get("absent-marker") is None
 print("WATCH also protects a read of an absent key against later creation")

第一组先读到库存二，让竞争连接扣成一，再把根据旧值计算出的一写回事务。两个调用方都想扣一次，最后却只从二变成一。这段明确安排的执行顺序说明：不被插队的提交，修复不了事务之前已经过期的读取结果。

第二组先监视再读。故意插入的竞争扣减使第一次队列被拒绝，预订标记仍不存在，而对手把库存改成一的结果保留。第二次尝试重新监视并读到一，再一起写入零和预订标记。循环最多两次，每一次是否冲突以及最终值都由断言检查，不依赖碰运气产生竞态。

最后两组验证容易漏想的条件：写回相同字节，以及创建原本不存在的监视键。两种情况都会阻止队列里的标记落地。代码打印的四条摘要都来自响应和最终存储状态验证，而不是只看有没有抛异常。

这次验证覆盖隔离实例上的乐观冲突处理，不证明调度公平、预订恰好执行一次、网络故障恢复、持久化或集群切换。实际预订仍需要自己的业务标识，以及对提交结果未知的明确处理方式；示例中的标记键只是便于观察，不能直接当作完整订单协议。

来源

Redis 事务，乐观并发与事务失败语义，已核验 2026-10-15。
Redis WATCH，基于监视键的条件执行，已核验 2026-10-15。
Redis EXEC，空响应与执行结果，已核验 2026-10-15。
Redis UNWATCH，清除连接级监视，已核验 2026-10-15。
redis-py 8.1.0 客户端实现，即时读取、连接绑定及 WatchError 路径，已核验 2026-10-15。
Redis Cluster 规范，多键操作的哈希槽边界，已核验 2026-10-15。
Redis 8.10.1 构建说明，仅编译核心及选择分配器，已核验 2026-10-15。

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 TTL 让每个键自带时钟

Tue, 29 Jun 2027 00:00:00 +0000

Redis 过期机制回答的是一个键什么时候应当停止可见，而不是整个服务最多使用多少内存。截止时间属于键，后续命令可能保留、替换或者移除它。因此，可靠地使用 TTL，既要检查首次写入，也要覆盖更新路径。看到写命令成功，不能证明之前设置的截止时间仍然存在，更不能直接推断数据最终会按原计划消失。

截止时间不是自动滑动计时器

EXPIRE 使用秒，PEXPIRE 使用毫秒。Redis 将过期信息保存为绝对 Unix 时间戳，所以服务器停止运行期间，时间仍然继续流逝。系统时钟必须稳定，跨机器恢复数据时尤其需要注意时钟差异。它不是独立于系统时间变化的单调时长承诺。下面的实验只使用正常流逝的时间，不调整本机系统时钟。

GET 不会刷新过期时间。INCR 这类原地修改保留键已有的超时；普通成功的 SET 则替换值，并清除原来的超时。SET KEEPTTL 可以保留原期限，再次显式设置过期命令则会改变截止时间。需要滑动会话的应用必须主动实现续期策略，不能以为用户每次读取数据都会自然延长访问窗口。

当值和初始寿命属于同一次操作时，应使用 SET EX 或 SET PX 一起写入。分成 SET、EXPIRE 两条命令，会留下一个值已经存在、期限却尚未写入的失败窗口。客户端如果恰好在两条命令之间崩溃，就可能留下持久条目。这是写入协议缺陷，不是后台过期周期执行得太慢，调整清理频率也修复不了它。

检查真正存在的状态

TTL 返回剩余秒数；键存在但没有过期时间时返回 -1，键不存在时返回 -2。PTTL 提供毫秒分辨率，PEXPIRETIME 则返回绝对截止时间。要验证一次读取有没有续期，比较绝对期限比比较两次倒计时更可靠，因为两条查询之间时间正常流逝，本来就可能让剩余数值减少。查询结果只是当时的快照，不保证键一定能存活到那个时刻。

EXPIRE NX 只在没有期限时添加期限。GT 只接受更晚的截止时间，其中持久键被当成无限寿命处理。PERSIST 则显式移除过期设置。调用方需要检查命令返回的结果，不能把“命令被接受”理解成“条件成立且状态已经改变”。相对过期时间为零或负数时，键会立即被删除，并不是改成永久保存的另一种写法。

坏掉的样子

被动过期在访问时检查截止时间，主动过期负责处理那些过期后没有再被访问的键。物理清理延迟，不等于普通主节点 GET 可以持续交付已经过期的值。反过来，条目被移除，也不保证分配器马上把页面交还操作系统。读取可见性、数据结构清理与进程 RSS 是不同观察对象，不能只看其中一个就替其他两个下结论。

TTL 不是硬内存预算。写入速率、值的大小、尚未到期的数据、命令开销和分配器行为都会影响占用；逐出还可能让键在期限到来之前消失。业务授权不能只检查缓存键是否存在，也不能从单实例实验推导复制或故障切换保证。那些工作流仍需明确自己的业务截止时间、读写路径及一致性边界，分别建立验收证据。

快速验证

准备 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

在同一个 shell 中，用 "$redis_lab/venv/bin/python" 执行 Python 代码。它在 /tmp 的专用临时目录下创建 Unix socket，启动独立 Redis，并关闭 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(policy="noeviction"):
 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", policy,
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=True,
 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()


with instance() as client:
 assert client.ttl("missing") == -2
 client.set("session", "A", px=60000)
 deadline = client.pexpiretime("session")
 assert client.get("session") == "A"
 assert client.pexpiretime("session") == deadline
 client.set("session", "B", keepttl=True)
 assert client.pexpiretime("session") == deadline
 print("GET and SET KEEPTTL preserve the absolute deadline")

 client.set("session", "C")
 assert client.ttl("session") == -1
 assert client.expire("session", 60, nx=True)
 assert not client.expire("session", 120, nx=True)
 assert client.expire("session", 120, gt=True)
 assert not client.expire("session", 30, gt=True)
 assert client.persist("session")
 assert client.ttl("session") == -1
 print("plain SET clears TTL; NX, GT and PERSIST follow their conditions")

 client.set("counter", "1", px=60000)
 deadline = client.pexpiretime("counter")
 assert client.incr("counter") == 2
 assert client.pexpiretime("counter") == deadline
 assert client.expire("counter", 0)
 assert client.get("counter") is None
 print("INCR preserves TTL; EXPIRE zero deletes immediately")

 client.pexpire("session", 100)
 limit = time.monotonic() + 3
 while client.get("session") is not None:
 assert time.monotonic() < limit, "key did not expire"
 time.sleep(0.01)
 assert client.ttl("session") == -2
 print("after expiry: GET is None and TTL is -2")

绝对截止时间在 GET 和 SET KEEPTTL 之后保持不变；普通 SET 则使 TTL 变成 -1。条件过期的断言区分了成功更新与条件不满足，PERSIST 又把条目恢复为无期限状态。另一个计数器执行 INCR 后仍保留原期限，EXPIRE 零则让它立即不可读取，证明两种写入语义不能混用。

最后，一百毫秒超时使 GET 返回 None，TTL 返回 -2。程序通过有上限的轮询观察实际消失，不要求操作系统恰好在某个毫秒调度检查。这些结果验证命令语义和普通的过期读取，不证明物理回收时点、主动清理吞吐量、复制行为、故障切换或已经被其他地方复制走的数据是否安全销毁。

来源

Redis EXPIRE，期限更新、条件选项、时钟及主动与被动过期，已核验 2026-10-15。
Redis SET，值与寿命的原子写入及 KEEPTTL，已核验 2026-10-15。
Redis TTL，剩余寿命及 -1、-2 的返回含义，已核验 2026-10-15。
Redis 8.10.1 编译说明，仅编译核心及分配器选择，已核验 2026-10-15。

RDB 与 AOF：两种保住 Redis 的方式

Tue, 15 Jun 2027 00:00:00 +0000

RDB 与 AOF 保存的是 Redis 状态的不同表示。选择之前应回答两个问题：允许丢失多少近期数据，以及可以接受多长恢复时间？单独一个持久化开关无法回答这些问题。真正需要的是可恢复的文件、明确的写入确认策略，以及验证过具体数据值的恢复流程，而不只是能够启动的进程。

快照记录一个时点，不保证固定间隔

RDB 是紧凑的时点数据集。BGSAVE 派生子进程，先写临时文件，完成后再替换旧快照；父进程继续处理请求，但派生进程、写时复制增加的内存以及磁盘工作仍有成本。SAVE 则同步保存并阻塞其他客户端，本文只把它用于很小的隔离测试数据，不应照搬到繁忙服务上。

例如 save 60 1000 同时要求经过指定时间并达到修改次数条件，不是“无论有多少修改，每六十秒都必定生成一份快照”，也不保证保存能按时成功完成。实际恢复暴露窗口取决于最近一份可用快照的状态有多旧；漏掉或失败的保存会扩大这个窗口。因此，要检查成功保存的记录与结果，不能只看配置中的时间数字。

AOF 改变恢复数据的表示

AOF 记录数据变更，并按 appendfsync 策略同步。everysec 通常暴露大约最近一秒的写入，no 把刷盘时机交给操作系统；always 在有效配置允许的情况下先同步再回复，代价是额外的同步开销。这些策略不保护整块存储设备丢失，也不能保证故障切换时被提升的副本包含每一条已经在原节点落盘的写入。

现代 AOF 是 manifest、基础文件和增量文件组成的集合，基础文件可以使用 RDB 格式。因此，“AOF 启动必定从头回放庞大的文本历史”不准确；重写还会去掉重建当前状态不再需要的历史操作。文件大小、启动耗时、重写开销和请求延迟，应结合实际数据集测量，不能仅凭 RDB 或 AOF 的名称排序。

两者同时启用，不等于自动合并

在没有额外启动覆盖的通常配置下，启用了 AOF 的 Redis 会选择 AOF 恢复，而不是先独立加载 dump.rdb，再把另一份日志叠加上去。AOF 内部的 RDB 格式基础文件属于其自身文件集合。另行保留的 RDB 仍可用于备份和明确选择的恢复操作，但不会自动补齐缺损的 AOF 文件。

已有的 RDB 部署也不能仅修改 appendonly 然后直接重启。应遵循官方的在线转换流程，等待初始 AOF 成功生成，并把配置持久化，之后再考虑重启。下面的两个测试分别从空目录开始，目的在于比较恢复语义，绝不是迁移已有数据库的操作清单，更不应替换成生产目录运行。

坏掉的样子

BGSAVE 请求成功只代表请求被接受，不代表快照已经成功完成。存储写入失败、无法创建子进程或磁盘空间不足，都可能让实际可用恢复点停留在很久之前。需要结合 INFO persistence、错误日志和资源余量判断；即使 Redis 仍能回复请求，后台持久化也可能已经失败或显著恶化尾延迟。

如果唯一文件副本与服务位于同一台机器、共享同一个故障范围，那么两种格式都还不能算独立备份。应在机器之外保留一致副本，并实际恢复验证。AOF 会保存应用误删的结果，快照也可能已包含同一个错误。历史留存和应用层数据核验，不能被“进程已经可以接受连接”代替。

快速验证

准备 POSIX 环境、C 编译器、make、curl、tar，以及 Python 3.10 以上版本。实验已在 macOS、Redis 8.10.1、redis-py 8.1.0、Python 3.14.4 上执行。以下步骤只用 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

在同一个 shell 中，用 "$redis_lab/venv/bin/python" 执行 Python 代码。每组测试都有独立目录和 Unix socket，不监听 TCP，不安排自动快照。两组都主动保存一份小快照，只有第二组启用 AOF，并使用 always、保持重写期间同步。SIGKILL 只作用于代码创建的子进程；数据文件保留到重新启动并核验完成，随后清理临时目录。

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

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


@contextmanager
def instance(directory, aof):
 endpoint = str(Path(directory) / "redis.sock")
 process = subprocess.Popen([
 os.environ["REDIS_SERVER"], "--port", "0",
 "--unixsocket", endpoint, "--unixsocketperm", "700",
 "--dir", directory, "--dbfilename", "dump.rdb", "--save", "",
 "--appendonly", "yes" if aof else "no", "--appendfsync", "always",
 "--appenddirname", "appendonlydir", "--appendfilename", "appendonly.aof",
 "--aof-use-rdb-preamble", "yes", "--no-appendfsync-on-rewrite", "no",
 "--auto-aof-rewrite-percentage", "0",
 ], 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, process
 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 in (0, -signal.SIGKILL), errors.decode()


def crash(process):
 assert process.poll() is None
 process.kill()
 assert process.wait(timeout=5) == -signal.SIGKILL


for aof in (False, True):
 with TemporaryDirectory(prefix="redis-restore-", dir="/tmp") as directory:
 with instance(directory, aof) as (client, process):
 assert client.set("version", "snapshot")
 assert client.incr("counter") == 1
 assert client.save()
 snapshot = (Path(directory) / "dump.rdb").read_bytes()
 assert snapshot.startswith(b"REDIS")
 assert client.set("version", "after-snapshot")
 assert client.set("later", "present")
 assert client.incr("counter") == 2
 if aof:
 assert client.info("persistence")["aof_last_write_status"] == "ok"
 crash(process)

 assert (Path(directory) / "dump.rdb").read_bytes() == snapshot
 with instance(directory, aof) as (client, process):
 expected = ([b"after-snapshot", b"present", b"2"] if aof
 else [b"snapshot", None, b"1"])
 assert client.mget("version", "later", "counter") == expected
 assert client.dbsize() == (3 if aof else 2)
 assert (Path(directory) / "dump.rdb").read_bytes() == snapshot
 print("RDB + AOF" if aof else "RDB only", expected)
print("an unchanged standalone RDB does not override enabled AOF recovery")

RDB-only 恢复出的 version 是 snapshot，later 键不存在，计数器是一；启用 AOF 的那组得到 after-snapshot、后来写入的 later 键，以及计数器二。两组的独立 RDB 文件字节在进程被杀和检查重启期间都保持不变，说明第二组不是因为偷偷又保存了一份新快照才恢复更新的数据。

计数器刻意没有先用 SET 初始化：快照里已有一，如果错误地把两次递增再回放到它上面，结果就会变成三，而不是正确的二。这让实验能够检查状态语义，而不只是确认进程启动或键数量相同。

SIGKILL 跳过正常关闭，但并没有让操作系统崩溃，也没有清空文件系统缓存。因此，该实验建立的是快照恢复边界和通常的 AOF 启动选择，并未验证断电、备份传输完整性、副本故障切换或生产数据量下的恢复时间。作出更强承诺之前，应为这些情形分别安排验收。

来源

Redis 持久化，快照、AOF 启动选择、在线转换与备份，已核验 2026-09-08。
Redis SAVE，同步快照行为与阻塞成本，已核验 2026-09-08。
Redis BGSAVE，后台保存及请求被接受的含义，已核验 2026-09-08。
Redis INFO，持久化进度与结果字段，已核验 2026-09-08。
Redis 8.10.1 配置，快照触发条件与 AOF 策略，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅构建核心与选择分配器，已核验 2026-09-08。

Redis 内存比率需要结合分配背景判断

Thu, 03 Jun 2027 00:00:00 +0000

即使应用键已经删除，Redis 进程仍可能保留较大的常驻内存。这个现象值得解释，但它本身既不能证明内存泄漏，也不能直接证明分配器碎片。真正要回答的是哪些字节仍被分配、哪些页面仍驻留，以及这种占用是否威胁实际容量预算。只看一个名字里带“碎片”的比率，很容易选错处理对象。

把不同测量对象分开

INFO memory 中的 used_memory 表示 Redis 统计的分配量，used_memory_rss 则是操作系统观察到的进程常驻内存。它们都不等于应用负载长度的简单相加，键、对象、元数据、客户端及其他开销也要占空间。MEMORY USAGE 可以估计单个键及其值的分配量，包括相关开销，但不测量这个键独立贡献了多少进程 RSS。

mem_fragmentation_ratio 大体比较常驻内存和 Redis 统计的分配量，两者差额还可能包括代码、共享库、栈以及分配器保留的页面。删除数据后分母下降，即使 RSS 几乎不变，比率也可能迅速升高。因此必须同时检查绝对字节数；一个很小的空实例出现较高比率，不等于它正在占用危险数量的内存，更不是必须立即重启的充分理由。

used_memory_peak 有助于解释此前负载峰值留下的占用。used_memory_dataset 是另一个统计视角，不承诺空键空间对应零进程分配。各项数据也并非全都在 INFO 执行的同一瞬间采样。写入活跃时，不应要求经过四舍五入的比率，精确等于独立读取的两个数字相除，否则可能把采样差异误当成实现错误。

先核实分配器和版本

分配器专用指标有助于区分碎片、保留页面和非堆开销，但含义取决于实际构建。Redis 8.10.1 源码通过小尺寸分配桶的碎片计数计算相关指标，并对 Lua 部分作调整。不能把所有版本的指标都简单重算成 active 除以 allocated；通用文档公式与实际行为不符时，应检查对应版本实现，而不是让旧解释覆盖当前事实。

本实验有意使用 libc 编译。该构建没有 jemalloc 的详细统计，Redis 会用其他测量值补算部分分配器字段，碎片计数则保持为零。因此 allocator_frag_ratio 等于一，不证明进程真的完全没有碎片。解释专门字段或选择处理方式之前，应先记录 mem_allocator，确认数字来自真实分配器统计，还是当前构建能够提供的有限信息。

坏掉的样子

RSS 上升的同时数据集也在增长，首先需要分析负载和容量，而不是自动诊断为碎片。数据集下降、RSS 稳定，提示常驻占用被保留，却仍不能识别每个保留页面的用途。同样，一次快照无法排除泄漏。应比较相同负载下的时间序列、值大小分布、历史峰值及进程限制，避免把相关现象直接当成唯一原因。

MEMORY PURGE 只在相应实现支持时尝试让分配器回收。Redis 明确说明，除 jemalloc 外的分配器执行它属于无害的空操作，因此成功回复不是内存已经回收的证据；它也不会删除应用键。主动碎片整理是另一种机制，需要构建支持，启用后还可能增加 CPU 与延迟，必须单独测量成本和收益。

为了降低比率而重启，可能带来停机、冷缓存负载，或者在持久化与恢复不足时丢失数据。应先证明存在实际容量问题，并准备演练过的恢复路径，再把重启纳入处理方案。maxmemory 不是 RSS 上限，键数减少也不保证页面立即归还操作系统；不能只看到键数归零，就宣布整个内存问题已经修复。

快速验证

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 创建专用 Redis 进程和私有 Unix socket，关闭 TCP 与持久化，仅写入自己的三百二十个样本键。值大小交替为十六或六十四 KiB，短暂停顿让指标有机会刷新，但不假设采样恰好发生在某个时刻。结束后关闭自己的进程，移除临时运行目录。

from contextlib import contextmanager
import json
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(policy="noeviction"):
 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", policy,
 ], stdout=subprocess.DEVNULL, stderr=subprocess.PIPE)
 client = redis.Redis(unix_socket_path=endpoint, decode_responses=True,
 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()


with instance() as client:
 def snapshot(stage):
 time.sleep(0.2)
 info = client.info("memory")
 fields = ["used_memory", "used_memory_dataset", "used_memory_rss",
 "used_memory_peak", "mem_fragmentation_ratio", "mem_allocator",
 "allocator_frag_ratio", "allocator_frag_bytes"]
 print(stage, json.dumps({"keys": client.dbsize(),
 **{name: info[name] for name in fields}}, sort_keys=True))
 return info

 empty = snapshot("empty")
 for index in range(320):
 client.set(f"sample:{index}", "x" * (16384 if index % 2 == 0 else 65536))
 assert client.dbsize() == 320
 assert client.memory_usage("sample:0") >= 16384
 loaded = snapshot("loaded")
 assert loaded["used_memory"] > empty["used_memory"] + 10 * 1024 * 1024
 for index in range(1, 320, 2):
 assert client.delete(f"sample:{index}") == 1
 assert client.dbsize() == 160
 half = snapshot("large values deleted")
 assert half["used_memory"] < loaded["used_memory"] - 8 * 1024 * 1024
 for index in range(0, 320, 2):
 assert client.delete(f"sample:{index}") == 1
 assert client.dbsize() == 0
 assert client.memory_usage("sample:0") is None
 cleared = snapshot("all values deleted")
 assert cleared["used_memory"] < half["used_memory"]
 assert cleared["used_memory_peak"] >= loaded["used_memory"]
 assert client.memory_purge()
 snapshot("after MEMORY PURGE")
 print("PASS: logical allocations fell; no RSS or purge-effect threshold is assumed")

原有运行记录在加载后报告 used_memory 约十六点七 MiB。删除所有键后，这个数值降到约一点零四 MiB，而 RSS 仍在二十点八 MiB 附近，于是整体比率升到约二十。MEMORY USAGE 同时确认指定键已不存在：逻辑分配确实减少，但常驻内存没有按同样比例下降，不能仅凭较高比率反推应用键没有删掉。

这次 libc 实验中，分配器专用碎片比率始终为一，MEMORY PURGE 也成功返回，却没有带来有意义的 RSS 下降。断言检查键数和逻辑分配量之间的关系，精确 RSS 仅作观察，不设为通过阈值。它证明统计对象存在差异及空操作限制，不证明 jemalloc 整理的效果、Linux 内存压力行为，也不构成对某个生产进程的泄漏诊断。

来源

Redis INFO，进程、分配、峰值与分配器内存字段，已核验 2026-09-08。
Redis MEMORY USAGE，单键分配估计及相关开销，已核验 2026-09-08。
Redis MEMORY PURGE，jemalloc 支持及其他分配器的空操作行为，已核验 2026-09-08。
Redis 8.10.1 对象统计，对应版本的碎片计算方式，已核验 2026-09-08。
Redis 8.10.1 内存采样，缓存测量结果及补算分配器字段，已核验 2026-09-08。
Redis 8.10.1 编译说明，核心构建与分配器选择，已核验 2026-09-08。

Redis 的键名要起得清楚

Tue, 01 Jun 2027 00:00:00 +0000

Redis 键是平面键空间中的二进制安全名称，不是文件路径，也不是数据库表结构声明。冒号可以按约定分隔业务归属、环境、实体和标识，例如 cart:prod:string:42 能表达意图。但 Redis 不会把这些字段解释成类型检查或访问限制，不能仅凭名字就推断服务端已经替应用建立了约束。

让约定没有歧义

写入方、读取方、维护任务和迁移逻辑，应采用相同字段顺序与标识编码。不同前缀可以让两个服务分别存储同一个业务编号；若最后编码出来的完整名字相同，仍然会碰撞。命名规范帮助人和代码协作，并没有创建由 Redis 独立管理的命名空间。

类型标签也只是说明。SET 可以在名字带 hash 的键下写入字符串，之后 HSET 就会报 WRONGTYPE。排查时应用 TYPE 查看真实数据类型，序列化格式与类型要求则属于应用契约。不能把名字中的“列表”“哈希”当作当前数据已经符合预期的证据。

名字宜简短清晰，不必压缩成难懂缩写，也不要把整段文档塞进去。键名占内存并随命令传输，但对象开销和负载本身同样重要；没有测量就不能宣称一次改名显著加快查询。标识编码还应避免分隔符、通配符和集群花括号取得本来不希望赋予的含义。

模式匹配不等于模式删除

SCAN MATCH 接受 glob 模式。从游标零开始，把每次返回的新游标用于下一次调用，直到再次返回零。COUNT 是工作量提示，不保证精确返回多少条，也不是严格内存上限。某一页可能没有匹配项，但游标还不为零，不能据此提前结束。每次调用仍需要服务端工作，增量扫描不等于完全没有阻塞成本。

完整迭代保证能看到在迭代全过程始终存在、且符合模式的键，但可能重复返回；迭代中新增或删除的键没有同样保证。应用应按需要去重，或让处理逻辑可以安全重复。扫描不是快照，更不能把一个空页面当作集合已经遍历完毕。

DEL 的语义不同：它接收精确键名，不接收模式。参数末尾带星号，不会删除所有同前缀兄弟键；只有真的存在名字包含这个星号的键，才会删除那一个。命令行工具之外还有 shell 展开这一层，应正确引用参数，不要把终端的展开行为误认为 Redis 自己支持通配删除。

坏掉的样子

维护脚本若假定 DEL 会展开前缀，可能实际什么也没删，却报告清理完成。相反，先用宽泛模式收集 SCAN 结果，再无条件删除每个匹配，也可能误伤不属于自己的数据。必须核对精确目标与修改策略；而且发现与删除之间，同名键可能已经被重建，之前审阅过的名字不一定还指向同一个逻辑对象。

前缀也不是安全边界。访问限制应通过合适的 ACL 键模式和命令权限落实，必要时使用独立部署边界。键模式权限无法约束不携带键参数、直接作用于整个数据库的命令，所以给账户一个前缀模式不等于万事安全。服务名前缀也不会自动预留内存，更不构成淘汰策略隔离。

Redis Cluster 的哈希标签是命名约定之外一个会影响路由的明确机制。有效花括号标签决定槽计算所使用的字节；即便两个服务前缀不同，只要标签相同也能落在同一槽。这可以服务于有关联的多键操作，但若给所有键套上同一个固定标签，就可能把负载集中起来，而不是均匀分散。

快速验证

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()


with instance() as client:
 client.set("cart:prod:string:42", "cart-value")
 client.set("billing:prod:string:42", "billing-value")
 assert client.get("cart:prod:string:42") == b"cart-value"
 assert client.get("billing:prod:string:42") == b"billing-value"
 client.set("cart:prod:hash:42", "not-a-hash")
 assert client.type("cart:prod:hash:42") == b"string"
 try:
 client.hset("cart:prod:hash:42", "item", "value")
 except redis.ResponseError as error:
 assert "WRONGTYPE" in str(error)
 else:
 raise AssertionError("a type label unexpectedly enforced a schema")
 print("namespaces separate exact names; a hash label does not create a hash value")

 prefix = "cart:prod:string:"
 expected = {f"{prefix}{number}".encode() for number in range(24)}
 for key in expected:
 client.set(key, "value")
 expected.add(b"cart:prod:string:42")
 cursor, found, pages = 0, set(), 0
 while True:
 cursor, keys = client.scan(cursor=cursor, match=prefix + "*", count=3)
 assert all(key.startswith(prefix.encode()) for key in keys)
 found.update(keys)
 pages += 1
 assert pages < 1000, "unexpected nontermination in this bounded test"
 if cursor == 0:
 break
 assert found == expected
 print("SCAN reaches cursor zero and finds the stable fixture, with duplicates deduplicated")

 assert client.delete(prefix + "*") == 0
 assert all(client.exists(key) for key in expected)
 client.set(prefix + "*", "literal-star")
 assert client.delete(prefix + "*") == 1
 assert all(client.exists(key) for key in expected)
 print("DEL treats the asterisk literally; it does not expand a key pattern")

 from redis.crc import key_slot

 assert key_slot(b"cart:{customer-42}:items") == key_slot(b"billing:{customer-42}:total")
 assert key_slot(b"cart:{customer-42}:items") == key_slot(b"customer-42")
 print("matching hash tags select the same slot across different service prefixes")

第一组在 cart 与 billing 前缀下分别写值，再故意向名字标注 hash 的键写入字符串。TYPE 返回 string，HSET 失败，证明可读标签不会强制建立类型。它们只是不同的完整键名，不是具有目录继承关系的路径。

稳定测试数据包含二十五个匹配的字符串键。扫描循环持续到游标归零，用集合消化可能的重复，也接受页大小变化。测试中的次数上限只是捕获这份小型固定数据上的异常不终止，不是生产通用扫描上限，也没有验证并发增删时的集合完整性。

第一次删除“前缀加字面星号”返回零，二十五个键都还在。创建完全等于那个名称的键后，再删就返回一，其它兄弟键仍保留。实验没有实施通配清理，也没有删除任何共享数据。

最后使用固定版本客户端的 key_slot 计算，确认两个不同前缀、都带 customer-42 标签的键会算出同一个槽。这是在客户端进行的计算，不是实际搭建 Redis Cluster 的路由验收。四条摘要均有断言支撑，但不验证 ACL 强制执行、并发删除安全、集群路由或内存节省。

来源

Redis 键与值，二进制安全键名及命名约定，已核验 2026-09-08。
Redis SCAN，游标保证、重复结果与 COUNT 提示，已核验 2026-09-08。
Redis DEL，精确键参数删除，已核验 2026-09-08。
Redis TYPE，检查真实值类型，已核验 2026-09-08。
Redis ACL 文档，键模式与独立的命令权限，已核验 2026-09-08。
Redis Cluster 规范，哈希标签与槽分布，已核验 2026-09-08。
redis-py 8.1.0 键槽计算，实验使用的客户端哈希算法，已核验 2026-09-08。
Redis 8.10.1 构建说明，仅编译核心及选择分配器，已核验 2026-09-08。

读穿透缓存：未命中时取数回填

Wed, 26 May 2027 00:00:00 +0000

读穿透缓存给调用者提供统一的读取接口：命中时返回已存值，未命中时调用加载函数，再把结果保存起来。关键边界是由谁拥有这个 loader。把它放到缓存接口后面，可以减少重复的查找逻辑，但并不会自动解决并发、写入、访问授权或不同缓存副本之间的一致性。模式名称不是这些能力已经具备的证明。

找到真正负责加载的一层

在 cache-aside 模式中，应用显式查询缓存，未命中后访问数据源并回填；读穿透则让缓存组件拥有这条未命中路径。它可以是应用进程里的库，也可以是远程缓存服务。两种部署方式各有更新边界：修改进程内库的 loader，仍然需要把变更部署到使用它的进程，不能笼统宣称所有读者都会免部署地自动获得新逻辑。

单独一个 Redis GET 也不是读穿透加载器。字符串键不存在时，它返回 nil，不会自动发现并查询你的数据库。客户端库、缓存服务或应用适配层必须另外提供加载逻辑。下面的实验用带记忆功能的函数包装器提供统一读取接口，缓存和数据源都在当前进程内；这不是 Redis 服务端加载功能的演示。

读取模式没有定义写入模式

读穿透本身没有规定写操作经过哪里，写穿透是另一项安排。即便读写共用一个组件，仍需要定义数据源写入和缓存更新分别失败时的行为。绕过组件的其他写入方，可能让缓存保持旧值。应沿真实业务更新路径检查参与者，不能因为使用了一个模式名称，就假定所有写入都会配合清理。

TTL 限制的是某个缓存条目的复用时间，并不保证下一次重载从滞后副本或有缺陷的 loader 中取到最新真值。过期也不一定立即从内存中释放字节。寿命应依据数据需求选择，而非套用统一的几秒或几分钟；用户数据的 TTL 再短，也不构成权限隔离。命中率很高同样不能证明内容正确。

坏掉的样子

记录不存在与数据源不可用，是两个不同结果。缓存一次合法的“不存在”可以减少重复查询，但如果随后创建了记录，这个否定结果也可能继续遮住新记录，直到到期或失效。若把超时转换成一次正常返回的空值，就可能把故障写成错误的缓存内容。必须明确哪些结果允许保存，以及调用者如何区分缺失和失败。

并发加载是另一项独立契约。Cachetools 明确说明：锁保护缓存对象的访问，但被包装的函数在锁外运行，因此只有锁并不能抑制重复加载。它的 condition 选项另行处理同键的并发执行。下面的实验只运行单线程，刻意不使用这两个参数，不能把代码当成已经具备线程安全或分布式协作的实现。

失效还可能与一个已经读到旧源版本的加载操作竞争。删除某个键，并不天然阻止那个在途结果稍后重新写入。应根据真实的写入和加载协议选择协调方式，并测试操作顺序。也不要把大范围按键模式删除当作默认修复：它会让更多条目变冷，却没有证明源头缺陷已经解决。

快速验证

需要 Python 3.10 或更新版本；本次使用 Python 3.12.14 和 cachetools 7.1.8。安装固定依赖后，用 "$readthrough_lab/venv/bin/python" 执行 Python 代码。缓存存储、到期和函数记忆行为都由现有库负责；测试手动推进专用时钟，无需睡眠，也不修改系统时间。实验不联系 Redis 或外部数据库，只有依赖安装需要联网。

readthrough_lab=$(mktemp -d)
python3 -m venv "$readthrough_lab/venv"
"$readthrough_lab/venv/bin/python" -m pip install cachetools==7.1.8

from collections import Counter

from cachetools import TTLCache, cached

clock = [0]
cache = TTLCache(maxsize=8, ttl=10, timer=lambda: clock[0])
source = {"tea": 100}
failures = set()
loads = Counter()


@cached(cache=cache, info=True)
def price(sku):
 loads[sku] += 1
 if sku in failures:
 raise OSError("source unavailable")
 return source.get(sku)


assert price("tea") == price("tea") == 100
assert loads["tea"] == 1
source["tea"] = 120
clock[0] = 9
assert price("tea") == 100 and loads["tea"] == 1
clock[0] = 10
assert price("tea") == 120 and loads["tea"] == 2
print("hit does not extend TTL: old value at t=9; reload at t=10")

source["tea"] = 130
cache.pop(price.cache_key("tea"))
assert price("tea") == 130 and loads["tea"] == 3
print("explicit eviction: next read loads the updated source")

assert price("coffee") is None
source["coffee"] = 200
assert price("coffee") is None and loads["coffee"] == 1
cache.pop(price.cache_key("coffee"))
assert price("coffee") == 200 and loads["coffee"] == 2
print("None is cached: newly created data needs expiry or invalidation")

cache.pop(price.cache_key("tea"))
failures.add("tea")
for _ in range(2):
 try:
 price("tea")
 except OSError:
 pass
 else:
 raise AssertionError("failure was hidden")
assert loads["tea"] == 5
assert price.cache_key("tea") not in cache
failures.remove("tea")
assert price("tea") == price("tea") == 130
assert loads["tea"] == 6
print("exceptions are not cached: two failed loads, then one recovery load")
print(price.cache_info())

前两次读取只执行一次 loader。修改数据源之后，仍然有效的缓存价格不会随之改变，在第九秒仍返回 100；到了第十秒，条目过期，包装器才加载 120。这验证的是从插入开始计算的寿命，而不是每次访问都延长的滑动过期。随后按包装器实际使用的缓存键移除条目，下一次读取才取得新的价格 130。

不存在的 coffee 价格会以 None 形式缓存。仅创建源记录不会替换这份已存的空结果，显式移除后才能重新加载到 200。连续两次源故障都会执行 loader 并抛出异常，缓存中不留下 tea 条目；恢复以后，一次成功加载可以供应两次读取。最后报告四次命中和八次未命中，失败的加载也计入未命中。

这些断言证明的是这个包装器实际观察到的未命中、到期、空结果与错误行为，没有证明写入原子性、并发未命中抑制、内存压力下的淘汰或分布式一致性。验收真实服务时，要把 loader 的执行次数和结果分类与缓存统计一起记录。两次 HTTP 请求变快，或者 Redis 全局命中计数增加，都无法单独指出某个应用 loader 是否真的执行过。

来源

Cachetools 文档，TTLCache、cached、同步选项与异常处理，已核验 2026-09-07。
Redis GET，键缺失时返回 nil，不会加载其他数据源，已核验 2026-09-07。
AWS Builders’ Library：缓存挑战与策略，冷缓存、否定结果缓存与源站负载风险，已核验 2026-09-07。

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 位图用位而不是存储数字

Thu, 29 Apr 2027 00:00:00 +0000

Redis 位图是把字符串按单个位解释的用法，并不是一种独立的键类型。它适合稠密的是非标记，例如按用户记录每日活跃状态。一千万个连续标志需要一百二十五万个载荷字节，但这个估算不包括键名、对象元数据、分配器额外开销，也不包括业务标识到位偏移的映射，不能直接当成实例总内存。

先定义偏移的契约

SETBIT 在从零开始的偏移处写入零或一，并返回写入前的位值。已经为一的位置再次写一，不会增加成员数量。偏移零对应第一个字节的最高位，偏移八才进入第二个字节。对同一个键执行 GET，读到的是底层字节，它们未必是有效文本，所以二进制数据不应默认按 UTF-8 解码。

GETBIT 对缺失键或超出现有字符串长度的位置返回零，而且不会因为读取就扩容。因此，零不能区分“明确不活跃”与“尚未记录”，需要先决定业务是否允许合并这两种状态。SETBIT 与 GETBIT 要求键的值是字符串；如果键实际是哈希，会报类型错误，不会自动把哈希字段转换成位。BITOP 则会在目标键写入新的字符串。

内存取决于写入过的最高偏移，而不是当前有多少个位为一。写偏移 n 至少需要 floor(n / 8) + 1 个载荷字节，即使要写入的是零也一样。后来把高位清零，并不会缩短字符串。稀疏外部编号因此可能用极少的有效标记触发巨大分配。应验证允许的偏移范围，并采用稳定且足够稠密的编号映射，而不是直接信任任意业务 ID。SETBIT 要求偏移小于二的三十二次方，对应最大五百一十二 MiB 字符串。这个协议上限不是合理的单次请求分配预算，应用应按业务规模设置更小的允许范围。

计数和组合都要明确范围

BITCOUNT 默认检查全部字节。可选的 start 和 end 是包含两端的字节位置；从 Redis 7.0 开始，可以用 BIT 修饰符把它们改为位位置。切换单位只改变查询区间，不会改变键里实际存储的表示。返回值是为一的位数，不是最大的成员编号，也不是位图所能容纳的全部用户数。

BITOP OR 计算成员并集，AND 计算交集。较短的输入和不存在的键，会被视为补零到最长输入的长度。目标键会被新字符串覆盖，原本附在目标键上的过期时间也会移除。因此，派生结果需要明确的寿命策略，不能以为之前给结果键设置过一次期限，以后的重算就会自动继承。

坏掉的样子

BITCOUNT、BITPOS 和 BITOP 都可能遍历大量数据。底层位运算即使经过优化，也不代表全量计算是常数时间；把字符串扩展到远端偏移，还需要分配中间的空间。评估时要同时看偏移跨度、查询频率、派生结果保留多久以及峰值分配。活跃用户很少，并不能证明稀疏位图占用的资源很少。

BITPOS 即使只搜索一个子区间，返回的仍是相对于整个位图的绝对位偏移。不指定结束位置而查找零时，如果现有字符串全是一，就可能返回字符串右侧的第一个位置，相当于认为末尾还有补零。明确同时给出起止边界后，范围内找不到目标位才返回 -1。如果用位图表示固定容量的资源池，这两种查询语义不能混用。

找到一个零也不等于已经预约该位置。两个调用方可能先后读到同一空位，再各自写入；单独的 BITPOS 加 SETBIT 不是一个原子占用动作。如果忽略 SETBIT 返回的旧值，就可能把同一位置分给两个人。同样，合并两天的活跃位图，前提是两份数据使用完全相同的编号映射，否则并集结果即使数值正常，也不再代表同一组用户。

快速验证

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" 执行下面代码。程序仅连接自己在 /tmp 下创建的 Redis Unix socket，关闭 TCP 与持久化，终止自身服务进程后只移除本次运行目录。下载依赖需要网络。实验中最大的位图载荷只有一 MiB，不会为了验证原理而分配前面讨论的巨大偏移。

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()


with instance() as client:
 assert client.getbit("missing", 100) == 0
 assert client.exists("missing") == 0
 assert client.setbit("active", 0, 1) == 0
 assert client.setbit("active", 2, 1) == 0
 assert client.setbit("active", 2, 1) == 1
 assert client.type("active") == b"string"
 assert client.get("active") == b"\xa0"
 assert client.bitcount("active") == 2
 print("offset zero is the high bit; repeated SETBIT returns old 1 without adding membership")

 highest = 8 * 1024 * 1024 - 1
 assert client.setbit("sparse", highest, 0) == 0
 assert client.strlen("sparse") == 1024 * 1024
 assert client.bitcount("sparse") == 0
 assert client.setbit("sparse", highest, 1) == 0
 assert client.setbit("sparse", highest, 0) == 1
 assert client.strlen("sparse") == 1024 * 1024
 print("writing a distant zero allocates 1048576 payload bytes; clearing does not shrink")

 client.set("range", b"\x80\x01")
 assert client.bitcount("range", 0, 1) == 2
 assert client.bitcount("range", 0, 1, mode="BIT") == 1
 assert client.bitpos("range", 1, 1, 1) == 15
 client.set("full", b"\xff")
 assert client.bitpos("full", 0) == 8
 assert client.bitpos("full", 0, 0, 0) == -1
 print("ranges default to bytes; BIT changes units; BITPOS returns absolute bit offsets")

 client.set("other", b"\x50\x01")
 client.set("union", b"obsolete", px=60000)
 assert client.bitop("OR", "union", "active", "other") == 2
 assert client.get("union") == b"\xf0\x01"
 assert client.bitcount("union") == 5
 assert client.ttl("union") == -1
 assert client.bitop("AND", "intersection", "active", "other") == 2
 assert client.get("intersection") == b"\x00\x00"
 print("BITOP zero-pads shorter inputs; OR has 5 flags; destination TTL is removed")

 client.hset("hash", "field", b"value")
 try:
 client.setbit("hash", 0, 1)
 except redis.ResponseError as error:
 assert "WRONGTYPE" in str(error)
 else:
 raise AssertionError("a hash is not converted into a bitmap")
 assert client.hget("hash", "field") == b"value"
 print("bitmap commands reject a hash without converting or replacing it")

偏移零和二组合成字节 0xa0，置位计数为二。对远端位置写零仍然生成一百零四万八千五百七十六个载荷字节；把该位写一再清零，长度保持不变。按字节范围与按位范围计数分别得到二和一，带边界的 BITPOS 结果则仍是绝对偏移，并不会从查询区间起点重新编号。

一个全一字节在无界零查询中返回八，在限定到该字节的查询中返回 -1。OR 得到跨两个字节的五个标记，同时目标键的 TTL 被清除；AND 得到两个全零字节。错误类型访问没有改变原来的哈希。这些结果验证存储表示与命令语义，不代表总进程内存测量，也没有证明并发资源分配正确性或生产吞吐量。

来源

Redis SETBIT，旧位值返回和字符串扩容，已核验 2026-09-08。
Redis GETBIT，缺失键与越界位置的读取，已核验 2026-09-08。
Redis BITCOUNT，置位计数及字节与位区间，已核验 2026-09-08。
Redis BITPOS，绝对偏移与有界零查询，已核验 2026-09-08。
Redis BITOP，结果字符串、补零和操作成本，已核验 2026-09-08。
Redis 8.10.1 构建说明，只编译核心及分配器选择，已核验 2026-09-08。

Redis 列表既是队列，也能当栈

Sun, 18 Apr 2027 00:00:00 +0000

Redis 列表是有顺序的字节值序列，可以从两端插入和取出。选择哪一端写、哪一端读，决定了它表现为队列还是栈。阻塞操作只是等待数据到达，并不自动提供分布式锁、消息确认或完整的任务处理协议。这些能力必须根据业务需要另外明确，不能从“支持阻塞”直接推导出来。

先把两端的约定说清楚

RPUSH 配合 LPOP 按先进先出顺序移除元素，早进入的元素先离开；RPUSH 配合 RPOP 则是后进先出。一条 LPUSH 带多个值时，会依照参数顺序逐个往左插入，因此传入 a、b、c 后，从左到右看到的是 c、b、a。设计队列时要验证生产者真正执行的命令，而不是只看图里画了哪一端。

列表允许重复值，相同消息插入两次就占两个位置，不会自动完成去重。当两次投递必须能够区分时，应使用不同的任务标识。LRANGE 的起止位置都包含在返回范围里，-1 表示最后一个元素。最后一个元素被移除时，整个列表键也会消失；对不存在的列表弹出会返回空结果，而不是创建一个空列表占位。

两端操作的单元素成本较低，但返回很大的范围或一次删除许多元素，仍然需要相应的工作量。LTRIM 可以保留最近一段窗口，不过用它裁剪待处理任务，就等于主动丢弃被裁掉的条目。生产者写入和随后的单独裁剪是两条操作，不能当成原子提交。保留哪一段应由数据用途决定，不能把日志窗口策略直接套到任务队列上。

等待的是连接，不是整个服务器

BLPOP 在数据到来或等待超时前阻塞当前连接，其他连接仍可正常执行，生产者也能照常投递。在 redis-py 中，成功结果包含键名和取出的值，超时返回 None；超时参数为零则表示无限等待。客户端的套接字超时需要容纳预期的服务器等待时间及响应时间，否则可能先在客户端超时。

消费者没有业务工作时，阻塞调用仍会占用连接。因此应给消费者设置有界的连接预算，并避免让生产者与正在等待的消费者共用同一条连接。还要区分移除顺序与完成顺序：FIFO 保证先移走较早的元素，多个工作者却可能先完成后来的任务。仅凭阻塞等待，无法保证某个业务资源只有一个持有者。

坏掉的样子

LPOP 和 BLPOP 都在业务处理完成之前把任务从列表里移除。消费者刚取到任务就崩溃，或者服务器弹出后响应丢失，该任务都已经不在待处理列表中。Redis 不会自动把它恢复回来，也不要求消费者确认完成。单独配置持久化，并不能修补这类应用层交接窗口。

Redis 6.2 开始提供 LMOVE，可以在一条原子命令中把任务从待处理列表转移到处理中列表；BLMOVE 是对应的阻塞版本。使用 Redis Cluster 时，两个列表键必须落在同一哈希槽；名称看起来相关，并不能保证满足这一条件。成功处理后，可通过 LREM 按唯一任务标识移除一个条目，作为应用约定的确认。对于长时间没有完成的任务，应用仍需定义恢复策略，因为列表不会自动为每个元素维护租约、时间戳或重试次数。

如果业务副作用已经完成，但确认操作失败，恢复时就可能重复执行。因此唯一任务标识、幂等处理和迟到工作者的处置策略都很重要，两个列表之间的移动不等于恰好执行一次。下面只把一个已知任务明确放回待处理列表，用来验证机制，不把手动操作冒充自动故障检测或生产级恢复调度器。

快速验证

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" 执行下面的代码。程序仅通过 /tmp 下的私有 Unix socket 连接自己启动的 Redis，关闭 TCP、定时快照和追加日志。退出时只终止自己创建的进程并移除本次运行目录。下载依赖需要网络，实验不访问默认本机 Redis，也不会清理其他实例的数据。

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()


with instance() as client:
 client.rpush("fifo", b"a", b"b", b"c")
 assert [client.lpop("fifo") for _ in range(3)] == [b"a", b"b", b"c"]
 assert client.exists("fifo") == 0
 assert client.lpop("fifo") is None
 client.rpush("stack", b"a", b"b", b"c")
 assert [client.rpop("stack") for _ in range(3)] == [b"c", b"b", b"a"]
 client.lpush("left", b"a", b"b", b"c")
 assert client.lrange("left", 0, -1) == [b"c", b"b", b"a"]
 client.rpush("duplicates", b"same", b"same")
 assert client.llen("duplicates") == 2
 print("FIFO a,b,c; LIFO c,b,a; multi-value LPUSH reverses argument order; duplicates stay")

 def consume():
 with client.client() as connection:
 connection.client_setname("list-lab-consumer")
 return connection.blpop("channel", timeout=1)

 with ThreadPoolExecutor(max_workers=1) as worker:
 future = worker.submit(consume)
 deadline = time.monotonic() + 1
 while not any(
 entry["name"] == "list-lab-consumer" and "b" in entry["flags"]
 for entry in client.client_list()
 ):
 assert time.monotonic() < deadline, "consumer never blocked"
 time.sleep(0.01)
 client.rpush("channel", b"job:1")
 assert future.result(timeout=2) == (b"channel", b"job:1")
 assert client.blpop("empty", timeout=0.1) is None
 print("observed a blocked connection; RPUSH wakes it; empty BLPOP times out")

 client.rpush("ready", b"job:2", b"job:3")
 job = client.lmove("ready", "processing", "LEFT", "RIGHT")
 assert job == b"job:2"
 assert client.lrange("ready", 0, -1) == [b"job:3"]
 assert client.lrange("processing", 0, -1) == [b"job:2"]
 assert client.lmove("processing", "ready", "LEFT", "LEFT") == job
 assert client.lrange("ready", 0, -1) == [b"job:2", b"job:3"]
 assert client.lmove("ready", "processing", "LEFT", "RIGHT") == job
 assert client.lrem("processing", 1, job) == 1
 assert client.exists("processing") == 0
 print("LMOVE retains an in-flight job; explicit requeue and LREM acknowledgement work")

 client.set("wrong", b"not a list")
 try:
 client.lmove("ready", "wrong", "LEFT", "RIGHT")
 except redis.ResponseError as error:
 assert "WRONGTYPE" in str(error)
 else:
 raise AssertionError("LMOVE must reject a non-list destination")
 assert client.lrange("ready", 0, -1) == [b"job:3"]
 assert client.get("wrong") == b"not a list"
 client.rpush("recent", b"1", b"2", b"3", b"4")
 client.ltrim("recent", -2, -1)
 assert client.lrange("recent", 0, -1) == [b"3", b"4"]
 print("wrong-type move preserves source; LTRIM keeps only the requested window")

第一组断言分别验证先进先出、后进先出、多参数 LPUSH 的次序以及重复条目不会消失。生产者先通过 CLIENT LIST 确认消费者连接确实处于阻塞状态，再提交任务；另外一次对空列表的弹出则在有限等待后返回 None。这是在观察真实阻塞与唤醒，不是靠提前写好数据来模拟，也不要求精确的调度延迟。

LMOVE 取出的任务仍留在处理中列表，反向移动能把它重新入队，后续的 LREM 则移除确认条目。当目标键类型错误时，命令报错而源列表没有丢失元素。最后，LTRIM 只保留指定的两个值。这些检查证明命令行为，没有验证崩溃持久性、自动恢复、吞吐量或分布式锁语义。

来源

Redis LPUSH，多值插入的顺序，已核验 2026-09-08。
Redis LRANGE，包含端点的区间与操作成本，已核验 2026-09-08。
Redis BLPOP，连接阻塞、超时和移除式投递，已核验 2026-09-08。
Redis LMOVE，原子转移与处理中列表模式，已核验 2026-09-08。
Redis LREM，按值与数量移除元素，已核验 2026-09-08。
Redis Cluster 规范，多键命令的同槽边界，已核验 2026-10-15。
Redis 8.10.1 构建说明，只编译核心及分配器选择，已核验 2026-09-08。

Redis · XB 现场笔记

Redis hash 用一个键装多个字段

只读取调用方真正需要的字段

更新操作有精确的返回语义

紧凑编码是实现选择

坏掉的样子

快速验证

来源

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

先确定每个事件交给谁

保留窗口不是持久化设置

坏掉的样子

快速验证

来源

Redis Streams 让一个消费组分担工作

读取位置与待处理任务不同

恢复需要显式决策

坏掉的样子

快速验证

来源

Redis 按距离处理地理位置

经度必须放在纬度前面

把查询条件写成明确契约

坏掉的样子

快速验证

来源

测量 Redis 流水线的实际收益

比较等价的工作

计入应用实际支付的成本

坏掉的样子

快速验证

来源

Redis Lua 脚本执行时不被穿插

把判断放在数据旁边

坏掉的样子

保留源码，限制工作量

快速验证

来源

Redis 列表与有序集合，一字之差用途不同

先定义什么算不同条目

位置和分数选择的是不同内容

坏掉的样子

快速验证

来源

Redis 的过期是截止时间，逐出是容量策略

时间与容量是两个独立维度

先确定候选范围，再讨论排序

坏掉的样子

快速验证

延伸阅读

来源

Redis Cluster 把键分到不同的槽位

键选择槽，不要求机器持有连续区间

客户端也参与路由

放置关系不等于事务范围

坏掉的样子

快速验证

来源

Redis AOF 用速度换持久性

执行、记录与确认不是同一步

按确认语义选择同步策略

重写产物是一组文件

坏掉的样子

快速验证

来源

WATCH 保护 Redis 中依赖读取的更新决定

先监视，再读取依赖

重试整个决策，而不是旧计算结果

坏掉的样子

快速验证

来源

Redis 流消费组记录投递位置

消费组在投递时推进位置

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

坏掉的样子

快速验证

来源

Redis TTL 让每个键自带时钟

截止时间不是自动滑动计时器

检查真正存在的状态