今天我們來深入聊一聊 Facebook 是如何將一個簡單的開源緩存軟件 memcached，打造成一個能夠支撐起全球最大社交網絡、每秒處理數十億次請求的分布式緩存系統的。

我們會沿著 Facebook 的擴展之路，從單個集群內的優化，到跨集群、跨地區的擴展，逐步揭開其架構設計的精妙之處。

為什么要用 Memcache？基礎架構概覽

在開始之前，我們先解決一個基本問題：Facebook 為什么不直接從數據庫（比如 MySQL）讀取數據，而要費這么大勁去構建一個緩存系統？

答案很簡單： 快 。對于 Facebook 這種讀多寫少（read-heavy）的業務場景，用戶的動態、評論、好友列表等信息被瀏覽的次數遠超被創建的次數。如果每次讀取都請求數據庫，MySQL 完全扛不住如此巨大的讀取壓力。而 memcached 是一個完全基于內存的鍵值存儲（key-value store），速度比基于磁盤的數據庫快幾個數量級。

核心架構：旁路緩存（Look-Aside Cache）

Facebook 使用 memcache 的模式非常經典，稱為 旁路緩存 。流程如下：

1. 讀（Read） ：Web 服務器需要數據時，首先會帶著一個 key 去 memcache 里查找。

• 緩存命中 (Cache Hit) ：直接拿到數據，返回給用戶。
• 緩存未命中 (Cache Miss) ：服務器會去后端數據庫（或其他服務）查詢，拿到數據后，一方面返回給用戶，另一方面把這份數據用 set(key, value) 的方式寫回 memcache，方便下次讀取。

2. 寫（Write） ：當數據發生變更時，Web 服務器會先更新數據庫。為了保證緩存數據的一致性，它并 不是 去更新 memcache 里的值，而是直接向 memcache 發送一個 delete(key) 命令，將舊的緩存數據刪除。

為什么寫操作是 delete 而不是 update？

論文中提到，因為 delete 是 冪等 (idempotent) 的。簡單說，重復執行多次 delete 和執行一次的效果是一樣的，這在復雜的網絡環境中能簡化系統設計，避免因重試等機制導致數據錯亂。而如果兩個 update 請求因為網絡延遲亂序到達，就可能導致緩存中存儲的是一個舊版本的數據。

（上面可能面臨陳舊數據寫入/臟數據的問題，解決方案參考下文“減少負載：租約 (Leases) 的妙用”）

另外，需要明確兩個術語：

• memcached：指開源的、單機版的緩存軟件本身。
• memcache：在本文中，特指 Facebook 基于 memcached 構建的整個分布式緩存系統。

Memcached 與 Redis：現代緩存技術選型

我們來解決一個非常實際的工程問題：memcached 在今天用得還多嗎？它和現在非常流行的 Redis 相比，我們應該如何選擇？

首先，memcached 本身是一個單機的內存緩存程序。我們常說的“部署一個 memcached 集群”，實際上是指通過客戶端的路由邏輯（或像 mcrouter 這樣的代理），將不同的 key 分發到不同的 memcached 實例上，從而在邏輯上構成一個分布式系統。

在今天的技術選型中，Redis 因其豐富的功能和靈活性，在很多場景下已經成為首選。但 memcached 憑借其極致的簡潔和性能，依然在特定領域（尤其是需要大規模、低延遲純緩存的場景）擁有一席之地。它們的對比可以總結如下：

選型建議：

• 選擇 Memcached ：如果你的需求非常純粹，就是一個高速、高并發、分布式的鍵值緩存，且不需要復雜的數據結構和持久化。它的簡潔性和多線程帶來的高吞吐在某些大規模場景下是巨大優勢。
• 選擇 Redis ：絕大多數場景下的更優選擇。如果你需要使用哈希、列表等數據結構，或者需要消息隊列、排行榜（有序集合）、分布式鎖等功能，Redis 提供了開箱即用的解決方案。

集群之內：攻克延遲與負載

