使用Go實現健壯的內存型緩存

使用Go實現健壯的內存型緩存

本文介紹了緩存的常見使用場景、選型以及注意點,比較有價值。
譯自:Implementing robust in-memory cache with Go

內存型緩存是一種以消費內存爲代價換取應用性能和彈性的方式,同時也推遲了數據的一致性。在使用內存型緩存時需要注意並行更新、錯誤緩存、故障轉移、後臺更新、過期抖動,以及緩存預熱和轉換等問題。

由來

緩存是提升性能的最便捷的方式,但緩存不是萬能的,在某些場景下,由於事務或一致性的限制,你無法重複使用某個任務的結果。緩存失效是計算機科學中最常見的兩大難題之一。

如果將操作限制在不變的數據上,則無需擔心緩存失效。此時緩存僅用於減少網絡開銷。然而,如果需要與可變數據進行同步,則必須關注緩存失效的問題。

最簡單的方式是基於TTL來設置緩存失效。雖然這種方式看起來遜於基於事件的緩存失效方式,但它簡單且可移植性高。由於無法保證事件能夠即時傳遞,因此在最壞的場景中(如事件代理短時間下線或過載),事件甚至還不如TTL精確。

短TTL通常是性能和一致性之間的一種折衷方式。它可以作爲一道屏障來降低高流量下到數據源的負載。

Demo應用

下面看一個簡單的demo應用,它接收帶請求參數的URL,並根據請求參數返回一個JSON對象。由於數據存儲在數據庫中,因此整個交互會比較慢。

下面將使用一個名爲plt的工具對應用進行壓測,plt包括參數:

  • cardinality - 生成的唯一的URLs的數據,會影響到緩存命中率
  • group - 一次性發送的URL相似的請求個數,模擬對相同鍵的併發訪問。
go run ./cmd/cplt --cardinality 10000 --group 100 --live-ui --duration 10h --rate-limit 5000 curl --concurrency 200 -X 'GET'   'http://127.0.0.1:8008/hello?name=World&locale=ru-RU'   -H 'accept: application/json'

上述命令會啓動一個client,循環發送10000個不同的URLs,每秒發送5000個請求,最大併發數爲200。每個URL會以100個請求爲批次將進行發送,用以模仿單個資源的併發,下面展示了實時數據:

image

Demo應用通過CACHE環境變量定義了三種操作模式:

  • none:不使用緩存,所有請求都會涉及數據庫
  • naive:使用簡單的map,TTL爲3分鐘
  • advanced:使用github.com/bool64/cache 庫,實現了很多特性來提升性能和彈性,TTL也是3分鐘。

Demo應用的代碼位於:github.com/vearutop/cache-story,可以使用make start-deps run命令啓動demo應用。

在不使用緩存的條件下,最大可以達到500RPS,在併發請求達到130之後DB開始因爲 Too many connections而阻塞,這種結果不是最佳的,雖然並不嚴重,但需要提升性能。

image

使用advanced緩存的結果如下,吞吐量提升了60倍,並降低了請求延遲以及DB的壓力:

image
go run ./cmd/cplt --cardinality 10000 --group 100 --live-ui --duration 10h curl --concurrency 100 -X 'GET'   'http://127.0.0.1:8008/hello?name=World&locale=ru-RU'   -H 'accept: application/json'
Requests per second: 25064.03
Successful requests: 15692019
Time spent: 10m26.078s

Request latency percentiles:
99%: 28.22ms
95%: 13.87ms
90%: 9.77ms
50%: 2.29ms

字節 VS 結構體

哪個更佳?

取決於使用場景,字節緩存([]byte)的優勢如下:

  • 數據不可變,在訪問數據時需要進行解碼
  • 由於內存碎片較少,使用的內存也較少
  • 對垃圾回收友好,因爲沒有什麼需要遍歷的
  • 便於在線路上傳輸
  • 允許精確地限制內存

字節緩存的最大劣勢是編解碼帶來的開銷,在熱點循環中,編解碼導致的開銷可能會非常大。

