Redis该竞态条件场景是否存在？缓存写入后查询延迟咨询

核心疑问解答 #

Redis写入操作返回成功后，单节点场景下内存中数据已就绪，不会出现查询延迟；但在主从集群/多节点场景下，可能因主从异步复制的延迟，导致从节点暂时无法查询到刚写入的数据——这是你遇到场景3的最可能原因。

问题根源分析 #

你的路由A在主节点写入占位符后立即返回轮询ID，若路由B的查询请求打到了未完成同步的从节点，此时从节点还没有该key的缓存，就会误触发“轮询ID不存在”的场景3。

除此之外，还要排查以下潜在问题：

• 路由A的占位符写入是否真的成功？比如网络波动、Redis连接超时导致SET命令失败，但代码未捕获异常就返回了轮询ID。
• 是否使用了Redis客户端的本地缓存？部分客户端会开启本地缓存，导致查询时读取旧数据。

解决方案 #

1. 强制读写请求路由到同一节点 #

• 让路由A的写入和路由B的查询都指向主节点，彻底规避主从同步延迟问题。如果使用Redis Cluster，可通过客户端配置指定查询命令路由到key对应的主节点。
• 若必须使用从节点查询，可在路由B查询前执行READWRITE命令（Redis 6+支持），强制当前连接切换到主节点查询。

2. 同步主从复制后再返回 #

路由A在写入占位符后，执行WAIT命令等待从节点完成同步，再返回轮询ID：

SET poll:123 "{status: 'pending'}"
WAIT 1 5000  # 等待1个从节点同步，超时5秒

只有当WAIT返回成功（同步的从节点数达标），才返回轮询ID给调用者，确保后续路由B无论查主还是从节点，都能拿到占位符。

3. 优化路由B的重试逻辑 #

当路由B查询不到key时，不要直接返回场景3，而是增加短间隔重试（比如间隔100ms重试2-3次），同时重试时优先查询主节点。多数情况下，主从同步延迟在毫秒级，重试后就能拿到占位符。

4. 排查写入操作的可靠性 #

检查路由A的代码，确保SET命令的返回值被正确校验：

# 示例Python代码，确保写入成功才返回ID
redis_client = redis.Redis(...)
set_result = redis_client.set(f"poll:{poll_id}", json.dumps({"status": "pending"}))
if not set_result:
    raise Exception("Failed to create placeholder in Redis")
return poll_id

避免因写入失败却返回轮询ID，导致路由B查询不到key。

内容的提问来源于stack exchange，提问作者Bassinator