|
分布式緩存一般被定義為一個數據集合，它將數據分布（或分區(qū)）于任意數目的集群節(jié)點上。集群中的一個具體節(jié)點負責緩存中的一部分數據，整體對外提供統(tǒng)一的訪問接口 [1]。分布式緩存一般基于冗余備份機制實現數據高可用，又被稱為內存數據網格（IMDG, in-memory data grid）。在云平臺飛速發(fā)展的今天，作為提升應用性能的重要手段，分布式緩存技術在工業(yè)界得到了越來越廣泛的關注和研發(fā)投入 [2]。彈性緩存平臺 [3] 是分布式緩存集群在云計算場景下的新形態(tài)，其強調集群的動態(tài)擴展性與高可用性。動態(tài)擴展性表達了緩存平臺可提供透明的服務擴展的能力，高可用性則表達了緩存平臺可以容忍節(jié)點失效。 Tair 是阿里巴巴集團自研的彈性緩存 / 存儲平臺，在內部有著大量的部署和使用。Tair 的核心組件是一個高性能、可擴展、高可靠的 NoSQL 存儲系統(tǒng)。目前支持 MDB、LDB、RDB 等存儲引擎。其中 MDB 是類似 Memcached 的內存存儲引擎，LDB 是使用 LSM Tree 的持久化磁盤 KV 存儲引擎，RDB 是支持 Queue、Set、Maps 等數據結構的內存及持久化存儲引擎。 Tair 的數據分片和路由算法采用了 Amazon 于 2007 年提出的一種改進的一致性哈希算法 [4]。該算法將整個哈?？臻g分為若干等大小的 Q 份數據分區(qū)（也稱為虛擬節(jié)點，Q>>N，N 為緩存節(jié)點數），每個緩存節(jié)點依據其處理能力分配不同數量的數據分區(qū)?？蛻舳苏埱蟮臄祿?Key 值經哈希函數映射至哈希環(huán)上的位置記為 token，token 值再次被哈希映射為某一分區(qū)標識。得到分區(qū)標識后，客戶端從分區(qū)服務器映射表中查詢存放該數據分區(qū)的緩存節(jié)點后進行數據訪問。使用該算法對相同數據 Key 進行計算，其必然會被映射到固定的 DataServer 上，如圖： 此時 DataServer 單節(jié)點的讀寫性能便成了單數據 Key 的讀寫性能瓶頸，且無法通過水平擴展節(jié)點的方式來解決。由于阿里巴巴集團內部電商系的促銷活動天然的存在熱點數據，所以要增強整個彈性緩存 / 存儲平臺的穩(wěn)定性和服務能力，就必須提升熱點數據的讀寫能力，使其能做到水平擴展。 本文基于 Tair 的存儲和訪問原理，對緩存的讀寫熱點問題進行討論，并給出一個滿足現階段需求的熱點數據讀寫問題的解決方案。 解決方案分為三部分：熱點識別、讀熱點方案和寫熱點方案。其中讀寫熱點方案都是以服務端能對熱點訪問進行精準的識別為前提的。另外對于可以提前預知熱點 Key 的情況，也提供相應的客戶端 API 以支持特定數據 Key 或者特定 Namespace 的所有數據 Key 預先標記為熱點 Key 的能力。 DataServer 收到客戶端的請求后，由每個具體處理請求的工作線程（Worker Thread）進行請求的統(tǒng)計。工作線程用來統(tǒng)計熱點的數據結構均為 ThreadLocal 模式的數據結構，完全無鎖化設計。熱點識別算法使用精心設計的多級加權 LRU 鏈和 HashMap 組合的數據結構，在保證服務端請求處理效率的前提下進行請求的全統(tǒng)計，支持 QPS 熱點和流量熱點（即請求的 QPS 不大但是數據本身過大而造成的大流量所形成的熱點）的精準識別。每個采樣周期結束時，工作線程會將統(tǒng)計的數據結構轉交到后臺的統(tǒng)計線程池進行分析處理。統(tǒng)計工作異步在后臺進行，不搶占正常的數據請求的處理資源。 原始 Tair 的數據訪問方式是先進行 Hash(Key)%BucketCount 的計算，得出具體的數據存儲 Bucket，再檢索數據路由表找到該 Bucket 所在的 DataServer 后對其進行讀寫請求的。所以相同 Key 的讀寫請求必然落在固定的 DataServer 上，且無法通過水平擴展 DataServer 數量來解決。 本方案通過在 DataServer 上劃分一塊 HotZone 存儲區(qū)域的方式來解決熱點數據的訪問。該區(qū)域存儲當前產生的所有讀熱點的數據，由客戶端配置的緩存訪問邏輯來處理各級緩存的訪問。多級緩存架構如下： 所有 DataServer 的 HotZone 存儲區(qū)域之間沒有權重關系，每個 HotZone 都存儲相同的讀熱點數據。客戶端對熱點數據 Key 的請求會隨機到任意一臺 DataServer 的 HotZone 區(qū)域，這樣單點的熱點請求就被散列到多個節(jié)點乃至整個集群。 客戶端邏輯 當客戶端在第一次請求前初始化時，會獲取整個 Tair 集群的節(jié)點信息以及完整的數據路由表，同時也會獲取配置的熱點散列機器數（即客戶端訪問的 HotZone 的節(jié)點范圍）。隨后客戶端隨機選擇一個 HotZone 區(qū)域作為自身固定的讀寫 HotZone 區(qū)域。在 DataServer 數量和散列機器數配置未發(fā)生變化的情況下，不會改變選擇。即每個客戶端只訪問唯一的 HotZone 區(qū)域。 客戶端收到服務端反饋的熱點 Key 信息后，至少在客戶端生效 N 秒。在熱點 Key 生效期間，當客戶端訪問到該 Key 時，熱點的數據會首先嘗試從 HotZone 節(jié)點進行訪問，此時 HotZone 節(jié)點和源數據 DataServer 節(jié)點形成一個二級的 Cache 模型?？蛻舳藘炔堪藘杉?Cache 的處理邏輯，即對于熱點數據，客戶端首先請求 HotZone 節(jié)點，如果數據不存在，則繼續(xù)請求源數據節(jié)點，獲取數據后異步將數據存儲到 HotZone 節(jié)點里。使用 Tair 客戶端的應用常規(guī)調用獲取數據的接口即可，整個熱點的反饋、識別以及對多級緩存的訪問對外部完全透明。HotZone 緩存數據的一致性由客戶端初始化時設置的過期時間來保證，具體的時間由具體業(yè)務對緩存數據不一致的最大容忍時間來決定。 客戶端存儲于本地的熱點反饋過期后，數據 Key 會到源 DataServer 節(jié)點讀取。如果該 Key 依舊在服務端處于熱點狀態(tài)，客戶端會再次收到熱點反饋包。因為所有客戶端存儲于本地的熱點反饋信息的失效節(jié)奏不同，所以不會出現同一瞬間所有的請求都回源的情況。即使所有請求回源，也僅需要回源讀取一次即可，最大的讀取次數僅為應用機器數。若回源后發(fā)現該 Key 已不是熱點，客戶端便回到常規(guī)的訪問模式。 散列比和 QPS 偏差的關系 處理方式 對于寫熱點，因為一致性的問題，難以使用多級緩存的方式來解決。如果采用寫本地 Cache，再異步更新源 DataServer 的方案。那么在 Cache 寫入但尚未更新的時候，如果業(yè)務機器宕機，就會有已寫數據丟失的問題。同時，本地 Cache 會導致進行數據更新的某應用機器當前更新周期內的修改對其他應用機器不可見，從而延長數據不一致的時間。故多級 Cache 的方案無法支持寫熱點。最終寫熱點采用在服務端進行請求合并的方式進行處理。 熱點 Key 的寫請求在 IO 線程被分發(fā)到專門的熱點合并線程處理，該線程根據 Key 對寫請求進行一定時間內的合并，隨后由定時線程按照預設的合并周期將合并后的請求提交到引擎層。合并過程中請求結果暫時不返回給客戶端，等請求合并寫入引擎成功后統(tǒng)一返回。這樣做不會有一致性的問題，不會出現寫成功后卻讀到舊數據，也避免了 LDB 集群返回成功，數據并未落盤的情況（假寫）。具體的合并周期在服務端可配置，并支持動態(tài)修改生效。 客戶端設計 寫熱點的方案對客戶端完全透明，不需要客戶端做任何修改。 性能指標 LDB 集群實際壓測效果為單 Key 合并能做到單 Key 百萬的 QPS（1ms 合并，不限制合并次數），線上實際集群為了盡可能保證實時性，均采用了最大 0.1ms 以及單次最大合并次數為 100 次的限制。這樣單 Key 在引擎層的最大落盤 QPS 就能控制在 10000 以下（而合并的 QPS 則取決于應用的訪問頻率）。Tair 服務端的包處理是完全異步化的，進行熱點請求的合并操作并不阻塞對其他請求的處理。唯一的影響就是增大客戶端對熱點 key 的寫請求的 RT. 按照現在的配置，最壞情況下，客戶端的熱點 key 的寫操作會增大 0.1ms，這個影響是微乎其微的。
|
|
|
