在 Roblox 這個大規模多人線上遊戲環境中，使用者讀寫資料的量與速度之大，足以讓標準的快取模式不堪負荷。 使用者在瀏覽緩存靜態資料的標準網頁時，或許不會察覺 200 毫秒的延遲；但在 Roblox 上，若檢索互動資料或伺服器元資料時出現 200 毫秒的延遲，便可能導致遊戲卡頓，並破壞模擬遊戲世界的流暢性。Roblox 運作於一個充滿不可預測、高速且短暫資料的生態系統中，必須在數毫秒內完成資料檢索，方能維持沉浸感。 

我們的快取層旨在作為數百萬並發使用者與持久化儲存之間的大型緩衝器。它能處理每秒 13.8 億次查詢（QPS）的峰值負載，單一邏輯叢集的處理量更可突破 1 億 QPS。 在本篇文章中，我們將揭開幕後祕辛，說明我們如何架構出一個聯邦式快取服務，使其能突破 Redis® 節點的限制以實現龐大的吞吐量，同時還得應對我們最大叢集上前所未有的 10 倍流量激增。

突破產業極限，滿足不斷增長的需求

在 Roblox，我們的快取服務建構於 Redis® 技術之上，單一 Redis® 叢集理論上可支援多達 1,000 個節點。然而，實證與業界公認的極限卻低得多——約為 400 至 500 個節點。¹ 這主要是因為 Redis® 的去中心化 Gossip 協定，該協定透過節點間通訊來共享健康狀態、運作狀態及分片映射資訊。 當叢集規模超過數百個節點時，Gossip 協議產生的通訊流量便會開始消耗大量 CPU 和網路資源。每個節點必須處理來自日益增加的對等節點所傳來的狀態更新，這會從其主要任務——即以低延遲提供資料服務——中奪取資源。這種控制平面開銷可能導致系統不穩定及難以預測的效能表現，這正是託管雲端服務供應商實施節點限制的原因。這是一道實務上的上限，若要突破此限制，勢必會犧牲系統的可靠性。

然而，單一叢集的實務限制並不足以支援 Roblox 規模的平台運作。在 Roblox 平台中，最大的後端服務在高峰期曾要求單一邏輯 Redis® 叢集處理超過 1 億 QPS，而這個需求量在短短三個月內便從 1,000 萬飆升至此。

為突破此架構限制，我們採用了聯邦式架構，在多個較小且獨立的 Redis® 叢集前方部署客戶端反向代理。我們將每個叢集設定為 400 節點上限，以確保效能可預測。 

對我們數以千計的應用程式與服務而言，客戶端反向代理將這些分散的叢集呈現為單一、統一且可擴展的快取服務。透過這種聯邦架構，我們只需向聯邦中新增更多叢集，便能幾乎無限制地進行水平擴展，完全繞過 Gossip 協議的限制。 目前，我們最大的單一快取部署包含超過 6,000 個 Redis® 節點，背後由超過 15 個獨立的 Redis® 叢集所支撐——這種規模唯有透過此聯邦模型方能實現。

三階段遷移流程

在管理數百個活躍生產叢集的同時，從傳統架構遷移至聯邦式架構是一項重大工程。到了 2024 年底，其中許多叢集已接近我們 400 節點的上限，迫切需要轉向更高容量的模型。主要挑戰在於標準 Redis® 實例是獨立運作的，且無法內建感知其他叢集，因此必須在遷移過程中採用自訂方法來複製資料。

為解決此問題，我們開發了一套透明的三階段遷移流程，旨在讓服務過渡時無需客戶介入，亦無需進行應用程式端的變更。

遷移工作流程

1. 雙重寫入：我們配置了客戶端反向代理以執行雙重寫入，將傳入資料同時發送至原始叢集與新的聯邦目的地。
2. 資料一致性與讀取切換：當雙重寫入流程將相同資料填入新叢集後，由於所有資料皆受生存時間 (TTL) 限制，我們便將讀取流量從舊叢集轉移至新的聯邦式架構。
3. 除役：在確認新叢集穩定運作後，我們停止對原始叢集的所有寫入操作，並將其除役。

我們成功將最關鍵的服務遷移至支援超過 6,000 個節點的聯邦模型，遠遠超越單一 Redis® 叢集的限制。 

應對「Grow a Garden」的爆炸性成長

自 2025 年 4 月起，我們面臨了少有服務曾遭遇的龐大容量挑戰。這一切的導火線正是《Grow a Garden》的驚人成功。遊戲上線僅數週內，《Grow a Garden》不僅打破了 Roblox 的紀錄，更刷新了遊戲產業史上最高同時在線用戶數（CCU）的紀錄。 短短三個月內，遊戲玩家數量便從我們先前單一遊戲的 280 萬 CCU 紀錄，飆升至超過 2,100 萬的峰值。這股爆炸性成長使我們最大的 Redis® 叢集流量暴增 10 倍，整體快取流量更增加了 3 倍。

