簡介

緩存是計(jì)算機(jī)系統(tǒng)中的一種強(qiáng)大技術(shù)，從硬件緩存到操作系統(tǒng)、Web瀏覽器，尤其是后端開發(fā)中都有廣泛應(yīng)用。對(duì)于像Meta這樣的公司，緩存非常重要，它有助于降低延遲、處理大量工作負(fù)載，并節(jié)省成本。由于Meta的應(yīng)用場景非常緩存密集，這給他們帶來了另一組問題，即緩存失效。

多年來，Meta已將其緩存一致性水平從99.9999(六個(gè)九)提高到99.99999999(十個(gè)九)，這意味著他們的緩存集群中不到十億次寫入中只有不到1次會(huì)導(dǎo)致不一致。

本文將重點(diǎn)討論以下幾個(gè)主要部分：

• 緩存失效和緩存一致性是什么?
• Meta為什么如此深刻關(guān)注緩存一致性，即使六個(gè)九還不夠?
• Meta的監(jiān)控系統(tǒng)如何幫助他們改善緩存失效和緩存一致性，并解決Bug。

緩存失效和緩存一致性

根據(jù)定義，緩存不保存數(shù)據(jù)的真實(shí)來源，因此在源數(shù)據(jù)發(fā)生更改時(shí)，應(yīng)主動(dòng)使過期的緩存條目失效。如果在失效過程中出現(xiàn)問題，會(huì)導(dǎo)致緩存中的值與源數(shù)據(jù)不一致。

那么我們?nèi)绾问咕彺媸?

我們可以使用TTL(生存時(shí)間)來保持?jǐn)?shù)據(jù)的新鮮度，以確保沒有其他系統(tǒng)引起的緩存失效。但在本文中，我們將假設(shè)失效操作是由緩存之外的某個(gè)組件執(zhí)行的。

首先讓我們看看如何引入緩存不一致性：

請假設(shè)1、2、3、4是遞增序列中的時(shí)間戳。

• 緩存首先嘗試從數(shù)據(jù)庫獲取值。
• 但在值 x=42 到達(dá)緩存之前，某個(gè)操作更新了數(shù)據(jù)庫中的值為 x=43。
• 數(shù)據(jù)庫發(fā)送了 x=43 的緩存失效事件，并在 x=42 到達(dá)之前到達(dá)緩存，將緩存值設(shè)置為43。
• 現(xiàn)在事件 x=42 到達(dá)緩存，將緩存設(shè)置為42，從而引入了不一致性。

為了解決這個(gè)問題，我們可以使用版本字段來執(zhí)行沖突解決，使舊版本永遠(yuǎn)不會(huì)覆蓋當(dāng)前版本。這種解決方案對(duì)于互聯(lián)網(wǎng)上幾乎99%的公司都有效，但是Meta操作的規(guī)?？赡苁蛊洳蛔阋越鉀Q問題，因?yàn)槠湎到y(tǒng)的復(fù)雜性。

為什么Meta如此關(guān)注緩存一致性?

從Meta的角度來看，緩存不一致性幾乎與數(shù)據(jù)庫數(shù)據(jù)丟失一樣嚴(yán)重，而從用戶的角度來看，可能會(huì)導(dǎo)致非常糟糕的用戶體驗(yàn)。

當(dāng)您在Instagram上向用戶發(fā)送私信時(shí)，在幕后，存在著將用戶映射到存儲(chǔ)其消息的主要存儲(chǔ)的過程。

在這里假設(shè)有三個(gè)用戶：Bob、Mary和Alice。這些用戶都向Alice發(fā)送消息。Bob在美國，Alice在歐洲，Mary在日本。因此，系統(tǒng)將在接近用戶所在地區(qū)的最近區(qū)域進(jìn)行查詢，以將消息發(fā)送到Alice的數(shù)據(jù)存儲(chǔ)區(qū)域。在這種情況下，當(dāng)TAO副本在BOB和Mary所在的區(qū)域查詢時(shí)，它們都有不一致的數(shù)據(jù)，因此它將消息發(fā)送到區(qū)域，該區(qū)域沒有Alice的消息。

在上述情況下，可能會(huì)導(dǎo)致消息丟失和糟糕的用戶體驗(yàn)，因此這是Meta需要解決的重要問題之一。

監(jiān)控

為了解決緩存失效和緩存一致性問題，第一步是進(jìn)行測量。如果我們能夠準(zhǔn)確測量緩存的一致性，并在緩存中出現(xiàn)不一致的條目時(shí)發(fā)出警報(bào)，Meta確保他們的測量不包含任何誤報(bào)，因?yàn)橹蛋喙こ處煏?huì)學(xué)會(huì)忽略它，這個(gè)指標(biāo)將失去信任并變得無用。

在深入探討Meta實(shí)施的實(shí)際解決方案之前，最簡單的解決方案可能是記錄和跟蹤每個(gè)緩存狀態(tài)的變化。但是，對(duì)于大型工作負(fù)載的情況，Meta的系統(tǒng)每天處理超過10萬億次的緩存填充。記錄和跟蹤所有緩存狀態(tài)將會(huì)使本來已經(jīng)很重的緩存工作負(fù)載變得極其繁重，更不用說調(diào)試了。

Polaris