結構體的優勢:

  • 在訪問數據時無需進行編碼/解碼
  • 更好地表達能力,可以緩存那些無法被序列化的內容

結構體緩存的劣勢:

  • 由於結構體可以方便地進行修改,因此可能會被無意間修改
  • 結構體的內存相對比較稀疏
  • 如果使用了大量長時間存在的結構體,GC可能會花費一定的時間進行遍歷,來確保這些結構體仍在使用中,因此會對GC採集器造成一定的壓力
  • 幾乎無法限制緩存實例的總內存,動態大小的項與其他所有項一起存儲在堆中。

本文使用了結構體緩存。

Native 緩存

使用了互斥鎖保護的map。當需要檢索一個鍵的值時,首先查看緩存中是否存在該數據以及有沒有過期,如果不存在,則需要從數據源構造該數據並將其放到緩存中,然後返回給調用者。

整個邏輯比較簡單,但某些缺陷可能會導致嚴重的問題。

併發更新

當多個調用者同時miss相同的鍵時,它們會嘗試構建數據,這可能會導致死鎖或因爲緩存踩踏導致資源耗盡。此外如果調用者嘗試構建值,則會造成額外的延遲。

如果某些構建失敗,即使緩存中可能存在有效的值,此時父調用者也會失敗。

image

可以使用低cardinality和高group來模擬上述問題:

go run ./cmd/cplt --cardinality 100 --group 1000 --live-ui --duration 10h --rate-limit 5000 curl --concurrency 150 -X 'GET'   'http://127.0.0.1:8008/hello?name=World&locale=ru-RU'   -H 'accept: application/json'
image

上圖展示了使用naive緩存的應用,藍色標誌標識重啓並使用advanced緩存。可以看到鎖嚴重影響了性能(Incoming Request Latency)和資源使用(DB Operation Rate)。

一種解決方案是阻塞並行構建,這樣每次只能進行一個構建。但如果有大量併發調用者請求各種鍵,則可能會導致嚴重的鎖競爭。

更好的方式是對每個鍵的構建單獨加鎖,這樣某個調用者就可以獲取鎖並執行構建,其他調用者則等待構建好的值即可。

image

後臺更新

當緩存過期時,需要一個新的值,構建新值可能會比較慢。如果同步進行,則可以減慢尾部延遲(99%以上)。可以提前構建那些被高度需要的緩存項(甚至在數據過期前)。如果可以容忍老數據,也可以繼續使用這些數據。

這種場景下,可以使用老的/即將過期的數據提供服務,並在後臺進行更新。需要注意的是,如果構建依賴父上下文,則在使用完老數據之後可能會取消上下文(如滿足父HTTP請求),如果我們使用這類上下文來訪問數據,則會得到一個context canceled錯誤。

解決方案是將上下文與父上下文進行分離,並忽略父上下文的取消行爲。

另外一種策略是主動構建那些即將過期的緩存項,而無需父請求,但這樣可能會因爲一直淘汰那些無人關心的緩存項而導致資源浪費。

同步過期

假設啓動了一個使用TTL緩存的實例,由於此時緩存是空的,所有請求都會導致緩存miss並創建值。這樣會導致數據源負載突增,每個保存的緩存項的過期時間都非常接近。一旦超過TTL,大部分緩存項幾乎會同步過期,這樣會導致一個新的負載突增,更新後的值也會有一個非常接近的過期時間,以此往復。

這種問題常見於熱點緩存項,最終這些緩存項會同步更新,但需要花費一段時間。

對這種問題的解決辦法是在過期時間上加抖動。

如果過期抖動爲10%,意味着,過期時間爲0.95 * TTL1.05 * TTL。雖然這種抖動幅度比較小,但也可以幫助降低同步過期帶來的問題。

下面例子中,使用高cardinality 和高concurrency模擬這種情況。它會在短時間內請求大量表項,以此構造過期峯值。

