緩衝！緩衝！緩衝！！！（一）

前言

        相信大多數開發人員都比較瞭解緩衝了,很多開發人員都在軟體開發中使用了預定義或自訂的緩衝,並從中獲得了預期的應用程式的效能提升.這篇和後續文章將詳細的介紹與探討.net體系下的緩衝實現的機制,並討論它的優點與缺點.

 

使用緩衝的實際價值:
       在kevinhoffman，lonnykruger的書中寫到：開發人員經常需要將資料(臨時資料)臨時存放到一個儲存媒體以便快速存取.這種臨時資料的儲存空間叫做緩衝.如果開發人員合理使用緩衝,則可以大幅度提高應用程式的效能.

        上面是一段完美的關於緩衝的定義,就目前而言,迅速而便捷的將資料提供給核心處理代碼已成為一個重要的設計要求。,迅速是為了增強使用者體驗，便捷可以降低系統壓力。而緩衝則可以完成任務，雖然不是那麼完美。

 

形形色色的緩衝機制幾乎都有以下一些主要共同點：
       1．提供資料臨時儲存，快取資料是否存在具有不確定性。
       2．可以設定緩衝優先順序。
       3．可以制定緩衝依賴，依賴到期則快取資料不可用。 
       4．緩衝的核心是MAP

 

關於緩衝的一些討論：

臨時緩衝VS持久緩衝：
       其實從理論上說微軟.net的緩衝解決方案是最完美的緩衝的實現，但是正因為其教科書式的實現使得不少程式員們抱怨個不停。一個可能存在的悖論是：千辛萬苦獲得的資料被塞進緩衝，因為系統記憶體緊張而被放棄，雖然它是為了緩解壓力而來。這並不是微軟的問題，而是程式員們貪得無厭的胃口和不當的使用方式所致。
      在很多的開源緩衝機制中都採用的持久緩衝的方法來實現，其實這些與其說是緩衝，我覺得更像是一個增強session，將緩衝的優先順序，緩衝依賴機制安裝在其上。開發起來既簡單又輕鬆（.net cache 牽涉了大量底層Unmanaged 程式碼）。

內容緩衝VS資料緩衝：
　　內容緩衝不是唯一的選擇,資料緩衝也不是沒有優點。雖然效能上稍有不足，但是把資料存放在資料庫中卻省去了清理緩衝的麻煩，。另一個顯而易見的優點是易於負載分配，尤其是我們擁有一個怪獸資料庫伺服器時。從實現技術上來說,麻煩的多線程問題也可以方便的轉嫁。在選擇實現內容緩衝還是資料緩衝，有很多不得不考慮的因素，花落誰家就看所開發的程式所特殊要求了.

值得重視的依賴：
          .net framework給我們提供了常用的幾個緩衝依賴：時間，檔案，資料庫。但是由於微軟一貫的作分，我們無法建立新類型的依賴（SqlCacheDependency功能何其何其之弱…）。企業庫自訂依賴是個好主意，我們只需要繼承ICacheItemExpiration介面即可！雖然我依然被依賴的生存周期和清理折騰的焦頭爛額。