當服務器規模擴展到數千臺時，即便都在一個數據中心內，也會遇到巨大的挑戰。Facebook 的優化主要集中在兩個方面：降低訪問延遲和減少緩存未命中帶來的負載。

降低延遲：解決全連接與 Incast 擁塞

在一個集群中，一臺 Web 服務器為了響應單次用戶請求，可能需要與成百上千臺 memcached 服務器通信，這被稱為“ 全連接 (all-to-all) ”的通信模式。這種模式極易引發網絡擁堵，尤其是 Incast 擁塞（當大量服務器同時向一個目標發送數據時，會導致交換機緩沖區溢出而大量丟包）。

Facebook 的解決方案是從客戶端和服務端兩方面入手：

客戶端并行與批量請求

Web 服務器的客戶端庫會將一次頁面請求所需的所有數據依賴關系構建成一個有向無環圖（DAG），從而最大限度地并行發起請求 。同時，它會將多個 key 的請求合并成一個批量請求（batched request），平均一次會打包 24 個 key 。

這里提到的 DAG（有向無環圖），它并 不是 由緩存系統自動生成的，而是 由應用程序的業務邏輯定義的 。

舉個例子，渲染一個用戶個人主頁，可能需要以下數據：

1. 用戶基本信息（user_info）
2. 用戶的好友列表（friend_list）
3. 用戶的最新動態（latest_posts）

這三者都依賴于 user_id。一旦獲取到 user_id，這三份數據之間沒有依賴關系，可以并行去獲取。應用框架會根據代碼中聲明的這種依賴關系，構建出一個 DAG，然后調度 memcache 客戶端盡可能地并行執行獨立的請求分支，同時將同一分支上的多個請求打包，從而最小化網絡往返次數和等待時間。

協議選擇與連接優化

• 對于 get 請求，使用 UDP 協議。UDP 無連接的特性減少了建立和維護 TCP 連接的開銷，從而降低了延遲。雖然 UDP 不可靠，但 Facebook 的網絡設施質量很高，實踐中只有約 0.25% 的 get 請求被丟棄，客戶端直接將這些視為緩存未命中即可。
• 對于 set 和 delete 這類必須保證可靠性的操作，則通過 TCP 完成。為了避免海量 Web 線程與 memcached 服務器建立過多 TCP 連接，他們引入了一個名為 mcrouter 的代理進程。mcrouter 部署在 Web 服務器本地，負責將來自多個線程的 TCP 請求聚合起來，再統一轉發給 memcached 服務器，極大地減少了連接數和服務器資源消耗。

客戶端流量控制

為了解決 Incast 擁塞，客戶端實現了一個滑動窗口（sliding window）機制來控制未完成的請求數量。當窗口過小，請求串行化會增加延遲；當窗口過大，則會引發網絡擁堵和丟包。通過動態調整窗口大小，可以在兩者之間找到一個平衡點。

減少負載：租約 (Leases) 的妙用

緩存未命中會給后端數據庫帶來巨大壓力。Facebook 引入了一種非常巧妙的機制—— 租約 (Leases) ，它一舉解決了兩個老大難問題： 陳舊數據寫入（stale sets）和驚群效應（thundering herds） 。

問題一：陳舊數據寫入 (Stale Sets)

想象這個場景：

1. 客戶端 C1 請求 key，緩存未命中。
2. C1 去數據庫查詢，得到 value=1。但此時 C1 因為某些原因卡頓了一下。
3. 在此期間，另一個用戶更新了數據，數據庫中 key 的值變為 2，并刪除了緩存。
4. 客戶端 C2 也請求 key，緩存未命中，從數據庫拿到 value=2，并成功寫入緩存。
5. 卡頓的 C1 終于恢復，將它持有的舊數據 value=1 寫入了緩存，覆蓋了新數據。

此時，緩存中就存在了一個臟數據。

問題二：驚群效應 (Thundering Herds)/緩存雪崩

