在Goroutine中异步写入Redis缓存是否合理？附Go代码示例

你的异步写入缓存的思路有几个明显的问题，具体如下：

• 缓存写入失败完全无感知
  你用goroutine异步执行ss.cache.Save，但没有捕获这个操作的错误。如果Redis连接中断、写入超时或者权限不足，这个错误会直接被丢弃，既不会打日志也不会触发重试。结果就是缓存一直建不起来，所有后续请求都会直接打第三方API，不仅加重依赖服务的压力，还失去了缓存的意义。

• 竞态引发的缓存击穿/惊群效应
  当某个股票代码的缓存过期或不存在时，如果同时有大量请求进来，所有请求都会走到调用第三方API的分支，瞬间发起大量重复的API请求。这会直接把第三方API打满，甚至触发对方的限流机制，导致接口大面积报错。因为异步写入缓存的过程中，后续请求还是会判定缓存未命中，继续调用API。

• Goroutine泄漏风险
  如果ss.cache.Save内部没有设置合理的超时时间，或者Redis出现长时间阻塞，这个goroutine会一直处于挂起状态。大量这类未退出的goroutine会持续占用内存，最终导致服务内存泄漏，甚至崩溃。另外，你没有给goroutine绑定合适的上下文，请求已经返回给客户端了，goroutine还在后台运行，后续排查问题时很难追踪关联。

• 缺乏缓存错误降级机制
  你只考虑了缓存写入失败的情况，但如果缓存读取失败（比如Redis挂了），当前逻辑会直接走到调用API的分支，这本身没问题，但如果缓存恢复后，还是没有机制去重建缓存，会导致缓存一直无法被利用。

简单的改进方向 #

1. 给异步缓存操作加错误处理
   在goroutine里捕获ss.cache.Save的错误，打印日志，必要时加入重试机制（比如指数退避重试，最多重试3次），避免缓存写入失败后完全无动作：

   go func() {
       err := ss.cache.Save(code, chart, expireAt)
       if err != nil {
           ss.logger.Error("failed to save stock info to cache", "code", code, "err", err)
           // 可选：加入重试逻辑
       }
   }()
   

2. 解决竞态问题
   可以用Go官方的sync/singleflight包，把相同股票代码的请求合并，同一时间只有一个请求去调用第三方API，其他请求等待结果，避免重复调用：

   // 先定义singleflight.Group
   var sf singleflight.Group
   
   // 在handler里使用
   stockInfo, err, _ := sf.Do(code, func() (interface{}, error) {
       // 这里放调用第三方API的逻辑
       return chart, nil
   })
   

   或者用Redis的SET ... NX命令做分布式锁，第一个请求拿到锁后去调用API并写入缓存，其他请求等待锁释放后读取缓存。
3. 给缓存操作加超时上下文
   给缓存的读写操作带上带超时的上下文，避免goroutine长时间阻塞：

   ctx, cancel := context.WithTimeout(context.Background(), 500*time.Millisecond)
   defer cancel()
   err := ss.cache.SaveWithContext(ctx, code, chart, expireAt)
   

4. 合理设置缓存过期时间
   根据股票数据的更新频率设置过期时间，比如5分钟，同时可以加入主动更新机制（比如定时拉取热门股票数据更新缓存），避免缓存集中过期引发的雪崩问题。

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