快取中介軟體-快取架構的實現（下）

前言

快取架構，說白了就是利用各種手段，來實現快取，從而降低伺服器，乃至資料庫的壓力。

這裡把之前提出的快取架構的技術分類放出來：

• 瀏覽器快取
  • Cookie
  • LocalStorage
  • SessionStorage
• CDN快取
• 負載層快取
  • Nginx快取模組
  • Squid快取伺服器
  • Lua擴充套件
• 應用層快取
  • Etag
  • ThreadLocal
  • Guava
• 外部快取
  • Redis
• 資料庫快取
  • MySql快取

前面的《快取中介軟體-快取架構的實現（上）》已經簡單說明了瀏覽器快取，CDN快取，負載層快取。這次將會繼續闡述應用層快取，外部快取，資料庫快取。

應用層快取

應用層的快取，往往使用者的請求最終達到了應用伺服器，但是未達到資料庫，其涉及應用伺服器的具體開發。

Etag

之所以將Etag技術放在應用層快取，是因為使用者的請求必定達到應用層。

Etag的意思就是，如果連續兩次請求的請求內容是一致的，那麼兩次響應也應該是一致的。那麼第一次請求的響應，就可以充當第二次請求的響應。

當然實際業務中，也存在兩次請求一致，但是響應不一致（如都是查詢銀行餘額，但是並不一樣，可能兩次操作中間，工資到賬了）。這就涉及到快取的資料一致性問題，後面會提到。這裡不再深入。

那麼應用伺服器怎麼判斷兩次請求一致呢。它可以通過兩次請求的hash，進行對比判斷。其中涉及HTTP協議，如304狀態碼，請求協議頭If-None-Match欄位，響應協議頭Etag欄位。

請求流程

服務端已經做好了對應的開發與設定（如Spring的ShallowEtagHeaderFilter()）。

第一次請求

1. 客戶端發出請求RequestA
2. 服務端接收到客戶端的請求RequestA，進行以下處理：
   1. 在應用中，根據請求RequestA計算對應的MD5值
   2. 在返回響應ResponseA的協議頭中的Etag欄位設定前面計算出來的MD5值
   3. 返回對應頁面
3. 客戶端接收到響應ResponseA，在瀏覽器中展示。並在瀏覽器中快取ResponseA

第二次請求

1. 客戶端再次發出請求RequestB，並且RequestB與RequestA請求內容相同（如都是請求同一個頁面等）
2. 服務端接收到客戶端的請求RequestB，進行以下處理：
   1. 根據請求計算的新ETag，並判斷是否與請求RequestB協議頭中的If-None-Match欄位對應的值（就是之前ResponseA的ETag欄位的值）一致
      1. 如果沒有超限， 在Response中設定協議狀態為304，向客戶端返回對應ReponseB
3. 客戶端接收到響應ReponseB，確認其協議狀態為304，則直接使用之前快取的響應ResponseA，作為請求RequestB的返回響應

上述其實是功能邏輯，如果按照程式碼邏輯，其實應該這樣說：

客戶端

1. 客戶端準備傳送請求
2. 瀏覽器檢測該頁面是否有對應的ETag欄位的值
3. 如果有對應的值，就置入請求的協議頭
4. 準備妥當後，瀏覽器想伺服器傳送請求

服務端

1. 根據請求的協議頭，判斷是否具備Last-Modified/If-None-Match欄位
2. 如果有對應欄位，進行以下判斷
   1. 根據請求計算的新ETag，並判斷是否與請求協議頭中的If-None-Match欄位對應的值（就是之前ResponseA的ETag欄位的值一致
      1. 如果沒有超限，在Response中設定協議狀態為304，向客戶端返回對應Reponse
3. 如果上述2中任一條件未滿足，則執行以下邏輯：
   1. 在應用中，根據請求RequestA計算對應的MD5值，儲存在應用中
   2. 返回對應頁面
   3. 在返回響應ResponseA的協議頭中的Etag欄位設定前面計算出來的MD5值

準確地說，這應該是HTTP協議提供的快取方案，而不僅僅只是ETag。因為ETag僅僅與HTTP協議的五大條件請求首部中的If-None-Match與If-Match兩個首部相關。除此之外，還有If-Modified-Since，If-Unmodified-Since，If-Range三個條件請求首部。如果以後有機會專門寫一篇有關HTTP協議的部落格。迫切的小夥伴，也可以翻閱《HTTP權威指南》一書的第七章（尤其是7.8）。

