valkey连接池需显式配置minidleconns=32、poolsize=128、idletimeout=5m、maxconnage=30m；session key应为sess:appname:session_id并带ex写入；中间件须入口读+出口刷ttl；降级仅允许只读且依赖全局开关。
Valkey连接池配置必须显式设置MaxIdle和MaxActive
Valkey（原Redis）在Go中用github.com/valkey-io/valkey-go或github.com/go-redis/redis/v9时，连接池默认参数极保守——MaxIdle=0、MaxActive=0，实际等于禁用复用。高并发下会频繁建连，直接触发connect: cannot assign requested address或超时。
实操建议：
- 设
MaxIdle=32、MaxActive=128（按QPS预估，一般50–100 QPS对应32–64 idle） - 务必配
IdleTimeout=5m和MaxConnAge=30m，避免TIME_WAIT堆积 - 使用
WithContext调用所有命令，防止goroutine泄漏 - 示例片段：
opt := &redis.Options{ Addr: "127.0.0.1:6379", Password: "", DB: 0, PoolSize: 128, MinIdleConns: 32, MaxConnAge: 30 * time.Minute, IdleTimeout: 5 * time.Minute, }
Session Key设计要带应用标识和过期时间戳
多个服务共用一个Valkey实例时，若只用session:<code>id作key，不同服务可能覆盖彼此的session。更糟的是，单纯依赖Valkey的EXPIRE不保险——如果进程重启或网络抖动导致SET没带EX参数，session就永久滞留。
实操建议：
- Key格式统一为
sess:<code>appname:session_id，比如sess:auth-api:abc123 - 写入时用
SETEX或SET带EX参数，不要分开SET+EXPIRE - Value里存JSON，包含
expires_at字段（Unix秒），读取时双重校验：Valkey TTL > 0 &&expires_at> now.Unix() - 避免用
INCR或HSET管理session，原子性难保证且不易调试
Session中间件需拦截Set-Cookie并同步刷新Valkey TTL
浏览器发请求带Cookie: session_id=xxx，后端查Valkey命中后，若不做TTL刷新，用户持续活跃但session却过期——这是最常被忽略的点。单纯在每次请求末尾EXPIRE一次不够：若中间件提前return（如鉴权失败），TTL就漏刷了。
实操建议：
- 在中间件入口处读session，并记录原始TTL（用
PTTL获取毫秒级剩余时间） - 在HTTP handler return前统一调用
client.Expire(ctx, key, ttl)，ttl取原始剩余时间与配置最大有效期的较小值 - 若用Gin，挂载中间件时确保它在
gin.Recovery()之前，否则panic时TTL不刷新 - 禁止在handler里手动
Set-Cookie，必须走框架的c.SetCookie()，否则Secure/HttpOnly等属性丢失
Valkey故障时Session降级策略不能只靠本地内存缓存
Valkey宕机时，若fallback到map[string]interface{}内存缓存，看似可用，实则引发一致性灾难：多实例间session状态完全分裂，用户在A实例登录后，切到B实例就“未登录”。更危险的是，恢复Valkey后旧内存数据未清除，造成脏读。
实操建议：
- 降级开关必须全局统一（如etcd/ZooKeeper里的
/config/session/fallback_enabled），不能每个实例自己判断 - 降级模式下只允许读已有session，禁止写新session或更新
expires_at——即“只读降级” - 加
atomic.Bool标记Valkey是否健康，每30秒用PING探测，连续3次失败才触发降级 - 日志里必须打
session_fallback_active=1字段，方便ELK告警；降级期间所有session操作记WARN而非ERROR
Valkey不是黑盒存储，Session也不是简单KV塞进去就行。Key结构、TTL刷新时机、故障时的读写边界，三者缺一都会让分布式会话变成线上定时炸弹。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
