“一键置顶”必须用先删后写+带版本号的原子写入，因cache-aside模式无法满足强可见、低延迟、写优先要求，易导致页面不刷新、并发状态错乱、脏缓存等问题；需拆分主数据与置顶元信息、用setnx保版本、双读兜底+singleflight防击穿。
“一键置顶”不是加个 TTL 就完事——它本质是写优先、强可见、低延迟的缓存更新问题，必须用先删后写 + 带版本号的原子写入来保一致性，否则用户点完“置顶”页面不刷新，或多人并发操作时状态错乱。
为什么不能用 Cache-Aside 模式做置顶
Cache-Aside 适合读多写少、允许短暂不一致的场景（比如消息收件人列表），但“置顶”是用户强感知操作：点一下，列表顶部必须立刻变。如果沿用“先查缓存→查 DB→写缓存”流程，会出三类问题：
- 用户 A 点置顶，B 同时刷新页面，仍看到旧顺序（缓存未更新）
- 用户 A、B 几乎同时点置顶，DB 更新成功，但 Redis 缓存只保留最后一次 Set 的结果，中间态丢失
- 写 DB 成功、删缓存失败（网络抖动），后续读到脏缓存，置顶失效
所以，“置顶”这类操作必须走 Write-Through 或更稳妥的 Delete-Then-Set 模式，并把“是否置顶”这个状态单独建模，不混在完整数据结构里。
key 设计与版本控制：避免覆盖冲突
不能把整个列表 JSON 存一个 key（如 post:list:123），否则每次置顶都要全量重写，且无法区分“谁置的顶”。正确做法是拆成两层：
- 主数据 key：
post:data:456（存帖子正文、作者等不变字段） - 置顶元信息 key：
post:pinned:456（只存{"user_id":789,"ts":1747049160,"version":12}）
关键点：
Go语言（Golang）1.26.0
下载
Go语言（Golang）1.26.0版本提供 Go 官方 Windows amd64 MSI 安装包下载入口，版本号 1.26.0，可用于旧项目维护、兼容性测试和指定版本开发环境配置。
-
version字段必须由 Go 层递增生成（比如从 DB 读当前 version 加 1），不能靠 Redis 的INCR——避免并发写导致 version 跳变 - 写缓存时用
rdb.SetNX(ctx, key, val, ttl)，确保只有 version 更高的写入才生效；若失败，说明有更新操作已抢先落地，当前请求应丢弃或重试 - 读取时先
GET post:pinned:456，再根据user_id和ts决定是否参与排序，而不是直接信任缓存值
删除 + 原子写入：防止缓存与 DB 不一致
“置顶”操作的 Go 函数骨架必须严格按以下顺序执行，缺一不可：
- 开启事务或使用带重试的 DB 更新（如
UPDATE posts SET pinned_at=NOW(), pinned_by=? WHERE id=? AND version >= ?） - DB 更新成功后，立即调
rdb.Del(ctx, "post:pinned:456")—— 删除比更新更轻量，失败概率低，且为下一步留出干净状态 - 紧接着调
rdb.Set(ctx, "post:pinned:456", payload, ttl)，payload中含新version和ts - 若
Del或Set报redis: connection pool timeout或context.DeadlineExceeded，记录 warn 日志但不回滚 DB（DB 是权威源），下游读逻辑需能容忍短暂缺失缓存
注意：不要用 SETEX 替代 DEL + SET，因为 SETEX 不是原子删除+写入，中间存在窗口期，其他请求可能读到旧值。
读路径如何保证“刚置顶就可见”
前端刷新列表时，后端不能只查缓存——必须做“双读兜底”：
- 第一步：尝试
rdb.Get(ctx, "post:pinned:456")，若命中且version匹配本地已知最新值，直接用 - 第二步：若缓存未命中、或
version过旧、或值为"null"，立刻查 DB 获取最新pinned_at和pinned_by，并异步触发一次rdb.Set回填（不阻塞响应） - 第三步：排序逻辑始终以 DB 字段为 fallback，缓存只作加速——这是降级安全线
最容易被忽略的是：**所有涉及置顶状态的 HTTP 接口，必须对同一 post_id 请求启用 singleflight.Group，否则高并发下大量重复 DB 查询会打垮数据库，而这不是 Redis 能解决的问题。**
