微軟分布式緩衝AppFabric（Velocity）學習－緩衝概念（三）

接上一篇

4.到期和回收(Expiration and Eviction)

Velocity中，對象並不是一直駐留在記憶體中。除了顯示使用Remove方法將其移除，還有可能到期機制或回收機制從快取叢集中去除。

4.1到期機制（Expiration）

緩衝到期機制允許快取叢集自動從緩衝中刪除緩衝對象。使用Put或Add方法時，有一個逾時時間的選擇性參數，用來決定緩衝在記憶體中的存留時間。如果緩衝對象沒有設定逾時時間，具名快取（Named Cache）中的配置將決定對象的產生時間。

如果對象在並發時被鎖，對象不會因到期時間而從記憶體中移除。但當並發鎖解鎖時，對象將立即從記憶體只移除。

本機快取失效機制（ocal Cache Invalidation）

一旦對象被下載到本機快取，您的應用程式將一直使用這些對象，直到他們是失效，無論是否由另一個用戶端上快取叢集更新這些對象。出於這個原因，最好是不經常變化的資料緩衝到本地。有兩種類型的本機快取失效機制：基於逾時的失效和基於通知的失效。

基於逾時的失效機制（Timeout-based Invalidation）

緩衝到本地的對象將一直駐留在記憶體中直到到達它的逾時時間，逾時時間是通過用戶端配製指定的(ttlValue in the app.config file). 。對象從記憶體中移除後，應用程式再次訪問時將從快取叢集中重新擷取。

逾時機制的特性決定著它不會對快取叢集中對象即時更新，建議更新不頻繁的資料使用此機制。

基於通知的失效機制（Notification-based Invalidation）

在使用是路由用戶端時，可以使用快取通知來自動更新本機快取資料以減少應用程式使用到期資料的可能性。

當使用快取通知時，應用程式會定時檢查快取叢集中是否有新的可用通知。查詢的時間間隔預設為300秒，查詢時間在應用程式中的設定檔中是一個單獨的節點，通過設定檔的clientNotifications節點的pollInterval屬性來修改。還可以要代碼中通過DataCacheFactory 的建構函式來指定。

回收機制（Eviction）

為了保持緩衝主機的記憶體上面可以有足夠的記憶體用於快取資料，Velocity使用LRU（最近最久未使用）演算法，用一個界限值確保記憶體均勻分配在所有緩衝主機中。

當記憶體的使用率超過了界限值時，Velocity將啟動回收機制回收已到期對象。如果回心到期對象後，記憶體的使用率還在界限值之上，將使用LRU機制糾繼續回收對象，不管對象是否已到期，直到將同存的使用率降到界限值以下。

配置說明

到期和回收機制通過群集設定檔的本設定。可以使用基於PowerShell的管理員工具來管理，另外以下方法允許你重寫緩衝的預設設定。

－CreateRegion方法允許你啟用和禁用域中對象的回收機制

－Add和Put方法允許重寫，可以指定過緩衝中對象的到期時間

－PutAndUnlock和Unlock方法允許重載，可以擴充項物件解鎖後的到期時間

－ResetObjectTimeout 方法允許顯示指定對象的存留時間，此方法重寫緩衝配置的設定

 

5. 高可用性（High Availability ）

“Velocity”的高可用性功能支援單獨的緩衝主機上儲存資料的副本，使快取資料持續可用。如果啟用了群集的高可用性功能，應用仍然程式可以在群集中的部分緩衝主機掛了的情況下取出資料。

沒有高可用性啟用，“Velocity”仍提供一些保護快取資料的措施，對象不儲存在是在域中，而是分布在叢集的所有主機。由於分布式的特性，群集中的主機越多，因某一台機器故障而帶來的資料訪問問題會越少。

僅管高可用性可以減少緩衝主機和應用程式間的故障，但也有可能整個群集掛掉，所以應用程式設計時應該考慮到在沒有快取服務情況下的狀態，畢竟緩衝總有不存在的時候。

建議群集中至少有三個緩衝主機，出於苛刻的一致性要求，需有兩台緩衝主機啟用高可用性功能。

高可用性如何運行

當啟用高可用性功能時，每個獨立的主機都儲存了對象或域的複本。快取叢集管理維護這些複本，當主快取資料失敗時，會複本中的資料提供給應用程式。啟用高可用性不會對編程方面產生任務影響。

效能注意事項

維護緩衝複本時必需識別所有主緩衝的變化，這裡有一些效能會消耗在複本的同步中。需要考慮當主緩衝丟失後，重新加載入緩衝複本的代價。（大概是這意思）

What Happens When a Cache Host Fails

