Golang源码分析之golang/sync之singleflight

目录
  • 1.背景
    • 1.1. 项目介绍
    • 1.2.使用方法
  • 2.源码分析
    • 2.1.项目结构
    • 2.2.数据结构
    • 2.3.API代码流程
  • 3.总结

1.背景

1.1. 项目介绍

golang/sync库拓展了官方自带的sync库,提供了errgroup、semaphore、singleflight及syncmap四个包,本次分析singlefliht的源代码。
singlefliht用于解决单机协程并发调用下的重复调用问题,常与缓存一起使用,避免缓存击穿。

1.2.使用方法

go get -u golang.org/x/sync

  • 核心API:Do、DoChan、Forget
  • Do:同一时刻对某个Key方法的调用, 只能由一个协程完成,其余协程阻塞直到该协程执行成功后,直接获取其生成的值,以下是一个避免缓存击穿的常见使用方法:
func main() {
   var flight singleflight.Group
   var errGroup errgroup.Group

   // 模拟并发获取数据缓存
   for i := 0; i < 10; i++ {
      i := i
      errGroup.Go(func() error {
         fmt.Printf("协程%v准备获取缓存\n", i)
         v, err, shared := flight.Do("getCache", func() (interface{}, error) {
            // 模拟获取缓存操作
            fmt.Printf("协程%v正在读数据库获取缓存\n", i)
            time.Sleep(100 * time.Millisecond)
            fmt.Printf("协程%v读取数据库生成缓存成功\n", i)
            return "mockCache", nil
         })
         if err != nil {
            fmt.Printf("err = %v", err)
            return err
         }
         fmt.Printf("协程%v获取缓存成功, v = %v, shared = %v\n", i, v, shared)
         return nil
      })
   }
   if err := errGroup.Wait(); err != nil {
      fmt.Printf("errGroup wait err = %v", err)
   }
}
// 输出:只有0号协程实际生成了缓存,其余协程读取生成的结果
协程0准备获取缓存
协程4准备获取缓存
协程3准备获取缓存
协程2准备获取缓存
协程6准备获取缓存
协程5准备获取缓存
协程7准备获取缓存
协程1准备获取缓存
协程8准备获取缓存
协程9准备获取缓存
协程0正在读数据库获取缓存
协程0读取数据库生成缓存成功
协程0获取缓存成功, v = mockCache, shared = true
协程8获取缓存成功, v = mockCache, shared = true
协程2获取缓存成功, v = mockCache, shared = true
协程6获取缓存成功, v = mockCache, shared = true
协程5获取缓存成功, v = mockCache, shared = true
协程7获取缓存成功, v = mockCache, shared = true
协程9获取缓存成功, v = mockCache, shared = true
协程1获取缓存成功, v = mockCache, shared = true
协程4获取缓存成功, v = mockCache, shared = true
协程3获取缓存成功, v = mockCache, shared = true

DoChan:将执行结果返回到通道中,可通过监听通道结果获取方法执行值,这个方法相较于Do来说的区别是执行DoChan后不会阻塞到其中一个协程完成任务,而是异步执行任务,最后需要结果时直接从通道中获取,避免长时间等待。

func testDoChan() {
   var flight singleflight.Group
   var errGroup errgroup.Group

   // 模拟并发获取数据缓存
   for i := 0; i < 10; i++ {
      i := i
      errGroup.Go(func() error {
         fmt.Printf("协程%v准备获取缓存\n", i)
         ch := flight.DoChan("getCache", func() (interface{}, error) {
            // 模拟获取缓存操作
            fmt.Printf("协程%v正在读数据库获取缓存\n", i)
            time.Sleep(100 * time.Millisecond)
            fmt.Printf("协程%v读取数据库获取缓存成功\n", i)
            return "mockCache", nil
         })
         res := <-ch
         if res.Err != nil {
            fmt.Printf("err = %v", res.Err)
            return res.Err
         }
         fmt.Printf("协程%v获取缓存成功, v = %v, shared = %v\n", i, res.Val, res.Shared)
         return nil
      })
   }
   if err := errGroup.Wait(); err != nil {
      fmt.Printf("errGroup wait err = %v", err)
   }
}
// 输出结果
协程9准备获取缓存
协程0准备获取缓存
协程1准备获取缓存
协程6准备获取缓存
协程5准备获取缓存
协程2准备获取缓存
协程7准备获取缓存
协程8准备获取缓存
协程4准备获取缓存
协程9正在读数据库获取缓存
协程9读取数据库获取缓存成功
协程3准备获取缓存
协程3获取缓存成功, v = mockCache, shared = true
协程8获取缓存成功, v = mockCache, shared = true
协程0获取缓存成功, v = mockCache, shared = true
协程1获取缓存成功, v = mockCache, shared = true
协程6获取缓存成功, v = mockCache, shared = true
协程5获取缓存成功, v = mockCache, shared = true
协程2获取缓存成功, v = mockCache, shared = true
协程7获取缓存成功, v = mockCache, shared = true
协程4获取缓存成功, v = mockCache, shared = true
协程9获取缓存成功, v = mockCache, shared = true