優勢

• 降低資料庫訪問壓力。如果ETag成功，則直接返回狀態碼304，沒有資料庫操作。
• 降低應用伺服器壓力。如果ETag成功，則直接返回狀態碼304，無需業務操作等，如日誌。
• 降低頻寬壓力。根據統計表明，一般請求響應模型中，響應的報文大小遠大於請求的保溫大小。那麼如果返回響應的主體為空，只有304狀態碼等協議頭，則可以大大降低系統頻寬壓力。

缺點

• 技術學習投入。如果想要較好利用 ，需要熟悉HTTP協議的快取設計（包括理念，架構，步驟等）
• 需要對現有的業務體系，進行一定的調整
• 資料重新整理問題的處理，確保資料的“新鮮度”
• 應用系統的計算資源佔用。有人提出ETag的MD5計算帶來了對應的應用系統的CPU佔用問題。這個需要說一下：
  • 這取決於具體請求本身是否有比MD5計算更大的CPU佔用問題。
  • 合理的快取架構設計一般不會有這樣的問題（如靜態資源等CPU佔用少的請求，根本就在前面的瀏覽器，CDN，負載均衡層處理掉了）

實際應用

實際應用部分，主要有兩點需要提及。

• 由於If-None-Match的部分缺點，有需要的小夥伴最好引入Last-Modified-Since搭配使用
• 實際開發方面，Spring提供了ShallowEtagHeaderFilter()，也可以自行擴充套件

PS：部分人認為只需要Last-Modified-Since即可，但是僅使用Last-Modified-Since存在以下問題：

• 1s週期內的變化，無法處理（因為Last-Modified-Since記錄的最小時間單位為秒）
• 部分資料雖然發生了變化，但其實我們所需要的內容並沒有變化（如週期性的重寫等）
• 部分應用系統的系統時間存在衝突（即叢集內的應用伺服器例項的絕對系統時間存在秒級差別。至於叢集的時間統一相關的問題，日後有機會專門寫一篇部落格（感覺自己立下了無數flag））。

ThreadLocal

ThreadLocal是什麼，我就不在此解釋了。不瞭解的小夥伴，可以這樣理解：ThreadLocal就是一個類中的靜態Map，其key就是執行執行緒（呼叫類例項的執行緒）的name，而value就是呼叫位置設定的值。

優勢

• （核心）避免介面定義汙染。如應用系統中（同一JVM中）存在A->B->C這樣的操作鏈路。但只有A和C用到了特定引數（如使用者資訊），那麼為了能夠呼叫C，B也必須引入該特定引數（如使用者引數），即使B沒有用到該特定引數。這就造成了介面定義的汙染（詳見執行緒級快取ThreadLocalCache）
• 資料快取。由於ThreadLocal是通過棧封閉的理念實現了執行緒安全，所以其在一些場景下有著特定的使用。

缺點

• ThreadLocal快取設計與學習，及原有系統的改動
• （核心）由於可能涉及多執行緒與呼叫鏈上多個呼叫節點，所以設計與問題排查會有較大的難度

實際應用

在我之前接收的IOT專案中，終端系統通過感測器資料讀取程式與感測器配置，獲得原始資料（包括原始監測值，以及配置表中對應配置（如硬體標識，報警閾值等））。但是原始資料採集後，會進行資料清洗，資料報警評估，資料儲存等多個操作。但是其中的資料清洗並不涉及硬體標識，與報警閾值等。所以採用ThreadLocal來儲存對應資料（硬體配置），避免方法介面的汙染。當然，後來由於該流程並不都是有前後順序要求，所以添加了事件監聽，進行非同步解耦，降低系統複雜度。

GuavaCache

Guava代表著應用級快取，更準確說是單JVM例項快取。在原單機系統時，我們往往並不是採用Redis這樣的分散式快取（除非是希望利用其資料處理，如GEO處理，集合處理等），而是採用GuavaCache或自定義快取（自定義快取的設計，後面會有一篇專門的部落格）。

優勢

• 資源佔用小。畢竟只是運行於單機的一種快取工具
• 實現了一種簡便的快取管理工具，滿足了大多數單機系統對快取的需求

