互連網項目中各節點緩衝的使用總結_緩衝

在Web和App項目中， 緩衝的使用無處不在。它的使用，無非就是為了緩解兩大耗時黑戶對使用者體驗的影響，同時盡量地減少伺服器的負擔： 對磁碟的訪問 網路訪問
（ 原創文章，轉載請註明轉自Clement-Xu的csdn部落格。）
所以，緩衝的引入一般都是為了減少這兩個訪問的次數。由於互連網項目節點繁多，每個節點都會考慮自己的緩衝方案，不同節點之間也需要建立相應的協議來充分地利用緩衝。
對緩衝的選擇和使用一般需要考慮下面幾個方面： 儲存方式：包括：本機快取（非共用）、伺服器緩衝（共用）、分布式、非持久化、可持久化、等等 失效機制：包括：自動定時失效、條件觸發失效、手動失效、等等。
一個互連網應用的典型網路架構如下：

其中，每一個節點都可以使用緩衝以提高整個網路的服務效率。
瀏覽器緩衝： 一般有兩種： 頁面/檔案快取：html、圖片等由瀏覽器進行緩衝。 資料緩衝：需要緩衝的資料有資料字典等需要頻繁使用又不經常修改的資料。實現的方法可以是利用cookie、JS對象（參考： http://blog.csdn.net/clementad/article/details/46807641）、HTML5的localStorage和sessionStorage（參考： http://blog.csdn.net/clementad/article/details/46841821）、等等。
失效機制：下次請求頁面/檔案的時候，由伺服器返回狀態代碼304表示該頁面或檔案沒有更新，可以使用緩衝中的內容；否則的話就不使用緩衝。資料的緩衝由自訂的協議協商失效時機，比如可以利用某個cookie的失效來判斷資料的失效、或者瀏覽器關閉時失效。
APP緩衝： 一般有兩種方式快取資料： 資料庫（SQLite）緩衝方式 檔案快取方式
失效機制：一般需要和API伺服器協商何時失效。一種做法是：每次需要展示資料之前，向API伺服器請求最新的資料（帶上本機快取資料更新的時間戳記作為請求參數），伺服器判斷緩衝的時間戳記和伺服器資料的時間戳記，如果資料庫的資料比APP緩衝的資料新，就返回資料，否則返回一個資料無更新的標誌（類似於HTTP協議中的304/307狀態代碼）。還可以結合APP自己決定在一段時間內（比如一個小時內）不再調用API介面請求最新資料，進一步減少網路互動。
Proxy 伺服器緩衝： 一般是對頁面（包括靜態頁面和動態網頁面）和檔案（圖片、mp3、視頻、等等）進行緩衝。比如Nginx可以配置對那些頁面進行緩衝、以及什麼情況下失效。
Proxy 伺服器緩衝對於異地訪問很有用，比如web伺服器在北京、Proxy 伺服器在廣州，那麼廣州的使用者通過Proxy 伺服器訪問時，廣州的Proxy 伺服器就可以緩衝一份資料，這樣下一次廣州訪問就不用去北京拿資料了。
Web/API伺服器緩衝： 由於web/API伺服器一般都是多個伺服器分布式部署的，需要緩衝的資料有兩類： 需要共用的資料：比如使用者相關的資訊：登入後分配的token，手機驗證碼、session相關的資訊、等等。這些資料的緩衝需要放在大家都可以訪問的快取服務器中，比如redis。（Redis各種資料結構/類型的簡要區別： http://blog.csdn.net/clementad/article/details/46714293）。另外，Spring-Data定義了一些介面、註解和實現對各種緩衝的存取，可以很方便的使用。 可以不共用的資料：比如系統配置資訊、地區資訊、一些基礎資料、等等。這些資訊一般配置在資料庫或檔案中，而這些資訊一般是很少改動的，所以可以直接存放在web/API伺服器的記憶體中，比如可以用Java的ConcurrentHashMap來存放，或者使用已經封裝好的Guava Cache（參考：對Guava Cache的封裝和使用： http://blog.csdn.net/clementad/article/details/46491701）。

失效機制：一般對緩衝的資料都會設定自動失效時間，比如手機驗證碼設定兩分鐘自動失效。對於一些配置資訊，可以設定長一點的失效時間（比如一天），另外需要提供手動失效的介面，以便需要緊急修改的資料可以馬上生效。另外，某些緩衝（比如Guava Cache）會設定一個最大儲存空間，緩衝空間滿了之後，會根據一定的淘汰演算法（FIFO、LRU、LFU等，參考：  http://blog.csdn.net/clementad/article/details/48229243 ）清除掉一些資料。
應用伺服器緩衝： 一般是緩衝系統配置資訊，以及一些靜態、不需要經過計算的資訊。可以根據是否需要伺服器間同步和共用，決定使用快取服務器（如redis）、或本機快取（如Guava Cache： http://blog.csdn.net/clementad/article/details/46491701）
失效機制跟Web/API伺服器緩衝類似。
資料庫緩衝： 資料庫可以把查詢語句執行的結果緩衝起來，下次收到同樣的查詢請求時就可以直接從緩衝中擷取資料。啟用查詢快取對效能的提高效果非常明顯（參考：  http://blog.csdn.net/clementad/article/details/46806469 ）。
失效機制：緩衝空間滿了之後，會根據一定的演算法釋放一部分資料；資料庫表中某條記錄被修改了之後，跟這個記錄相關的緩衝也會被失效。
搜尋引擎等其他伺服器緩衝： 基本上所有的伺服器節點都會考慮緩衝的使用，比如Solr可以把搜尋的結果緩衝起來，下次同樣的搜尋就可以節省系統開銷。
總的來說，凡是有節點的地方，就可以有緩衝的存在。另外，CDN也可以看做是一種緩衝，把伺服器中的檔案快取到距離使用者最近的地方。