天天看點

如何正确使用緩存技術

緩存技術是用來提升程式運作性能的常見手段,如你所見, 阿裡巴巴、新浪微網誌、美團網等網際網路龍頭企業都是用緩存技術來提升自己家網站的性能。然而,任何事物都有兩面性, 緩存技術使用得當帶來的好處自然不言而喻, 但是如果使用不當, 産生的副作用也夠讓人喝一壺的。

我們寫伺服器程式時,使用緩存的目的無非就是減少資料庫通路次數降低資料庫的壓力和提升程式的響應時間, 然而根據具體的使用場景又可以派生出無數種情況, 比如說

程式頻繁讀取資料庫, 但是查詢獲得的結果卻總是相同的,這部分相同的結果是不是可以放入緩存 ?

獲得查詢結果要進行複雜的運算,非常消耗時間, 運算結果是不是可以放入緩存 ?

有一些在網站每個頁面都需要使用的資料, 比如說使用者資料, 是不是可以放入緩存 ?

還有另外不勝枚舉等等各種情況,概括起來就是那些變化不那麼頻繁, 從源頭讀取又顯得耗費資源和性能的資料, 是不是都應該放入緩存 ?

既然身為行業技術風向标的淘寶、美團、新浪裡面的技術大牛們都在使用緩存技術, 那麼咱們自然也得跟上他們的腳步。 然而不知道大家有沒有聽到有這樣一種流傳甚廣說法:“在選擇一樣東西前,請先問一下自己,我喜歡嗎? 我适合嗎?我需要嗎?”, 具體到我們在工作中選擇使用某種技術,喜歡其實不應該是左右我們選擇某項技術的關鍵, 而合适和需要才是我們應該詳細考慮的。 這個道理自然也适合于是否使用緩存技術上面。

通常來講,狹義上的緩存僅指一些緩存軟體, 如memcached或redis; 而廣義上緩存不僅包括緩存軟體, 程式的記憶體空間、static變量、磁盤檔案、甚至資料庫自身, 隻要能用來放置臨時資料提升程式性能的都可以稱之為緩存。

我們在使用緩存技術提高程式性能時應該不僅僅把緩存的範圍局限于狹義的緩存技術, 而應該從廣義的緩存技術集合中, 結合自身程式的特點選擇一種合适的緩存模式。 比如說使用者資訊資料,就算全都放session之中也未嘗不可, 難不成使用者資料會有幾十上百兆不成;比如說複雜的查詢結果臨時放置的位置,建立一個表存放或存儲在磁盤檔案中亦可;比如說需要頻繁讀取的結果 , 如果是使用Java之類的語言, 那麼放在一個static變量中也可以解決問題;以上這些都是緩存技術的應用實踐。

有的同學可能會提出質疑,為什麼我們非要搞這麼多的花樣?直接使用緩存軟體不是都能解決上面這些問題嗎? 然而并不是, 因為我們在享受緩存軟體帶來的好處的同時,卻往往忽略它帶來的副作用,而這些副作用在程式的開發的初期階段往往是不會顯現出來的, 到了開發後期或者部署上線至生産環境時,問題才有可能暴露出來。 舉一個例子來側面說明下

假如我們開發一個非常簡單的網站應用程式,隻有少量的簡單資料需要存儲,那麼應該選擇什麼作為我們存儲資料的媒體? 關系資料庫或者xml檔案? 答案很顯然, xml檔案存儲方案顯然要優于關系資料庫。 我們使用資料庫存儲資料, 那麼勢必需要在伺服器安裝資料庫軟體, 建立通路使用者, 而且同樣的事情在開發環境和生産環境都需要做一遍, 跟環境相關的東西如資料庫位址、使用者名、密碼之類都還都需要存儲在某個配置檔案中, 一來二去問題就變得相對複雜了。 而存儲在xml中就簡單的多了, 直接在項目中建個目錄存儲檔案就行了, 至于xml的程式設計接口那是任何一種技術的标準配置,根本不用自己去實作。 這樣把程式部署至線上環境會友善的多, 不用考慮各種環境依賴問題。 而使用關系資料庫, 對于這類簡單的項目就是拿着牛刀去殺雞,真正的威力發揮不出來, 還把問題搞的複雜 。

在某些情況下, 緩存軟體和上面例子中的關系資料庫其實扮演的是同一個角色 ,緩存軟體真正的威力沒有發揮出來, 卻把程式搞的相對複雜,這不是得不償失的做法嗎?

是以, 在決定使用緩存軟體前, 一定先确定上面所提的廣義的緩存都沒有辦法滿足需求了,屆時再使用緩存軟體才能将它能發揮的價值最大化,或可抵消使用它帶來的副作用。

知乎:https://www.zhihu.com/people/aspwebchh

github:https://github.com/aspwebchh

email: [email protected]