原文链接：赏析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 // 标示后果是否是共享后果}Do办法
// 入参：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
// 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/...。
Dochan和Forget办法
//异步返回// 入参数：key：标识雷同申请，fn：要执行的函数// 出参数：<- chan 期待接管后果的channelfunc (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写段代码判断以后零碎的存储形式吗?
- 面试中如果这样写二分查找