Windows Server AppFabric Caching

這套 AppFabric Caching 比我用過的 memcached 複雜多了，MSDN有一篇文章進行介紹Introduction to Caching with Windows Server AppFabric (Beta 1)，這裡頭的概念很多，到現在為止還是模模糊糊的，本文主要是一些概念的理解，可能有不對的地方，歡迎大家指出來。

Windows Server AppFabric Caching 的體繫結構

從可看出 AppFabric Caching的大致架構，他給Clients提供一個統一的緩衝介面(Unified Cache View)， Client 可以不用在意到底實際的緩衝層(Cache Layer)有多複雜，通過統一的的 API 介面就可以使用 AppFabric Caching 進行 3H( High Scalability, High Availability, High Performance ) 應用系統的開發。

   1: //Define Array for 1 Cache Host

   2: List<DataCacheServerEndpoint> servers = new List<DataCacheServerEndpoint>(1);

   3:  

   4: //Specify Cache Host Details 

   5: //  Parameter 1 = host name

   6: //  Parameter 2 = cache port number

   7: servers.Add(new DataCacheServerEndpoint("localhost", 22233));

   8:  

   9: //Create cache configuration

  10: DataCacheFactoryConfiguration configuration = new DataCacheFactoryConfiguration();

  11:  

  12: //Set the cache host(s)

  13: configuration.Servers = servers;

  14:  

  15: //Set default properties for local cache (local cache disabled)

  16: configuration.LocalCacheProperties = new DataCacheLocalCacheProperties();

  17:  

  18: //Disable exception messages since this sample works on a cache aside

  19: DataCacheClientLogManager.ChangeLogLevel(System.Diagnostics.TraceLevel.Off);

  20:  

  21: //Pass configuration settings to cacheFactory constructor

  22: myCacheFactory = new DataCacheFactory(configuration);

  23:  

  24: //Get reference to named cache called "default"

  25: myDefaultCache = myCacheFactory.GetCache("default");

 

Windows Server AppFabric Caching 主要特點有：

• 任何可以被序列化的 CLR 對象都可以通過簡單的 Cache API 將資料緩衝
• 支援企業規模：可支援上百台主機的伺服器架構
• 可彈性的調整配置，並通過網路快取服務
• 支援動態調整規模，可隨時新增節點
• 支援高可用性架構
• 自動Server Load Balancer
• 可與 Event Tracing for Windows (ETW), System Center 等機制整合管理與監控
• 提供與 ASP.NET 的無縫整合，將 Session 資料儲存至緩衝，也可在 Web farm 架構下將應用程式資料緩衝 ，減少資料庫大量讀取的負擔
• 第一版遵循 cache-aside architecture ( 明確快取, Explicit Caching )，意即你必須在你的應用程式中明確指明你要新增(Put)或移除(Remove)快取的項目，所有快取資料並不會自動與任何來源資料庫進行同步。

資料分類

你的應用程式中如果要充分利用AppFabric Caching的功能，很有必要瞭解通常緩衝的資料類型。 這些資料類型可分類為引用資料、 活動資料和資源資料，因為不同的快取資料類型適用的情境是不同的。

1. 引用資料類型（Reference Data）

   這種資料類型負責儲存“較重要的資料”，而且這類資料都是不會經常變動的資料，而且每次變更資料都會建立一個新的版本，所以這類資料非常適合用來共用給多使用者、多應用程式的情況，用來加速所有應用程式的訪問速度，降低各應用程式對資料庫系統造成的負荷。對於“讀取”需求遠大於“寫入”需求的資料都很適合用這種資料類型進行資料緩衝，例如：產品類別。

   針對大型應用程式或者大流量的網站，引用資料類型也可以設定成自動複製到快取叢集的多台伺服器，以增加應用系統的擴充性。

2. 活動資料（Activity Data）

   所謂活動資料類型指的是生命週期很短的程式資料，這類資料通常不會被各應用程式或不同使用者共用，例如購物車資訊，就屬於這類活動資料。這類資料在大型應用中甚至可以跨伺服器的緩衝空間，可以很輕易的達到高擴充性的需求。