Roblox 將快取系統部署於自家資料中心的實體伺服器上，而這波前所未有的成長並未包含在我們的長期容量規劃中。為了抵禦這股洶湧浪潮並維持平台穩定，我們必須在優先確保可靠性的前提下，大幅提升現有伺服器群組的運作效率。 

在流量激增期間提升效率

首先，我們需要找出系統中影響最大的瓶頸，以便優先進行優化工作。Roblox Caching 運行於兩個不同的硬體彙集：一個用於 Redis® 後端節點，另一個用於 Envoy。我們的 Redis® 彙集主要受記憶體限制，而客戶端代理則受運算能力限制。 

針對受記憶體限制的 Redis® 機群，我們實施了一項新的調度策略，以更好地平衡各實體機器群組之間的記憶體利用率。我們還微調了容器大小，以減少記憶體碎片化。 

為提升 CPU 利用率，我們對快取系統實施了兩項關鍵優化：

1. 客戶端代理自動擴展：我們調整了運算密集型客戶端代理叢集的自動擴展策略。透過降低允許的目標 CPU 偏差值，我們在不改變擴展閾值的情況下，成功提升了工作負載的平均 CPU 利用率。
2. 內部叢集健康檢查：我們優化了內部健康檢查機制，以消除不必要的心跳訊號，在維持原始偵測間隔的同時節省運算資源。

這些變更使 CPU 使用率提升了近 10%。最後，我們透過 cgroup 容器級隔離，將這兩種截然不同的工作負載合併部署至同一台機器池中，從而將整體容量需求降低了 25%。

打造堅如磐石的可靠性

即使在全力應對破紀錄的需求之際，可靠性仍是我們的首要任務。 

端到端可觀察性

我們首先著重於理解潛在故障，透過大量投資於可觀測性堆疊，對快取系統進行全面且端到端的健康狀態監控。藉由追蹤整個請求生命週期中的伺服器成功與客戶端失敗狀況，我們能迅速偵測並診斷問題，往往能在影響用戶之前就預先防範。 例如，我們新增了熱鍵偵測功能，透過採樣即時流量來識別被過度存取且造成快取層負荷過大的資料。當系統標記出熱鍵時，我們便能主動在伺服器端與客戶端對這些鍵的流量進行限流，以防止系統過載。

故障處理

在任何此規模的分散式系統中，偶爾會發生局部故障。我們已針對系統進行設計，使其能優雅地處理這些故障並將其影響降至最低。

• 批次請求中的局部故障：我們重新架構了系統，以處理批次請求中的局部故障。過去，在分片批次請求中，單一請求失敗就會導致整個批次失敗。現在，即使部分金鑰無法成功檢索，其餘請求仍可成功。
• 緩解隊列頭阻塞：快取系統理應具備高速處理能力。即使輕微的網路延遲，也可能導致請求堆積並超時，此現象稱為「隊列頭阻塞」。我們已在客戶端和代理層實作智慧型重試機制與連線池策略，以防止單一緩慢請求影響其他請求。
• 故障與延遲注入：為測試系統韌性，我們定期透過故障注入框架，在生產環境中注入受控的故障（節點中斷、機架中斷、網路延遲、API 錯誤）。透過分析系統在這些條件下的行為，我們能主動識別並修復弱點，確保持續的可靠性。

客戶端韌性

為防止快取系統因流量驟增而不堪負荷，我們實作了強健的客戶端故障容錯機制。此機制在應用程式層運作，確保沒有單一服務能壟斷快取資源。

• 流量控制的速率限制：我們的客戶端對總外發流量設有上限，確保其發送的請求數量不會超過後端服務的處理能力。當超過此限制時，系統會對請求進行限流，從而防止服務因過載而癱瘓。
• 重試與超時機制：我們的客戶端函式庫採用經過精細調校的重試機制，包含超時設定與重試配額，以防止「雷霆之群」效應。此機制能限制影響範圍、釋放資源，並透過防止系統因無限期卡死及同時重試而過載，從而提升整體系統的響應能力。

Roblox 快取的未來

Roblox 的快取發展歷程始於由各應用程式擁有者直接管理的裸機 Redis® 叢集，隨後轉移至由我們的快取團隊管理的 Memcached 叢集，最終過渡到 Redis® 即服務（Redis®-as-a-service）模式，在此模式下，Redis® 叢集將作為託管服務提供。 雖然此模式在我們目前的規模下已證實極為有效，但我們也意識到，對於像 Roblox 這樣動態的平台而言，該模式在服務效率與資源隔離方面仍存在侷限。

隨著平台持續擴展，我們計劃對基於 ValKey 打造的次世代多租戶快取服務進行重大投資。此架構旨在透過多租戶機制共享共通資源以大幅降低成本，同時確保每個租戶在資料、資源及故障方面的隔離性。我們的目標是大幅提升快取基礎架構的效能、可擴展性、可靠性與成本效益，以滿足 Roblox 上日益龐大的體驗需求。

致謝： 

這項成就源自團隊的共同努力。感謝以下對此貢獻良多的團隊成員：Utkarsh Singh、Karthick Ramachandran、Vineesha Kasireddy、Weiji Hu 以及 Leon Gao。