從毫秒到微秒：針對現代 AI 的 Valkey 架構模式分析
在現代的高性能系統中，尤其是 AI 推理服務中，數據存取的延遲（Latency）直接決定了用戶體驗與運算成本。許多工程師習慣於「毫秒級（ms）」的響應時間，但在 AI 特徵存儲（Feature Store）等極端場景下，毫秒級的延遲可能成為系統的瓶頸。
本文將透過對比 Valkey（Redis 的開源分支）的不同架構模式，分析為什麼我們應該挑戰現有的代理（Proxy）架構，並轉向直接訪問（Direct Access）模式，以實現微秒級（µs）的性能提升。
為什麼 AI 時代需要「微秒級」延遲？
對於大多數應用，100 毫秒的響應時間是可以接受的。但讓我們以 AI 預測服務（例如 DoorDash 的欺詐檢測或餐廳推薦）為例：
AI 特徵存儲的挑戰 一個典型的預測服務可能有 100 毫秒的總時間預算（Budget）。然而，為了讓 AI 模型做出精準預測，系統需要從特徵存儲中獲取數百個特徵（例如：用戶近期的登入次數、信用卡是否為新卡等）。
這裡會遇到兩個核心問題： 扇出效應與尾端延遲 (Tail Latency)：當你並行發起數百個請求時，整體延遲將由「最慢的那一個請求」決定（類似接力賽）。即便中位數延遲（p50）很低，只要 p99 延遲較高，每一次預測請求幾乎都會觸碰到那個慢請求，導致整體性能下降。 順序依賴 (Sequential Lookup)：某些數據具有依賴關係，必須先獲取 A 才能請求 B。這種順序操作會迅速消耗掉 100 毫秒的預算，導致留給 AI 模型運算的時間不足。
因此，底層存儲必須將延遲壓低到微秒級，才能在滿足複雜數據需求後，仍為 AI 模型保留足夠的運算時間。
傳統的「毫秒級」架構：代理模式 (Proxied Architecture)
隨著 Redis/Valkey 的普及，單機性能達到瓶頸後，業界演進出了「代理架構」。
為什麼會使用 Proxy？ 在許多舊系統或大規模集群中，開發者會在應用端與 Valkey 伺服器之間加入一個代理層（如 Envoy Proxy），原因包括： 解耦與簡化：客戶端不需要知道後端分片（Sharding）的複雜拓撲。 連接多路複用 (Connection Multiplexing)：當有 10 萬個 Pods 同時連接 Valkey 時，直接連接會撐爆伺服器。Proxy 可以將大量客戶端連接聚合，轉化為少數幾個對後端的長連接。 遺留系統兼容：無需修改舊版客戶端代碼即可實現集群擴展。
代理模式的隱形成本 雖然 Proxy 帶來了管理上的便利，但它引入了顯著的性能與成本開銷：
A. 延遲增加 在一次典型的 p50 請求中，若總延遲為 1 毫秒（1000µs）： 網絡跳數 (Network Hops)：客戶端 $\to$ Proxy $\to$ Valkey $\to$ Proxy $\to$ 客戶端。兩次網絡跳轉（假設每次 300µs）就佔用了 600µs。 處理開銷：剩下的 400µs 需分攤給 Proxy 的路由邏輯、Valkey 的處理以及客戶端的處理。
B. CPU 成本爆炸 Proxy 是一個極其耗費 CPU 的組件。因為它需要處理兩倍的 I/O（接收請求 $\to$ 發送請求 $\to$ 接收響應 $\to$ 發送響應）。 在實際測試中（使用 AWS Graviton 實例，50 萬 QPS），Envoy Proxy 的 CPU 利用率高達 90%，而後端 Valkey 僅 60%。這意味著 Proxy 成為了系統的性能瓶頸（Chokepoint）。
C. 可靠性陷阱：單點故障與線頭阻塞 (Head-of-Line Blocking) 這是最危險的一點。在 Proxy 模式下，客戶端通常使用一個連接池（Connection Pool）與 Proxy 通訊。 場景分析：若後端 3 個分片中，分片 1 發生緩慢故障（Slowness），而分片 2 和 3 依然健康。 由於所有請求都經過同一個 Proxy 連接池，請求分片 1 的慢請求會迅速佔滿連接池的所有連接。 結果：原本發往分片 2 和 3 的健康請求也因為拿不到連接而被拒絕。 影響：單個分片的局部故障，會導致整個集群的可用性掉至 0%。
微秒級的解決方案：直接訪問模式 (Direct Access)
為了追求極致效率，我們應採取類似 SpaceX 膠囊設計的思維：質疑不必要的需求（如 Proxy），直接簡化架構。
核心機制：智能客戶端 (Smart Client) 移除 Proxy 後，客戶端直接與 Valkey 分片通訊。為了實現這一點，客戶端必須具備「拓撲感知」能力，能夠理解數據分佈並將請求直接路由到正確的節點。
直接訪問模式的優勢
故障隔離 (Fault Isolation) 與 隔艙模式 (Bulkhead Pattern) 在直接訪問模式下，客戶端為每個分片維護獨立的連接池。 當分片 1 發生緩慢故障時，僅分片 1 的連接池會被佔滿。 發往分片 2 和 3 的請求依然走獨立通道，完全不受影響。 結果：系統可用性僅下降 1/3（局部故障），而非全面崩潰。這在工程上稱為「隔艙模式」，確保局部損壞不會導致整艘船沉沒。
成本大幅降低 由於移除了 CPU 密集型的 Proxy 層，達到相同吞吐量（如 100 萬 QPS）所需的硬件資源大幅減少。 代理模式：需要多台 Proxy 實例 + Valkey 實例 $\approx$ \$700/月。 直接訪問：僅需 Valkey 實例 $\approx$ \$230/月。 結論：成本降低至原來的 1/3。
延遲突破 移除了一次網絡跳轉與 Proxy 的處理時間，尾端延遲（p99）從 2.4 毫秒降低至約 567 微秒。
工程判斷與實務建議
適用情境分析
維度 代理模式 (Proxied) 直接訪問模式 (Direct Access) :--- :--- :--- 適用場景 極大規模連接數、遺留系統、對拓撲透明度要求極高 AI 特徵存儲、低延遲交易、高性能緩存 延遲 毫秒級 (ms) 微秒級 ($\mu$s) 成本 高 (需額外支付 Proxy CPU 成本) 低 (僅支付存儲成本) 可靠性 低 (易受線頭阻塞影響，故障擴散) 高 (天然具備分片級故障隔離) 複雜度 客戶端簡單，運維複雜 (需管理 Proxy 層) 客戶端需集成智能路由，運維簡單
給工程師的實作建議 審視需求：如果你目前的系統延遲在 1-10ms 且能滿足業務，Proxy 的便利性可能是合理的。但如果你在構建 AI 推理 pipeline，請務必考慮直接訪問模式。 優先考慮故障隔離：不要僅僅為了方便而使用 Proxy。請意識到連接池共享帶來的風險，儘量在客戶端實現分片級的隔離。 監控尾端延遲：不要只看 p50。在高性能數據層中，p99 才是決定系統穩定性的關鍵指標。 工具選擇：對於需要高性能、開源且社區支持的緩存需求，Valkey 提供了一個極佳的起點，其高效的內存管理與社區貢獻使其能支持極高的每秒請求數 (RPS)。
最後，設計高效系統的關鍵在於「回歸核心需求」。就像 NASA 從複雜的航天飛機（帶翼、貼瓷磚）轉向簡單的膠囊設計一樣，在架構設計中，移除不必要的中間層往往是獲得性能飛躍的最快路徑。