緩存資料庫架構過時了，是時候採用混合內存架構了

作者：Srini Srinivasan是企業級非關係資料庫開發商Aerospike的首席產品官兼創始人。他在設計、開發和運營大規模基礎設施方面有著20年的豐富經驗，並持有資料庫、互聯網、移動和分散式系統技術方面的30餘項專利。

數字經濟經常上演這一幕：出現閃電般的連鎖反應，將數據轉化為洞察力，將機會轉化為商業價值。由於數據的速度和數量增加，支持這種增長的常見做法就是增加更多緩存。

但是基於緩存的資料庫架構從來不是為滿足當今的交互系統在數量和延遲方面的要求而設計的。數據數量一龐大，緩存就變得費用高、不可靠且不穩定。

這就需要一種更好的數據架構，而不是求助於更多的內存或更好的緩存。為了實現即時決策，數字化企業需要一種新的混合內存架構，可以實時處理事務數據和分析數據，以抓住商機。

據Forrester研究公司的一份報告「1」稱，「混合內存架構是一種新方法，充分利用易失性存儲器（DRAM）和非易失性存儲器（比如SSD和快閃記憶體），以提供一致、可信、可靠、低延遲的訪問，從而支持新老一代的事務應用、運營應用和分析應用。實施這類架構讓企業組織得以從雙層內存架構轉為單層結構，從而簡化數據的移動和存儲，無需緩存層。早期採用者已看到它給公司帶來的幾個好處，比如降低擁有成本、大幅減少伺服器佔用空間、簡化管理以及提高可擴展性。」

這五個跡象表明基於緩存的資料庫架構可能已過時，是時候改而採用混合內存架構了：

緩存節點不受控制地增加

隨著貴公司不斷發展，你的數據和緩存大小也會相應增加。隨著交互的價值不斷增加，新的應用軟體和項目要求訪問資料庫，增加事務量和緩存工作集大小。伺服器數量需要增加，即使年初就編製好了預算。增長超預期時，必須解決這個問題，否則你的交互系統就跟不上步伐。

不斷投入資金以應對這種增長不具有可持續性。業務增長意味著數據呈非線性增長，因為要整理或查詢每個客戶和每個事務的更多信息。加上使用另外的數據源以便更好地分析，你的緩存會迅速增加，從而消耗可用的預算。你可以將緩存數據重新平衡到SSD，短期內降低成本，但此舉會加大管理這些數據的複雜性。

重新填充緩存需要數小時甚至數天

故障是不可避免的事實。你的數據中心或雲越龐大，故障的頻率越高。對於大多數公司來說，在雲和DevOps時代配置新的緩存伺服器現在只需幾分鐘。但這不適用於緩存層中的數據。數據必須「還原」到達到命中率可以接受的水平，然後才能獲得減輕資料庫負載的預期影響。對於大多數數據密集的公司而言，這個過程可能需要數小時甚至數天——迫使它們處理有限的性能、不準確的數據、甚至更嚴重的過度配置帶來的不必要成本以及應用軟體複雜性。

不妨看一個實際例子。全球第六大經紀公司在基於緩存的傳統關係資料庫管理系統（RDBMS）架構上運行其當天交易系統。由於每天交易量龐大，這家經紀公司在緩存和資料庫方面都面臨挑戰。由於擔心導致基於緩存的系統過載，它無法每天多次執行準確的風險計算。因此，這家公司在交易期間在做出財務決策（比如保證金貸款等）方面如同兩眼抹黑。若使用混合存儲系統，可以每隔幾分鐘重新評估風險指標，幫助做出更合理的業務決策。當客戶在一天內多次交易時，遇到了另一個問題：客戶的頭寸（賬戶中的股票和資金）必須始終準確。如果備用緩存裡面是舊數據，客戶因頭寸顯示不足或沒有資金而無法進行另外的交易，會發生什麼？客戶的頭寸最終會準確，但這需要多長時間、面臨多大的損失？往好里說，客戶在等待屏幕刷新幾次時遇到糟糕的體驗。往壞里說，經紀公司可能要對錯失或不準確的交易承擔責任。