當一個熱點 key（比如首頁上的熱門新聞）突然失效（被更新或刪除），成千上萬的請求會同時穿透緩存，打到數據庫上，可能瞬間壓垮數據庫。

租約的解決方案

租約是 memcached 在處理緩存未命中時，返回給客戶端的一個 64 位 令牌 (token) 。

解決 Stale Sets

客戶端在 set 數據時必須帶上這個租約令牌。memcached 會驗證令牌的有效性。在上面的例子中，當數據被更新時，memcached 會將與該 key 相關的租約（C1 持有的）標記為無效。因此，當 C1 帶著過期的租約來寫緩存時，請求會被直接拒絕，從而保證了緩存不會被舊數據污染。這類似于一種 樂觀鎖 或 load-link/store-conditional 操作。

解決 Thundering Herds

memcached 服務器會對租約的發放進行 速率限制 ，例如，針對同一個 key，10 秒內只發放一個租約。這樣，當熱點 key 失效時，只有第一個請求的客戶端能拿到租約并去查詢數據庫。其他客戶端在 10 秒內再次請求時，會收到一個特殊通知，告訴它們“稍等片刻再試”。通常，第一個客戶端在毫秒級時間內就能把新數據寫回緩存。后續的客戶端重試時，就能直接命中緩存了。通過這種方式，原本成千上萬的數據庫請求被縮減到只有一次，效果極其顯著。

故障處理：Gutter 服務器

如果一臺 memcached 服務器宕機，所有指向它的請求都會失敗，這同樣會形成一股流量洪峰沖擊數據庫。

如何處理緩存節點宕機？

一個常見的想法是將宕機節點上的 key 通過哈希算法重新分布到其他健康的節點上。但 Facebook 指出這是 危險的 ，因為如果某個 key 是熱點 key，它可能會將大量請求帶到新的節點上，導致該節點也被壓垮，從而引發 級聯故障 (cascading failures) 。

Facebook 的方案是設立一個專門的、小規模的服務器池，叫做 Gutter 。這些服務器平時基本是空閑的。當客戶端訪問一臺 memcached 服務器超時后，它不會重新哈希，而是會把請求重試到 Gutter 服務器上。Gutter 作為一個臨時的緩存替代品，接管了失效服務器的負載，從而保護了后端數據庫。Gutter 中緩存項的過期時間很短，以避免數據一致性問題。

這引出了另一個問題：為什么 Gutter 服務器要保持空閑，而不是也用來提供普通服務？因為當一臺服務器故障時，接替它的 Gutter 服務器需要擁有足夠的、未被占用的處理能力來承接前者的全部負載。

區域之內：跨集群復制

隨著業務增長，單個集群的規模總有上限。Facebook 將一個數據中心劃分為多個 前端集群 (frontend clusters) ，它們共享一個 存儲集群 (storage cluster) （即數據庫）。這個整體被稱為一個 區域 (region) 。

這種架構下，最大的挑戰是如何處理跨集群的數據復制和一致性問題。

區域性失效 (Regional Invalidations)

由于每個前端集群都有自己獨立的 memcache，一份數據可能被緩存在多個集群中。當數據庫中的數據更新時，必須通知所有集群刪除對應的舊緩存。

這個任務由一個叫 mcsqueal 的守護進程完成。它部署在數據庫服務器上，通過實時監控數據庫的提交日志（binlog），來捕獲數據變更操作。一旦捕獲到變更，mcsqueal 就會解析出需要失效的 memcache key，然后將刪除請求廣播給該區域內所有前端集群的 memcache 。

這種基于 變更數據捕獲 (Change Data Capture, CDC) 的異步失效模式，比讓 Web 服務器直接廣播失效請求更可靠、更高效，因為它能更好地批量處理請求，并且基于可靠的數據庫日志，可以重放丟失的失效消息。

區域性失效：mcsqueal 的可靠之道

mcsqueal 詳細機制：基于 變更數據捕獲 (Change Data Capture, CDC) 的系統是保證跨集群緩存一致性的基石，其流程遠比 Web 服務器直接發 delete 請求要精妙和可靠。

