分布式系統中的CAP理論，面試必問，你理解了嘛？
對于剛剛接觸分布式系統的小伙伴們來說，一提起分布式系統，就感覺高大上，深不可測。而且看了很多書和視頻還是一臉懵逼。這篇文章主要使用大白話的方式，帶你理解一下分布式系統
我們寫代碼的時候，經常會需要從數據庫里讀取一些數據，比如配置信息或者諸如每周熱點商品之類的數據。
應用讀取數據庫
如果這些數據既不經常變化，又需要頻繁讀取，那比起每次都去讀數據庫，更優的解決方案就是將它們放到應用的本地內存里，這樣可以省下不少數據庫 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
Copyright ? 2016-2023 天津谷騏科技有限公司 版權所有 sitemap.xml
違法及侵權請聯系：2376512515@qq.com 津ICP備18001702號
津公網安備 12010102000574號