【Go并发编程】Go使用协程批量获取数据，加快接口返回速度
<p>服务端经常需要返回一个列表，里面包含很多用户数据，常规做法当然是遍历然后读缓存。</p><p>使用Go语言后，可以并发获取，极大提升效率。</p>
<h2 id="使用channel">使用channel</h2>
<pre><code class="language-go">package main
import (
"fmt"
"time"
)
func add2(a, b int, ch chan int) {
c := a + b
fmt.Printf("%d + %d = %d\n", a, b, c)
ch <- 1 //执行完了就写一条表示自己完成了
}
func main() {
start := time.Now()
chs := make([]chan int, 10)
for i := 0; i < 10; i++ {
chs = make(chan int)
go add2(1, i, chs) //分配了10个协程出去了
}
for _, ch := range chs {
<-ch //循环等待，要每个完成才能继续，不然就等待
}
end := time.Now()
consume := end.Sub(start).Seconds()
fmt.Println("程序执行耗时(s)：", consume)
}
</code></pre>
<p>在每个协程的 add() 函数业务逻辑完成后，我们通过 ch <- 1 语句向对应的通道中发送一个数据。</p>
<p>在所有的协程启动完成后，我们再通过 <-ch 语句从通道切片 chs 中依次接收数据（不对结果做任何处理，相当于写入通道的数据只是个标识而已，表示这个通道所属的协程逻辑执行完毕）.</p>
<p>直到所有通道数据接收完毕，然后打印主程序耗时并退出。</p>
<h2 id="使用waitgroup">使用WaitGroup</h2>
<ul>
<li>Add：WaitGroup 类型有一个计数器，默认值是0，我们可以通过 Add 方法来增加这个计数器的值，通常我们可以通过个方法来标记需要等待的子协程数量；</li>
<li>Done：当某个子协程执行完毕后，可以通过 Done 方法标记已完成，该方法会将所属 WaitGroup 类型实例计数器值减一，通常可以通过 defer 语句来调用它；</li>
<li>Wait：Wait 方法的作用是阻塞当前协程，直到对应 WaitGroup 类型实例的计数器值归零，如果在该方法被调用的时候，对应计数器的值已经是 0，那么它将不会做任何事情</li>
</ul>
<pre><code class="language-go">package main
import (
"fmt"
"sync"
)
func addNum(a, b int, deferFunc func()) {
defer func() {
deferFunc()
}()
c := a + b
fmt.Printf("%d + %d = %d\n", 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() //等待令牌消耗完
}
</code></pre>
<p>需要注意的是，该类型计数器不能小于0，否则会抛出如下 panic：</p>
<p><code>panic: sync: negative WaitGroup counter</code></p>
<h2 id="应用到实践">应用到实践</h2>
<pre><code class="language-go">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 = NewUserCache(userId).GetBase()
wg.Done()
}(index, userId, userCaches)
}
wg.Wait()
return userCaches
}
</code></pre>
<p>这种写法有两个问题：<br>
1.并发肯定带来乱序，所以要考虑需要排序的业务场景。<br>
2.map是线程不安全的，并发读写会panic。</p>
<h3 id="优化一下">优化一下：</h3>
<pre><code class="language-go">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 = value.(UserBase)
}
i++
}
return userCaches
}
</code></pre>
<p>为什么不直接上锁？</p>
<ol>
<li>因为经过我的测试，会很慢，没有sync.Map优化的好。</li>
<li>这样可以保证顺序。</li>
</ol>
</div>
<div id="MySignature" role="contentinfo">
当你停下来休息的时候，不要忘记别人还在奔跑！<br><br>
来源：https://www.cnblogs.com/HappyTeemo/p/17109302.html
頁:
[1]