当前位置：首页 >专题 >Go 请求合并与缓存防击穿工程实践专题
Go 请求合并与缓存防击穿工程实践专题
官方入口与权威资料
先建立请求合并、共享状态和缓存治理的正确边界
Go 官方网站
Go 官方语言、工具链和文档入口。
singleflight 官方包文档
golang.org/x/sync/singleflight 的 API、Do、DoChan、Forget 和 shared 结果说明。
singleflight 官方源码
Go 官方 x/sync 仓库中的 singleflight 实现源码。
Go sync 包文档
Go 官方 sync 包文档，覆盖 Map、Mutex、Once、Pool 和 WaitGroup 等同步工具。
Redis 官方：如何治理惊群问题
Redis 官方从 TTL 抖动、请求合并、布隆过滤器和限流角度解释 thundering herd。
Redis 官方 Cache-Aside 文档
Redis 官方 cache-aside 示例，说明缓存 miss、single-flight loader 和锁保护。
Go 官方 context 包文档
context 官方 API 文档，覆盖取消、截止时间和请求范围值传递。
站内实战文章
从缓存 miss 到并发回源、错误传播和下游保护
Go HTTP 客户端超时实战：别让默认 Client 拖垮 goroutine
常见问题
请求合并和缓存防击穿最容易混淆的边界
singleflight 能替代分布式锁吗？
不能。singleflight 只在单个进程内合并相同 key 的进行中调用，多实例部署时每个实例仍可能各自回源；跨实例协调需要 Redis 锁、共享缓存或其他分布式方案，并单独评估锁超时和故障边界。
singleflight 能解决缓存穿透和缓存雪崩吗？
它主要解决同一热点 key 在短时间内的重复回源，也就是缓存击穿的一部分。缓存穿透还需要空值缓存或布隆过滤器，缓存雪崩还需要 TTL 抖动、预热、限流和降级等组合措施。
Do 和 DoChan 应该怎么选？
同步等待结果时 Do 更直接；需要通过 select 同时监听请求 context、超时或其他事件时，DoChan 更容易编排。无论选择哪一个，都要保证回源函数本身支持取消或有明确超时。
请求合并的 key 应该怎么设计？
key 必须包含会影响结果的完整业务维度，例如租户、地区、语言和版本；key 太粗会错误共享结果，key 太细又无法合并。建议记录 shared 比例、等待时长和回源错误，结合指标持续校准。
相关专题
继续查看相近方向内容