如果其中一個緩衝主機出故障不會對應用程式產生任何影響，快取叢集將重新路由到緩衝複本，同時將該緩衝的複本的訪問優先權提升到主複本。然後再產生該緩衝的次要複本，並平均分佈於其它可用主機。

要啟用高可用性，群集中最少要有三台緩衝主機，並且有兩台主機處於正常運行狀態。

 

高可用性的一推薦做法

－讓群集中有大量的緩衝主機

－將緩衝系統中的所有快取服務、緩衝主機、快取用戶端、資料來源服務都部署在企業防火牆的同一個域下。（快取用戶端也要在這裡面？）

－使用SqlServer做為你的分布式緩衝系統

－使用SqlServer儲存快取叢集配置

－使用SqlServer執行緩衝的管理規則

－如果有可能，請使用SqlServer 2008的容錯移轉群資料庫做為快取叢集的儲存位置

－盡量少修改配置，因為這會重啟整個群集，如果有可能，可以用重新建立name caches方法來代替修改配置

－必需在重啟服務前使用Stop-CacheHost命令來停止緩衝主機。用Stop－CacheHost命令來關閉群集中管理角色的主機不會成功，因為當管理角色的主機關閉後會導致整個群集關閉。

 

6. 快取通知（Cache Notifications ）

Velocity提供了快取通知，當快取叢集中有對緩衝的操作時，允許應用程式接收非同步通知。快取通知也提供了讓本機快取失效的功能。

為了接收非同步快取通知，在應用程式中要添加一個快取通知的回呼函數。當您添加回調，您可以定義快取作業觸發一個緩衝的通知，當緩衝發變化時會調用該函數通知應用程式。

觸發快取通知

如所示，改變這兩個地區和緩衝的對象（稱為緩衝內的項目）可以觸發快取通知。

快取通知的類型由DataCacheOption類的成員定義

通知範圍（Notification Scope）

根據應用程式的業務要求，你不一定要對緩衝中所有對象和域的事件做監聽。Velocity可以從地區的層級和域層級的快取層級縮小您的通知的範圍。

在緩衝層級，應用程式將監聽到緩衝所有對象和域的變化；在域層級應用程式將監聽到某個域中的有對象的變化；在Item level，應用程式將僅監聽到某個對象發生的變化。

可以用以下三個方法指定不能的監聽層級

－AddCacheLevelCallback

－AddRegionLevelCallback

－AddItemLevelCallback

通知順序（Notification Order）

快取用戶端收通知的順序保障通知在一個地區範圍內。

 

查詢間隔（Polling Interval）

使用快取通知時，應用程式會按指定的時間間隔檢查是否有新的通知可用，預設輪循時間是300秒。

When Notifications are Lost

由於伺服器的負載問題，緩衝主機只能處理一定量的快取作業，所有一此快取用戶端可能在沒有接收到通知時，緩衝主機就將通知隊列終止。快取用戶端也有可能因為某個快取服務服務故障而丟失通知，雖然快取叢集仍然正常運行。這種情況下應用程式會接收到訊息通知失敗的通知，可以通過添加 AddFailureNotificationCallback函數處理此訊息。

When the Cache Cluster is Lost

丟失通知與丟失快取叢集之間有很大的區別，如果應用程式丟失通知，會接收到通知失敗的通知，而快取叢集掛了之後應用程式將接收不到任務通知，再嘗試串連群集時時應用程式會拋出異常。

啟用快取通知

快取通知和通知的層級都可以在群集的設定檔中設定。可以把它當做緩衝的一個屬性來建立緩衝。預設情況下快取通知是不啟用的。

 

7.群集主機和群集管理（Lead Hosts and Cluster Management ）

Velocity是一組動態服務同時啟動並執行組合，為應用程式提供一個唯一的邏輯緩衝。要做到這些，需要一些開銷花在各主機的協同工作上。在Velocity中，群集管理角色是用到管理緩衝主機，最終組成一個快取叢集。

根據分布式緩衝的不同配置，有兩個選項可用於群集管理角色。如果使用SQL Server資料來儲存群集配置，SQL Server執行個體同時也是群集的管理角色。

如果使用網張共用目錄來儲存群集配置，群集管理的角色將是被指定的一台緩衝主機，這台主機被稱為lead hosts(只能叫它為主機中的戰鬥機了)，它除了有群集中的其它緩衝主機的職責外還肩負著群集管理角色的重任。

 

群集管理角色的職責（Cluster Management Role Duties）

－確保快取叢集一直正常運行

－管理群集中的所有可用緩衝主機

－協助緩衝主機加入快取叢集

叢集管理和Lead Host名稱（Cluster Management and Lead Host Designations）

有兩個主要配置用於決定如何配置快取叢集。

