使用增強版 singleflight 合併事件推送，效果炸裂！

捉蟲大師發表於2023-05-19
事件

hello，大家好啊，我是小樓。

最近在工作中對 Go 的 singleflight 包做了下增強，解決了一個效能問題，這裡記錄下，希望對你也有所幫助。

singleflight 是什麼

singleflight 直接翻譯為”單（次）飛（行）“，它是對同一種請求的抑制，保證同一時刻相同的請求只有一個在執行，且在它執行期間的相同請求都會 Hold 直到執行完成，這些 hold 的請求也使用這次執行的結果。

舉個例子，當程式中有讀（如 Redis、MySQL、Http、RPC等）請求，且併發非常高的情況，使用 singleflight 能得到比較好的效果，它限制了同一時刻只有一個請求在執行，也就是併發永遠為1。

image

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，畫個圖線感受下：

image

增強一點點 ??

假設有事件 A、B、C、D 先後到達，A 事件仍然先正常執行推送，在 A 事件推送的時候，B、C、D 事件 Hlod 住，當 A 事件推送完成後，B 事件開始推送，B 事件將把 A 事件推送時期積攢的事件都一起推送掉，即 B、C、D 一次性推送完成。

image

增強程式碼參考

增強的定義為 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

相關文章