关于golang:源码赏析singleflight设计-防缓存穿透神器

原文链接：赏析 Singleflight 设计

哈喽，大家好，我是 asong。明天想与大家分享一下singleflight 这个库，singleflight仅仅只有 100 多行却能够做到避免缓存击穿，有点厉害哦！所以本文咱们就一起来看一看他是怎么设计的～。

留神：本文基于 https://pkg.go.dev/golang.org… 进行剖析。

平时在高并发零碎中，会呈现大量的申请同时查问一个 key 的状况，如果此时这个热 key 刚好生效了，就会导致大量的申请都打到数据库下面去，这种景象就是缓存击穿。缓存击穿和缓存雪崩有点像，然而又有一点不一样，缓存雪崩是因为大面积的缓存生效，打崩了 DB，而缓存击穿则是指一个 key 十分热点，在不停的扛着高并发，高并发集中对着这一个点进行拜访，如果这个 key 在生效的霎时，继续的并发到来就会穿破缓存，间接申请到数据库，就像一个完整无缺的桶上凿开了一个洞，造成某一时刻数据库申请量过大，压力剧增！

办法一

咱们简略粗犷点，间接让热点数据永远不过期，定时工作定期去刷新数据就能够了。不过这样设置须要辨别场景，比方某宝首页能够这么做。
办法二

为了避免出现缓存击穿的状况，咱们能够在第一个申请去查询数据库的时候对他加一个互斥锁，其余的查问申请都会被阻塞住，直到锁被开释，前面的线程进来发现曾经有缓存了，就间接走缓存，从而爱护数据库。然而也是因为它会阻塞其余的线程，此时零碎吞吐量会降落。须要结合实际的业务去思考是否要这么做。
办法三

办法三就是 singleflight 的设计思路，也会应用互斥锁，然而绝对于办法二的加锁粒度会更细，这里先简略总结一下 singleflight 的设计原理，前面看源码在具体分析。

singleflightd 的设计思路就是将一组雷同的申请合并成一个申请，应用 map 存储，只会有一个申请达到 mysql，应用 sync.waitgroup 包进行同步，对所有的申请返回雷同的后果。

曾经急不可待了，直奔主题吧，上面咱们一起来看看 singleflight 是怎么设计的。

singleflight的构造定义如下：