2.源码分析

2.1.项目结构

  • singleflight.go:核心实现,提供相关API
  • singleflight_test.go:相关API单元测试

2.2.数据结构

  • singleflight.go
// singleflight.Group
type Group struct {
   mu sync.Mutex       // map的锁
   m  map[string]*call // 保存每个key的调用
}

// 一次Do对应的响应结果
type Result struct {
   Val    interface{}
   Err    error
   Shared bool
}

// 一个key会对应一个call
type call struct {
   wg sync.WaitGroup
   val interface{} // 保存调用的结果
   err error       // 调用出现的err
   // 该call被调用的次数
   dups  int
   // 每次DoChan时都会追加一个chan在该列表
   chans []chan<- Result
}

2.3.API代码流程

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

func (g *Group) Do(key string, fn func() (interface{}, error)) (v interface{}, err error, shared bool) {
   g.mu.Lock()
   if g.m == nil {
      // 第一次执行Do的时候创建map
      g.m = make(map[string]*call)
   }
   // 已经存在该key,对应后续的并发调用
   if c, ok := g.m[key]; ok {
      // 执行次数自增
      c.dups++
      g.mu.Unlock()
      // 等待执行fn的协程完成
      c.wg.Wait()
      // ...
      // 返回执行结果
      return c.val, c.err, true
   }

   // 不存在该key,说明第一次调用,初始化一个call
   c := new(call)
   // wg添加1,后续其他协程在该wg上阻塞
   c.wg.Add(1)
   // 保存key和call的关系
   g.m[key] = c
   g.mu.Unlock()
   // 真正执行fn函数
   g.doCall(c, key, fn)
   return c.val, c.err, c.dups > 0
}

func (g *Group) doCall(c *call, key string, fn func() (interface{}, error)) {
   normalReturn := false
   recovered := false

   // 第三步、最后的设置和清理工作
   defer func() {
      // ...
      g.mu.Lock()
      defer g.mu.Unlock()
      // 执行完成,调用wg.Done,其他协程此时不再阻塞,读到fn执行结果
      c.wg.Done()
      // 二次校验map中key的值是否为当前call,并删除该key
      if g.m[key] == c {
         delete(g.m, key)
      }
      // ...
      // 如果c.chans存在,则遍历并写入执行结果
      for _, ch := range c.chans {
          ch <- Result{c.val, c.err, c.dups > 0}
        }
      }
   }()

   // 第一步、执行fn获取结果
   func() {
      // 3、如果fn执行过程中panic,将c.err设置为PanicError
      defer func() {
         if !normalReturn {
            if r := recover(); r != nil {
               c.err = newPanicError(r)
            }
         }
      }()
      // 1、执行fn,获取到执行结果
      c.val, c.err = fn()
      // 2、设置正常返回结果标识
      normalReturn = true
   }()

   // 第二步、fn执行出错,将recovered标识设置为true
   if !normalReturn {
      recovered = true
   }
}

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

func (g *Group) DoChan(key string, fn func() (interface{}, error)) <-chan Result {
   // 一次调用对应一个chan
   ch := make(chan Result, 1)
   g.mu.Lock()
   if g.m == nil {
      // 第一次调用,初始化map
      g.m = make(map[string]*call)
   }
   // 后续调用,已存在key
   if c, ok := g.m[key]; ok {
      // 调用次数自增
      c.dups++
      // 将chan添加到chans列表
      c.chans = append(c.chans, ch)
      g.mu.Unlock()
      // 直接返回chan,不等待fn执行完成
      return ch
   }

   // 第一次调用,初始化call及chans列表
   c := &call{chans: []chan<- Result{ch}}
   // wg加一
   c.wg.Add(1)
   // 保存key及call的关系
   g.m[key] = c
   g.mu.Unlock()

   // 异步执行fn函数
   go g.doCall(c, key, fn)

   // 直接返回该chan
   return ch
}

