LPUSH + BRPOP（或RPUSH + BLPOP）天然保证单消费者FIFO顺序；混用命令、依赖本地时间戳或误用LPOP会导致乱序；List比Stream更适配严格串行场景；需设BRPOP超时、任务占位锁及心跳检测防卡死。
Redis List 做队列时，单消费者怎么保证入队顺序和出队顺序一致
用 LPUSH + BRPOP（或 RPOP）组合，天然保序。Redis 的 List 是链表结构，LPUSH 从左端插入，BRPOP 从右端阻塞弹出，整个过程严格 FIFO，只要只有一个消费者，顺序不会乱。
常见错误是混用命令：比如用 RPUSH 入队、BRPOP 出队，看起来也 FIFO，但一旦中间有多个生产者并发 RPUSH，而 Redis 不保证多命令原子性（除非包在 EVAL 或事务里），就可能因网络延迟/执行时机导致逻辑错位；更危险的是误用 LPOP 配 RPUSH，这直接变成 LIFO。
- 始终固定一端进、另一端出：推荐
LPUSH+BRPOP（左进右出）或RPUSH+BLPOP（右进左出） - 避免在应用层对同个 key 混用
PUSH/POP方向 - 不要依赖客户端本地时间戳或序列号来“重排序”——List 本身已有序，加额外排序反而引入竞态
为什么不用 Redis Stream 而坚持用 List
Stream 确实支持多消费者组、消息确认、历史回溯，但它的「全局递增 ID」和「消费者组内无序投递」特性，在单消费者强顺序场景下反而是累赘。比如你用 XADD 发 5 条，再用 XREADGROUP 拉取，Redis 不保证这 5 条一定按 ID 顺序被同个 consumer 处理完——尤其当 consumer 崩溃重连后，pending 队列可能打乱处理节奏。
List 则简单粗暴：没有 pending、没有 group、没有 ack 概念，BRPOP 成功即出队，失败不丢数据（除非超时重试逻辑写错），适合「任务必须逐条、严格串行执行」的场景，比如订单状态机流转、数据库 binlog 补偿同步。
- Stream 适合「至少一次+可重复处理」，List 适合「恰好一次+不可跳步」
- Stream 的
MAXLEN截断是按条数，List 的LTRIM是按索引，后者更可控 - 如果未来要扩为多消费者，List 就得改架构；但若现在明确只需单线程串行，别过早上 Stream
单线程消费时，如何防止任务卡死导致后续全部阻塞
BRPOP 默认无限等待，一个耗时长或异常 hang 住的任务，会把整个消费线程堵死。必须设超时，并在超时后主动检查当前任务状态，而非无脑重试。
- 给
BRPOP加超时参数，例如BRPOP queue_name 30（30 秒） - 超时后不直接
continue，先用LLEN queue_name看队列是否真空，排除网络抖动误判 - 任务执行前用
SET task_id processing EX 600 NX做轻量占位，防止进程崩溃后残留任务无人接手 - 绝不把 DB 查询、HTTP 调用等阻塞操作裸写在消费循环里——应拆成「取任务 → 写待处理标记 → 异步执行 → 更新结果」三步
Python 示例：带心跳检测的健壮单消费者
import redis
import time
<p>r = redis.Redis()
queue_key = "task_queue"</p><p>while True:</p><h1>阻塞最多 30 秒</h1><pre class="brush:php;toolbar:false;">result = r.brpop([queue_key], timeout=30)
if result is None:
continue # 超时，继续轮询
_, task_data = result
task_id = task_data.decode()
# 尝试加锁，10 分钟过期，仅当不存在时设置
lock_key = f"lock:{task_id}"
if r.set(lock_key, "1", ex=600, nx=True):
try:
process_task(task_data) # 实际业务逻辑
finally:
r.delete(lock_key) # 必须释放
else:
# 锁存在，说明其他实例已在处理（或崩溃残留），跳过
pass
这里没用 WATCH/MULTI 事务，因为单命令 SET ... NX EX 已足够原子。重点不是锁多严谨，而是避免一个失败任务拖垮整条流水——超时、占位、跳过，三者缺一不可。
真正容易被忽略的，是消费者进程自身的心跳上报。如果只靠 Redis 连接存活判断，无法区分「卡死」和「正常慢任务」。建议额外用 SET consumer_heartbeat timestamp EX 60 定期刷新，由外部看门狗检查，否则故障发现延迟会远超预期。
