應用性能優化記錄之三——前置緩存時間調整

         繼續咱們的優化之路。首先咱們在應用層這一層查看nginx的訪問日誌，發現nginx+lua緩存

的回源率很是之高。以前也說過，在前置機這一層，lua默認寫了10分鐘的緩存，所以10分鐘之

後 jimdb緩存失效，就必須回源一次，見下圖局部圖：

 

 

 

         針對這一點，必需要讓緩存10分鐘失效頻繁回源的問題獲得解決。通過我們的頭腦風

暴，大體造成了兩種方案。

        第一種：應用主推數據。當應用數據發生變動以後，主動推送數據到jimdb。 相似於生產

者-消費者模式。見下圖（紅色爲變更部分）：

       

      這樣作的好處就是緩存時間能夠設置的比較長，當數據發生變更以後，應用直接操做緩存，

回源會變的比較少。後端應用的壓力會減輕一些。當時我比較傾向於這種方案。

       第二種：應用不主動推送數據到緩存中。而是回源的時候，response header頭中帶上特定

的參數好比：cache-time=50000之類的數據。而後lua中讀到這個緩存值，做爲緩存時間，將數

據set到緩存中去

見下圖 （紅色爲變更部分） ：

     第二種方案主要是把set緩存的操做前移到了前置機lua中，後端應用發生變動的時候，只需

要delete緩存便可。

      綜合兩種方案，我的比較傾向於第一種，這樣作能夠弱化應用層的做用。可是review方案的

時候，發現還有一種特殊狀況咱們沒有考慮到：有一類數據，好比首頁數據，在應用層某個頁

面設置了生效時間以後，到指定時間，首頁數據會發生變動。考慮到這重業務的存在，又進一

步優化了一下以上的兩種方案。

 

        第一種方案改良版：

         

 

  改由後臺應用主推數據，放入的內容一次放入2份數據：當前有效的數據做爲一個cache，另

一個cache就是設置了有效期的排期數據，當後臺數據發生變動，每次都會去刪除緩存中的這

些cache，同時從新計算當前有效數據和計算設置了時間的數據排期並set緩存。這樣作，瀏覽

應用的做用能夠繼續弱化，可是後端的數據生產系統。就必需要在每個發生變動的地方

delete數據及計算有效值。依賴耦合度比較高。

 

  第二種方案改良版：

        

        這種方案數據生產應用，每次變動只需delete緩存數據便可。比較簡單。在訪問過程當中，

由瀏覽應用計算每個頁面哪個是當前有效的，而且和下一個有效頁面時間計算出當前頁面

的有效時間，做爲cache有效時間在response header返回。這樣在當前頁面失效後，會回源去

從新獲取數據。

       兩種方案各有優劣，你們都有點取捨不定。綜合考慮以後，最終採用了第二種方案。由於

當前系統改造的時間已經比較倉促了。時間離大促也很是緊張。如何在有限的時間以內最快的

完成改造，是咱們的取捨的重要權衡點。第二種方案改造點比較簡單，涉及的系統層面代碼比

較少。很是適合咱們當前的狀況。所以，改造以後。咱們成功的實現了緩存有效期的自動化變

更。再也不是每一個緩存寫死的10分鐘，有效下降了回源率。

         本次改動以後，瀏覽應用的CPU平常使用率降到了5%如下。說明此次改動仍是頗有效果

的，見下圖：