快取中間件-快取架構的實作（下）

前言

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

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

• 瀏覽器快取
  • 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

標籤：架構設計

上一篇：K8s~為pod添加sidecar進行日志收集

下一篇：微服務到底改變了什么，你知道嗎？