3. 資源資料（Resource Data）

   不管是 Reference Data (共用讀取) 或者 Activity Data (獨佔寫入) 已經很適合做資料緩衝，但並非所有應用程式類型都支援這種方式快取，這裡的“資源資料”指的是“共用的”且“同時需要被讀寫”的資料，而且讀寫量都非常大的情況。 例如“庫存資訊”的庫存量就經常變動，而且必須提供各應用程式即時的資訊，而且可能隨時變更庫存數量，這類資料就稱之為資源資料。

   這類型的快取資料通常遇到最大的問題在於很難提供高有效性(High Availability)的支援，由於維護高有效性的資料必須精確的鑑效組資料的一致性，所以必須實做交易處理(transactions)、變更通知(data change notifications)、設定緩衝失效(invalidations)等特性，通過 AppFabric Caching可讓你設定這類資料自動複寫到不同快取主機，輕易達到 高有效性 的需求。

使用的情境

• 社交類SNS網站

    

      由於使用者名稱稱、好友名單都是不會經常變動的資料，所以這種情境很適合採用 參考資料類型 (Reference Data) 來進行快取。

• 公司專屬應用程式系統( Enterprise LOB ) -- 例如: ERP, CRM, …

      對於供貨商資料、價格資訊可以通過 參考資料類型 (Reference Data) 來進行快取，而其他像是訂單資訊、發票資訊、付款資訊 都可以用 活動資料類型 (Activity Data) 來快取。

 

AppFabric Caching 基本概念

上面講的是關於“分布式緩衝架構”的基本觀念，這裡講的是“開發模型”的基本概念，瞭解這些概念才能讓你在實際利用 AppFabric Caching (Code Name: Velocity) 開發程式時有比較清晰的概念。

邏輯層架構

邏輯架構依次描述如下：

• 每台 伺服器 (Machine) 可以執行好幾個 緩衝執行個體(Cache Instance 或 Cache Host) ， 就好像一台機器可以運行好幾個 SQL Server 執行個體一樣的意思。
• 每個 緩衝執行個體 (Cache Host) 可以包含多個 具名快取空間 (Named Cache) ，具名快取可以設定成跨越多個 Cache Hosts 或 Machines
• 每個 具名快取空間 (Named Cache) 可以包含多個 地區 (Regions)
• 每個 快取區域 (Regions) 可以包含多個 快取項目 (Cache Items)
• 每個 快取項目 (Cache Items) 包含 可序列化的 CLR對象 (Objects)

緩衝概念（Cache Concepts）

• 主節點 ( Primary Node )

    所有 地區 (Regions) 的資料都會置於主要節點上，任何通過 Cache Client 過來擷取快取資料時都會自動被路由(Routed)到主要節點讀寫資料。

• 次節點 ( Secondary Nodes )

   如果 具名快取空間 (Named Cache) 為了高可用性(high availability) 而配置“備份”，就會用“次要節點”用來儲存這些“備份用的 地區 (Regions) ”備忘: 地區包含多個快取項目)。如果“主節點”損壞，快取叢集所收到的請求就會自動路由到“次節點”來取得讀取資料。

 

 

緩衝類型 ( Cache Types )

AppFabric 支援兩種常見的緩衝類型：分區緩衝、本機快取

• 分區緩衝 ( Partitioned Cache )

講“分區緩衝”很容易誤解其意思，這概念並不像“磁碟分割”那樣一個實體硬碟分區成好幾個扇區，而是將“所有快取服務器”全部整合成一個記憶體緩衝儲存區 (快取叢集)，你可以在這個“快取叢集”分區出你想要的任何大小。 因此，通過 Partitioned Cache 很適合用在需要海量儲存空間緩衝的應用程式，這可大幅提升應用程式的擴充性(Scalability)，當記憶體不夠用時就只要增加伺服器即可。 當新快取服務器加入整個快取叢集後，AppFabric Caching 會自動進行負載平衡，並將部分快取項目自動移至新主機，當快取項目平均分散在各台主機後也會增加整體快取叢集的輸送量(Throughtput)。 由於是將多台伺服器整合成一個大記憶體，所以快取資料並不會重複儲存，如例：K2,V2 指的是 “Key/Value Pair 2” 的意思，由於通過 Put 指令寫入快取項目時勢將資料寫入到 Cache 2 這個 緩衝實體(Cache Host) 中，所以當另一台主機從 Cache 3 取得(Get) K2,V2 資料時，就會通過 AppFabric Caching 內部的 Routing 機制從 Cache2 取得資料，而這些複雜的 Routing 作業全都由 AppFabric Caching 幫你完成。

