緩存是計算機(jī)系統(tǒng)中的一種強(qiáng)大技術(shù),從硬件緩存到操作系統(tǒng)、Web瀏覽器,尤其是后端開發(fā)中都有廣泛應(yīng)用。對于像Meta這樣的公司,緩存非常重要,它有助于降低延遲、處理大量工作負(fù)載,并節(jié)省成本。由于Meta的應(yīng)用場景非常緩存密集,這給他們帶來了另一組問題,即緩存失效。
多年來,Meta已將其緩存一致性水平從99.9999(六個九)提高到99.99999999(十個九),這意味著他們的緩存集群中不到十億次寫入中只有不到1次會導(dǎo)致不一致。
本文將重點討論以下幾個主要部分:
根據(jù)定義,緩存不保存數(shù)據(jù)的真實來源,因此在源數(shù)據(jù)發(fā)生更改時,應(yīng)主動使過期的緩存條目失效。如果在失效過程中出現(xiàn)問題,會導(dǎo)致緩存中的值與源數(shù)據(jù)不一致。
那么我們?nèi)绾问咕彺媸?
我們可以使用TTL(生存時間)來保持?jǐn)?shù)據(jù)的新鮮度,以確保沒有其他系統(tǒng)引起的緩存失效。但在本文中,我們將假設(shè)失效操作是由緩存之外的某個組件執(zhí)行的。
首先讓我們看看如何引入緩存不一致性:
請假設(shè)1、2、3、4是遞增序列中的時間戳。
為了解決這個問題,我們可以使用版本字段來執(zhí)行沖突解決,使舊版本永遠(yuǎn)不會覆蓋當(dāng)前版本。這種解決方案對于互聯(lián)網(wǎng)上幾乎99%的公司都有效,但是Meta操作的規(guī)模可能使其不足以解決問題,因為其系統(tǒng)的復(fù)雜性。
從Meta的角度來看,緩存不一致性幾乎與數(shù)據(jù)庫數(shù)據(jù)丟失一樣嚴(yán)重,而從用戶的角度來看,可能會導(dǎo)致非常糟糕的用戶體驗。
當(dāng)您在Instagram上向用戶發(fā)送私信時,在幕后,存在著將用戶映射到存儲其消息的主要存儲的過程。
在這里假設(shè)有三個用戶:Bob、Mary和Alice。這些用戶都向Alice發(fā)送消息。Bob在美國,Alice在歐洲,Mary在日本。因此,系統(tǒng)將在接近用戶所在地區(qū)的最近區(qū)域進(jìn)行查詢,以將消息發(fā)送到Alice的數(shù)據(jù)存儲區(qū)域。在這種情況下,當(dāng)TAO副本在BOB和Mary所在的區(qū)域查詢時,它們都有不一致的數(shù)據(jù),因此它將消息發(fā)送到區(qū)域,該區(qū)域沒有Alice的消息。
在上述情況下,可能會導(dǎo)致消息丟失和糟糕的用戶體驗,因此這是Meta需要解決的重要問題之一。
為了解決緩存失效和緩存一致性問題,第一步是進(jìn)行測量。如果我們能夠準(zhǔn)確測量緩存的一致性,并在緩存中出現(xiàn)不一致的條目時發(fā)出警報,Meta確保他們的測量不包含任何誤報,因為值班工程師會學(xué)會忽略它,這個指標(biāo)將失去信任并變得無用。
在深入探討Meta實施的實際解決方案之前,最簡單的解決方案可能是記錄和跟蹤每個緩存狀態(tài)的變化。但是,對于大型工作負(fù)載的情況,Meta的系統(tǒng)每天處理超過10萬億次的緩存填充。記錄和跟蹤所有緩存狀態(tài)將會使本來已經(jīng)很重的緩存工作負(fù)載變得極其繁重,更不用說調(diào)試了。
Polaris在非常高的層面上,作為客戶端與一個有狀態(tài)服務(wù)進(jìn)行交互,并且假設(shè)沒有對服務(wù)內(nèi)部的了解。Polaris的工作原理是“緩存應(yīng)該最終與數(shù)據(jù)庫一致”。Polaris接收失效事件并查詢所有副本,以驗證是否存在任何其他違反約束的情況。例如:
如果Polaris接收到一個失效事件,表示 x=4,版本為4,它會作為客戶端檢查所有緩存副本,以驗證是否存在任何不變量的違反情況。如果一個副本返回 x=3 @ 版本3,Polaris會將其標(biāo)記為不一致,并重新排隊以稍后對其進(jìn)行相同目標(biāo)緩存主機(jī)的檢查。Polaris會在一分鐘、五分鐘或十分鐘的時間范圍內(nèi)報告不一致性。
這種多時間尺度設(shè)計不僅允許Polaris在內(nèi)部具有多個隊列來有效地實現(xiàn)退避和重試,而且對于防止產(chǎn)生誤報至關(guān)重要。
讓我們通過一個例子來理解:
假設(shè)Polaris接收到一個失效事件,表示 x=4,版本為4。但是當(dāng)Polaris檢查緩存時,找不到鍵 x 的條目,這應(yīng)該被標(biāo)記為不一致。在這種情況下,有兩種可能性:
現(xiàn)在,我們?nèi)绾未_保這兩種情況中的哪一種是正確的?
為了驗證,在這兩種情況中,Polaris需要通過查詢數(shù)據(jù)庫來檢查。繞過緩存的查詢可能需要大量計算資源,并且可能會使數(shù)據(jù)庫面臨風(fēng)險,因為保護(hù)數(shù)據(jù)庫和擴(kuò)展讀取重負(fù)載是緩存的兩個最常見用例。因此,我們不能向系統(tǒng)發(fā)送太多查詢。
Polaris通過延遲執(zhí)行此類檢查并直到不一致樣本超過設(shè)置的閾值(例如1分鐘或5分鐘)時才對數(shù)據(jù)庫進(jìn)行調(diào)用來解決此問題。Polaris生成的指標(biāo)是“M分鐘內(nèi)緩存寫入的 N 個九的一致性”。因此,目前Polaris提供了一個指標(biāo),即緩存在五分鐘的時間尺度上的一致性達(dá)到99.99999999。
現(xiàn)在讓我們看看Polaris如何幫助Meta使用編碼示例解決Bug。
讓我們通過一個編碼示例來理解流程:
假設(shè)一個緩存維護(hù)一個鍵到元數(shù)據(jù)映射和鍵到版本映射。
cache_data = {}cache_version = {}meta_data_table = {"1": 42}version_table = {"1": 4}def read_value(key): value = read_value_from_cache(key) if value is not None: return value else: return meta_data_table[key]def read_value_from_cache(key): if key in cache_data: return cache_data[key] else: fill_cache_thread = threading.Thread(target=fill_cache(key)) fill_cache_thread.start() return Nonedef fill_cache(key): fill_cache_metadata(key) fill_cache_version(key)def fill_cache_metadata(key): meta_data = meta_data_table[key] print("Filling cache meta data for", meta_data) cache_data[key] = meta_datadef fill_cache_version(key): time.sleep(2) version = version_table[key] print("Filling cache version data for", version) cache_version[key] = versiondef write_value(key, value): version = 1 if key in version_table: version = version_table[key] version = version + 1 write_in_databse_transactionally(key, value, version) time.sleep(3) invalidate_cache(key, value, version)def write_in_databse_transactionally(key, data, version): meta_data_table[key] = data version_table[key] = versiondef invalidate_cache(key, metadata, version): try: cache_data = cache_data[key][value] ## To produce error except: drop_cache(key, version)def drop_cache(key, version): cache_version_value = cache_version[key] if version > cache_version_value: cache_data.pop(key) cache_version.pop(key)read_thread = threading.Thread(target=read_value, args=("1"))write_thread = threading.Thread(target=write_value, args=("1",43))print_thread = threading.Thread(target=print_values)
在緩存失效過程中,如果由于某種原因?qū)е率Р僮魇。⑶耶惓L幚沓绦蚓哂性谶@種情況下刪除緩存的條件。
請記住,這只是可能觸發(fā)Bug的非常簡化的示例,實際的Bug還涉及數(shù)據(jù)庫復(fù)制和跨區(qū)域通信。該Bug只有在以上所有步驟按特定順序發(fā)生時才會觸發(fā)。該Bug隱藏在交錯操作和瞬態(tài)錯誤背后的錯誤處理代碼中。
現(xiàn)在您是值班工程師,收到了Polaris的緩存不一致性警報,最重要的是檢查日志以確定問題可能出現(xiàn)在哪里。正如之前討論的,記錄每個緩存數(shù)據(jù)更改幾乎是不可能的,但是如果我們只記錄有可能導(dǎo)致更改的數(shù)據(jù)呢?
得不一致?
Meta構(gòu)建了一個有狀態(tài)追蹤庫,在這個小窗口中記錄和跟蹤緩存變異,所有有趣和復(fù)雜的交互觸發(fā)導(dǎo)致緩存不一致性的Bug。
對于任何分布式系統(tǒng)來說,可靠的監(jiān)控和日志系統(tǒng)至關(guān)重要,以確保我們能夠捕獲Bug,一旦捕獲到Bug,我們就能夠快速找到根本原因,從而減輕問題。借鑒Meta的例子,Polaris識別出了異常并立即觸發(fā)了警報。有了一致性追蹤的信息,值班工程師們不到30分鐘就找到了Bug的位置。
參考鏈接:https://engineering.fb.com/2022/06/08/core-infra/cache-made-consistent/
本文鏈接:http://www.tebozhan.com/showinfo-26-84717-0.htmlMeta如何將其緩存一致性提高至99.99999999
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。郵件:2376512515@qq.com
上一篇: 關(guān)于TypeScript中的泛型,希望這篇文章能讓你徹底理解泛型
下一篇: C# 12 中新增的幾大功能你都知道嗎?