go run ./cmd/cplt --cardinality 10000 --group 1 --live-ui --duration 10h --rate-limit 5000 curl --concurrency 200 -X 'GET' 'http://127.0.0.1:8008/hello?name=World&locale=ru-RU' -H 'accept: application/json'
image

從上圖可以看出,使用naive緩存無法避免同步過期問題,藍色標識符表示重啓服務並使用帶10%抖動的advanced緩存,可以看到降低了峯值,且整體服務更加穩定。

緩存錯誤

當構建值失敗,最簡單的方式就是將錯誤返回給調用者即可,但這種方式可能會導致嚴重的問題。

例如,當服務正常工作時可以藉助緩存處理10K的RPS,但突然出現緩存構建失敗(可能由於短時間內數據庫過載、網絡問題或如錯誤校驗等邏輯錯誤),此時所有的10K RPS都會命中數據源(因爲此時沒有緩存)。

對於高負載系統,使用較短的TTL來緩存錯誤至關重要。

故障轉移模式

有時使用過期的數據要好於直接返回錯誤,特別是當這些數據剛剛過期,這類數據有很大概率等於後續更新的數據。

故障轉移以精確性來換取彈性,通常是分佈式系統中的一種折衷方式。

緩存傳輸

緩存有相關的數據時效果最好。

當啓動一個新的實例時,緩存是空的。由於產生有用的數據需要花費一定的時間,因此這段時間內,緩存效率會大大降低。

有一些方式可以解決"冷"緩存帶來的問題。如可以通過遍歷數據來預熱那些可能有用的數據。

例如可以從數據庫表中拉取最近使用的內容,並將其保存到緩存中。這種方式比較複雜,且並不一定能夠生效。

此外還可以通過定製代碼來決定使用哪些數據並在緩存中重構這些表項。但這樣可能會對數據庫造成一定的壓力。

還可以通過共享緩存實例(如redis或memcached)來規避這種問題,但這也帶來了另一種問題,通過網絡讀取數據要遠慢於從本地緩存讀取數據。此外,網絡帶寬也可能成爲性能瓶頸,網絡數據的編解碼也增加了延遲和資源損耗。

最簡單的辦法是將緩存從活動的實例傳輸到新啓動的實例中。

活動實例緩存的數據具有高度相關性,因爲這些數據是響應真實用戶請求時產生的。

傳輸緩存並不需要重構數據,因此不會濫用數據源。

在生產系統中,通常會並行多個應用實例。在部署過程中,這些實例會被順序重啓,因此總有一個實例是活動的,且具有高質量的緩存。

Go有一個內置的二進制系列化格式encoding/gob,它可以幫助以最小的代價來傳輸數據,缺點是這種方式使用了反射,且需要暴露字段。

使用緩存傳輸的另一個注意事項是不同版本的應用可能有不兼容的數據結構,爲了解決這種問題,需要爲緩存的結構添加指紋,並在不一致時停止傳輸。

下面是一個簡單的實現

// RecursiveTypeHash hashes type of value recursively to ensure structural match.
func recursiveTypeHash(t reflect.Type, h hash.Hash64, met map[reflect.Type]bool) {
    for {
        if t.Kind() != reflect.Ptr {
            break
        }

        t = t.Elem()
    }

    if met[t] {
        return
    }

    met[t] = true

    switch t.Kind() {
    case reflect.Struct:
        for i := 0; i < t.NumField(); i++ {
            f := t.Field(i)

            // Skip unexported field.
            if f.Name != "" && (f.Name[0:1] == strings.ToLower(f.Name[0:1])) {
                continue
            }

            if !f.Anonymous {
                _, _ = h.Write([]byte(f.Name))
            }

            recursiveTypeHash(f.Type, h, met)
        }

    case reflect.Slice, reflect.Array:
        recursiveTypeHash(t.Elem(), h, met)
    case reflect.Map:
        recursiveTypeHash(t.Key(), h, met)
        recursiveTypeHash(t.Elem(), h, met)
    default:
        _, _ = h.Write([]byte(t.String()))
    }
}

