hello，大家好啊，我是小樓。 最近在工作中對 Go 的 singleflight 包做了下增強，解決了一個性能問題，這裡記錄下，希望對你也有所幫助。 # singleflight 是什麼 singleflight 直接翻譯為”單（次）飛（行）“，它是對同一種請求的抑制，保證同一時刻相同的請求只有 ...
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，畫個圖線感受下：