你仍無法使用緩存優先的架構符合SLA

如果你使用面向知名在線支付系統的欺詐檢測系統，不符合服務級別協議（SLA）可能意味著每天因錯失交易或欺詐交易而損失數百萬美元。RDBMS和第一代NoSQL資料庫本身都不夠快，無法滿足亞毫秒級的響應時間，因此你必須在其前面放置緩存。但實際情況卻很少這麼簡單；而且面對增長，這種架構也無法保證符合SLA。

以全球最大的支付處理公司之一為例。由於支付領域迅速發生變化，該公司需要為10倍增長作好規劃。擴展架構以滿足這種增加的負載意味著，少則從300台伺服器增加到3000台，多則擴展到10000台伺服器。改用混合內存架構為這家公司帶來了顯著的成效。伺服器數量從300台減少到20台，消除了緩存層和雙資料庫集群，節省了數百萬美元的運營成本。在峰值負載下，欺詐演算法的性能從175毫秒提高至不足80毫秒。即使欺詐檢測沒有及時返回，混合系統也繼續處理交易。這意味著以前演算法未符合SLA導致每天數額高達數百萬美元（相當於一年超過10億美元）的交易面臨欺詐風險。

你的數據足夠大，需要集群

貴公司終於開始壯大，你的緩存大小逐漸變成了分散式內存資料庫，需要面對分片、集群及其他新技術帶來的更大負擔。又很難找到擁有這些技能的人員。

你可能已經在應用軟體中使用分片技術來創建更多容量，畢竟這是最佳實踐。然而，如果公司發展夠快，分片可能不再管用，這就需要集群管理。集群機制通常比分片更先進，但帶來了一系列新的限制和不足，需要了解清楚。比如說，一些命令在集群環境中可能得不到支持，可能不支持多個資料庫，程序員需要知道哪個節點服務於哪個子集的密鑰，跨集群的密鑰查找可能成問題。

緩存踩踏經常發生

緩存踩踏（cache stampede）是一種級聯故障，可能由單單一個節點的隨機性故障引發。這可能歸咎於依賴糟糕的集群/分片演算法，導致其餘節點上的負載不均衡。

從用戶角度來看，緩存踩踏意味著他們想要查看或購買的商品無法載入，最終超時中斷。不耐煩的用戶會放棄請求，或者嘗試刷新頁面，這會加劇問題。無論怎樣，結果對你的聲譽或收入而言都是災難性的。

處理緩存踩踏有三種方法：鎖定、外部重新計算和概率提前到期。而所有方法都需要在應用軟體層面更改代碼，然後要「推銷」給開發團隊，以便它們將更改後的代碼集成到原有代碼中，以防問題再次出現。到頭來，這些方法都沒有解決問題。

那麼，為什麼你的應用軟體開發人員當初要承受緩存和資料庫管理這個負擔呢？這帶來了不必要的複雜性，影響質量和上市時間，並使客戶體驗面臨更大的風險。為什麼不完全丟棄緩存層，依賴管理所有這些問題的分散式資料庫，又不需要更改應用軟體？

重新評估外部緩存的需求

上述的伺服器增長、架構複雜性、不穩定性和緩存踩踏等問題表明，外部緩存層並不總是最佳的成功策略，對於突髮式或繁重、不斷加大的數據負載的系統而言更是如此。

外部緩存層作為確保性能和規模的事實架構的時代早已一去不復返。數據的增長以及對響應時間的持續下行壓力使得這項技術對許多使用場合而言已過時。是時候質疑最佳實踐和公認架構方面的當前思路了。混合內存架構是正在進行數字化轉型的企業目前和未來取得成功的關鍵。

「1」：Forrester 報告：混合內存架構驅動實時交互系統

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！