hello，大家好啊，我是小樓。
最近在工作中對 Go 的 singleflight 包做了下增強，解決了一個效能問題，這裡記錄下，希望對你也有所幫助。
singleflight 是什麼
singleflight 直接翻譯為”單（次）飛（行）“，它是對同一種請求的抑制，保證同一時刻相同的請求只有一個在執行，且在它執行期間的相同請求都會 Hold 直到執行完成，這些 hold 的請求也使用這次執行的結果。
舉個例子，當程式中有讀（如 Redis、MySQL、Http、RPC等）請求，且併發非常高的情況，使用 singleflight 能得到比較好的效果，它限制了同一時刻只有一個請求在執行，也就是併發永遠為1。
singleflight 的原理
最初 singleflight 出現在 groupcache 專案中，這個專案也是 Go 團隊所寫，後來該包被移到 Go 原始碼中，在 Go 原始碼中的版本經過幾輪迭代，稍微有點複雜，我們以最原始的原始碼來講解原理，更方便地看清本質。
https://github.com/golang/groupcache/blob/master/singleflight/singleflight.go
singleflight 把每次請求定義為 call，每個 call 物件包含了一個 waitGroup，一個 val，即請求的返回值，一個 err，即請求返回的錯誤。
type call struct {
wg sync.WaitGroup
val interface{}
err error
}
再定義全域性的 Group，包含一個互斥鎖 Mutex，一個 key 為 string，value 為 call 的 map。
type Group struct {
mu sync.Mutex
m map[string]*call
}
Group 物件有一個 Do 方法，其第一個引數是 string 型別的 key，這個 key 也就是上面說的 map 的 key，相同的 key 標誌著他們是相同的請求，只有相同的請求會被抑制；第二個引數是一個函式 fn，這個函式是真正要執行的函式，例如呼叫 MySQL；返回值比較好理解，即最終呼叫的返回值和錯誤資訊。
func (g *Group) Do(key string, fn func() (interface{}, error)) (interface{}, error) {
// ①
g.mu.Lock()
if g.m == nil {
g.m = make(map[string]*call)
}
// ②
if c, ok := g.m[key]; ok {
g.mu.Unlock()
c.wg.Wait()
return c.val, c.err
}
// ③
c := new(call)
c.wg.Add(1)
g.m[key] = c
g.mu.Unlock()
c.val, c.err = fn()
c.wg.Done()
g.mu.Lock()
delete(g.m, key)
g.mu.Unlock()
return c.val, c.err
}
將整個程式碼分成三塊：
- ① 懶載入方式初始化 map；
- ② 如果當前 key 存在，即相同請求正在呼叫中，就等它完成，完成後直接使用它的 value 和 error；
- ③ 如果當前 key 不存在，即沒有相同請求正在呼叫中，就建立一個 call 物件，並把它放進 map，接著執行 fn 函式，當函式執行完喚醒 waitGroup，並刪除 map 相應的 key，返回 value 和 error。
讀可以抑制，寫呢？
我們透過上面的介紹能瞭解，singleflight 能解決併發讀的問題，但我又遇到一個併發寫的問題。為了能讓大家快速進入狀態，先花一點篇幅描述一下遇到的實際問題：
微服務中的註冊中心想必大家都有所瞭解，如果不瞭解，可以去查查相關概念，或者翻看我以前的文章，老讀者應該能發現我寫了很多相關的文章。
服務提供方在註冊之後，會將變更事件推送到消費方，推送事件的處理流程是：接收到事件，查詢組裝出最新的資料，然後推送給訂閱者。存在兩種情況可能會導致短時間內註冊請求非常多，推送事件多會影響整個註冊中心的效能：
- 介面級註冊（類似 Dubbo），每臺機器會註冊N多次
- 服務併發釋出，例如每次釋出重啟100臺機器，那麼註冊的併發就可能是100
拿到這種問題，第一想到的解法是：合併推送。但，怎麼合併呢？
是不是每次推送的時候等一等，等事件都來了再一把推過去就可以了？但等多久呢？什麼時候該等呢？粗暴點，每秒鐘推送一次，這樣就能將一秒內的時間都聚合，但這會影響推送的時效性，顯然不符合我們精益求精的要求。
直接使用 singleflight，能行嗎？
套用上面 singleflight ，在第一個事件推送過程中，其他相同的事件被 Hold 住，等第一個事件推送完成後，這些 Hold 的事件不再執行推送直接返回。
稍微想一下就知道這樣是有問題的，假設有三個事件 A、B、C，分別對應到三個版本的資料A1、B1、C1，A 最先到達，在 A 開始推送後但沒完成時 B、C 事件到達，A 事件觸發推送了 A1 版本的資料，B、C 事件在 A 事件推送完成後，直接丟棄，最終推送到消費者上的資料版本為 A1，但我們肯定期望推送的資料版本為 C1，畫個圖線感受下：
增強一點點 ??
假設有事件 A、B、C、D 先後到達，A 事件仍然先正常執行推送，在 A 事件推送的時候，B、C、D 事件 Hlod 住，當 A 事件推送完成後，B 事件開始推送，B 事件將把 A 事件推送時期積攢的事件都一起推送掉，即 B、C、D 一次性推送完成。
增強程式碼參考
增強的定義為 WriteGroup，借用 singleflight 原先的實現，具體程式碼就不必解讀了，對照上面的例子應該很好理解。
package singleflight
import (
"sync"
)
type WriteGroup struct {
mu sync.Mutex
wgs map[string]*sync.WaitGroup
group Group
}
func (g *WriteGroup) Do(key string, fn func() error) error {
g.mu.Lock()
if g.wgs == nil {
g.wgs = make(map[string]*sync.WaitGroup)
}
wg, ok := g.wgs[key]
if !ok {
wg = &sync.WaitGroup{}
wg.Add(1)
g.wgs[key] = wg
}
g.mu.Unlock()
if !ok {
err := fn()
g.mu.Lock()
wg.Done()
delete(g.wgs, key)
g.mu.Unlock()
return err
}
wg.Wait()
_, err := g.group.Do(key, func() (interface{}, error) {
return nil, fn()
})
return err
}
效果如何？
理論上，如果沒有併發，事件和以前一樣推送，沒有合併，當然這也沒毛病。當併發大於 2 時，開始發揮威力。在實際的壓測上，註冊併發 1500 時，合併的事件達到 99.9%，效果相當炸裂！
最後感謝能抽空看到這裡，如果你能點贊、在看、分享，我會更加感激不盡~
- 搜尋關注微信公眾號"捉蟲大師"，後端技術分享，架構設計、效能最佳化、原始碼閱讀、問題排查、踩坑實踐
- 進技術交流群加微信 MrRoshi