Go使用協程批次獲取資料，加快介面返回速度

伺服器端經常需要返回一個列表，裡面包含很多使用者資料，常規做法當然是遍歷然後讀快取。

使用Go語言後，可以並行獲取，極大提升效率。

使用channel

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[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 = %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() //等待令牌消耗完
}

需要注意的是，該型別計數器不能小於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
}

為什麼不直接上鎖？

因為經過我的測試，會很慢，沒有sync.Map優化的好。
這樣可以保證順序。