摘要：?相信很多研發同學都有過引入緩存進入到應用架構設計中的經歷，本文從幾個角度闡述一些選型誤區和使用誤區以及高階使用技巧等，供開發者參考。

阿里云高級解決方案架構師 楊旭

世界最大混合云的總架構師，4年前，開始作為雙11阿里云技術負責人，負責搭建全球最大的混合云結構，把 “雙11”的電商業務和技術場景在阿里云上實現，并保障這個混合云在雙11當天能夠滿足全球客戶的購物需求。

正文

相信很多研發同學都有過引入緩存進入到應用架構設計中的經歷，本文從幾個角度闡述一些選型誤區和使用誤區以及高階使用技巧等，供開發者參考。

1. 什么情況下開始考慮緩存？

緩存的主要目的是為了擋一些讀多寫少的用戶請求，且數據在一定時間周期內保持不變，再且業務允許一定時間差而導致的臟數據。假設你的業務直接讀寫持久化存儲(比如mysql)的壓力不大，換言之持久化存儲的水位還較低可控范圍內，那么不建議引入緩存，不但增加了一道依賴提高了系統復雜度，而且并沒有帶來可觀的解決問題收益。引入緩存是為了提高系統承載能力且有效減少對后端持久化存儲的沖擊。遵循架構簡單適用的原則，不要為了使用緩存而使用。

2. 確定引入緩存后我該如何設計內部數據結構和緩存服務架構？

先說緩存數據結構，這里往往存在使用誤區，不少開發者將大字節key-value型數據寫入緩存系統，業務頻繁讀取，那么問題來了，從普通緩存服務器的網卡能力來看，幾K甚至幾十K大小的key-value，QPS上不了多少就會打爆網卡，因此數據大小遵循小夠用原則，而不是什么都往里面放。

另外內存型緩存更關注整體內存使用量，業務的key數量以及平均key大小跟內存之間的博弈，同時務必合理設置數據過期時間。不推薦復雜數據結構和時間復雜度高的操作，比如redis的執行時間為O(N)的指令集。最后最重要一點切記把內存型緩存當做持久存儲對待，從應用系統設計上內存型緩存是要考慮隨時丟失的場景。

至于緩存服務架構如何選擇，有幾種供參考，單master模式，master-slave模式(快速切換)，集群模式(有必要進行業務數據分片)等。外加運維管控系統，常見的緩存服務結構：

Figure 3來源阿里云ApsaraDB for Redis

3. 幾種高階使用場景介紹

針對一些常見的緩存大規模使用場景，介紹幾例高階的用法：

一、 大流量下緩存前置架構以提高服務性能。比如APP_A請求APP_B，正常路徑從APP_A → APP_B → Cache，前置做法簡單的說是APP_A內嵌APP_B的client，以達到直接讀取Cache，請求不經過APP_B。這兒也有個問題，APP_B的研發同學需要把控好plugin到APP_A的客戶端，比如權限的收放，哪些可以在客戶端里做，哪些操作不能在客戶端側做，根據業務實際場景斟酌。

二、 SmartClient智能客戶端。客戶端可以根據配置變更動態做出變化，比如QPS限流，白名單等等策略，通過配置動態更新通知客戶端做相應的預期調整。舉個例子，流量突增導致緩存壓力過大，通過配置變更使得客戶端部分讀緩存改為走讀mysql，有效分擔緩存系統壓力。

三、 復雜緩存失效場景如何解？除了根據業務場景主動設置數據過期時間，還有幾種情況，比如因數據請求更新mysql完畢，同時應用觸發更新cache數據以達到緩存和mysql的數據一致性，此外假設還有跨機房集群而需要多個集群失效保持同步，一般會通過主動失效服務來做多側的同步失效。如圖中的“失效中心”角色:

Figure 4來源阿里巴巴內部業務系統

【往期回顧】
1.阿里云王牌架構師一問開發者：我需要一個高并發的架構，我的系統要改造成微服務嗎
https://yq.aliyun.com/articles/623271?spm=a2c4e.11155435.0.0.120433122PgFrW

2.阿里云王牌架構師二問開發者：容器和虛擬化你會怎么選？
https://yq.aliyun.com/articles/623272?spm=a2c4e.11155435.0.0.120433122PgFrW

3.阿里云王牌架構師楊曦：N多環境N多應用個性配置管理如何從混亂到簡單？
https://yq.aliyun.com/articles/623882?spm=a2c4e.11155435.0.0.7a783312apAOKE

原文鏈接

本文為云棲社區原創內容，未經允許不得轉載。