Redis在Go中作为“高能中转站”，本质是跨服务临时状态枢纽，需按消息队列+缓存+原子状态三重角色设计，选List或Stream取决于中转定义：任务分发用List+BRPOP+Lua实现延迟重试，事件广播必须用Stream+XADD/XREADGROUP保障位点回溯；go-redis/v8初始化须显式配置MinIdleConns、MaxRetries、Read/WriteTimeout；中转数据须JSON序列化带type标签、设合理TTL、提关键字段至顶层；消费需原子GET+DEL或写processed key判重，禁用WATCH/MULTI，且每环节须验证终点（如XINFO/XPEMDING）。
Redis 在 Go 架构里扮演“高能中转站”的角色，关键不在于它存得快，而在于不丢、不乱、不卡、可追溯。单靠 SET 和 GET 可堆不出可靠的中转——它本质上是个跨服务、跨进程的临时状态枢纽，必须按照消息队列+缓存+原子状态三重角色来设计。
用 List 还是 Stream 做中转？别光看文档说哪个更新
选型的关键在于你对“中转”的定义是什么：
- 如果中转指的是任务分发，比如上传后触发校验、转码，需要失败重试、死信隔离、多消费者负载均衡 → 用
List+BRPOP，再配合 Lua 用ZPOPMIN+ZADD实现延迟重试。 - 如果中转指的是事件广播，比如订单创建后通知库存、风控、日志，要求消费位点可回溯、多组消费者独立读取 → 必须上
Stream，XADD/XREADGROUP是底线。 - 至于
Pub/Sub，它不适合做中转：消息无持久化，消费者离线就丢，连“临时”都算不上。
go-redis/v8 初始化时，这三个配置项最容易被忽略
连接池和超时不是“配了就行”，它们直接影响吞吐和故障恢复速度。具体来说：
MinIdleConns设成 5–10，避免突发流量下频繁建连，尤其在 Kubernetes Pod 启动初期。MaxRetries设成 2，不是 0 也不是 5——网络抖动时重试有意义，但 Redis 主从切换期间连续重试会放大雪崩。ReadTimeout和WriteTimeout必须显式设成 5s 以内，否则一个慢查询就能卡住整个连接池，后续请求全堵在pool.Wait()上。
示例片段：
rdb := redis.NewClient(&redis.Options{
Addr: "redis-srv:6379",
MinIdleConns: 5,
MaxRetries: 2,
ReadTimeout: 3 * time.Second,
WriteTimeout: 3 * time.Second,
})
中转数据写入前必须做的三件事
不是所有数据都适合直接塞进 Redis——结构松散、体积过大、缺少上下文的数据进来就等于埋雷。所以写入前务必做好这三步：
- 强制序列化为
JSON并加Content-Type标签，比如{"type":"file_upload","payload":{...}}，避免下游解析错位。 - 写入时带
TTL，且 TTL 值 ≠ 业务超时值。例如文件处理预期 30s，TTL 设成90s，留出重试和人工干预窗口。 - 关键字段（如
trace_id、source_service）必须提一层到顶层，不能藏在 payload 深处——监控和 debug 时没法一个一个 grep。
为什么 DEL 之后还要检查 EXISTS？中转链路里，确认缺失比确认存在更关键
中转不是单向管道，而是状态跃迁过程。常见错误是：Worker 处理完就 DEL key，但上游没收到 ACK 就重发，导致重复消费。
- 正确做法：用 Lua 脚本原子执行
GET+DEL，通过返回值判断是否真被消费；若返回 nil，说明已被其他 Worker 处理过。 - 更稳的做法：消费成功后写入一个
processed:{id}key，TTL 设成原中转 key 的 2 倍；下游可通过EXISTS processed:{id}快速判重，无需查 DB。 - 别依赖
WATCH/MULTI：在高并发中转场景下，乐观锁冲突率高，反而拖慢吞吐。
真正难的不是把数据塞进 Redis，而是让每个中转环节都具备“可验证的终点”。比如上传完成写入 Stream 后，必须立刻用 XINFO CONSUMERS 确认 group 已注册；消费端启动后第一件事不是拉数据，而是用 XPENDING 检查是否有积压未 ACK 的消息——这些细节不落地，再高的 QPS 也撑不住真实业务流。