詳細流程如下：

1. 修改數據庫事務 ：當 Web 服務器要更新數據時，它發給數據庫的事務不僅僅是 UPDATE 或 INSERT 語句。它還會附加元數據，明確指出這個數據庫變更會影響到哪些 memcache 的 key 。
2. 寫入可靠日志 ：數據庫執行事務，并將數據變更和這些需要失效的 key 一同記錄到其高可靠的提交日志中（例如 MySQL 的 binlog）。這是最關鍵的一步，因為日志是持久化且有序的。
3. mcsqueal 監控與解析 ：mcsqueal 守護進程像一個忠實的哨兵，持續不斷地監控（tail）數據庫的提交日志。當它讀到新的變更記錄時，就會從中解析出那些需要被刪除的 key。
4. 廣播與中繼 ：mcsqueal 將提取出的刪除請求，批量打包后，廣播給區域內所有前端集群。這些請求并非直接打到 memcached 服務器上，而是先發送給每個集群中專門負責中繼的 mcrouter 實例。
5. mcrouter 精準投遞 ：mcrouter 收到批量包后，將其解開，并根據每個 key 的哈希值，將刪除命令精準地路由到該 key 所在的具體 memcached 服務器上。

這套機制的核心優勢在于 可靠性 和 效率 。因為失效指令記錄在數據庫的持久化日志里，即使中途 mcsqueal 進程崩潰或者網絡中斷，恢復后只需從上次中斷的位置繼續讀取日志即可，保證了失效消息“ 不丟不重 ” 。同時，高效的批量處理也極大地降低了網絡開銷。

冷集群預熱 (Cold Cluster Warmup)

當一個新的前端集群上線，或者一個集群因維護重啟時，它的緩存是空的（稱為“冷集群”），此時所有請求都會穿透到數據庫，造成巨大沖擊。

為了解決這個問題，Facebook 設計了 冷集群預熱 機制。簡單來說，就是讓冷集群里的客戶端在緩存未命中時，不去請求數據庫，而是去請求一個緩存數據齊全的“熱集群”的 memcache 。這相當于用其他集群的緩存來幫助新集群“預熱”。為了處理這期間可能發生的競爭問題（例如，數據剛在熱集群被更新，冷集群就來讀取舊數據），他們在向冷集群發送 delete 命令時，會附加一個短暫的“ 拒絕寫入 ”時間（如 2 秒）。這能有效防止臟數據被寫入冷集群的緩存中。

當一個新集群（冷集群）上線時，讓它從一個已有集群（熱集群）的緩存中拉取數據預熱，是一個非常聰明的辦法。但如何處理競爭問題，以及 2 秒的“拒絕寫入”時間是怎么回事？

預熱機制與競爭問題

預熱的基本流程是：冷集群的客戶端在緩存未命中后，會向熱集群發送 get 請求，拿到數據后再嘗試 add 到本地緩存中。

這里的競爭在于：在冷集群客戶端從“獲取數據”到“寫入本地緩存”的這個時間窗口內，原始數據可能已經被更新了。此時，失效消息會同時發往熱集群和冷集群。如果冷集群的客戶端動作不夠快，就可能把已經過期的舊數據寫入本地緩存。

“拒絕寫入”的妙用

為了解決這個問題，Facebook 對 delete 命令做了擴展。發往冷集群的失效刪除命令，會附帶一個參數，即 拒絕寫入期 (hold-off time) ，默認為 2 秒。

當冷集群的 memcached 服務器收到這樣一條命令后，它會：

1. 刪除指定的 key。
2. 在該 key 上設置一個 臨時鎖 ，在接下來的 2 秒內， 拒絕 所有針對這個 key 的 add 或 set 操作。

現在我們再看預熱流程：當冷集群客戶端帶著從熱集群取回的舊數據嘗試 add 到本地時，如果一個失效消息剛剛到達，這個 add 操作就會因為這個 2 秒的鎖而 失敗 。

