1.redis適合的場景？
（1）會話快取（session cache）：redis持久化，session共享，主要用於單點登入，快取token、簡訊驗證碼、查詢頻次高資料。
（2）全頁面快取（fpc）：redis提供磁碟持久化，重啟redis例項，載入速度不會改變。
（3）佇列：提供記憶體儲存引擎list和set操作。
（4）排行榜/計數器：redis支援集合（set）和有序集合（sorted set），對遞增或遞減支援非常友好。
例如：publish news 'this is a test'，subscribe news。訂閱所有人：psubscribe ne*。
2.redis預設資料庫
（1）redis是乙個字典結構的儲存伺服器。
（2）預設共16個資料庫。檢視配置檔案：/usr/local/redis-5.0.4/redis.conf
（3）客戶端和redis建立連線，資料庫預設0庫。若切換庫名，用命令：select 1
（4）乙個空redis例項占用記憶體1m左右。
（5）使用命令：flush all，清空所有庫中的資料。flush db0，清空0庫中的資料。
（6）無許可權訪問或者全部訪問資料庫的每個庫。
（7）以編號命名，不支援自定義資料庫命名。命名以dbx命名。
（8）乙個應用程式對應乙個redis例項。
3.集群下redis
（1）不支援多個資料庫切換，只存在乙個db0庫。
（2）key批量操作有限：mset、mget必須在乙個slot槽。
（3）複製只支援一層，不支援樹形複製結構。
（4）key事務和lua支援有限：操作key必須在乙個節點上
（5）key是資料分割槽的最小粒度，不支援bigkey分割槽。
（6）redis集群預先分好16384個桶(雜湊槽)。
4.redis支援的資料型別。
（1）string：最基本資料型別，二進位制安全字串，最大大小512m。
（2）list：按新增順序保持順序的字串列表。
（3）set：無序字串集合，不存在重複的元素。
（4）sorted set：已排序的字串集合。
（5）hash：key-value對的一種集合。
5.redis執行緒
（1）redis是單程序單執行緒的，redis利用佇列技術將併發訪問變為序列訪問，消除了傳統資料庫序列控制的開銷。
（2）多執行緒處理會涉及到鎖，而且多執行緒處理會涉及到執行緒切換而消耗cpu。因為cpu不是redis的瓶頸，redis的瓶頸最有可能是機器記憶體或者網路頻寬。單執行緒無法發揮多核cpu效能，不過可以通過在單機開多個redis例項來解決。
6.redis優勢
（1）速度快，因為資料存在記憶體中，類似於hashmap，hashmap的優勢就是查詢和操作的時間複雜度都是o(1)
（2）支援豐富資料型別，支援string，list，set，sorted set，hash
（3）支援事務，操作都是原子性，所謂的原子性就是對資料的更改要麼全部執行，要麼全部不執行
（4）豐富的特性：可用於快取，訊息，按key設定過期時間，過期後將會自動刪除
7.快取雪崩
現象：（1）快取失效，大量請求訪問redis服務
（2）redis集群大面積故障
（3）redis失效，大量請求轉向mysql資料庫
（4）mysql請求急劇增加，導致伺服器宕機
（5）大量服務依賴於mysql和redis服務，各伺服器集群雪崩，直至**徹底崩潰
解決：（1）快取降級：運用ehcache等本地快取；對源服務訪問進行限流、資源隔離（熔斷）、設定開關進行自動或者人工降級。如，個性化需求不能提供服務，可以降級補充熱點資料，不至於造成前端頁面是空白。哪些業務是核心(必須保證)，哪些業務可以容許暫時不提供服務(利用靜態頁面替換)等，以及配合伺服器核心指標，來後設定整體預案。
（1.1）一般：比如有些服務偶爾因為網路抖動或者服務正在上線而超時，可以自動降級
（1.2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，並傳送告警
（1.3）錯誤：比如可用率低於90%，或者資料庫連線池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級
（1.4）嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級
（2）快取高可用性：快取層設計高可用，redis sentinel 和 redis cluster 實現高可用。
（3）redis備份和快速預熱：redis資料備份和恢復，快速快取預熱
（4）提前演練：在專案上線前，進行快取層宕掉演練，應用及後端的負載情況及可能出現的問題。
8.快取穿透
現象：快取穿透是查詢乙個不存在資料。快取redis沒有查詢到資料，需要從mysql資料庫中查詢，查不到資料不寫入快取，導致不存在資料每次請求都到資料庫查詢，造成快取穿透。
解決：若查詢資料庫為空，設定預設值存放到快取中，之後訪問可以直接到快取中獲取值，不繼續訪問資料庫。設定乙個過期時間或有值時更新快取中的值。在快取中查詢值時，可給key設定
一些格式規則，在查詢時候將不符合規則的key過濾。
9.快取併發
現象：多個redis的client同時set key引起的併發問題
解決：redis自身是單執行緒操作，多個客戶端併發操作，按照先到先執行原則，後來的會阻塞。redis在set key操作時，將其放在佇列中使其序列話，乙個乙個執行。
10.快取預熱
解決：直接寫快取重新整理頁面，上線時可手工操作；若資料量小，可在專案啟動時自行載入。最終目的是系統上線前，將資料存放到快取中，待使用者傳送請求時，直接查詢快取，不必先查詢資料庫，然後將資料快取。
11.快取擊穿
現象：某乙個key為熱點資料，訪問頻率高，處於集中式高併發訪問情況。當該key失效瞬間，大量請求擊穿快取，直接請求資料庫，好似屏風上開了乙個小洞。
解決：（1）熱點資料設定永不過期
（2）基於 redis or zookeeper 實現互斥鎖，等待第乙個請求構建完快取後，再釋放鎖，從而其它請求方可通過該 key 訪問資料。
Redis快取穿透 快取雪崩
把redis作為快取使用已經是司空見慣，但是使用redis後也可能會碰到一系列的問題，尤其是資料量很大的時候，經典的幾個問題如下 一 快取和資料庫間資料一致性問題 分布式環境下 單機就不用說了 非常容易出現快取和資料庫間的資料一致性問題，針對這一點的話，只能說，如果你的專案對快取的要求是強一致性的，...
Redis 快取穿透 快取雪崩
目錄 1.快取穿透 如何避免？如何選擇？2 快取擊穿 如何解決 3.快取雪崩 如何解決？快取穿透 一般的快取系統，都是按照key去快取查詢，如果不存在對應的value，就應該去後端系統查詢 比如db 一些惡意的請求會故意查詢不存在的key，請求量很大，就會對後端系統造成很大的壓力，或導致資料庫異常。...
redis快取穿透 快取雪崩
什麼是快取雪崩 在同一時間內大量的快取資料失效，大量的請求都會去資料庫查詢，造成快取雪崩。解決方法 這個沒有完美的解決方法，但是可以分析使用者行為，盡量讓失效時間點均勻分布，還有就是在快取失效後，通過加鎖或者佇列來控制讀資料庫寫快取的執行緒數量，比如對某國key只允許乙個執行緒查詢資料庫和快取，其他...