－leadHostManagement：群集層級的配置，用於管理叢集角色。為true時，lead hosts將履行群體管理職責。當選擇網際網路共用目錄為儲存位置時，此配置僅能為true。當選擇Sqlserver為儲存位置時，可以通過將該值設定為true來指定某個主機為lead hosts.

-quorumHost:緩衝主機分級的配置。當從SqlServer為儲存位置時，用更改主機位置。

 

When a Lead Host Fails

為了保持可用的緩衝叢集，大多數Lead host必須保持可用。確保它有較少的伺服器故障導致群集自行關閉。例如：有6個服務的緩衝群體，兩被指定為群集的管理者。

如果一台普通主機掛了，群體仍正常運行。非lead hosts主機的資料將會丟失（假設高可用性未啟用），但其餘的服務和資料仍正常，群體仍可正常運行。如果所有非lead hosts主機都掛了，lead host將不會再被視為lead hosts.

Lead hosts的其它選項

Velocity在安裝時有一個群集大小選項用於指定lead hosts 在群體中的數量。也可以在安裝後再指定額外的lead hosts，但需要重點考慮分配太多lead hosts會帶來一個問題。

－必須始終有大量的lead hosts可正常運行，這樣才能確保群集的正常運行。

－在小群，其中一個或兩個導致主機故障可能導致群集發生故障，建議指定更多的導致主機。

－在大型群集中，要保證50個緩衝主機正常運行應指定5至7個lead hosts.

 

8. TCP/IP 通訊

Velocity中，所有主機通過互相間的TCP/IP通訊共同組成了快取叢集。為了確保緩衝主機間的通訊，應關閉主機音的防火牆。快取用戶端使用Tcp/IP方式對緩衝進行操作，但它可以在有防火牆的狀態下工作。

Velocity是下個設計為運行在防火牆內的高效能的程式。為了儘可能的提高效能，資料都未進行加密，所以很可能受到“sniffing”和“replay”攻擊。

TCP/IP連接埠設定

為了正常運行，每個快取服務器需要配置緩衝主機服務在防火牆例外列表中。使用三個獨立的連接埠是：群集的連接埠，仲裁連接埠，和快取連接埠。

每個快取的主機和快取用戶端指定連接埠，這些連接埠號碼可以不同。快取叢集通過群集配置來跟蹤每個緩衝主機，並維護主機間的通訊。

以下給出三個連接埠號碼的相關說明：

安全考慮：

在安裝過程中安裝程式會自動設定這些連接埠到防火牆例外列表中。卸載後的緩衝主機服務，我們建議手動根據企業的政策和伺服器上的其他應用的需要重新設定這些連接埠。在某些情況下，這可能意味著在防火牆中關閉這些連接埠。

 

9.資料分類（Data Classification ）這部分翻譯省去很多東西，只簡單介紹下概念

能過選擇適當的快取資料類型，Velocity可以為你的應用程式帶來很多好處。資料可以採取多種形式，並駐留在您的應用程式的不同層次。分布式緩衝使得不同類型的資料可以輕鬆儲存和檢索，不受服務邊界限制和語義的差異影響（後面的這句翻譯不知道對不對）

大多數應用程式的多個資料執行個體都只使用一個資料來源。比如：一個應用程式的主要資料庫中儲存的資料需要高度的資料一致性和完整性，並採取措施，以確保每一塊資料是唯一的。通常在中介層和商務邏輯操作的資料是來源資料的副本，並可能與組織為了展示層中的有用資料的其他部分。正是這些中介層的緩衝的副本。

有三種類型的資料，適合於分布式緩衝：

Reference Data

Reference Data（非獨佔寫資料）是不會常發生變化的資料的一個版本。它是原資料的複本，Reference Data通常是按照配置的間隔時間周期的重新整理資料。

由於Reference Data不會經常更改，在一定程度上可以將資料緩衝，而不用在每次讀取資料時都訪問資料來源。使用Reference Data有助於提高應用程式的規模和效能。

 

Activity Data

Activity Data（獨佔寫資料）是由根據即時執行產生的業務資料的一部分。資料來源做為業務事務的一部分，在事務結束後，資料將做為曆史日誌。

例如定單資料，應用程式的Session狀態或線上購物車。考慮到購物車是一個線上的程式，每個購物車都有一個工作階段狀態。在這個購物的會話中，購物車的儲存著使用者選擇的資料。購物車資料被一個交易的事務獨佔訪問。

當購物的會話處於活動狀態時，購物車的資料是可讀可寫的，但它並不是共用的。

Resource Data

並不是所有的資料都可能被歸為Reference (共用讀)和activity(獨佔寫)兩種資料。還有的資料可以同時被讀寫。如拍賣情境下，總是以最高價格為的資料為準。

 

 

Technorati 標籤: 微軟分布式緩衝,Velocity