Redis內核原理及雪崩和穿透企業級架構深刻剖析4-綜合組件環境實戰

本套技術專欄是做者（秦凱新）平時工做的總結和昇華，經過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和集羣環境容量規劃等內容，請持續關注本套博客。QQ郵箱地址：1120746959@qq.com，若有任何學術交流，可隨時聯繫。

1 緩存雪崩的解決方案

• 事前：redis高可用，主從+哨兵，redis cluster，避免全盤崩潰
• 事中：本地ehcache緩存 + hystrix限流&降級，避免MySQL被打死
• 過後：redis持久化，快速恢復緩存數據

2 cache aside pattern

• 讀的時候，先讀緩存，緩存沒有的話，那麼就讀數據庫，而後取出數據後放入緩存，同時返回響應

• 更新的時候，先刪除緩存，而後再更新數據庫

3 緩存不一致問題

只有在對一個數據在併發的進行讀寫的時候，纔可能會出現這種問題

其實若是說你的併發量很低的話，特別是讀併發很低，天天訪問量就1萬次，那麼不多的狀況下，會出現剛纔描述的那種不一致的場景

可是問題是，若是天天的是上億的流量，每秒併發讀是幾萬，每秒只要有數據更新的請求，就可能會出現上述的數據庫+緩存不一致的狀況

3.1 緩存不一致問題1

• 問題：先修改數據庫，再刪除緩存，若是刪除緩存失敗了，那麼會致使數據庫中是新數據，緩存中是舊數據，數據出現不一致

• 解決思路

  先刪除緩存，再修改數據庫，若是刪除緩存成功了，若是修改數據庫失敗了，那麼數據庫中是舊數據，緩存中是空的，那麼數據不會不一致

  由於讀的時候緩存沒有，則讀數據庫中舊數據，而後更新到緩存中

3.2 緩存不一致問題2

• 數據發生了變動，先刪除了緩存，而後要去修改數據庫，此時還沒修改

  一個請求過來，去讀緩存，發現緩存空了，去查詢數據庫，查到了修改前的舊數據，放到了緩存中 數據變動的程序完成了數據庫的修改，致使此時數據庫和緩存不一致。

4 數據庫與緩存更新與讀取操做進行異步串行化

• 異步串行化

  更新數據的時候，根據數據的惟一標識，將操做路由以後，發送到一個jvm內部的隊列中，讀取數據的時候，若是發現數據不在緩存中，那麼將從新讀取數據+更新緩存的操做，根據惟一標識路由以後，也發送同一個jvm內部的隊列中。一個隊列對應一個工做線程，每一個工做線程串行拿到對應的操做，而後一條一條的執行。

  這樣的話，一個數據變動的操做，先執行，刪除緩存，而後再去更新數據庫，可是還沒完成更新， 此時若是一個讀請求過來，讀到了空的緩存，那麼能夠先將緩存更新的請求發送到隊列中，此時會在隊列中積壓，而後同步等待緩存更新完成

  這裏有一個優化點，一個隊列中，其實多個更新緩存請求串在一塊兒是沒意義的，所以能夠作過濾，若是發現隊列中已經有一個更新緩存的請求了，那麼就不用再放個更新請求操做進去了，直接等待前面的更新操做請求完成便可

  待那個隊列對應的工做線程完成了上一個操做的數據庫的修改以後，纔會去執行下一個操做，也就是緩存更新的操做，此時會從數據庫中讀取最新的值，而後寫入緩存中

  若是請求還在等待時間範圍內，不斷輪詢發現能夠取到值了，那麼就直接返回; 若是請求等待的時間超過必定時長，那麼這一次直接從數據庫中讀取當前的舊值

• 讀請求長時阻塞

  因爲讀請求進行了很是輕度的異步化，因此必定要注意讀超時的問題，每一個讀請求必須在超時時間範圍內返回，該解決方案，最大的風險點在於說，可能數據更新很頻繁，致使隊列中積壓了大量更新操做在裏面，而後讀請求會發生大量的超時，最後致使大量的請求直接走數據庫，務必經過一些模擬真實的測試，看看更新數據的頻繁是怎樣的

  另一點，由於一個隊列中，可能會積壓針對多個數據項的更新操做，所以須要根據本身的業務狀況進行測試，可能須要部署多個服務，每一個服務分攤一些數據的更新操做

  若是一個內存隊列裏竟然會擠壓100個商品的庫存修改操做，每一個庫存修改操做要耗費10ms區完成，那麼最後一個商品的讀請求，可能等待10 * 100 = 1000ms = 1s後，才能獲得數據

  這個時候就致使讀請求的長時阻塞

  必定要作根據實際業務系統的運行狀況，去進行一些壓力測試，和模擬線上環境，去看看最繁忙的時候，內存隊列可能會擠壓多少更新操做，可能會致使最後一個更新操做對應的讀請求，會hang多少時間，若是讀請求在200ms返回，若是你計算事後，哪怕是最繁忙的時候，積壓10個更新操做，最多等待200ms，那還能夠的

  若是一個內存隊列可能積壓的更新操做特別多，那麼你就要加機器，讓每一個機器上部署的服務實例處理更少的數據，那麼每一個內存隊列中積壓的更新操做就會越少

5 redis的併發競爭

• 就是多客戶端同時併發寫一個key，可能原本應該先到的數據後到了，致使數據版本錯了。或者是多客戶端同時獲取一個key，修改值以後再寫回去，只要順序錯了，數據就錯了。
• redis本身就有自然解決這個問題的CAS類的樂觀鎖方案

6 生產環境中的redis部署方案

6.1 redis部署須要考慮的問題

redis是主從架構？集羣架構？用了哪一種集羣方案？有沒有作高可用保證？有沒有開啓持久化機制確保能夠進行數據恢復？線上redis給幾個G的內存？設置了哪些參數？壓測後大家redis集羣承載多少QPS？

6.2 redis部署線上思路

• 採用redis cluster 模式，10臺機器，5臺機器部署了redis主實例，另外5臺機器部署了redis的從實例，每一個主實例掛了一個從實例，5個節點對外提供讀寫服務，每一個節點的讀寫高峯qps可能能夠達到每秒5萬，5臺機器最可能是25萬讀寫請求/s。

• 機器是什麼配置？32G內存+8核CPU+1T磁盤，可是分配給redis進程的是10g內存，通常線上生產環境，redis的內存儘可能不要超過10g，超過10g可能會有問題。

• 由於每一個主實例都掛了一個從實例，因此是高可用的，任何一個主實例宕機，都會自動故障遷移，redis從實例會自動變成主實例繼續提供讀寫服務

  你往內存裏寫的是什麼數據？每條數據的大小是多少？假如商品數據每條是10kb。100條數據是1mb，10萬條數據是1g。常駐內存的是200萬條商品數據，佔用內存是20g，僅僅不到總內存的50%。

7 總結

結合大數據在咱們工業大數據平臺的實踐，總結成一篇實踐指南，方便之後查閱反思，後續我會根據本篇博客進行代碼技術實踐實現。

凱新雲技術社區