應用性能優化記錄之二——應用往雲上遷移所帶來的新挑戰

         接上回，既然docker中安裝redis有各類各類的問題，短期內專家又解決不了的話，那麼

考慮以後，只能變動當前系統的架構

第一種，捨棄掉前置緩存層，以下圖：

        

 

   捨棄掉這一層以後，好處就是應用往雲上遷移的工做基本就完成了。可是更大的問題是壞

處。沒有這一層以後，全部請求只要穿透CDN，直接就會打到後端應用上，形成應用不小的壓

力。一番衡量以後，以爲仍是內心沒底，放棄。

 

      第二種方案，沿用以前的架構，放棄每一個前置機docker自建redis的作法，lua去遠程redis集

羣中獲取數據。這種作法，雖然相比以前的物理機時代增長了網絡IO的開銷，可是儘可能最小的

改動原有的架構，可使應用平滑遷移到雲上。這是改過以後的架構：

 

    

      注意圖中藍色部分，前置機鏈接的緩存集羣和後端應用使用的緩存集羣是一個。 這裏採用

公司本身包裝的redis中間件-jimdb。lua腳本經過AP方式鏈接jimdb。

        當請求穿透CDN時，仍然是前置機lua去jimdb緩存拿出數據，如取到數據，就直接返回；

取不到數據，回源到應用層，應用層響應以後，把數據寫入緩存。

      這樣改過以後，應用終於遷移到雲上了。大出一口長氣。然而接下來針對單機房整個應用的

性能數據顯示。集羣最高TPS爲2000+每秒，遠遠沒有達到咱們6000+的預期指標。

      此時此刻，咱們仍是有信心的，既然達不到，那就優化吧。因而決定繼續對整個系統代碼和

架構作一些調整。到底怎麼作的呢？請聽下回優化詳解