筆者做過公司多個專案的微服務架構和改造，就微服務的快取設計這個問題來發表一下自己的看法。

從3個層面來回答這個問題：

為什麼用快取？

什麼場景下使用快取？

基於快取的架構設計點

在高併發場景下，如果直接讀DB，很容易出現效能瓶頸，因此需要透過快取來減少DB的壓力，使得大量的訪問進來能夠命中快取，只有少量的需要讀DB。快取基於記憶體，可支援的併發量遠遠大於基於硬碟的資料庫。所以對於高併發設計，快取的設計必不可少。

我們都知道快取可以提升系統響應速度，那麼一般哪些場景下需要用到快取呢？我們可以列舉3個場景：

2.1 計數快取

計數對於資料庫來講，是非常繁重的任務，需要查詢大量的資料，最後得出計數結果，當資料改變的時候，需要重新刷一遍，非常影響效能。

因此可以設計一個計數服務，後端對接快取，將計數作為結果放在快取裡面，當資料改變時，呼叫計數服務增加或者減少計數。計數服務可以使用Redis進行單個計數，也可以用hash表進行批次計數。

微服務中的使用場景為閘道器中的流量控制、配額控制等計數服務。

2.2 頻繁讀+低頻寫

比如一個網上商城，商品品類資訊的更新品類相對而言是比較低的，但是幾乎所有商品相關的查詢服務都需要讀取商品的品類資訊。像這種低頻寫、高頻讀的資料，比較適合放到快取中，來提升服務效能。

2.3 較大內容的高頻讀資料

這個和2.2的主要區別是防止在快取中的量級。比如物聯網場景中的白名單資訊。接入物聯網的裝置量級一般比較大，可以到萬、千萬甚至上億級別。對於這些裝置的白名單控制不可能每次都讀取DB來做許可權驗證。因此需要設計針對大量資料的分散式快取來提升服務效能。

基於快取的架構設計點可以從2個方面來考慮：

3.1 分場景

要區分快取的實際應用場景，來進行不同的快取技術選型。對於微服務閘道器中的流量控制所用到的分散式快取，可以使用redis+本地快取技術的方案。對於商品分類資訊的存放，使用本地快取就可以滿足需求。對於大型檔案的快取，則推薦本地檔案+本地快取的方式，配合版本管理實現。

3.2 快取架構的高可用

引入快取是為了解決效能瓶頸，但是實質上是引入了更多依賴。比如使用redis，如果沒有足夠的容錯機制，redis一旦掛了，則會導致服務不可用。

可以使用分片，這樣每一個快取例項都不大，但是例項數目比較多，一方面可以實現負載均衡，防止單個例項稱為瓶頸或者熱點，另一方面如果一個例項掛了，影響面相對會小很多，高可用性大大增強。分片機制可以在客戶端實現，可以使用中介軟體實現，也可以使用Redis的Cluster的方式，分片的演算法往往都是雜湊取模，或者一致性雜湊。