這個話題的**於，2年前折騰redis cluster過程中，遇到的各種坑後積累出的一些想法，加上過去一年在梳理搖旺的快取系統中遇到的問題後，有必要集中寫寫這一塊，算做乙個階段性總結。
在開始往下講之前，或許部分同學會問，快取如果掛了，把快取重啟或者啟動起來不就可以了嗎？沒錯，快取掛了，確實需要盡快將快取恢復回來，但是如果認為快取掛了，就直接重啟快取就完事了，那就將問題看得過於簡單化了。對於乙個大型網際網路系統而言，這時服務呼叫方是無法對快取進行訪問操作，只能將流量完全打到服務方系統，服務方系統面對服務過載在劫難逃。接下來就不是快取宕機那麼簡單了，而是系統不可用，乃至對外服務徹底癱瘓掉。反過來說，快取啟動後，快取裡的資料已經還在初始化中，快取查詢還是無法進行，所有的流量還是會繼續打到服務方系統上。
所以如果出現快取宕機，我們需要考慮兩方面的問題：
快取恢復前，如何保證系統能繼續正常有序的工作快取恢復後，如何保證快取在k/v恢復前，對應的服務不會過載。
以上這兩個問題，才是本文真正想討論的問題。以下部分，會針對以上兩個問題分別進行討論。
快取宕機後，並且未恢復前，呼叫方系統請求通過呼叫cache，發現cache系統狀態不可用，則轉向請求服務方系統（通過介面從資料庫訪問資料），我們可選的方案如下：
a. 發現快取不可用，不進一步呼叫服務提供方系統，直接返回預先設定的系統預設值。
b. 發現快取不可用，呼叫方系統按照一定的比率或者概率，決定讓部分請求呼叫服務提供方。
c. 呼叫服務方之前，根據服務方反饋的狀態，動態決定請求是否呼叫服務方，或者直接返回預設值。
方案a 實施起來最容易，如果呼叫方知道直接呼叫服務提供方系統可能扛不住自己的全部流量，索性不請求服務方，等待快取恢復後在繼續訪問。但這個方案的侷限性在於，如果有寫需求，這個方案就行不通了，因為很難簡單的設定預設值, 並且，如果快取缺乏持久化的話，資料快取的更新是需要一次次呼叫來初始化的。
方案b的方案的優點在於，讓一部分執行緒請求服務方系統，保證資料能及時更新的同時，快取也能持續初始化，至於讓多少比例的流量直接呼叫服務，保守的做法就是保證呼叫方的併發不大於服務方的最大吞吐量。所以，在採用b方案之前，一定要做好效能或者壓力測試。
方案c的做法，實際上類似於上篇我寫的hystrix的circuit-breaker機制，如果服務方系統執行正常，執行請求；如果服務方系統過載，則拒絕服務，保護服務提供方的同時，最大限度挖掘服務方效能。可以參考的效能引數有cpu負載、記憶體使用率、gc頻率、介面響應時間等。
總結一下，方案c應該是系統應對快取宕機的改進方向，但是如果時間有限的前提下，可以先利用短平快的方案b實施起來。
接下來，我們來討論一下第二個問題，cache已經從宕機過程恢復過來了，如果快取key的數量較少，那麼自然不用擔心，很快快取將預熱成功，也不會有引起服務過載的情況出現。但是如果快取的量或者當前前端過來的流量不好估計的時候，是不建議貿然將流量直接切過來的。
為了保證系統能順利恢復正常，我們應該採用流控的方法，循序漸進的放開流量，讓快取逐步預熱。流量控制剛開始可以為20%，然後50%，然後80%，最後全量，在放開一部分，需要實時觀察系統的狀態，根據前端流量的變化和後端的承受能力，制定放開的節奏。除此之外，強烈推薦後端系統製作專門的工具對cache進行主動性預熱，加快系統恢復的速度，特別是快取沒有做必要的持續化的時候。
閱讀原文
應對分布式快取宕機的方案
這個話題的 於，2年前折騰redis cluster過程中，遇到的各種坑後積累出的一些想法，加上過去一年在梳理搖旺的快取系統中遇到的問題後，有必要集中寫寫這一塊，算做乙個階段性總結。在開始往下講之前，或許部分同學會問，快取如果掛了，把快取重啟或者啟動起來不就可以了嗎？沒錯，快取掛了，確實需要盡快將快...
分布式快取布置方案
有時我們僅布置一台快取機器 如mencached，redis 是不夠的，因此需要分布式快取。那麼問題來了，當我們布置了多台機器，我們如何確定乙個資料應該儲存在哪一台機器上？或者說，我們怎麼知道我們要查詢的資料分布在哪一台機器上？通常有以下兩種方式 普通hash分布 一致性hash分布 下面以php為...
分布式快取
分布式快取 原則來說跟應用伺服器分布式應該是一樣，但快取是有狀態的。怎麼樣提高命中？1.最原始的演算法 那就是key hash取模，取到伺服器ip。在大量伺服器伸縮行有問題，加入一台伺服器就有可能讓所有的快取都失效。如 key hash 後是100，取10膜是0，取11膜 1，101 取10膜是1，...