golang防缓存击穿利器--singleflight

缓存击穿

    给缓存加一个过时时间，下次未命中缓存时再去从数据源获取结果写入新的缓存，这个是后端开发人员再熟悉不过的基操。本人以前在作直播平台活动业务的时候，当时带着这份再熟练不过的自信，把复杂的数据库链表语句写好，各类微服务之间调用捞数据最后算好的结果，丢进了缓存而后设了一个过时时间，当时噼里啪啦两下写完代码以为稳如铁蛋，结果在活动快结束以前，数据库很友好的挂掉了。当时回去查看监控后发现，是在活动快结束前，大量用户都在疯狂的刷活动页，致使缓存过时的瞬间有大量未命中缓存的请求直接打到数据库上所致使的，因此这个经典的问题稍不注意仍是害死人

    防缓存击穿的方式有不少种，好比经过计划任务来跟新缓存使得从前端过来的全部请求都是从缓存读取等等。以前读过 groupCache的源码，发现里面有一个颇有意思的库，叫singleFlight, 由于groupCache从节点上获取缓存若是未命中，则会去其余节点寻找，其余节点尚未的话再从数据源获取，因此这个步骤对于防击穿很是有必要。singleFlight使得groupCache在多个并发请求对一个失效的key进行源数据获取时，只让其中一个获得执行，其他阻塞等待到执行的那个请求完成后，将结果传递给阻塞的其余请求达到防止击穿的效果。

SingleFlight 使用Demo

本文模拟一个数据源是从调用rpc获取的场景

而后再模拟一百个并发请求在缓存失效的瞬间同时调用rpc访问源数据

效果

能够看到100个并发请求从源数据获取时，rpcServer端只收到了来自client 17的请求，而其他99个最后也都获得了正确的返回值。

SingleFlight 源码剖析

在看完singleFlight的实际效果后，欣喜若狂，想必其实现应该至关复杂吧， 结果翻看源码一看, 100行不到的代码就解决了这么个业务痛点， 不得不佩服。

package singlefilght

import "sync"

type Group struct {
    mu sync.Mutex
    m map[string]*Call // 对于每个须要获取的key有一个对应的call
}

// call表明须要被执行的函数
type Call struct {
    wg sync.WaitGroup // 用于阻塞这个调用call的其余请求
    val interface{} // 函数执行后的结果
    err error         // 函数执行后的error
}

func (g *Group) Do(key string, fn func()(interface{}, error)) (interface{}, error) {

    g.mu.Lock()
    if g.m == nil {
        g.m = make(map[string]*Call)
    }
    
    // 若是获取当前key的函数正在被执行，则阻塞等待执行中的，等待其执行完毕后获取它的执行结果
    if c, ok := g.m[key]; ok {
        g.mu.Unlock()
        c.wg.Wait()
        return c.val, c.err
    }

    // 初始化一个call，往map中写后就解
    c := new(Call)
    c.wg.Add(1)
    g.m[key] = c
    g.mu.Unlock()
    
  // 执行获取key的函数，并将结果赋值给这个Call
    c.val, c.err = fn()
    c.wg.Done()
    
    // 从新上锁删除key
    g.mu.Lock()
    delete(g.m, key)
    g.mu.Unlock()

    return c.val, c.err

}

    对的没看错， 就这么100行不到的代码就能解决缓存击穿的问题，这算是我写过最愉快的一篇博了，同时也推荐你们去读一读groupCache这个项目的源码，会有更多惊喜的发现