缓存击穿策略singleFlight

小鱼儿 2022-12-07 15:14 88阅读 0赞

## 简介 ##

**缓存击穿**：缓存失效时，有大量并发请求过来。大量请求从缓存上拿不到数据，请求压力全部打到数据库上。  
场景1：活动结束前。为了完成活动任务，请求活动配置数据请求一般会有爆发性增长。当你的服务没有做防止缓存击穿的话，就有可能让你的数据库**宕机**

## singleFlight包 ##

singleFlight会将对同一个key的所有请求，变成一个请求，所有请求共享一个请求返回的数据。  
场景：活动尾声大量并发请求获取活动配置数据。设置该活动key为**activity\_key**,所有请求都会开个goroutine处理。所有请求都通过DO函数绑定 key和fn回调函数进行处理。singleFlight内部利用一个map和一个call对象。实现了所有请求共享一个请求返回的数据。

## singleFlight源码解析 ##

type call struct {
        
    	wg sync.WaitGroup // 并发调用group.Do时，控制fn的调用。
    
    	// These fields are written once before the WaitGroup is done
    	// and are only read after the WaitGroup is done.
    	val interface{
        }
    	err error
    
    	// forgotten indicates whether Forget was called with this call's key
    	// while the call was still in flight.
    	forgotten bool // key是否存在group的map
    
    	// These fields are read and written with the singleflight
    	// mutex held before the WaitGroup is done, and are read but
    	// not written after the WaitGroup is done.
    	dups  int             // 并发调用key fn的数量
    	chans []chan<- Result //这里的Chan都是带缓存的chan，保存的是fn的结果
    }
    
    // Group represents a class of work and forms a namespace in
    // which units of work can be executed with duplicate suppression.
    type Group struct {
        
    	mu sync.Mutex       // protects m
    	m  map[string]*call // lazily initialized
    }
    
    // Result holds the results of Do, so they can be passed
    // on a channel.
    type Result struct {
        
    	Val    interface{
        } // fn的返回值
    	Err    error
    	Shared bool			//是否有并发请求 共享返回结果。
    }
    
    // Do executes and returns the results of the given function, making
    // sure that only one execution is in-flight for a given key at a
    // time. If a duplicate comes in, the duplicate caller waits for the
    // original to complete and receives the same results.
    // The return value shared indicates whether v was given to multiple callers.
    func (g *Group) Do(key string, fn func() (interface{
        }, error)) (v interface{
        }, err error, shared bool) {
        
    	g.mu.Lock()//锁的范围只针对map，不锁fn的调用，主要也是不需要锁fn，不同key的fn调用 已经被wg控制在一次了。
    	if g.m == nil {
        
    		g.m = make(map[string]*call)
    	}
    	if c, ok := g.m[key]; ok {
        //有并发同一个key的情况
    		c.dups++//并发数
    		g.mu.Unlock()
    		c.wg.Wait()//等待第一个请求fn返回，所以在上面就把锁释放了。
    		return c.val, c.err, true//返回结果被多个请求共享
    	}
    	//没有并发的情况
    	c := new(call)
    	c.wg.Add(1)//wg控制fn仅有一次调用
    	g.m[key] = c
    	g.mu.Unlock()
    
    	g.doCall(c, key, fn)
    	return c.val, c.err, c.dups > 0
    }
    
    // DoChan is like Do but returns a channel that will receive the
    // results when they are ready.
    func (g *Group) DoChan(key string, fn func() (interface{
        }, error)) <-chan Result {
        
    	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 {
        
    		c.dups++
    		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)//fn的真正调用地
    
    	return ch
    }
    
    // doCall handles the single call for a key.
    func (g *Group) doCall(c *call, key string, fn func() (interface{
        }, error)) {
        
    	c.val, c.err = fn()//一般耗时点在fn中,fn中如果出现了panic 会导致wg.Wait一直等待
    	c.wg.Done()
    
    	g.mu.Lock()//如果在 fn调用中 调用了 group.Forget函数，delete操作不用做了。同时有新的并发Do进来。不会走到dup的情况中。new 一个call走新的流程。
    	if !c.forgotten {
        
    		delete(g.m, key)//fn 完成就将key 删除。
    	}
    	for _, ch := range c.chans {
        
    		ch <- Result{
        c.val, c.err, c.dups > 0}
    	}
    	g.mu.Unlock()
    }
    
    // Forget tells the singleflight to forget about a key.  Future calls
    // to Do for this key will call the function rather than waiting for
    // an earlier call to complete.
    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()
    }
    //场景1
    //有100个并发请求过来，请求11第一个到了。req11进行真正的fn调用。其余的99个都在wait中等待req11的fn的返回。但是这99个都没有锁 group的map。
    //但是由于fn调用长。我们调用了 group.Forget,将原来的key delete。此时又来了100个并发。req111 第一个过来。虽然这200个req的key都相同，
    //但是原来的key被forget删除了。原来的前99个请求都被wait阻塞中，等req11的fn返回后，这99个则共享返回结果。后100个请求则是新调用了一个fn，
    //前后这个2个 100次请求互不影响，从数据源的角度来看 就是来了两次。 其实既然都是共享一次返回值，为什么还要在中途 forget呢，反正都是从source请求。
    //你就算想在 cache是一个集群。那也是没有啥用的呀。

## singleFlight包可能会出现的bug ##

关于这个bug已经在github上有issue了，但是截至今天我并没有看到官方有改动。  
主要的问题是Do绑定的fn函数。fn在doCall中调用时如果panic了，（而我们为了程序的稳定性在上层调用了recover，一般在调用go 的开始出加上recover。）当程序出现了panic会触发本goroutine中的defer函数，但是doCall中没有，那么接下来的wg.Done和map的delete操作都不会进行操作。**可能会导致wg.Wait一直阻塞。以及key一直无法添加的情况** go1.14的defer的性能得到了极大的提升。在该情况下可以对doCall进行改造从而解决fn panic的问题。

func (g *Group) doCall(c *call, key string, fn func() (interface{
        }, error)) {
        
    	defer func() {
        //这样解决了死锁  是否会隐藏问题！！！！！！！！！ 对recover 打印日志 再做短信报警的话 可以处理这个问题。
    		fmt.Println("doCall 2")
    		c.wg.Done()
    		g.mu.Lock()//如果在 fn调用中 调用了 group.Forget函数，delete操作不用做了。同时有新的并发Do进来。不会走到dup的情况中。new 一个call走新的流程。
    		if !c.forgotten {
        
    			delete(g.m, key)//fn 完成就将key 删除。
    		}
    		for _, ch := range c.chans {
        
    			ch <- Result{
        c.val, c.err, c.dups > 0}
    		}
    		g.mu.Unlock()
    	}()
    	c.val, c.err = fn()//一般耗时点在fn中
    }

## 小结 ##

在涉及到fn绑定回调函数，延时调用，定时调用，或者循环调用等的情况下，都要考虑一下fn调用时panic的情况。有时这种panic会导致goroutine一直等待着（goroutine泄露，也可以叫做内存泄露）