劣勢

• 功能沒有分散式快取中介軟體完善（尤其是自定義的快取工具）
• 如果是採用Guava這樣的第三方快取工具，需要對工具的一定學習成本
• 如果是自定義實現（為了更為精簡，定製化），往往效能的提高對技術水平有著一定的需求（如SoftReference的利用等）
• 對原有應用的改變

外部快取

外部快取的一個重要代表，就是Redis，Memcache這樣的分散式快取中介軟體。當然外部快取，你要把檔案系統等劃分進來，也不是不行，只要可以滿足對快取的定義即可。

這裡以Redis為例。

Redis

Redis作為當下最為流行的分散式快取中介軟體，其應用可以說是非常廣泛的，也是我非常喜歡使用的一種分散式快取中介軟體。其是一個開源的，C語言編寫的，基於記憶體，支援持久化的日誌型，KV型的網路程式。

優點

• 使用簡單。Redis的單機使用不要太簡單。即使是新人，也可以在很短的時間內上手，並在實際開發中應用（當然，如果專案中已經有了相關配置，並提供了相關Util就更方便了）
• 效能強悍。即使是單機的Redis，也可以在一個普通效能的伺服器上，提供每秒十萬級的讀寫能力（當然影響的情況很多，詳見redis的BenchMark）
• 功能強大。Redis提供了GEO的相關操作（計算兩點距離等），集合相關操作（交集，並集等），流相關操作（類似訊息佇列）
• 應用場景多。如Session伺服器（分散式Session的優秀解決方案），計數器（Incr），分散式鎖等

缺點

• 需要部署Redis伺服器。並且為了確保可用性，往往需要進行叢集部署
• 精通較難。
  • 功能方面。功能強大的Redis，其內部實現還是有不少東西的，包括其持久化機制，記憶體管理
  • 理論方面。如Redis記憶體管理方面，涉及LRU，LFU演算法，以及其自定義簡化版的實現。又或者其哨兵機制涉及的Raft分散式選舉演算法等
  • 部署方面。單機部署，以及多種叢集部署（生產級部署，可以看我之前的部落格-Redis安裝（單機及各類叢集，阿里雲））

實際應用

在我之前接手過的某綜合系統（涵蓋社交，線上教育，直播等），其Session伺服器是通過Redis進行支撐的。通過將<SessionId,Session>的方式，儲存在Redis，而SeesionId會儲存在使用者的Cookie中（至於某些小夥伴擔心的Cookie禁用問題，這就涉及Cookie的知識內容了。Cookie會儲存在URL中）

再舉一個例子（Redis的應用場景太多了）。之前負責的IOT專案中，其中控系統的報警模組有這麼一個需求：同一個終端的同一個感測器在30min中，只報警一次，避免報警刷屏的現象。而中控系統已經採用了Redis（中控系統是可以叢集部署，確保可用性，避免效能瓶頸），所以利用Redis的集合特性與expire特性，進行了對應的快取設計。這個在之後會專門寫一篇部落格，進行闡述。

資料庫快取

這裡說的資料庫，是指Mysql，Oracle這樣的資料庫，而不是Redis這樣的。

這裡就以Mysql舉例，這個大家應該是最熟悉的。

Mysql

Mysql快取機制，就是快取sql文字，及其對應的快取結果，通過KV形式儲存到Mysql伺服器記憶體中。之後Mysql伺服器，再次遇到同樣的sql語句，就會從快取中直接返回結果，而不需要再進行sql解析，優化，執行。

可能某些人擔心，如果資料改變了，而請求的語句是select * from xxx，那不就一直拿到舊資料了嘛。放心，mysql有這方面的處理，當對應表的資料有所修改，那麼使用了這個表的資料的快取就全部失效。所以對於經常變動的資料表，快取並沒有太大價值。

優勢

• 提升效能。同樣的語句，第一次執行可能需要1s，而第二次執行往往只需要幾毫秒。
• 避免索引時間。因為是通過請求的sql，直接從快取中獲取對應結果，所以沒有進行索引查詢操作。
• 降低資料庫磁碟操作。雖然請求到達了資料庫，但如果沒有進行硬碟操作（尋道，讀取資料等），那麼該次資料庫操作對資料庫的資源消耗就小了許多（因為在資料庫中最消耗時間的就是索引操作與硬碟操作）
• 降低資料庫資源消耗，提高查詢時間。因為其避免了資料庫獲得sql後的所有操作，取而代之的是從快取獲取資料（一個KV讀取操作，資源消耗可以幾乎可以忽略了）