這個失敗是一個非常重要的信號，它告訴客戶端：“你手上的數據已經舊了！” 客戶端捕獲到這個失敗后，就會放棄這次預熱操作，轉而直接從權威數據源——數據庫——去獲取最新的數據。

為什么是 2 秒？如果延遲更長怎么辦？

• 為什么是 2 秒？ 這是一個基于海量實踐數據得出的 工程經驗值 (heuristic) 。2 秒被認為足以覆蓋絕大多數情況下，失效消息在數據中心內部網絡中的傳播和處理延遲。
• 如果延遲超過 2 秒呢？ 論文坦誠地承認，這種情況理論上是可能發生的。如果一條失效消息因為極端網絡擁堵等原因，延遲超過了 2 秒才到達，那么一個 stale 的值的確可能被成功寫入緩存。

但這正是 Facebook 架構哲學的一個完美體現：他們愿意接受這種極小概率的、短暫的數據不一致，來換取 巨大的運維收益 ——將一個集群的預熱時間從幾天縮短到幾小時。這是一種在“一致性”和“可用性/性能”之間做出的清醒且務實的權衡。

跨越區域：全球一致性挑戰

為了降低全球用戶的訪問延遲和容災，Facebook 在世界各地部署了多個區域（數據中心）。架構上，他們設定一個 主區域 (master region) ，存放主數據庫，其他區域作為 從區域 (replica regions) ，存放只讀的數據庫副本。數據通過 MySQL 的復制機制從主區域同步到從區域。

這里最大的挑戰是 復制延遲 (replication lag) 。如果一個歐洲用戶更新了他的頭像（寫請求被路由到美國的主區域），然后立即刷新頁面（讀請求在本地的歐洲從區域），他很可能因為復制延遲而看不到自己的更新。

為了解決這個問題，Facebook 使用了一種叫 遠程標記 (remote marker) 的機制。 當一個寫請求發生在從區域時：

1. 客戶端首先在 本地memcache 中設置一個標記 key（如 remote_marker_for_key_X）。
2. 然后將寫請求發送到 主區域 的數據庫。
3. 同時刪除 本地memcache 中真正的 key_X 。

當后續的讀請求來到從區域：

1. 它首先請求 key_X，緩存未命中。
2. 接著它會檢查是否存在 remote_marker_for_key_X。
3. 如果標記存在，說明這個 key 剛剛在主區域被更新，本地數據庫副本的數據可能是舊的。于是，客戶端會將這次讀請求 直接路由到主區域 去查詢最新數據，從而避免讀到舊數據。

這是一種典型的 用延遲換取一致性 的權衡。雖然跨區域讀取會慢一些，但保證了更好的用戶體驗（直接請求美國數據比用戶等待數據復制到歐洲區域更快）。

總結與啟示

Facebook 的 Memcache 架構是一個在工程實踐中不斷演化、充滿權衡的杰作。從它的演進中，我們可以學到幾個核心思想，這對我們日常的系統設計和面試都大有裨益：

1. 分離關注點 ：將緩存系統和持久化存儲系統分離，使得兩者可以獨立擴展和優化。
2. 將復雜性推向客戶端 ：memcached 服務器本身極其簡單，大部分復雜邏輯如路由、序列化、錯誤處理、服務發現等都放在了無狀態的客戶端（或 mcrouter）中。這使得系統核心組件非常穩定，而客戶端邏輯可以快速迭代和部署。
3. 為失敗而設計 ：從 Gutter 系統到 mcsqueal 的可靠重放，整個系統處處體現著對故障的思考，致力于避免單點故障和級聯故障。
4. 簡單為王 ：系統設計中充滿了務實的權衡，例如容忍短暫的陳舊數據以換取極高的性能和可用性，避免引入過于復雜但收益有限的優化。

希望今天的講解能幫助大家更深入地理解這個經典的分布式緩存系統。這其中的很多設計思想，比如租約、CDC、Gutter 模式等，都是非常值得我們在自己的項目中借鑒的。