可以通過HTTP或其他合適的協議來傳輸緩存數據,本例中使用了HTTP,代碼爲/debug/transfer-cache。注意,緩存可能會包含不應該對外暴露的敏感信息。

在本例中,可以藉助於單個啓用了不同端口的應用程序實例來執行傳輸:

CACHE_TRANSFER_URL=http://127.0.0.1:8008/debug/transfer-cache HTTP_LISTEN_ADDR=127.0.0.1:8009 go run main.go
2022-05-09T02:33:42.871+0200    INFO    cache/http.go:282       cache restored  {"processed": 10000, "elapsed": "12.963942ms", "speed": "39.564084 MB/s", "bytes": 537846}
2022-05-09T02:33:42.874+0200    INFO    brick/http.go:66        starting server, Swagger UI at http://127.0.0.1:8009/docs
2022-05-09T02:34:01.162+0200    INFO    cache/http.go:175       cache dump finished     {"processed": 10000, "elapsed": "12.654621ms", "bytes": 537846, "speed": "40.530944 MB/s", "name": "greetings", "trace.id": "31aeeb8e9e622b3cd3e1aa29fa3334af", "transaction.id": "a0e8d90542325ab4"}
image

上圖中藍色標識標識應用重啓,最後兩條爲緩存傳輸。可以看到性能不受影響,而在沒有緩存傳輸的情況下,會受到嚴重的預熱懲罰。

一個不那麼明顯的好處是,可以將緩存數據傳輸到本地開發機器,用於重現和調試生產環境的問題。

鎖競爭和底層性能

基本每種緩存實現都會使用鍵值映射來支持併發訪問(通常是讀)。

大多數場景下可以忽略底層性能帶來的影響。例如,如果使用內存型緩存來處理HTTP API,使用最簡單的map+mutex就足夠了,這是因爲IO操作所需的時間要遠大於內存操作。記住這一點很重要,以免過早地進行優化以及增加不合理的複雜性。

如果依賴內存型緩存的應用是CPU密集型的,此時鎖競爭可能會影響到整體性能。

爲了避免併發讀寫下的數據衝突,可能會引入鎖競爭。在使用單個互斥鎖的情況下,這種同步可能會限制同一時間內只能進行一個操作,這也意味着多核CPU可能無法發揮作用。

對於以讀爲主的負載,標準的sync.Map 就可以滿足性能要求,但對於以寫爲主的負載,則會降低其性能。有一種比sync.Map性能更高的方式github.com/puzpuzpuz/xsync.Map,它使用了 Cache-Line Hash Table (CLHT)數據結構。

另一種常見的方式是通過map分片的方式(fastcache, bigcache, bool64/cache)來降低鎖競爭,這種方式基於鍵將值分散到不同的桶中,在易用性和性能之間做了折衷。

內存管理

內存是一個有限的資源,因此緩存不能無限增長。

過期的元素需要從緩存中淘汰,這個步驟可以同步執行,也可以在後臺執行。使用後臺回收方式不會阻塞應用本身,且如果將後臺回收進程配置爲延遲迴收的方式時,在需要故障轉移時就可以使用過期的數據。

如果上述淘汰過期數據的方式無法滿足內存回收的要求,可以考慮使用其他淘汰策略。在選擇淘汰策略時需要平衡CPU/內存使用和命中/丟失率。總之,淘汰的目的是爲了在可接受的性能預算內優化命中/丟失率,這也是評估一個淘汰策略時需要注意的指標。

下面是常見的選擇淘汰策略的原則:

  • 最近最少頻率使用(LFU),需要在每次訪問時維護計數器
  • 最近最少使用(LRU),需要在每次訪問時更新元素的時間戳或順序
  • 先進先出(FIFO),一旦創建緩存就可以使用緩存中的數據,比較輕量
  • 隨機元素,性能最佳,不需要任何排序,但精確性最低