type Group struct {
    mu sync.Mutex       // 互斥锁，保障并发平安
    m  map[string]*call // 存储雷同的申请，key 是雷同的申请，value 保留调用信息。}

Group构造还是比较简单的，只有两个字段，m是一个 map，key 是雷同申请的标识，value是用来保留调用信息，这个 map 是懒加载，其实就是在应用时才会初始化；mu是互斥锁，用来保障 m 的并发平安。m存储调用信息也是独自封装了一个构造：

type call struct {
    wg sync.WaitGroup
    // 存储返回值，在 wg done 之前只会写入一次
    val interface{}
  // 存储返回的错误信息
    err error

    // 标识别是否调用了 Forgot 办法
    forgotten bool

    // 统计雷同申请的次数，在 wg done 之前写入
    dups  int
  // 应用 DoChan 办法应用，用 channel 进行告诉
    chans []chan<- Result}
// Dochan 办法时应用
type Result struct {Val    interface{} // 存储返回值
    Err    error // 存储返回的错误信息
    Shared bool // 标示后果是否是共享后果
}

// 入参：key：标识雷同申请，fn：要执行的函数
// 返回值：v: 返回后果 err: 执行的函数错误信息 shard: 是否是共享后果
func (g *Group) Do(key string, fn func() (interface{}, error)) (v interface{}, err error, shared bool) {
    // 代码块加锁
    g.mu.Lock()
    // map 进行懒加载
    if g.m == nil {
      // map 初始化
        g.m = make(map[string]*call)
    }
    // 判断是否有雷同申请
    if c, ok := g.m[key]; ok {
      // 雷同申请次数 +1
        c.dups++
        // 解锁就好了，只须要期待执行后果了，不会有写入操作了
        g.mu.Unlock()
        // 已有申请在执行，只须要期待就好了
        c.wg.Wait()
        // 辨别 panic 谬误和 runtime 谬误
        if e, ok := c.err.(*panicError); ok {panic(e)
        } else if c.err == errGoexit {runtime.Goexit()
        }
        return c.val, c.err, true
    }
    // 之前没有这个申请，则须要 new 一个指针类型
    c := new(call)
    // sync.waitgroup 的用法，只有一个申请运行，其余申请期待，所以只须要 add(1)
    c.wg.Add(1)
    // m 赋值
    g.m[key] = c
    // 没有写入操作了，解锁即可
    g.mu.Unlock()
    // 惟一的申请该去执行函数了
    g.doCall(c, key, fn)
    return c.val, c.err, c.dups > 0
}

这里是惟一有疑难的应该是辨别 panic 和runtime谬误局部吧，这个与上面的 docall 办法有关联，看完 docall 你就晓得为什么了。

// doCall handles the single call for a key.
func (g *Group) doCall(c *call, key string, fn func() (interface{}, error)) {
  // 标识是否失常返回
    normalReturn := false
  // 标识别是否产生 panic
    recovered := false
  
    defer func() {
        // 通过这个来判断是否是 runtime 导致间接退出了
        if !normalReturn && !recovered {
      // 返回 runtime 错误信息
            c.err = errGoexit
        }

        c.wg.Done()
        g.mu.Lock()
        defer g.mu.Unlock()
    // 避免反复删除 key
        if !c.forgotten {delete(g.m, key)
        }
        // 检测是否呈现了 panic 谬误
        if e, ok := c.err.(*panicError); ok {
            // 如果是调用了 dochan 办法，为了 channel 防止死锁，这个 panic 要间接抛出去，不能 recover 住，要不就暗藏谬误了
            if len(c.chans) > 0 {go panic(e) // 开一个写成 panic
                select {} // 放弃住这个 goroutine，这样能够将 panic 写入 crash dump} else {panic(e)
            }
        } else if c.err == errGoexit {// runtime 谬误不须要做任何时，曾经退出了} else {
            // 失常返回的话间接向 channel 写入数据就能够了
            for _, ch := range c.chans {ch <- Result{c.val, c.err, c.dups > 0}
            }
        }
    }()
  // 应用匿名函数目标是 recover 住 panic，返回信息给下层
    func() {defer func() {
            if !normalReturn {
                // 产生了 panic，咱们 recover 住，而后把错误信息返回给下层
                if r := recover(); r != nil {c.err = newPanicError(r)
                }
            }
        }()
        // 执行函数
        c.val, c.err = fn()
    // fn 没有产生 panic
        normalReturn = true
    }()
    // 判断执行函数是否产生 panic
    if !normalReturn {recovered = true}
}

这里来简略形容一下为什么辨别 panic 和runtime谬误，不辨别的状况下如果调用呈现了恐慌，然而锁没有被开释，导致应用雷同密钥的所有后续调用都呈现了死锁，具体能够查看这个issue：https://github.com/golang/go/…。

// 异步返回
// 入参数：key：标识雷同申请，fn：要执行的函数
// 出参数：<- chan 期待接管后果的 channel
func (g *Group) DoChan(key string, fn func() (interface{}, error)) <-chan Result {
  // 初始化 channel
    ch := make(chan Result, 1)
    g.mu.Lock()
  // 懒加载
    if g.m == nil {g.m = make(map[string]*call)
    }
  // 判断是否有雷同的申请
    if c, ok := g.m[key]; ok {
    // 雷同申请数量 +1
        c.dups++
    // 增加期待的 chan
        c.chans = append(c.chans, ch)
        g.mu.Unlock()
        return ch
    }
    c := &call{chans: []chan<- Result{ch}}
    c.wg.Add(1)
    g.m[key] = c
    g.mu.Unlock()
    // 开一个写成调用
    go g.doCall(c, key, fn)
    // 返回这个 channel 期待接收数据
    return ch
}
// 开释某个 key 下次调用就不会阻塞期待了
func (g *Group) Forget(key string) {g.mu.Lock()
    if c, ok := g.m[key]; ok {c.forgotten = true}
    delete(g.m, key)
    g.mu.Unlock()}

因为咱们在应用 singleflight 时须要本人写执行函数，所以如果咱们写的执行函数始终循环住了，就会导致咱们的整个程序处于循环的状态，积攒越来越多的申请，所以在应用时，还是要留神一点的，比方这个例子：

result, err, _ := d.singleGroup.Do(key, func() (interface{}, error) {
        for{// TODO}
}

不过这个问题个别也不会产生，咱们在日常开发中都会应用 context 管制超时。

好啦，这篇文章就到这里啦。因为最近我在我的项目中也应用 singleflight 这个库，所以就看了一下源码实现，真的是厉害，这么短的代码就实现了这么重要的性能，我怎么就想不到呢。。。。所以说还是要多读一些源码库，真的能学到好多，真是应了那句话：你晓得的越多，不晓得的就越多！

欢送关注公众号：Golang 梦工厂

举荐往期文章：

学习 channel 设计：从入门到放弃
Go 语言如何实现可重入锁？
Go 语言中 new 和 make 你应用哪个来分配内存？
源码分析 panic 与 recover，看不懂你打我好了！
空构造体引发的大型打脸现场
面试官：两个 nil 比拟后果是什么？
面试官：你能用 Go 写段代码判断以后零碎的存储形式吗?
面试中如果这样写二分查找

关于golang:源码赏析singleflight设计-防缓存穿透神器

前言

缓存击穿

什么是缓存击穿

如何解决

源码赏析

数据结构

Do 办法

docall

Dochan 和 Forget 办法

注意事项

总结

Just My Socks（注册教程内含优惠码）

关于golang:源码赏析singleflight设计-防缓存穿透神器

前言

缓存击穿

什么是缓存击穿

如何解决

源码赏析

数据结构

Do 办法

docall

Dochan 和 Forget 办法

注意事项

总结

Just My Socks（注册教程 内含优惠码）

Just My Socks（注册教程内含优惠码）