背景

在使用缓存时,容易发生缓存击穿。

缓存击穿:一个存在的key,在缓存过期的瞬间,同时有大量的请求过来,造成所有请求都去读dB,这些请求都会击穿到DB,造成瞬时DB请求量大、压力骤增。

singleflight

介绍

import "golang.org/x/sync/singleflight"

singleflight类的使用方法就新建一个singleflight.Group,使用其方法Do或者DoChan来包装方法,被包装的方法在对于同一个key,只会有一个协程执行,其他协程等待那个协程执行结束后,拿到同样的结果。

  • Group结构体

    代表一类工作,同一个group中,同样的key同时只能被执行一次。
  • Do方法

    func (g *Group) Do(key string, fn func() (interface{}, error)) (v interface{}, err error, shared bool)

    key:同一个key,同时只有一个协程执行。

    fn:被包装的函数。

    v:返回值,即执行的结果。其他等待的协程都会拿到。

    shared:表示是否有其他协程得到了这个结果v。
  • DoChan方法

    func (g *Group) DoChan(key string, fn func() (interface{}, error)) <-chan Result

    与Do方法一样,只是返回的是一个channel,执行结果会发送到channel中,其他等待的协程都可以从channel中拿到结果。

ref:https://godoc.org/golang.org/x/sync/singleflight

示例

  • 使用Do方法来模拟,解决缓存击穿的问题
func main() {
var singleSetCache singleflight.Group getAndSetCache:=func (requestID int,cacheKey string) (string, error) {
log.Printf("request %v start to get and set cache...",requestID)
value,_, _ :=singleSetCache.Do(cacheKey, func() (ret interface{}, err error) {//do的入参key,可以直接使用缓存的key,这样同一个缓存,只有一个协程会去读DB
log.Printf("request %v is setting cache...",requestID)
time.Sleep(3*time.Second)
log.Printf("request %v set cache success!",requestID)
return "VALUE",nil
})
return value.(string),nil
} cacheKey:="cacheKey"
for i:=1;i<10;i++{//模拟多个协程同时请求
go func(requestID int) {
value,_:=getAndSetCache(requestID,cacheKey)
log.Printf("request %v get value: %v",requestID,value)
}(i)
}
time.Sleep(20*time.Second)
}

输出:

2020/04/12 18:18:40 request 4 start to get and set cache...
2020/04/12 18:18:40 request 4 is setting cache...
2020/04/12 18:18:40 request 2 start to get and set cache...
2020/04/12 18:18:40 request 7 start to get and set cache...
2020/04/12 18:18:40 request 5 start to get and set cache...
2020/04/12 18:18:40 request 1 start to get and set cache...
2020/04/12 18:18:40 request 6 start to get and set cache...
2020/04/12 18:18:40 request 3 start to get and set cache...
2020/04/12 18:18:40 request 8 start to get and set cache...
2020/04/12 18:18:40 request 9 start to get and set cache...
2020/04/12 18:18:43 request 4 set cache success!
2020/04/12 18:18:43 request 4 get value: VALUE
2020/04/12 18:18:43 request 9 get value: VALUE
2020/04/12 18:18:43 request 6 get value: VALUE
2020/04/12 18:18:43 request 3 get value: VALUE
2020/04/12 18:18:43 request 8 get value: VALUE
2020/04/12 18:18:43 request 1 get value: VALUE
2020/04/12 18:18:43 request 5 get value: VALUE
2020/04/12 18:18:43 request 2 get value: VALUE
2020/04/12 18:18:43 request 7 get value: VALUE

可以看到确实只有一个协程执行了被包装的函数,并且其他协程都拿到了结果。

源码分析

看一下这个Do方法是怎么实现的。

首先看一下Group的结构:

type Group struct {
mu sync.Mutex
m map[string]*call //保存key对应的函数执行过程和结果的变量。
}

Group的结构非常简单,一个锁来保证并发安全,另一个map用来保存key对应的函数执行过程和结果的变量。

看下call的结构:

type call struct {
wg sync.WaitGroup //用WaitGroup实现只有一个协程执行函数
val interface{} //函数执行结果
err error
forgotten bool
dups int //含义是duplications,即同时执行同一个key的协程数量
chans []chan<- Result
}

看下Do方法