缺點

• mysql快取的應用，及配置需要足夠的專業知識（一般的後端並不會非常深入這個層次，往往需要專門的DBA進行處理）
• mysql快取的判斷規則不夠智慧，提高了查詢快取的使用門檻，降低了其效率
• mysql快取的檢查與清理需要佔用一定資源
• mysql快取的記憶體管理不夠完善，會產生一定記憶體碎片（貌似mysql並不是直接採用資料庫的記憶體，就像JVM一樣。如果有不同意見的，可以私信或@我。畢竟我並不擅長資料庫，雖然剛接手的工作是進行資料庫中介軟體開發。囧）

擴充套件

• 較為深入的mysql查詢快取解釋，詳見MySQL查詢快取的優缺點
• 引數設定，詳見mysql 快取

實際應用

在我之前接收的IOT專案中，無論是終端系統，還是中控系統，往往都存在大資料量的資料查詢，單次的資料查詢往往涉及萬級，十萬級資料的查詢，並且可能頻繁查詢（就是多次重新整理頁面資料）。

一方面，我通過批量寫入（降低資料庫連線的佔用頻次），降低資料庫對應資料表的修改頻次（從原來的幾秒一次，變為一分鐘一次）。另一方面，進行資料庫快取相關配置，確保在一分鐘內的資料庫不需要進行索引操作與硬碟操作，直接返回記憶體內的結果。從而有效提高了前端頁面資料展示效果。

當然後續，我為了針對這一特定業務場景與需求，對業務稍做了調整，從而大大提高了資料查詢效果，大幅降低應用系統資源消耗（這個我會專門寫一篇部落格，甚至專門開一個系列，用來描寫這種粒度的特定業務場景的方案設計）。

布隆過濾器

之前有人私信我，認為布隆過濾器應該歸類於快取架構的一部分。

我開始認為這有一定道理，因為布隆過濾器確實涉及資料的快取，它需要以往資料的記錄，來實現。但是後來我想了想，布隆過濾器並不應該劃分為快取中，因為布隆過濾器是基於快取的，應用快取的。就像你可以說Redis快取屬於快取架構的一部分，但是你不可以說呼叫快取的應用伺服器屬於快取。所以最終，我並沒有將布隆過濾器劃分為快取的一部分。而是將它作為一種非常有意思的過濾器，一種限流方式，一種安全手段等。

不過作為擴充套件，這裡簡單說一下布隆過濾器。說白了，就是利用Hash的雜湊對映特性，進行資料過濾。如我在應用中設定一個數組Array（其所有值都為0），其長度為固定的10W。我針對每個使用者計算一個hash值，並將這個hasn值對10W進行取餘操作，獲得index值（如1000）。我將Array中第index位置的value設定為1。這樣放在生產環境後，如果有一個使用者，其計算出來的index在Array中對應位置的值為0，則說明這個使用者在系統中不存在（當然，如果是1，也並不能就說明其就是系統的使用者，畢竟存在雜湊衝突與取餘衝突，不過概率較低）。通過這樣的手段，有效避免無效請求等。

後續可能會專門寫一篇有關布隆過濾器的部落格。

總結

以上就是快取架構相關的知識了。當然，這些知識都是粒度比較大的，雖然我舉了一些實際例子，但是需要大家針對具體應用場景，進行調整應用。另外，這些知識都是比較通用的。可能在特定業務場景下，還有一些方案沒有列在這裡。最後，沒有最好的技術，只有最合適的技術。這裡的許多技術都需要一定的業務規模（資料量，請求數，併發量等），採用比較好的價效比，需要大家仔細考慮。

如果有什麼問題或者想法，可以私信或@我。

願與諸君共進步。

參考

• 《HTTP權威指南》
• Redis安裝（單機及各類叢集，阿里雲））
• 執行緒級快取ThreadLocalCache
• mysql 快取
• MySQL查詢快取的優缺點
• redis的BenchMark
• .etc