一、redis雪崩、穿透、并發(fā)等5大難題解決方案
緩存雪崩
數(shù)據(jù)未加載到緩存中，或者緩存同一時間大面積的失效，從而導致所有請求都去查數(shù)據(jù)庫，導致數(shù)據(jù)庫CPU和內(nèi)存負載過高，甚至宕機。
比如一個雪崩的簡單過程：
1、redis集群大面積故障
2、緩存失效，但依然大量請求訪問緩存服務redis
3、redis大量失效后，大量請求轉(zhuǎn)向到MySQL數(shù)據(jù)庫
4、mysql的調(diào)用量暴增，很快就扛不住了，甚至直接宕機
5、由于大量的應用服務依賴mysql和redis的服務，這個時候很快會演變成各服務器集群的雪崩，最后網(wǎng)站徹底崩潰。
如何預防緩存雪崩：
1.緩存的高可用性
緩存層設計成高可用，防止緩存大面積故障。即使個別節(jié)點、個別機器、甚至是機房宕掉，依然可以提供服務，例如 Redis Sentinel 和 Redis Cluster 都實現(xiàn)了高可用。
2.緩存降級
可以利用ehcache等本地緩存(暫時支持)，但主要還是對源服務訪問進行限流、資源隔離（熔斷）、降級等。
當訪問量劇增、服務出現(xiàn)問題仍然需要保證服務還是可用的。系統(tǒng)可以根據(jù)一些關鍵數(shù)據(jù)進行自動降級，也可以配置開關實現(xiàn)人工降級，這里會涉及到運維的配合。
降級的最終目的是保證核心服務可用，即使是有損的。
比如推薦服務中，很多都是個性化的需求，假如個性化需求不能提供服務了，可以降級補充熱點數(shù)據(jù)，不至于造成前端頁面是個大空白。
在進行降級之前要對系統(tǒng)進行梳理，比如：哪些業(yè)務是核心(必須保證)，哪些業(yè)務可以容許暫時不提供服務(利用靜態(tài)頁面替換)等，以及配合服務器核心指標，來后設置整體預案，比如：
（1）一般：比如有些服務偶爾因為網(wǎng)絡抖動或者服務正在上線而超時，可以自動降級；
（2）警告：有些服務在一段時間內(nèi)成功率有波動（如在95~100%之間），可以自動降級或人工降級，并發(fā)送告警；
（3）錯誤：比如可用率低于90%，或者數(shù)據(jù)庫連接池被打爆了，或者訪問量突然猛增到系統(tǒng)能承受的最大閥值，此時可以根據(jù)情況自動降級或者人工降級；
（4）嚴重錯誤：比如因為特殊原因數(shù)據(jù)錯誤了，此時需要緊急人工降級。
3.Redis備份和快速預熱
1)Redis數(shù)據(jù)備份和恢復
2)快速緩存預熱
4.提前演練
最后，建議還是在項目上線前，演練緩存層宕掉后，應用以及后端的負載情況以及可能出現(xiàn)的問題，對高可用提前預演，提前發(fā)現(xiàn)問題。
緩存穿透
緩存穿透是指查詢一個一不存在的數(shù)據(jù)。例如：從緩存redis沒有命中，需要從mysql數(shù)據(jù)庫查詢，查不到數(shù)據(jù)則不寫入緩存，這將導致這個不存在的數(shù)據(jù)每次請求都要到數(shù)據(jù)庫去查詢，造成緩存穿透。
解決思路：
如果查詢數(shù)據(jù)庫也為空，直接設置一個默認值存放到緩存，這樣第二次到緩沖中獲取就有值了，而不會繼續(xù)訪問數(shù)據(jù)庫。設置一個過期時間或者當有值的時候?qū)⒕彺嬷械闹堤鎿Q掉即可。
可以給key設置一些格式規(guī)則，然后查詢之前先過濾掉不符合規(guī)則的Key。
緩存并發(fā)
這里的并發(fā)指的是多個redis的client同時set key引起的并發(fā)問題。其實redis自身就是單線程操作，多個client并發(fā)操作，按照先到先執(zhí)行的原則，先到的先執(zhí)行，其余的阻塞。當然，另外的解決方案是把redis.set操作放在隊列中使其串行化，必須的一個一個執(zhí)行。
緩存預熱
緩存預熱就是系統(tǒng)上線后，將相關的緩存數(shù)據(jù)直接加載到緩存系統(tǒng)。
這樣就可以避免在用戶請求的時候，先查詢數(shù)據(jù)庫，然后再將數(shù)據(jù)緩存的問題！用戶直接查詢事先被預熱的緩存數(shù)據(jù)！
解決思路：
1、直接寫個緩存刷新頁面，上線時手工操作下；
2、數(shù)據(jù)量不大，可以在項目啟動的時候自動進行加載；
目的就是在系統(tǒng)上線前，將數(shù)據(jù)加載到緩存中。
二、Redis為什么是單線程，高并發(fā)快的3大原因詳解
Redis的高并發(fā)和快速原因
1.redis是基于內(nèi)存的，內(nèi)存的讀寫速度非常快；
2.redis是單線程的，省去了很多上下文切換線程的時間；
3.redis使用多路復用技術，可以處理并發(fā)的連接。非阻塞IO 內(nèi)部實現(xiàn)采用epoll，采用了epoll+自己實現(xiàn)的簡單的事件框架。epoll中的讀、寫、關閉、連接都轉(zhuǎn)化成了事件，然后利用epoll的多路復用特性，絕不在io上浪費一點時間。
下面重點介紹單線程設計和IO多路復用核心設計快的原因。
為什么Redis是單線程的？
1.官方答案
因為Redis是基于內(nèi)存的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器內(nèi)存的大小或者網(wǎng)絡帶寬。既然單線程容易實現(xiàn)，而且CPU不會成為瓶頸，那就順理成章地采用單線程的方案了。
2.性能指標
關于redis的性能，官方網(wǎng)站也有，普通筆記本輕松處理每秒幾十萬的請求。
3.詳細原因
1）不需要各種鎖的性能消耗
Redis的數(shù)據(jù)結(jié)構(gòu)并不全是簡單的Key-Value，還有l(wèi)ist，hash等復雜的結(jié)構(gòu)，這些結(jié)構(gòu)有可能會進行很細粒度的操作，比如在很長的列表后面添加一個元素，在hash當中添加或者刪除
一個對象。這些操作可能就需要加非常多的鎖，導致的結(jié)果是同步開銷大大增加。
總之，在單線程的情況下，就不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現(xiàn)死鎖而導致的性能消耗。
2）單線程多進程集群方案
單線程的威力實際上非常強大，每核心效率也非常高，多線程自然是可以比單線程有更高的性能上限，但是在今天的計算環(huán)境中，即使是單機多線程的上限也往往不能滿足需要了，需要進一步摸索的是多服務器集群化的方案，這些方案中多線程的技術照樣是用不上的。
所以單線程、多進程的集群不失為一個時髦的解決方案。
3）CPU消耗
采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU。
但是如果CPU成為Redis瓶頸，或者不想讓服務器其他CUP核閑置，那怎么辦？
可以考慮多起幾個Redis進程，Redis是key-value數(shù)據(jù)庫，不是關系數(shù)據(jù)庫，數(shù)據(jù)之間沒有約束。只要客戶端分清哪些key放在哪個Redis進程上就可以了。
Redis單線程的優(yōu)劣勢
單進程單線程優(yōu)勢
- 代碼更清晰，處理邏輯更簡單不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現(xiàn)死鎖而導致的性能消耗不存在多進程或者多線程導致的切換而消耗CPU
單進程單線程弊端
- 無法發(fā)揮多核CPU性能，不過可以通過在單機開多個Redis實例來完善；
IO多路復用技術
redis 采用網(wǎng)絡IO多路復用技術來保證在多連接的時候， 系統(tǒng)的高吞吐量。
多路-指的是多個socket連接，復用-指的是復用一個線程。多路復用主要有三種技術：select，poll，epoll。epoll是最新的也是目前最好的多路復用技術。
這里“多路”指的是多個網(wǎng)絡連接，“復用”指的是復用同一個線程。采用多路 I/O 復用技術可以讓單個線程高效的處理多個連接請求（盡量減少網(wǎng)絡IO的時間消耗），且Redis在內(nèi)存中操作數(shù)據(jù)的速度非常快（內(nèi)存內(nèi)的操作不會成為這里的性能瓶頸），主要以上兩點造就了Redis具有很高的吞吐量。
Redis高并發(fā)快總結(jié)
1. Redis是純內(nèi)存數(shù)據(jù)庫，一般都是簡單的存取操作，線程占用的時間很多，時間的花費主要集中在IO上，所以讀取速度快。
2. 再說一下IO，Redis使用的是非阻塞IO，IO多路復用，使用了單線程來輪詢描述符，將數(shù)據(jù)庫的開、關、讀、寫都轉(zhuǎn)換成了事件，減少了線程切換時上下文的切換和競爭。
3. Redis采用了單線程的模型，保證了每個操作的原子性，也減少了線程的上下文切換和競爭。
4. 另外，數(shù)據(jù)結(jié)構(gòu)也幫了不少忙，Redis全程使用hash結(jié)構(gòu)，讀取速度快，還有一些特殊的數(shù)據(jù)結(jié)構(gòu)，對數(shù)據(jù)存儲進行了優(yōu)化，如壓縮表，對短數(shù)據(jù)進行壓縮存儲，再如，跳表，使用有序的數(shù)據(jù)結(jié)構(gòu)加快讀取的速度。
5. 還有一點，Redis采用自己實現(xiàn)的事件分離器，效率比較高，內(nèi)部采用非阻塞的執(zhí)行方式，吞吐能力比較大。
三、Redis緩存和MySQL數(shù)據(jù)一致性方案詳解
需求起因
在高并發(fā)的業(yè)務場景下，數(shù)據(jù)庫大多數(shù)情況都是用戶并發(fā)訪問最薄弱的環(huán)節(jié)。所以，就需要使用redis做一個緩沖操作，讓請求先訪問到redis，而不是直接訪問MySQL等數(shù)據(jù)庫。
這個業(yè)務場景，主要是解決讀數(shù)據(jù)從Redis緩存，一般都是按照下圖的流程來進行業(yè)務操作。
讀取緩存步驟一般沒有什么問題，但是一旦涉及到數(shù)據(jù)更新：數(shù)據(jù)庫和緩存更新，就容易出現(xiàn)緩存(Redis)和數(shù)據(jù)庫（MySQL）間的數(shù)據(jù)一致性問題。
不管是先寫MySQL數(shù)據(jù)庫，再刪除Redis緩存；還是先刪除緩存，再寫庫，都有可能出現(xiàn)數(shù)據(jù)不一致的情況。舉一個例子：
1.如果刪除了緩存Redis，還沒有來得及寫庫MySQL，另一個線程就來讀取，發(fā)現(xiàn)緩存為空，則去數(shù)據(jù)庫中讀取數(shù)據(jù)寫入緩存，此時緩存中為臟數(shù)據(jù)。
2.如果先寫了庫，在刪除緩存前，寫庫的線程宕機了，沒有刪除掉緩存，則也會出現(xiàn)數(shù)據(jù)不一致情況。
因為寫和讀是并發(fā)的，沒法保證順序,就會出現(xiàn)緩存和數(shù)據(jù)庫的數(shù)據(jù)不一致的問題。
如來解決？這里給出兩個解決方案，先易后難，結(jié)合業(yè)務和技術代價選擇使用。
緩存和數(shù)據(jù)庫一致性解決方案
1.第一種方案：采用延時雙刪策略
在寫庫前后都進行redis.del(key)操作，并且設定合理的超時時間。
偽代碼如下：
public void write(String key,Object data){
redis.delKey(key);
db.updateData(data);
Thread.sleep(500);
redis.delKey(key);
}
具體的步驟就是：
- 先刪除緩存；再寫數(shù)據(jù)庫；休眠500毫秒；再次刪除緩存。
那么，這個500毫秒怎么確定的，具體該休眠多久呢？
需要評估自己的項目的讀數(shù)據(jù)業(yè)務邏輯的耗時。這么做的目的，就是確保讀請求結(jié)束，寫請求可以刪除讀請求造成的緩存臟數(shù)據(jù)。
當然這種策略還要考慮redis和數(shù)據(jù)庫主從同步的耗時。最后的的寫數(shù)據(jù)的休眠時間：則在讀數(shù)據(jù)業(yè)務邏輯的耗時基礎上，加幾百ms即可。比如：休眠1秒。
設置緩存過期時間
從理論上來說，給緩存設置過期時間，是保證最終一致性的解決方案。所有的寫操作以數(shù)據(jù)庫為準，只要到達緩存過期時間，則后面的讀請求自然會從數(shù)據(jù)庫中讀取新值然后回填緩存。
該方案的弊端
結(jié)合雙刪策略+緩存超時設置，這樣最差的情況就是在超時時間內(nèi)數(shù)據(jù)存在不一致，而且又增加了寫請求的耗時。
2、第二種方案：異步更新緩存(基于訂閱binlog的同步機制)
技術整體思路：
MySQL binlog增量訂閱消費+消息隊列+增量數(shù)據(jù)更新到redis
- 讀Redis：熱數(shù)據(jù)基本都在Redis寫MySQL:增刪改都是操作MySQL更新Redis數(shù)據(jù)：MySQ的數(shù)據(jù)操作binlog，來更新到Redis
Redis更新
1）數(shù)據(jù)操作主要分為兩大塊：
- 一個是全量(將全部數(shù)據(jù)一次寫入到redis)一個是增量（實時更新）
這里說的是增量,指的是mysql的update、insert、delate變更數(shù)據(jù)。
2）讀取binlog后分析 ，利用消息隊列,推送更新各臺的redis緩存數(shù)據(jù)。
這樣一旦MySQL中產(chǎn)生了新的寫入、更新、刪除等操作，就可以把binlog相關的消息推送至Redis，Redis再根據(jù)binlog中的記錄，對Redis進行更新。
其實這種機制，很類似MySQL的主從備份機制，因為MySQL的主備也是通過binlog來實現(xiàn)的數(shù)據(jù)一致性。
這里可以結(jié)合使用canal(阿里的一款開源框架)，通過該框架可以對MySQL的binlog進行訂閱，而canal正是模仿了mysql的slave數(shù)據(jù)庫的備份請求，使得Redis的數(shù)據(jù)更新達到了相同的效果。
當然，這里的消息推送工具你也可以采用別的第三方：kafka、rabbitMQ等來實現(xiàn)推送更新Redis。
