我們寫代碼的時候,經常會需要從數據庫里讀取一些數據,比如配置信息或者諸如每周熱點商品之類的數據。
應用讀取數據庫
如果這些數據既不經常變化,又需要頻繁讀取,那比起每次都去讀數據庫,更優的解決方案就是將它們放到應用的本地內存里,這樣可以省下不少數據庫 IO,性能嘎一下就上來了。
應用優先讀緩存
那么現在問題就來了,假設我要在某個服務應用里實現一個緩存組件去存各種類型的數據,該怎么實現這個組件呢?
最簡單的的方案就是使用 map,也就是字典,將需要保存的結構以 key-value 的形式,保存到內存中。比如系統配置,key 就叫 system_config,value 就是具體的配置內容。需要讀取數據就用 v = m[key]來獲取數據,需要寫數據就執行m[key] = v.
單線程讀寫map
這樣看起來在單線程下是滿足需求了。但如果我想在多個線程(協程)里并發讀寫這個緩存呢?那必然會發生競態問題。這就需要加個讀寫鎖了。讀操作前后要加鎖和解鎖,也就是改成下面這樣。
RLock()v = m[key]RUnLock()
寫操作也需要相應修改:
Lock()m[key] = vUnLock()
多線程加鎖讀寫map
這在讀寫不頻繁的場景下是完全 ok 的,如果沒有什么性能要求,服務也沒出現什么瓶頸,就算新來的實習生笑它很 low,你也要有自信,這就是個好用的緩存組件。架構就是這樣,能快速滿足需求,不出錯就行。
但其實這個方案其實也有很大的問題,如果讀寫 qps 非常高,那么就會有一堆請求爭搶同一個 map 鎖,這對性能影響太大了。怎么解決呢?
上面的方案中,最大的問題是所有讀寫請求,都搶的同一個鎖,所以競爭才大,如果能將一部分請求改為搶 A 鎖,另一部分請求改為搶 B 鎖,那競爭就變小了。于是,我們可以將原來的一個 map,進行分片,變成多個 map,每個 map 都有自己的鎖。發生讀寫操作時,第一步先對 key 進行 hash 分片,獲取分片對應的鎖后,再對分片 map 進行讀寫。只有落在同一個分片的請求才會發生鎖爭搶。也就是說 map 拆的越細,鎖競爭就越小。
分片鎖
像這種將資源分割成多個獨立的分片(segments/shard),每個段都有一個對應的鎖來控制并發訪問的控制機制, 其實就是所謂的分片(段)鎖。看起來很完美,但其實還有問題。
像 C/C++這類語言中,用戶申請的內存需要由用戶自己寫代碼去釋放,一不小心忘了釋放那就會發生內存泄露,給程序員帶來了很大的心智負擔。為了避免這樣的問題,一般高級語言里都會自帶 GC,也就是垃圾回收(Garbage Collection),說白了就是程序員只管申請內存,用完了系統會自動回收釋放這些內存。比如 golang,它會每隔一段時間就去掃描哪些變量內存是可以被回收的。對于指針類型,golang 會先掃指針,再掃描指針指向的對象里的內容。map緩存里放的東西少還好說,緩存里的 key-value 一多,那就喜提多遍瘋狂掃描,浪費,全是浪費,golang 你糊涂啊。
gc掃描指針對象
那有沒有辦法可以減少這部分 gc 掃描 成本呢?有。golang 對于key 和 value 都不含指針的的map,會選擇跳過,不進行 gc 掃描。所以我們需要想辦法將 map 里的內容改成完全不含指針。原來 map 中放的 key-value,key和value 都可能是指針結構體。
原來 key 是用的字符串,在 golang 中字符串本質上也是指針,于是我們將它進行 hash 操作,將字符串轉為整形。信息經過 hash 操作后,有可能會丟掉部分信息,為了避免hash沖突時分不清具體是哪個 key-value,我們會將 key 放到 value 中一起處理,繼續看下面。
我們可以構造一個超大的 byte 數組 buf,將原來的 key value 等信息經過序列化,變成二進制01串。將它存放到這個超大 buf 中,并記錄它在 超大 buf 中的位置 index。然后將這個位置 index 信息放到 map 的 value 位置上,也就是從 key-velue,變成了 key-index。
引入buf減少gc掃描
同時為了防止 buf 數組變得過大,占用過多內存導致應用oom,還可以采用 ringbuf 的結構,寫到尾部就重頭開始寫,如果 ringbuf 空間不夠,還能對它進行擴容。
ringbuf擴容
對于寫操作,程序先將 key 進行 hash,得到所在分片 map,加鎖。
然后解鎖,結束流程。
寫分片map流程
對于讀操作,程序同樣先對 key 進行 hash,得到分片 map。加鎖,從分片 map 里拿到 value 對應的 index,拿著這個 index 到 ringbuf 數組中去獲取到 value 的值,然后解鎖,結束流程。
讀分片map流程
到這里,我們可以發現 map 的 key 和 value 都被改成了整形數字,也就省下了大量的 gc 掃描,大大提升了組件性能。其實這就是有名的高性能無 GC 的緩存庫 github.com/allegro/bigcache 的實現原理。
它的使用方法大概像下面這樣。
package mainimport ( "fmt" "github.com/allegro/bigcache/v3")func main() { // 設置 bigcache 配置參數 cacheConfig := bigcache.Config{ Shards: 1024, // 分片數量,提高并發性 } // 初始化 bigcache cache, _ := bigcache.NewBigCache(cacheConfig) // 寫緩存數據 key := "歡迎關注" value := []byte("小白debug") cache.Set(key, value) // 讀緩存數據 entry, _ := cache.Get(key) fmt.Printf("Entry: %s/n", entry)}
說白了就是 Get 方法讀緩存數據,Set 方法寫緩存數據,比較簡單。現在,大概原理和使用方法我們都懂了,我們再來看下 bigcache 中,兩個我認為挺巧妙的設計點。
在前面的介紹中,我猜你心里可能有疑問,程序從 ringbuf 讀寫 value 的時候,ringbuf里面放的都是 01 二進制數組,程序怎么知道該讀多少bit才算一個完整 value?bigcache 的解法非常值得學習,它重新定義了一個新的數據格式。
ringbuf內數據格式
當讀取 ringbuf 時,我們會先讀到 length,有了它,我們就能在 ringbuf 里拿到 header 和 data,header 里又含有 key 的長度,這樣就能在 data 里將 key 和 value 完整區分開來。
很多網絡傳輸框架中都會用到類似的方案,后面有機會跟大家細聊。
另外,還有個巧妙的設計是,在 bigcache 中, ringbuffer 的第 0 位并不用來存放任何數據,這樣如果發現 分片 map 中得到數據的 index 為 0,就可以直接認為沒有對應的緩存數據,那就不需要跑到 ringbuffer 里去撈一遍數據了,覺得學到了,記得在右下角給我點個贊。
ringbuf不使用第0位
bigcache 性能非常好,但也不是完全沒有問題。比較明顯的是,它讀寫數據時,用的都是byte數組,但我們平時寫代碼用的都是結構體,為了讓結構體和 byte 數組互轉,我們就需要用到序列化和反序列化,這些都是成本。
另外它的緩存淘汰策略也比較粗暴,用的是 FIFO,不支持 LRU 或 LFU 的淘汰策略。
本文鏈接:http://www.www897cc.com/showinfo-26-75379-0.htmlGolang 高性能無 GC 的緩存庫 bigcache 是怎么實現的?
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com