Partitioned Cache 還能配置“次緩衝節點”，讓“主快取資料”能自動將快取項目複製到另一台主機，達到高有效性(High Availability)的目標，如下是 HA 模式的：

 

• 本地快取 ( Local Cache )

  AppFabric  Caching也支援“本機快取”，通過本機快取可以有效省去“序列化/還原序列化”的 CPU 成本，可提升讀寫快取資料時的效能。 如示很容易能看出運用本機快取的情景：

 

 

到期與回收 ( Expiration and Eviction )

• 緩衝到期 ( Expiration )

在新增快取項目到 Regions 時可以指定該對象的存活時間(TTL; Time To Live)

• 緩衝回收 ( Eviction )

快取項目可以設定優先等級，當快取不夠用時就會依據 LRU (least-recently-used) 演算法將不常用的快取項目刪除，讓優先權較高的快取項目進入快取服務器。

一致性模型 ( Consistency Models )

• 樂觀版本更新機制 ( optimistic version-based updates )

通過這個機制可享受較高的執行效能，因為就算不同的 Client 端在同時執行 取得緩衝(Get) 或 寫入緩衝(Put) 動作可以同時執行，Velocity 會在內部維護一份快取項目的版本資訊，而且會在每次取得(Get)資料時一併傳回用戶端，所以不用維護鎖定(locking)的問題，但版本資訊在 Client 端需自行判斷新舊。

• 悲觀鎖定機制 ( pessimistic locking )

通過 API 提供的 GetandLock 取得資料時，若有其他程式也要通過 GetandLock 取得資料時就會發生失敗，但若 Client 使用單純的 Get 取得資料還是可以的。這時通過 PutAndLock 方法可以將資料回寫至 Velocity，這時鎖定狀態就會被解除，但如果直接使用 Put 方法則會直接取消鎖定狀態並直接複寫該對象的值，所以必須小心使用。通過 UnLock 方法也可以直接設定解除鎖定。

 

變更通知 ( Notifications )

在分布式的架構下，由於多個用戶端同時讀寫同一份資源，變更通知變的非常實用，當另一個用戶端變更了某個 地區 (Regions) 或 快取項目 (Cache Items) 時可以通過事件通知應用程式。

部署拓樸 ( Deployment Topology )

Velocity 是通過 Windows Service 提供服務，可以通過 TCP/IP 從本機或遠端電腦聯機，並通過 .NET Client API 直接操作使用。

如是兩種常見的 Velocity 部署模式：

• Embedded

將 緩衝宿主(Cache Host) 跟 IIS 主機安裝在一起，並聯合多台宿主組成快取叢集

• Cache Service

使用 專屬主機 提供 緩衝宿主(Cache Host)，提供一個宿主的 緩衝層(Caching Tier)

ASP.NET整合 ( ASP.NET Integration )

AppFabric 提供一組 SessionStoreProvider 可讓你很容易的將 Session 移至 AppFabric Caching 平台，並儲存到一個 分區緩衝 (Partitioned Cache) 中，通過設定也可以達到 HA (High Availability) 與 HS (High Scalability) 的規劃。

效能測試 ( Performance Testing )

如示，只要新增快取服務器幾乎呈現“線性成長”的輸送量，可有效提升應用程式的擴充性。

結論 ( Conclusion )

通過 AppFabric Caching 可以輕易的讓你將多台伺服器的記憶體融合成一個超大記憶體緩衝，通過單一 API 即可讀寫這些記憶體緩衝，當記憶體不夠時只要增加伺服器即可輕易擴充完成，不僅有效降低管理成本，還可輕易的達到 3H ( High Scalability, High Availability, High Performance ) 系統架構。