队列 · XB 现场笔记

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 保持有序，并行消费者的业务完成顺序仍可能与写入顺序不同，不能把分担任务解释成串行执行。

快速验证

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

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

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

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

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


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


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。

背压只有改变生产者行为，才真正控制了有界接入

Thu, 12 Aug 2027 00:00:00 +0000

背压把消费者的有限容量与生产者行为联系起来。通道已满时，生产者可能等待、拒绝新任务，或执行经过明确选择的丢弃策略。关键是容量限制真正改变上游怎么做。队列不断增长，或仪表盘显示积压，只能说明供需失衡，本身不自动形成控制接入的机制。需要从观察到过载，继续追到生产者是否确实减速或停止提交。

坏掉的样子

无界队列可以吸收短暂突发，却也会隐藏持续过载。如果到达速度长期超过完成速度，未完成任务和等待时间就持续增长。把积压挪到待处理线程、重试任务或另一个无界缓冲，并没有消除压力。容量边界必须覆盖任务真正被保存的位置，不能只限制一个容易观察的队列对象，却允许周围继续无限保留工作。

有界队列本身也没有定义完整过载策略。无限阻塞可能耗尽生产者线程或让关闭流程卡住；立即拒绝时，调用方若误认为成功，就可能丢失工作；每次拒绝后立即重试，又可能加重负载。应依据应用契约明确选择：在截止时间内等待、拒绝并稍后重试，还是有意丢弃。不同选择改变交付语义，不能在实现中含糊处理。

队列容量与处理完成是两件事。消费者取出项目可以释放槽位，但此时可能仍在处理这个项目。等待容量为二，也可能同时还有额外执行中的工作。生产者成功入队，仅说明队列接受了项目，不证明已经执行、持久保存或完成下游副作用。若把所有这些状态都叫作“成功”，过载和失败时就无法判断责任归属。

快速验证

将脚本保存为 check-backpressure.py，运行 python3 check-backpressure.py。它只使用 Python 标准库，在 Python 3.14.4 上执行。线程通过明确事件和有界等待协调，不依赖远端消息代理、数据库或刻意拖慢的外部服务。所有队列和任务都只存在当前进程中，结果用于观察接入与完成的语义，不代表分布式队列的持久化保证：

from queue import Queue,Full
from threading import Event,Thread
import json

unbounded=Queue()
for item in range(1000):unbounded.put_nowait(item)
assert unbounded.qsize()==1000
channel=Queue(maxsize=2)
channel.put('a');channel.put('b')
try:
 channel.put('deadline-rejected',timeout=.02)
 raise AssertionError('a full bounded queue accepted another item')
except Full:rejected=True
assert channel.qsize()==2
entered,delivered=Event(),Event()
def produce():
 entered.set();channel.put('c',timeout=2);delivered.set()
producer=Thread(target=produce,daemon=True);producer.start();assert entered.wait(1)
assert not delivered.wait(.05) and channel.qsize()==2
first=channel.get(timeout=1);assert first=='a'
assert delivered.wait(1);producer.join(timeout=1);assert not producer.is_alive()
assert channel.qsize()==2
rest=[channel.get(timeout=1),channel.get(timeout=1)];assert rest==['b','c']
assert channel.empty()
completed=Event()
def join():channel.join();completed.set()
waiter=Thread(target=join,daemon=True);waiter.start();assert not completed.wait(.05)
for item in [first,*rest]:channel.task_done()
assert completed.wait(1);waiter.join(timeout=1);assert not waiter.is_alive()
print(json.dumps({'unbounded_backlog':unbounded.qsize(),'bounded_capacity':2,'deadline_rejected':rejected,
 'blocked_producer_resumed_after_get':delivered.is_set(),'delivered_items':[first,*rest],
 'empty_queue_did_not_mean_processing_complete':True,'join_finished_after_task_done':completed.is_set()}))

第一个队列使用默认无界容量。没有消费者运行时，一千次 put_nowait 全部成功，留下同样数量的积压。这是小规模行为演示，不是耗尽内存测试。它说明接入成功本身无法证明下游已有进展，也不能证明到达速度可持续。监控若只统计提交成功率，就可能在处理能力不足时仍显示表面正常。

第二个队列容量为二，先放入 a 和 b。再次 put 使用短超时，随后抛出 Full，已有项目保持不变。失败项目没有被暗中排队等待以后执行。调用方因此获得明确接入结果，可以按契约决定重试或拒绝，而不是把无限等待包装成已经交付。脚本核对队列状态，避免仅凭异常出现就忽略是否发生了部分接收。

随后生产者线程尝试放入 c。两个槽位占满时，测试确认它仍被阻塞。取出 a 后空出一个位置，生产者完成 put，队列留下 b 和 c。程序验证三个已接受项目最终按顺序被取出。这演示压力确实传递到了生产者，又被具体容量变化释放，而不是仅记录一个队列长度，却让生产者继续无节制提交。