func (g *Group) Do(key string, fn func() (interface{}, error)) (v interface{}, err error, shared bool) {
g.mu.Lock()//写Group的m字段时,加锁保证写安全。
if g.m == nil {
g.m = make(map[string]*call)
}
if c, ok := g.m[key]; ok {//如果key已经存在,说明已经有协程在执行,则dups++,并等待其执行完毕后,返回其执行结果,执行结果保存在对应的call的val字段里
c.dups++
g.mu.Unlock()
c.wg.Wait()
return c.val, c.err, true
}
//如果key不存在,则新建一个call,并使用WaitGroup来阻塞其他协程,同时在m字段里写入key和对应的call
c := new(call)
c.wg.Add(1)
g.m[key] = c
g.mu.Unlock() g.doCall(c, key, fn)//第一个进来的协程来执行这个函数
return c.val, c.err, c.dups > 0
}

继续看下g.doCall里具体干了什么

func (g *Group) doCall(c *call, key string, fn func() (interface{}, error)) {
c.val, c.err = fn()//执行被包装的函数
c.wg.Done()//执行完毕后,就可以通知其他协程可以拿结果了 g.mu.Lock()
if !c.forgotten {//其实这里是为了保证执行完毕之后,对应的key被删除,Group有一个方法Forget(key string),可以用来主动删除key,这里是判断那个方法是否被调用过,被调用过则字段forgotten会置为true,如果没有被调用过,则在这里把key删除。
delete(g.m, key)
}
for _, ch := range c.chans {//将执行结果发送到channel里,这里是给DoChan方法使用的
ch <- Result{c.val, c.err, c.dups > 0}
}
g.mu.Unlock()
}

由此看来,其实现是非常简单的。不得不赞叹一百来行代码就实现了功能。

其他

顺便附上DoChan方法的使用示例:

func main() {
var singleSetCache singleflight.Group getAndSetCache:=func (requestID int,cacheKey string) (string, error) {
log.Printf("request %v start to get and set cache...",requestID)
retChan:=singleSetCache.DoChan(cacheKey, func() (ret interface{}, err error) {
log.Printf("request %v is setting cache...",requestID)
time.Sleep(3*time.Second)
log.Printf("request %v set cache success!",requestID)
return "VALUE",nil
}) var ret singleflight.Result timeout := time.After(5 * time.Second) select {//加入了超时机制
case <-timeout:
log.Printf("time out!")
return "",errors.New("time out")
case ret =<- retChan://从chan中取出结果
return ret.Val.(string),ret.Err
}
return "",nil
} cacheKey:="cacheKey"
for i:=1;i<10;i++{
go func(requestID int) {
value,_:=getAndSetCache(requestID,cacheKey)
log.Printf("request %v get value: %v",requestID,value)
}(i)
}
time.Sleep(20*time.Second)
}

看下DoChan的源码

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)//可以看到,每个等待的协程,都有一个结果channel。从之前的g.doCall里也可以看到,每个channel都给塞了结果。为什么不所有协程共用一个channel?因为那样就得在channel里塞至少与协程数量一样的结果数量,但是你却无法保证用户一个协程只读取一次。
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) return ch
}

