1. 程式人生 > >【技術架構】分散式快取特點

【技術架構】分散式快取特點

分散式快取概述

1.1 分散式快取的特性

分散式快取具有如下特性:

1) 高效能:當傳統資料庫面臨大規模資料訪問時,磁碟I/O 往往成為效能瓶頸,從而導致過高的響應延遲.分散式快取將高速記憶體作為資料物件的儲存介質,資料以key/value 形式儲存,理想情況下可以獲得DRAM 級的讀寫效能;

2) 動態擴充套件性:支援彈性擴充套件,通過動態增加或減少節點應對變化的資料訪問負載,提供可預測的效能與擴充套件性;同時,最大限度地提高資源利用率;

3) 高可用性:可用性包含資料可用性與服務可用性兩方面.基於冗餘機制實現高可用性,無單點失效(single point of failure),支援故障的自動發現,透明地實施故障切換,不會因伺服器故障而導致快取服務中斷或資料丟失.動態擴充套件時自動均衡資料分割槽,同時保障快取服務持續可用;

4) 易用性:提供單一的資料與管理檢視;API 介面簡單,且與拓撲結構無關;動態擴充套件或失效恢復時無需人工配置;自動選取備份節點;多數快取系統提供了圖形化的管理控制檯,便於統一維護;

5) 分散式程式碼執行(distributed code execution):將任務程式碼轉移到各資料節點並行執行,客戶端聚合返回結果,從而有效避免了快取資料的移動與傳輸.最新的Java 資料網格規範JSR-347中加入了分散式程式碼執行與Map/reduce 的API 支援,各主流分散式快取產品,如IBM WebSphere eXtreme Scale,VMware GemFire,GigaSpaces XAP 和Red Hat Infinispan 等也都支援這一新的程式設計模型.

1.2 典型應用場景

分散式快取的典型應用場景可分為以下幾類:

1) 頁面快取.用來快取Web 頁面的內容片段,包括HTML、CSS 和圖片等,多應用於社交網站等;

2) 應用物件快取.快取系統作為ORM 框架的二級快取對外提供服務,目的是減輕資料庫的負載壓力,加速應用訪問;

3) 狀態快取.快取包括Session 會話狀態及應用橫向擴充套件時的狀態資料等,這類資料一般是難以恢復的,對可用性要求較高,多應用於高可用叢集;

4) 並行處理.通常涉及大量中間計算結果需要共享;

5) 事件處理.分散式快取提供了針對事件流的連續查詢(continuous query)處理技術,滿足實時性需求;

6) 極限事務處理.分散式快取為事務型應用提供高吞吐率、低延時的解決方案,支援高併發事務請求處理,多應用於鐵路、金融服務和電信等領域.

1.3 分散式快取的發展

分散式快取經歷了多個發展階段,由最初的本地快取到彈性快取平臺直至彈性應用平臺[8],目標是朝著構建更好的分散式系統方向發展(如下圖所示).

1) 本地快取:資料儲存在應用程式碼所在記憶體空間.優點是可以提供快速的資料訪問;缺點是資料無法分散式共享,無容錯處理.典型的,如Cache4j;

2) 分散式快取系統:資料在固定數目的叢集節點間分佈儲存.優點是快取容量可擴充套件(靜態擴充套件);缺點是擴充套件過程中需要大量配置,無容錯機制.典型的,如 Memcached;

這裡寫圖片描述

3) 彈性快取平臺:資料在叢集節點間分佈儲存,基於冗餘機制實現高可用性.優點是可動態擴充套件,具有容錯能力;缺點是複製備份會對系統性能造成一定影響.典型的,如 Windows Appfabric Caching;
這裡寫圖片描述
這裡寫圖片描述

4) 彈性應用平臺:彈性應用平臺代表了雲環境下分散式快取系統未來的發展方向.簡單地講,彈性應用平臺是彈性快取與程式碼執行的組合體,將業務邏輯程式碼轉移到資料所在節點執行,可以極大地降低資料傳輸開銷,提升系統性能.典型的,如 GigaSpaces XAP.
這裡寫圖片描述
這裡寫圖片描述

1.4 分散式快取與NoSQL

NoSQL 又稱為Not Only Sql,主要是指非關係型、分散式、支援水平擴充套件的資料庫設計模式.NoSQL 放棄了傳統關係型資料庫嚴格的事務一致性和正規化約束,採用弱一致性模型.相對於NoSQL 系統,傳統資料庫難以滿足雲環境下應用資料的儲存需求,具體體現在以下3 個方面:

1) 根據CAP 理論,一致性(consistency)、可用性(availability)和分割槽容錯(partition tolerance)這3 個要素最多同時滿足兩個,不可能三者兼顧.對雲平臺中部署的大量Web 應用而言,資料可用性與分割槽容錯的優先順序通常更高,所以一般會選擇適當放鬆一致性約束.傳統資料庫的事務一致性需求制約了其橫向伸縮與高可用技術的實現;

2) 傳統資料庫難以適應新的資料儲存訪問模式.Web 2.0 站點以及雲平臺中存在大量半結構化資料,如使用者Session 資料、時間敏感的事務型資料、計算密集型任務資料等,這些狀態資料更適合以Key/Value 形式儲存,不需要RDBMS 提供的複雜的查詢與管理功能;

3) NoSQL 提供低延時的讀寫速度,支援水平擴充套件,這些特性對擁有海量資料訪問請求的雲平臺而言是至關重要的.傳統關係型資料無法提供同樣的效能,而記憶體資料庫容量有限且不具備擴充套件能力.分散式快取作為NoSQL 的一種重要實現形式,可為雲平臺提供高可用的狀態儲存與可伸縮的應用加速服務,與其他NoSQL 系統間並無清晰的界限.平臺中應用訪問與系統故障均具有不可預知性,為了更好地應對這些挑戰,應用軟體在架構時通常採用無狀態設計,大量狀態資訊不再由元件、容器或平臺來管理,而是直接交 付給後端的分散式快取服務或NoSQL 系統.

1.5 分散式快取與極限事務處理

隨著雲端計算與 Web 2.0 的進一步發展,許多企業或組織時常會面對空前的需求:百萬級的併發使用者訪問、每秒數以千計的併發事務處理、靈活的彈性與可伸縮性、低延時及7×24×365 可用性等.傳統事務型應用面臨極限規模的併發事務處理,出現了極限事務處理型應用,典型的有鐵路售票系統.Wikipedia 認為,極限事務處理是每秒多於500 事務或高於10 000 次併發訪問的事務處理[12].Gartner 將極限事務處理(extreme transactionprocessing,簡稱XTP)定義為一種為事務型應用的開發、部署、管理和維護供支援的應用模式,特點是對效能、可擴充套件性、可用性、可管理性等方面的極限需求.Gartner 在其報告中預測指出,極限事務處理型應用的規模將由2005 年的10%提升至2010 年的20%,極限事務處理技術是未來5 年~10 年的熱點技術.極限事務處理的引入,無疑給傳統Web 三層架構帶來了新的挑戰.即,如何在廉價的、標準化的硬體和軟體平臺之上,對大容量、業務關鍵型的事務處理應用提供良好的支撐.分散式快取作為一種關鍵的XTP 技術,可為事務型應用提供高吞吐率、低延時的技術解決方案.其延遲寫(write-behind)機制可提供更短的響應時間,同時極大地降低資料庫的事務處理負載,分階段事件驅動架構(staged event-driven architecture)可以支援大規模、高併發的事務處理請求.此外,分散式快取在記憶體中管理事務並提供資料的一致性保障,採用資料複製技術實現高可用性,具有較優的擴充套件性與效能組合.