取出其余项目后，队列已经为空，但另一个等待 join 的线程仍未完成。只有对三个已接受项目分别调用 task_done，join 才返回。取出动作先释放容量，任务确认之后才表示被跟踪工作完成。测试刻意分开这些事件，避免把队列清空误认为业务处理结束。生产系统也需要对“拿到任务”和“完成任务”保留对应区分。

让接入契约贯穿整个处理链

应使用队列操作的真实结果，不要根据 qsize 或 full 先检查再行动。其他线程可以随时改变队列，这些观察在并发环境下只具有近似性质。本例通过事件和暂停消费者，使断言对应受控观察；生产调用方应通过操作本身处理 Full 或成功 put，避免在检查与提交之间发生竞争，或将过期容量判断当成保证。

容量应对应真正保留的资源。项目大小不受限时，按个数限制不能直接封顶内存；等待队列限制也不包括所有活跃工作线程或外部请求。评估过载时，需要一起考虑处理并发和上游重试。一个有界组件周围如果仍存在无限待处理工作，整个系统依然可能无界，不能因局部出现 maxsize 就宣布过载闭环已经完成。

最后要定义完成的含义。Python task_done 更新队列记账，不是持久事务，也不证明外部副作用成功。工作线程失败、进程崩溃，或响应不明确之后的重试，都需要应用对应的交付与幂等契约。背压控制接入和节奏，正确性仍依赖明确处理已接受、被拒绝、执行中与已完成任务。两类职责配合，才能在压力变化时保持可解释行为。

来源

Python queue documentation，有界容量、Full、阻塞写入与任务完成，已核验 2026-09-12。
Google SRE: Handling Overload，客户端节流、负载丢弃与基于资源的过载限制，已核验 2026-09-12。

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。

队列定义投递，消费者仍须保护副作用

Fri, 05 Feb 2027 00:00:00 +0000

队列的投递承诺只描述工作流程中的一段边界。消息到达消费者，与业务副作用已经提交，是不同事件。至少一次允许重复投递，至多一次则允许在不确定时丢失而不继续重试。仅凭这两个标签，不能保证订单、通知或数据库更新在所有故障下都恰好完成一次。可靠性需要沿真正的数据和确认路径逐步检查。

找到发布、确认与提交的位置

首先明确生产方何时知道 broker 已经接受消息、保留多久，以及持久化政策覆盖哪些故障。消息从未成功发布、超过保留期或被明确删除，都不会因为消费者自称至少一次就自动恢复。恢复前提必须与投递标签一起记录，否则“永不丢失”会遮住多个根本没有交给队列负责的环节。

消费方若先确认，再提交业务结果，就会形成丢失窗口：broker 停止重试时，应用可能还没完成工作。先提交又留下另一种窗口：结果已成功，但确认丢失，工作于是重新出现。这个重复仍然符合投递契约，并不意味着最初操作失败。排查时要分别检查业务结果与确认结果，不能用其中一个推断另一个。

可见性超时与确认期限控制的是何时允许下一次尝试，不证明第一个工作进程已经停止。慢处理者可以与重投后的处理者同时运行，因此延长期限与防止重复副作用解决的是不同问题。应同时记录投递尝试和已经提交的业务结果，而不是只统计消费者调用次数，便把它当作成功执行次数。

在真正的事务边界内消除重复效果

若副作用都位于同一个事务数据库，可以把唯一操作身份与业务结果放进同一事务。唯一性检查必须能够裁决并发尝试，单独读取再无保护地写入并不够。还需要保存足够的载荷信息，识别“同一身份却携带不同指令”的情况，不能看到编号重复就无条件接受。这既是去重问题，也是操作身份的契约问题。

数据库事务不会自动包住外部邮件、支付接口或另一套独立存储。这些目标需要自己的幂等或协调契约。本地标记先写、远端调用后做，可能丢失效果；标记后写，则可能留下重复窗口。因此，本地去重表不能被说成端到端恰好一次保证。只有明确哪些动作一起提交、哪些动作仍独立失败，设计才有可检查的边界。

有些服务确实提供带明确范围的恰好一次投递能力，例如 Google Pub/Sub 说明了地域、订阅类型等限制，也区分投递重复与发布侧重复。应阅读具体契约，不应宣称这个能力不可能存在，也不能把它推广成所有下游副作用都已解决。多个已发布消息代表同一业务意图时，稳定业务身份仍然有独立价值。

坏掉的样子

持续失败的消息可能阻塞有序进度，过短期限则可能让本来正常的任务出现重叠尝试。重投计数能提供调查线索，却不能唯一判断是毒数据、慢依赖、确认丢失还是工作进程停滞。应关联消息身份、载荷、异常、处理时长和确认记录，再决定怎样修改重试政策。只根据“一条还是多条计数升高”断言根因，很容易修错位置。