上述給出瞭如何選項一個淘汰策略,下一個問題是"何時以及應該淘汰多少元素?"。

對於[]byte緩存來說,該問題比較容易解決,因爲大多數實現中都精確提供了控制內存的方式。

但對於結構體緩存來說就比較棘手了。在應用執行過程中,很難可靠地確定特定結構體對堆內存的影響,GC可能會獲取到這些內存信息,但應用本身則無法獲取。下面兩種獲取結構體內存的指標精確度不高,但可用:

  • 緩存中的元素個數
  • 應用使用的總內存

由於這些指標並不與使用的緩存內存成線性比例,因此不能據此計算需要淘汰的元素。一種比較合適的方式是在觸發淘汰時,淘汰一部分元素(如佔使用內存10%的元素)。

緩存數據的堆影響很大程度上與映射實現有關。可以從下面的性能測試中看到,相比於二進制序列化(未壓縮)的數據,map[string]struct{...}佔用的內存是前者的4倍。

基準測試

下面是保存1M小結構體(struct { int, bool, string })的基準測試,驗證包括10%的讀操作以及0.1%的寫操作。字節緩存通過編解碼結構體來驗證。

goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
name             MB/inuse   time/op (10%) time/op (0.1%)      
sync.Map         192 ± 0%   142ns ± 4%    29.8ns ±10%   // Great for read-heavy workloads.
shardedMap       196 ± 0%   53.3ns ± 3%   28.4ns ±11%   
mutexMap         182 ± 0%   226ns ± 3%    207ns ± 1%    
rwMutexMap       182 ± 0%   233ns ± 2%    67.8ns ± 2%   // RWMutex perf degrades with more writes.
shardedMapOf     181 ± 0%   50.3ns ± 3%   27.3ns ±13%   
ristretto        346 ± 0%   167ns ± 8%    54.1ns ± 4%   // Failed to keep full working set, ~7-15% of the items are evicted.
xsync.Map        380 ± 0%   31.4ns ± 9%   22.0ns ±14%   // Fastest, but a bit hungry for memory.
patrickmn        184 ± 0%   373ns ± 1%    72.6ns ± 5%   
bigcache         340 ± 0%   75.8ns ± 8%   72.9ns ± 3%   // Byte cache.
freecache        333 ± 0%   98.1ns ± 0%   77.8ns ± 2%   // Byte cache.
fastcache       44.9 ± 0%   60.6ns ± 8%   64.1ns ± 5%   // A true champion for memory usage, while having decent performance.

如果實際場景支持序列化,那麼fastcache可以提供最佳的內存使用(fastcache使用動態申請的方式來分配內存)

對於CPU密集型的應用,可以使用xsync.Map

從上述測試可以看出,字節緩存並不一定意味着高效地利用內存,如bigcachefreecache

開發者友好

程序並不會總是按照我們期望的方式允許,複雜的邏輯會導致很多非預期的問題,也很難去定位。不幸的是,緩存使得程序的狀況變得更糟,這也是爲什麼讓緩存更友好變得如此重要。

緩存可能成爲多種問題的誘發因素,因此應該儘快安全地清理相關緩存。爲此,可以考慮對所有緩存的元素進行校驗,在高載情況下,失效不一定意味着“刪除”,一旦一次性刪除所有緩存,數據源可能會因爲過載而失敗。更優雅的方式是爲所有元素設置過期時間,並在後臺進行更新,更新過程中使用老數據提供服務。

如果有人正在調查特定的數據源問題,緩存項可能會因爲過期而誤導用戶。可以禁用特定請求的緩存,這樣就可以排除緩存帶來的不精確性。可以通過特定的請求頭以及並在中間件上下文中實現。注意這類控制並不適用於外部用戶(會導致DOS攻擊)。

總結

本文比較了字節緩存和結構體緩存的優劣勢,介紹了緩存穿透、緩存錯誤、緩存預熱、緩存傳輸、故障轉移、緩存淘汰等問題,並對一些常見的緩存庫進行了基準測試。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章