談係統緩存設計誤區及高階使用技巧

來源:每日科技快訊 2018-08-11 00:46:21

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

阿裏雲高級解決方案架構師 楊旭

世界最大混合雲的總架構師,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來源阿裏巴巴內部業務係統

點擊查看原文

相關鏈接