需要限制重试并说明隔离失败如何审阅或重新执行。进入死信队列只是移动未完成工作，并没有完成它。去重记录的保存期限必须覆盖计划容忍的重放范围，删除身份记录之后，旧请求可能再次生效；永远保存又有存储和隐私代价。这里没有适用于所有任务的统一选择，应把保留与重放规则一起设计。

快速验证

保存为 delivery_guarantee_probe.py，使用 Python 3 运行。本次在 Python 3.12.14 与 SQLite 3.53.1 上通过。实验验证真实事务消费落点，而不是模拟 broker：临时数据库同时保存操作身份和一个无害数字总计，不会对任何账户扣款，也不向外发送消息。只有本程序自己的临时文件会被创建和清理。

from contextlib import closing
from pathlib import Path
from tempfile import TemporaryDirectory
import sqlite3


def apply(db, message_id, amount, interrupt=False):
 db.execute('BEGIN IMMEDIATE')
 try:
 prior = db.execute('SELECT amount FROM inbox WHERE id=?', (message_id,)).fetchone()
 if prior is not None:
 if prior[0] != amount:
 raise ValueError('same identity, different payload')
 db.commit()
 return False
 db.execute('INSERT INTO inbox VALUES (?, ?)', (message_id, amount))
 db.execute('UPDATE totals SET amount=amount+? WHERE id=1', (amount,))
 if interrupt:
 raise RuntimeError('controlled failure before commit')
 db.commit()
 return True
 except BaseException:
 db.rollback()
 raise


with TemporaryDirectory(prefix='queue-sink-') as directory:
 path = Path(directory) / 'sink.db'
 with closing(sqlite3.connect(path, isolation_level=None)) as db:
 db.execute('CREATE TABLE inbox(id TEXT PRIMARY KEY, amount INTEGER NOT NULL)')
 db.execute('CREATE TABLE totals(id INTEGER PRIMARY KEY, amount INTEGER NOT NULL)')
 db.execute('INSERT INTO totals VALUES (1, 0)')
 try:
 apply(db, 'work-1', 100, interrupt=True)
 except RuntimeError:
 pass
 else:
 raise AssertionError('controlled failure did not occur')
 assert db.execute('SELECT count(*) FROM inbox').fetchone() == (0,)
 assert db.execute('SELECT amount FROM totals').fetchone() == (0,)
 assert apply(db, 'work-1', 100)
 assert apply(db, 'work-2', 50)
 # Close and reopen the real database rather than retaining an in-memory set.
 with closing(sqlite3.connect(path, isolation_level=None)) as db:
 assert not apply(db, 'work-1', 100)
 try:
 apply(db, 'work-1', 999)
 except ValueError:
 pass
 else:
 raise AssertionError('conflicting payload reused the same identity')
 assert db.execute('SELECT count(*) FROM inbox').fetchone() == (2,)
 assert db.execute('SELECT amount FROM totals').fetchone() == (150,)
 assert not db.in_transaction
 print('rollback kept marker and effect together; reopened retry changed nothing; total=150')

两项写入之后主动抛出的异常，会让身份标记与总计一起回滚。随后重试，提交两项操作；关闭并重新打开数据库后，重复第一项身份不会改变结果，而用不同数额复用相同身份会报错。最终数据库有两个身份，总计为一百五十，并且连接不在事务中。这个检查比只把编号放进内存集合更能说明持久化边界。

这里验证的是 SQLite 落点中的回滚、关闭连接后重新打开仍保留已提交状态，以及重复处理。实验没有终止进程，没有模拟断电，没有运行并发消费者，也没有验证 broker 的发布、重投与确认。要作更广泛的投递承诺，仍须使用目标服务单独验证这些环节，不能把本地去重成功当成整个消息系统已经验收。

来源

Amazon SQS 标准队列，至少一次投递与重复处理，已核验 2026-10-15。
Amazon SQS 可见性超时，重试资格与重复边界，已核验 2026-10-15。
Google Pub/Sub 恰好一次投递，范围限定与发布侧重复，已核验 2026-10-15。
SQLite 事务，显式事务、提交与回滚，已核验 2026-10-15。

队列 · XB 现场笔记

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

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

恢复需要显式决策

坏掉的样子

快速验证

来源

背压只有改变生产者行为，才真正控制了有界接入

坏掉的样子

快速验证

让接入契约贯穿整个处理链

延伸阅读

来源

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

先把两端的约定说清楚

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

坏掉的样子

快速验证

来源

队列定义投递，消费者仍须保护副作用

找到发布、确认与提交的位置

在真正的事务边界内消除重复效果

坏掉的样子

快速验证

延伸阅读

来源