前不久,俺寫了篇文章談到了.NET下面的分布式緩存的一些問題,并結合DNT里面實現模式發表了一些自己的看法，近來通過學習相關的東西又有了一些新的體會, 寫在這里作為分布式緩存列系文章的第二部分.

　　其實對于性的擴展無非是Scale Up(向上擴展）或者是Scale Out(向外擴展）, 微軟對此的看法是一個App的緩存最好是以它自己為物理邊界進行讀寫，而不要放到別處去，這樣帶的問題可能有對象的序列化傳送，反序列化，網絡連接開銷，跨進程的開銷，對于高性能的站點來說都是不能忽視的問題.出于對這些因素的考慮微推薦的作法不是把多個應用放在一起在多臺Server布署，而是將一個App劃分成若干個小的應用布署到不同的服務器，下面的關系圖展示了這種關系, 這樣每種應用就可以獨立管理自己的緩存數據，但是對于象用戶數據這樣的通用數據仍然會存在多處.

兩種解決方案

　　為了解決緩存同步的問題，有人想出了解決辦法, 可以參考這兩個地方，這個是MS的，這里還有一個，先來看看Peter的這個吧, 主要思想就是把要放到緩存里面的東西加上一層包裝CacheControlItem, 實現代碼請去原文出處下載.

　　每臺機器都維護一個WebFarm里面的成員服務器的列表，如果有新的服務器進來發現自己不在這個列表中則會通知其它的服務器把它加到這個名單里面。添加緩存的這程是這樣， A服務器需要插入一個新的緩存值，它把這個項目插入到自己的緩存中，然后用它初始化一個CacheControlItem并指定它的緩存策略（優先級，緩存生存時間），設定它的動作，即添加，然后把這個結象序列化通過Web傳送到每一個成員服務器，接受到這些數據的服務器跟據這個對象的Action指令，把反序列化后的對象加入到自己的緩存里面，這樣一個同步的過程就完成了，移除緩存對象的過程與之類似，只不過不需要傳送對象，只在包裝類里面設定它的Action為刪除就可以了. 當然，為了提高性能，可以實現一個異步的偵聽線程專門用來響應緩存通知的請求. 總體上講這處辦法的效率比較低，在數據量較大的情況下可能會造成大量緩存數據的同步數據流。

　　我們再來看看M$是怎么做的，它的想法類似，只不過它不在WebFarm的成員服務器之間同步緩存，而只是保證每臺機器不要讀到已經失效的緩存數據，當緩存數據失效時(相關依賴數據被更新), 通過維護一個需要通知的服務器列表依次調用每臺服務器上的WebService，如果當前服務器上存在這鍵值的緩存則使它失效.

　　這兩個老外寫的東西似乎都比較啰索，不過對初學者來說比較友好，可以一步步地知道這件事情的來龍去脈，理解會清楚更刻一些。

Memcached到底有多快?

　　看了這些如果還不滿意，那么您可以試試Memcached它可以運行在Win32平臺下，在上篇文章中我們已經提到了這個東西，但是它在.NET的平臺下面究竟表現如何？是否能象在php平臺下面一樣地優秀，我們現在來做一個簡單的測試, 對比使用.NET自帶的Cache和Memcached兩種實現方式，看看差距究竟有多大，過程是這樣，分別生成10000個字符串對象并分別設定鍵值插入到緩存中，然后再取出來，看看花費的總時間. 服務器端:memcached-1.2.1-win32, 客戶端: memcacheddotNET_clientlib-1.1.5, 服務器端的使用也比較簡單，解壓文件之后在命令行下面輸入: c:/memcached -d install 先安裝服務, 接著 c:/memcached -d start就可以了，詳細使用方法見說明文件 -h 是查看幫助, 測試環境如下:

　　Memcached服務器 : Win2003 sp1, Framework 2.0,P4 D 3.4G, 768MB 內存, 千兆網卡.

　　Memcached客戶機 : Win2003 sp1, Framework 2.0,T2060, 1G內存( 沙加的神舟筆記本;) ), 千兆網卡.

　　兩臺機器通過直連線相連.

　　.NET Cache單機測試 : P4 D 3.4G, 768MB 內存.

　　測試結果, 存取10000個條目的時間:

         Memcached

         HttpRuntime.Cache

.NET內建緩存測試代碼

NET技術：.Net下的分布式緩存(2)--實現分布式緩存同步的手段，轉載需保留來源！

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。