3.总结

  • singleflight经常和缓存获取配合使用,可以缓解缓存击穿问题,避免同一时刻单机大量的并发调用获取数据库构建缓存
  • singleflight的实现很精简,核心流程就是使用map保存每次调用的key与call的映射关系,每个call中通过wg控制只存在一个协程执行fn函数,其他协程等待执行完成后,直接获取执行结果,在执行完成后会删去map中的key
  • singleflight的Do方法会阻塞直到fn执行完成,DoChan方法不会阻塞,而是异步执行fn,并通过通道来实现结果的通知

到此这篇关于Golang源码分析之golang/sync之singleflight的文章就介绍到这了,更多相关Golang源码分析singleflight内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 解决Golang并发工具Singleflight的问题

    目录 前言 定义 用途 简单Demo 源码分析 结构 对外暴露的方法 重点方法分析 Do 流程图 Forget doCall 实际使用 弊端与解决方案 参考文章 前言 前段时间在一个项目里使用到了分布式锁进行共享资源的访问限制,后来了解到Golang里还能够使用singleflight对共享资源的访问做限制,于是利用空余时间了解,将知识沉淀下来,并做分享 文章尽量用通俗的语言表达自己的理解,从入门demo开始,结合源码分析singleflight的重点方法,最后分享singleflight的实际

  • 使用Golang的singleflight防止缓存击穿的方法

    在使用缓存时,容易发生缓存击穿. 缓存击穿:一个存在的key,在缓存过期的瞬间,同时有大量的请求过来,造成所有请求都去读dB,这些请求都会击穿到DB,造成瞬时DB请求量大.压力骤增. singleflight 介绍 import "golang.org/x/sync/singleflight" singleflight类的使用方法就新建一个singleflight.Group,使用其方法Do或者DoChan来包装方法,被包装的方法在对于同一个key,只会有一个协程执行,其他协程等待那个

  • golang 防缓存击穿singleflight的实现

    目录 一.什么是缓存击穿 二.原理 三.实现 一.什么是缓存击穿 当一个key是热点key时,一般会做缓存来抗大量并发,但当缓存失效的一瞬间,这些大量的并发请求会击穿缓存,直接请求数据库 为了避免缓存击穿,一种解决方法可以设置缓存永不过期,另一种可以使用golang的包 singleflight golang.org/x/sync/singleflight 二.原理 多个并发请求对一个失效key进行数据获取时,只会有其中一个去直接获取数据,其它请求会阻塞等待第一个请求返回给它们结果 三.实现 p

  • Golang源码分析之golang/sync之singleflight

    目录 1.背景 1.1. 项目介绍 1.2.使用方法 2.源码分析 2.1.项目结构 2.2.数据结构 2.3.API代码流程 3.总结 1.背景 1.1. 项目介绍 golang/sync库拓展了官方自带的sync库,提供了errgroup.semaphore.singleflight及syncmap四个包,本次分析singlefliht的源代码.singlefliht用于解决单机协程并发调用下的重复调用问题,常与缓存一起使用,避免缓存击穿. 1.2.使用方法 go get -u golang

  • Golang Mutex互斥锁源码分析

    目录 前言 Mutex 特性 数据结构 Lock() Unlock() 前言 在上一篇文章中,我们一起学习了如何使用 Go 中的互斥锁 Mutex,那么本篇文章,我们就一起来探究下 Mutex 底层是如何实现的,知其然,更要知其所以然! 说明:本文中的示例,均是基于Go1.17 64位机器 Mutex 特性 Mutex 就是一把互斥锁,可以想象成一个令牌,有且只有这一个令牌,只有持有令牌的 goroutine 才能进入房间(临界区),在房间内执行完任务后,走出房间并把令牌交出来,如果还有其余的 

  • Golang通道channel的源码分析

    目录 前言 channel基础结构 channel初始化 channel发送 channel接收 小结 前言 channel是golang中标志性的概念之一,很好很强大! channel(通道),顾名思义,是一种通道,一种用于并发环境中数据传递的通道.通常结合golang中另一重要概念goroutine(go协程)使用,使得在golang中的并发编程变得清晰简洁同时又高效强大. 今天尝试着读读golang对channel的实现源码,本文主要是自己个人对于Channel源码的学习笔记,需要的朋友可

  • 详解Golang中select的使用与源码分析

    目录 背景 select 流程 背景 golang 中主推 channel 通信.单个 channel 的通信可以通过一个goroutine往 channel 发数据,另外一个从channel取数据进行.这是阻塞的,因为要想顺利执行完这个步骤,需要 channel 准备好才行,准备好的条件如下: 1.发送 缓存有空间(如果是有缓存的 channel) 有等待接收的 goroutine 2.接收 缓存有数据(如果是有缓存的 channel) 有等待发送的 goroutine 对channel实际使

  • 修改并编译golang源码的操作步骤

    最近为了做Hyperledger Fabric国密改造,涉及到了golang源码的改动.特将操作过程整理如下,以供参考: golang的源码安装其实比较简单,只需运行源码包中的脚本src/all.bash,等到出现类似以下字样就安装好了: Installed Go for linux/amd64 in xxx(目录地址) Installed commands in xxx(目录地址) 但是在源码安装1.5版本以上的go时会报以下的错误 : ##### Building Go bootstrap

  • futuretask源码分析(推荐)

    FutureTask只实现RunnableFuture接口: 该接口继承了java.lang.Runnable和Future接口,也就是继承了这两个接口的特性. 1.可以不必直接继承Thread来生成子类,只要实现run方法,且把实例传入到Thread构造函数,Thread就可以执行该实例的run方法了( Thread(Runnable) ). 2.可以让任务独立执行,get获取任务执行结果时,可以阻塞直至执行结果完成.也可以中断执行,判断执行状态等. FutureTask是一个支持取消行为的异

  • Java并发系列之AbstractQueuedSynchronizer源码分析(概要分析)

    学习Java并发编程不得不去了解一下java.util.concurrent这个包,这个包下面有许多我们经常用到的并发工具类,例如:ReentrantLock, CountDownLatch, CyclicBarrier, Semaphore等.而这些类的底层实现都依赖于AbstractQueuedSynchronizer这个类,由此可见这个类的重要性.所以在Java并发系列文章中我首先对AbstractQueuedSynchronizer这个类进行分析,由于这个类比较重要,而且代码比较长,为了

  • Java并发系列之Semaphore源码分析

    Semaphore(信号量)是JUC包中比较常用到的一个类,它是AQS共享模式的一个应用,可以允许多个线程同时对共享资源进行操作,并且可以有效的控制并发数,利用它可以很好的实现流量控制.Semaphore提供了一个许可证的概念,可以把这个许可证看作公共汽车车票,只有成功获取车票的人才能够上车,并且车票是有一定数量的,不可能毫无限制的发下去,这样就会导致公交车超载.所以当车票发完的时候(公交车以满载),其他人就只能等下一趟车了.如果中途有人下车,那么他的位置将会空闲出来,因此如果这时其他人想要上车

  • Java并发系列之CountDownLatch源码分析

    CountDownLatch(闭锁)是一个很有用的工具类,利用它我们可以拦截一个或多个线程使其在某个条件成熟后再执行.它的内部提供了一个计数器,在构造闭锁时必须指定计数器的初始值,且计数器的初始值必须大于0.另外它还提供了一个countDown方法来操作计数器的值,每调用一次countDown方法计数器都会减1,直到计数器的值减为0时就代表条件已成熟,所有因调用await方法而阻塞的线程都会被唤醒.这就是CountDownLatch的内部机制,看起来很简单,无非就是阻塞一部分线程让其在达到某个条

  • Java并发系列之ReentrantLock源码分析

    在Java5.0之前,协调对共享对象的访问可以使用的机制只有synchronized和volatile.我们知道synchronized关键字实现了内置锁,而volatile关键字保证了多线程的内存可见性.在大多数情况下,这些机制都能很好地完成工作,但却无法实现一些更高级的功能,例如,无法中断一个正在等待获取锁的线程,无法实现限定时间的获取锁机制,无法实现非阻塞结构的加锁规则等.而这些更灵活的加锁机制通常都能够提供更好的活跃性或性能.因此,在Java5.0中增加了一种新的机制:Reentrant

随机推荐