Redis Pub/Sub 不支持事务保证，无法实现ACID分布式事务，仅能作为轻量级事件通知触发器；真正的状态一致性必须依赖Redis Key过期监听、数据库记录或外部幂等服务等机制协同保障。
Redis 的发布订阅（Pub/Sub）本身不提供事务保证，不能直接实现 ACID 分布式事务。它只是一个轻量级、即发即弃的消息广播机制：消息不持久、无确认、无重试、无顺序保障，订阅者离线期间消息直接丢失。所以，如果你期望用 SUBSCRIBE + PUBLISH 替代 Kafka 或 RocketMQ 来做可靠事务协调，大概率会在生产环境踩坑。
但现实中，确实有人用它“模拟”分布式事务协调逻辑——关键在于不依赖 Pub/Sub 传递核心状态，只用它做低延迟、高并发的事件通知触发器，真正的状态和一致性保障交给其他机制（如 Redis key 过期监听、数据库记录、或外部幂等服务）。下面分几个实操重点讲清楚怎么做、为什么这么设计、以及哪些地方最容易翻车。
为什么不能直接用 publish / subscribe 做事务提交点
常见错误是把 PUBLISH "tx:commit" '{"tx_id":"abc123"}' 当作“提交指令”，然后让所有参与者监听并执行本地 commit。这会立刻暴露三个硬伤：
-
PUBLISH返回值只是当前在线订阅者数量，不表示消息是否被消费 —— 订阅者进程崩溃、网络抖动、甚至只是pubsub.listen()调用前漏了一条，就彻底断链 - 没有消息重放能力：
PSUBSCRIBE或SUBSCRIBE只接收连接建立后的消息，历史事件完全不可追溯 - 频道无权限隔离：任意客户端都能
PUBLISH到同名频道，恶意或误操作可伪造事务事件
真正可用的协调模式：用 PUBLISH 触发轮询，用 KEYEVENTS 监听状态变更
想让 Pub/Sub 在事务协调中起作用，必须把它降级为“信号枪”，而不是“信使”。推荐组合方案：
- 各服务在本地事务成功后，写入一个带过期时间的 Redis key，例如
tx:abc123:serviceA:done，TTL 设为 5 分钟 - 同时
PUBLISH tx:trigger "abc123"—— 这个动作极轻，只通知“可能有新事务状态了” - 协调器（或每个服务自己的后台任务）监听
tx:trigger，收到后立即SCAN所有tx:abc123:*:donekey，检查是否全部存在 - 更健壮的做法：开启 Redis 的键空间通知
notify-keyspace-events Ex，监听__keyevent@0__:expired事件 —— 某个服务超时未写 key，事件一触发，协调器就知道该走补偿流程
Python 示例：监听触发 + 校验 key 状态（非阻塞、可重入）
import redis
import json
import time
<p>r = redis.Redis()
pubsub = r.pubsub()
pubsub.subscribe('tx:trigger')</p><p>def check_tx_completion(tx_id):</p><div class="aritcle_card flexRow artxards">
<div class="artcardd flexRow">
<a class="aritcle_card_img" rel="nofollow" href="/xiazai/skill9083" title="redis-tools"><img
src="https://img.php.cn/upload/skill/000/000/081/179240224996227.jpg" alt="redis-tools" onerror="this.onerror='';this.src='/static/lhimages/moren/morentu.png'" ></a>
<div class="aritcle_card_info flexColumn">
<a rel="nofollow" href="/xiazai/skill9083" title="redis-tools" class="overflowclass">redis-tools</a>
<p class="overflowclass">按类别查找Redis命令、检测服务器连接、监控键数量和内存占用，支持离线速查表。</p>
</div>
<a rel="nofollow" href="/xiazai/skill9083" title="redis-tools" class="aritcle_card_btn flexRow flexcenter"><b></b><span>下载</span>
</a>
</div>
</div><h1>SCAN 比 KEYS 安全，避免阻塞</h1><pre class="brush:php;toolbar:false;">cursor, keys = r.scan(match=f'tx:{tx_id}:*:done', count=100)
done_services = {k.decode().split(':')[2] for k in keys}
expected = {'serviceA', 'serviceB', 'serviceC'}
return done_services == expectedfor msg in pubsub.listen(): if msg['type'] != 'message': continue tx_id = msg['data'].decode() if check_tx_completion(tx_id): r.publish('tx:committed', tx_id) # 仅用于下游通知，不承载状态 print(f"✅ TX {tx_id} confirmed") else: print(f"⏳ TX {tx_id} still pending: {check_tx_completion(tx_id)}")
注意这里没用 pubsub.psubscribe() 通配符 —— 频道名含变量易被注入，且 Redis 不支持 pattern 订阅的原子性校验。
容易被忽略的部署细节
这几个点线上出问题频率极高，但文档很少提：
- Redis 默认关闭键空间事件：
redis.conf中必须显式配置notify-keyspace-events Ex，Docker 启动需加--appendonly yes --notify-keyspace-events Ex -
pubsub.listen()是阻塞迭代器，一旦网络中断，整个循环卡住 —— 必须包在try/except里，捕获ConnectionError后重建连接和订阅 - 多个协调器实例同时监听同一频道？会重复处理 —— 必须用 Redis 分布式锁（
SET lock:tx:coord NX PX 30000）确保只有一个实例执行校验逻辑 - 别在
pubsub.listen()循环里做耗时操作（比如查 DB），否则消息积压；应把tx_id推进队列（如LPUSH tx:queue），另起 worker 消费
说到底，Redis Pub/Sub 在分布式事务里最稳的定位，就是那个“叮”一声提醒你该去查状态的闹钟 —— 响不响不重要，响完你得自己睁眼确认。
