Go使用协程批量获取数据,加快接口返回速度

服务端经常需要返回一个列表,里面包含很多用户数据,常规做法当然是遍历然后读缓存。

使用Go语言后,可以并发获取,极大提升效率。

使用channel

package main  import (    "fmt"    "time" )  func add2(a, b int, ch chan int) {    c := a + b    fmt.Printf("%d + %d = %dn", a, b, c)    ch <- 1 //执行完了就写一条表示自己完成了 }  func main() {    start := time.Now()    chs := make([]chan int, 10)    for i := 0; i < 10; i++ {       chs[i] = make(chan int)       go add2(1, i, chs[i]) //分配了10个协程出去了    }    for _, ch := range chs {       <-ch //循环等待,要每个完成才能继续,不然就等待    }    end := time.Now()    consume := end.Sub(start).Seconds()    fmt.Println("程序执行耗时(s):", consume) }  

在每个协程的 add() 函数业务逻辑完成后,我们通过 ch <- 1 语句向对应的通道中发送一个数据。

在所有的协程启动完成后,我们再通过 <-ch 语句从通道切片 chs 中依次接收数据(不对结果做任何处理,相当于写入通道的数据只是个标识而已,表示这个通道所属的协程逻辑执行完毕).

直到所有通道数据接收完毕,然后打印主程序耗时并退出。

使用WaitGroup

  • Add:WaitGroup 类型有一个计数器,默认值是0,我们可以通过 Add 方法来增加这个计数器的值,通常我们可以通过个方法来标记需要等待的子协程数量;
  • Done:当某个子协程执行完毕后,可以通过 Done 方法标记已完成,该方法会将所属 WaitGroup 类型实例计数器值减一,通常可以通过 defer 语句来调用它;
  • Wait:Wait 方法的作用是阻塞当前协程,直到对应 WaitGroup 类型实例的计数器值归零,如果在该方法被调用的时候,对应计数器的值已经是 0,那么它将不会做任何事情
package main  import (    "fmt"    "sync" )  func addNum(a, b int, deferFunc func()) {    defer func() {       deferFunc()    }()    c := a + b    fmt.Printf("%d + %d = %dn", a, b, c) }  func main() {    var wg sync.WaitGroup    wg.Add(10) //等于发了10个令牌    for i := 0; i < 10; i++ {       go addNum(i, 1, wg.Done) //每次执行都消耗令牌    }    wg.Wait() //等待令牌消耗完 }  

需要注意的是,该类型计数器不能小于0,否则会抛出如下 panic:

panic: sync: negative WaitGroup counter

应用到实践

func GetManyBase(userIds []int64) []UserBase {    userCaches := make([]UserBase, len(userIds))     var wg sync.WaitGroup    for index, userId := range userIds {       wg.Add(1)       go func(index int, userId int64, userCaches []UserBase) {          userCaches[index] = NewUserCache(userId).GetBase()           wg.Done()       }(index, userId, userCaches)    }    wg.Wait()     return userCaches } 

这种写法有两个问题:
1.并发肯定带来乱序,所以要考虑需要排序的业务场景。
2.map是线程不安全的,并发读写会panic。

优化一下:

func GetManyBase(userIds []int64) []UserBase { 	userCaches := make([]UserBase, len(userIds))  	var scene sync.Map  	var wg sync.WaitGroup 	for index, userId := range userIds { 		wg.Add(1) 		go func(index int, userId int64, userCaches []UserBase) { 			scene.Store(userId, NewUserCache(userId).GetBase()) 			wg.Done() 		}(index, userId, userCaches) 	} 	wg.Wait()  	i := 0 	for _, userId := range userIds { 		if value, ok := scene.Load(userId); ok { 			userCaches[i] = value.(UserBase) 		} 		i++ 	}  	return userCaches } 

为什么不直接上锁?

  1. 因为经过我的测试,会很慢,没有sync.Map优化的好。
  2. 这样可以保证顺序。
发表评论

相关文章