Polaris在非常高的層面上，作為客戶端與一個(gè)有狀態(tài)服務(wù)進(jìn)行交互，并且假設(shè)沒有對(duì)服務(wù)內(nèi)部的了解。Polaris的工作原理是“緩存應(yīng)該最終與數(shù)據(jù)庫一致”。Polaris接收失效事件并查詢所有副本，以驗(yàn)證是否存在任何其他違反約束的情況。例如：

如果Polaris接收到一個(gè)失效事件，表示 x=4，版本為4，它會(huì)作為客戶端檢查所有緩存副本，以驗(yàn)證是否存在任何不變量的違反情況。如果一個(gè)副本返回 x=3 @ 版本3，Polaris會(huì)將其標(biāo)記為不一致，并重新排隊(duì)以稍后對(duì)其進(jìn)行相同目標(biāo)緩存主機(jī)的檢查。Polaris會(huì)在一分鐘、五分鐘或十分鐘的時(shí)間范圍內(nèi)報(bào)告不一致性。

這種多時(shí)間尺度設(shè)計(jì)不僅允許Polaris在內(nèi)部具有多個(gè)隊(duì)列來有效地實(shí)現(xiàn)退避和重試，而且對(duì)于防止產(chǎn)生誤報(bào)至關(guān)重要。

讓我們通過一個(gè)例子來理解：

假設(shè)Polaris接收到一個(gè)失效事件，表示 x=4，版本為4。但是當(dāng)Polaris檢查緩存時(shí)，找不到鍵 x 的條目，這應(yīng)該被標(biāo)記為不一致。在這種情況下，有兩種可能性：

• 在版本3時(shí) x 是不可見的，但版本4的寫入是密鑰的最新寫入，并且確實(shí)存在緩存不一致性。
• 可能存在版本5的寫入刪除了鍵 x，也許Polaris只是看到了比失效事件中的更近期的數(shù)據(jù)視圖。

現(xiàn)在，我們?nèi)绾未_保這兩種情況中的哪一種是正確的?

為了驗(yàn)證，在這兩種情況中，Polaris需要通過查詢數(shù)據(jù)庫來檢查。繞過緩存的查詢可能需要大量計(jì)算資源，并且可能會(huì)使數(shù)據(jù)庫面臨風(fēng)險(xiǎn)，因?yàn)楸Ｗo(hù)數(shù)據(jù)庫和擴(kuò)展讀取重負(fù)載是緩存的兩個(gè)最常見用例。因此，我們不能向系統(tǒng)發(fā)送太多查詢。

Polaris通過延遲執(zhí)行此類檢查并直到不一致樣本超過設(shè)置的閾值(例如1分鐘或5分鐘)時(shí)才對(duì)數(shù)據(jù)庫進(jìn)行調(diào)用來解決此問題。Polaris生成的指標(biāo)是“M分鐘內(nèi)緩存寫入的 N 個(gè)九的一致性”。因此，目前Polaris提供了一個(gè)指標(biāo)，即緩存在五分鐘的時(shí)間尺度上的一致性達(dá)到99.99999999。

現(xiàn)在讓我們看看Polaris如何幫助Meta使用編碼示例解決Bug。

讓我們通過一個(gè)編碼示例來理解流程：

假設(shè)一個(gè)緩存維護(hù)一個(gè)鍵到元數(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 None

def 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_data

def fill_cache_version(key):
    time.sleep(2)
    version = version_table[key]
    print("Filling cache version data for", version)
    cache_version[key] = version

def 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] = version

def 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ū)е率Р僮魇?，并且異常處理程序具有在這種情況下刪除緩存的條件。

請記住，這只是可能觸發(fā)Bug的非常簡化的示例，實(shí)際的Bug還涉及數(shù)據(jù)庫復(fù)制和跨區(qū)域通信。該Bug只有在以上所有步驟按特定順序發(fā)生時(shí)才會(huì)觸發(fā)。該Bug隱藏在交錯(cuò)操作和瞬態(tài)錯(cuò)誤背后的錯(cuò)誤處理代碼中。

一致性追蹤

現(xiàn)在您是值班工程師，收到了Polaris的緩存不一致性警報(bào)，最重要的是檢查日志以確定問題可能出現(xiàn)在哪里。正如之前討論的，記錄每個(gè)緩存數(shù)據(jù)更改幾乎是不可能的，但是如果我們只記錄有可能導(dǎo)致更改的數(shù)據(jù)呢?

• 如果我們看一下上面實(shí)現(xiàn)的代碼，問題可能在于如果緩存未收到失效事件或失效操作未生效。從值班工程師的角度來看，我們需要檢查以下內(nèi)容：
• 緩存服務(wù)器是否接收到了失效操作?
• 服務(wù)器是否正確處理了失效操作?
• 項(xiàng)目是否在此后變

得不一致?

Meta構(gòu)建了一個(gè)有狀態(tài)追蹤庫，在這個(gè)小窗口中記錄和跟蹤緩存變異，所有有趣和復(fù)雜的交互觸發(fā)導(dǎo)致緩存不一致性的Bug。

結(jié)論

對(duì)于任何分布式系統(tǒng)來說，可靠的監(jiān)控和日志系統(tǒng)至關(guān)重要，以確保我們能夠捕獲Bug，一旦捕獲到Bug，我們就能夠快速找到根本原因，從而減輕問題。借鑒Meta的例子，Polaris識(shí)別出了異常并立即觸發(fā)了警報(bào)。有了一致性追蹤的信息，值班工程師們不到30分鐘就找到了Bug的位置。

參考鏈接：https://engineering.fb.com/2022/06/08/core-infra/cache-made-consistent/