使用Golang的singleflight防止缓存击穿的更多相关文章

  1. 使用singleflight防止缓存击穿(Java)

    缓存击穿 在使用缓存时,我们往往是先根据key从缓存中取数据,如果拿不到就去数据源加载数据,写入缓存.但是在某些高并发的情况下,可能会出现缓存击穿的问题,比如一个存在的key,在缓存过期的一刻,同时有 ...

  2. Redis缓存穿透、缓存雪崩和缓存击穿理解

    1.缓存穿透(不存在的商品访问数据造成压力) 缓存穿透,是指查询一个数据库一定不存在的数据.正常的使用缓存流程大致是,数据查询先进行缓存查询,如果key不存在或者key已经过期,再对数据库进行查询,并 ...

  3. redis 缓存击穿 看一篇成高手系列3

    什么是缓存击穿 在谈论缓存击穿之前,我们先来回忆下从缓存中加载数据的逻辑,如下图所示 因此,如果黑客每次故意查询一个在缓存内必然不存在的数据,导致每次请求都要去存储层去查询,这样缓存就失去了意义.如果 ...

  4. redis缓存雪崩,缓存穿透,缓存击穿的解决方法

    一.缓存雪崩 缓存雪崩表示在某一时间段,缓存集中失效,导致请求全部走数据库,有可能搞垮数据库,使整个服务瘫痪. 使缓存集中失效的原因: 1.redis服务器挂掉了. 2.对缓存数据设置了相同的过期时间 ...

  5. 缓存击穿、缓存失效及热点key的解决方案

    分布式缓存是网站服务端经常用到的一种技术,在读多写少的业务场景中,通过使用缓存可以有效地支撑高并发的访问量,对后端的数据库等数据源做到很好地保护.现在市面上有很多分布式缓存,比如Redis.Memca ...

  6. Redis 缓存穿透,缓存击穿,缓存雪崩的解决方案分析

    设计一个缓存系统,不得不要考虑的问题就是:缓存穿透.缓存击穿与失效时的雪崩效应. 一.什么样的数据适合缓存? 分析一个数据是否适合缓存,我们要从访问频率.读写比例.数据一致性等要求去分析.  二.什么 ...

  7. redis缓存穿透、缓存击穿、缓存雪崩

    缓存穿透 缓存穿透是指查询一个一定不存在的数据,由于缓存是不命中时需要从数据库查询,查不到数据则不写入缓存,这将导致这个不存在的数据每次请求都要到数据库去查询,造成缓存穿透. 解决办法: 预校验 在控 ...

  8. 【Redis】- 缓存击穿

    什么是缓存击穿 在谈论缓存击穿之前,我们先来回忆下从缓存中加载数据的逻辑,如下图所示 因此,如果黑客每次故意查询一个在缓存内必然不存在的数据,导致每次请求都要去存储层去查询,这样缓存就失去了意义.如果 ...

  9. 使用BloomFilter布隆过滤器解决缓存击穿、垃圾邮件识别、集合判重

    Bloom Filter是一个占用空间很小.效率很高的随机数据结构,它由一个bit数组和一组Hash算法构成.可用于判断一个元素是否在一个集合中,查询效率很高(1-N,最优能逼近于1). 在很多场景下 ...

随机推荐

  1. Mysql多条数据以一条展示和判断某字符是否在某字段

    多条数据以一条数据展示:GROUP_CONCAT select GROUP_CONCAT(uuid) from user; 判断某字符是否存在某字段:INSTR select * from( sele ...

  2. vue a标签下载图片文档显示下载失败

    解决:把所要下载的文件放到static文件下,具体原因-静态文件放在static内,否则webpack会打包.

  3. CAS和锁的相关面试题

    CAS 锁 锁的四种状态和升级 锁的四种状态:无锁.偏向锁.轻量级锁和重量级锁 无锁 无锁就是没有真正意义上的上锁,所有的线程还是能访问并修改同一个资源,但是通过算法控制,实现同时只有一个线程修改成功 ...

  4. Vue管理系统前端系列三登录页和首页及`vuex`管理登录状态

    目录 登录页面设计 vuex 对应 用户模块 丰富界面 首页相关代码 登录页面设计 该节记录了登录界面的设计,以及 vuex 的简单实用,然后将首页简单搭建完成. 先看最终效果图 先在 views 文 ...

  5. 企业项目实战 .Net Core + Vue/Angular 分库分表日志系统五 | 完善业务自动创建数据库

    教程预览 01 | 前言 02 | 简单的分库分表设计 03 | 控制反转搭配简单业务 04 | 强化设计方案 05 | 完善业务自动创建数据库 说明 这节来把基础的业务部分完善一下. 因为 IQue ...

  6. Java GUI 图书管理系统

    01 概述 一款功能强大的图书馆管理系统,功能齐全,小白/大学生项目实训,学习的不二之选. 02 技术 此系统使用 java awt 实现.java.awt是一个软件包,包含用于创建用户界面和绘制图形 ...

  7. sql 游标(理论)

    游标是处理结果集的一种机制 --声明游标 --ISO 语法 DECLARE cursor_name [ INSENSITIVE ] [ SCROLL ] CURSOR FOR select_state ...

  8. jmeter将上一个接口的返回值作为下一个接口的请求参数

    接口响应结果,通常为HTML.Json格式的数据,对于HTML的响应结果的提取,可以通过正则表达式,XPath提取. 对于Json格式响应结果,可以通过正则表达式.JSON Extractor插件.B ...

  9. WPF 使用WindowChrome自定义窗体 保留原生窗体特性

    本文大幅度借鉴dino.c大佬的文章 https://www.cnblogs.com/dino623/p/uielements_of_window.html https://www.cnblogs.c ...

  10. Unity碰撞消息(OnCollisionXXXX)和触发消息(OnTriggerXXXX)的调用情境

    MonoBehaviour中的消息非常多,一共有62个! 除了必须关注的脚本生命周期的一系列函数外,还有其他两组比较常混淆的消息:碰撞和触发. 按3D和2D物体区分,又分为碰撞:Collision.C ...