redis是鍵值對的數據庫，常用的五種數據類型為字符串類型（string），散列類型（hash），列表類型（list），集合類型（set），有序集合類型（zset）
Redis用作緩存，主要兩個用途：高性能，高併發，因為內存天然支持高併發
應用場景
分佈式鎖（string）
setnx key value，當key不存在時，將 key 的值設為 value ，返回1。若給定的 key 已經存在，則setnx不做任何動作，返回0。
當setnx返回1時，表示獲取鎖，做完操作以後del key，表示釋放鎖，如果setnx返回0表示獲取鎖失敗，整體思路大概就是這樣，細節還是比較多的，有時間單開一篇來講解
計數器（string）
如知乎每個問題的被瀏覽器次數
消息隊列（list）
在list裡面一邊進，一邊出即可
新浪/Twitter用戶消息列表（list）
假如說小編li關注了2個微博a和b，a發了一條微博（編號為100）就執行如下命令
b發了一條微博（編號為200）就執行如下命令：
假如想拿最近的10條消息就可以執行如下命令（最新的消息一定在list的最左邊）：
抽獎活動（set）
實現點贊，簽到，like等功能(set)
實現關注模型，可能認識的人（set）
seven關注的人
sevenSub -> {qing, mic, james}
青山關注的人
qingSub->{seven,jack,mic,james}
Mic關注的人
MicSub->{seven,james,qing,jack,tom}
電商商品篩選（set）
每個商品入庫的時候即會建立他的靜態標籤列表如，品牌，尺寸，處理器，內存
排行版（zset）
redis的zset天生是用來做排行榜的、好友列表, 去重, 歷史記錄等業務需求
過期策略
定期刪除
redis 會將每個設置了過期時間的 key 放入到一個獨立的字典中，以後會定期遍歷這個字典來刪除到期的 key。
定期刪除策略
Redis 默認會每秒進行十次過期掃描（100ms一次），過期掃描不會遍歷過期字典中所有的 key，而是採用了一種簡單的貪心策略。
從過期字典中隨機 20 個 key；
刪除這 20 個 key 中已經過期的 key；
如果過期的 key 比率超過 1/4，那就重複步驟 1；
惰性刪除
除了定期遍歷之外，它還會使用惰性策略來刪除過期的 key，所謂惰性策略就是在客戶端訪問這個 key 的時候，redis 對 key 的過期時間進行檢查，如果過期了就立即刪除，不會給你返回任何東西。
定期刪除是集中處理，惰性刪除是零散處理。
為什麼要採用定期刪除+惰性刪除2種策略呢？
如果過期就刪除。假設redis裡放了10萬個key，都設置了過期時間，你每隔幾百毫秒，就檢查10萬個key，那redis基本上就死了，cpu負載會很高的，消耗在你的檢查過期key上了
但是問題是，定期刪除可能會導致很多過期key到了時間並沒有被刪除掉，那咋整呢？所以就是惰性刪除了。這就是說，在你獲取某個key的時候，redis會檢查一下 ，這個key如果設置了過期時間那麼是否過期了？如果過期了此時就會刪除，不會給你返回任何東西。
並不是key到時間就被刪除掉，而是你查詢這個key的時候，redis再懶惰的檢查一下
通過上述兩種手段結合起來，保證過期的key一定會被幹掉。
所以說用了上述2種策略後，下面這種現象就不難解釋了：數據明明都過期了，但是還佔有著內存
內存淘汰策略
這個問題可能有小夥伴們遇到過，放到Redis中的數據怎麼沒了？
因為Redis將數據放到內存中，內存是有限的，比如redis就只能用10個G，你要是往裡面寫了20個G的數據，會咋辦？當然會幹掉10個G的數據，然後就保留10個G的數據了。那幹掉哪些數據？保留哪些數據？當然是幹掉不常用的數據，保留常用的數據了
Redis提供的內存淘汰策略有如下幾種：
1.noeviction 不會繼續服務寫請求 (DEL 請求可以繼續服務)，讀請求可以繼續進行。這樣可以保證不會丟失數據，但是會讓線上的業務不能持續進行。這是默認的淘汰策略。
2.volatile-lru 嘗試淘汰設置了過期時間的 key，最少使用的 key 優先被淘汰。沒有設置過期時間的 key 不會被淘汰，這樣可以保證需要持久化的數據不會突然丟失。（這個是使用最多的）
3.volatile-ttl 跟上面一樣，除了淘汰的策略不是 LRU，而是 key 的剩餘壽命 ttl 的值，ttl 越小越優先被淘汰。
4.volatile-random 跟上面一樣，不過淘汰的 key 是過期 key 集合中隨機的 key。
5.allkeys-lru 區別於 volatile-lru，這個策略要淘汰的 key 對象是全體的 key 集合，而不只是過期的 key 集合。這意味著沒有設置過期時間的 key 也會被淘汰。
6.allkeys-random 跟上面一樣，不過淘汰的策略是隨機的 key。allkeys-random 跟上面一樣，不過淘汰的策略是隨機的 key。
持久化策略
Redis的數據是存在內存中的，如果Redis發生宕機，那麼數據會全部丟失，因此必須提供持久化機制。
Redis 的持久化機制有兩種，第一種是快照（RDB），第二種是 AOF 日誌。快照是一次全量備份，AOF 日誌是連續的增量備份。快照是內存數據的二進制序列化形式，在存儲上非常緊湊，而 AOF 日誌記錄的是內存數據修改的指令記錄文本。AOF 日誌在長期的運行過程中會變的無比龐大，數據庫重啟時需要加載 AOF 日誌進行指令重放，這個時間就會無比漫長。所以需要定期進行 AOF 重寫，給 AOF 日誌進行瘦身。
RDB是通過Redis主進程fork子進程，讓子進程執行磁盤 IO 操作來進行 RDB 持久化，AOF 日誌存儲的是 Redis 服務器的順序指令序列，AOF 日誌只記錄對內存進行修改的指令記錄。即RDB記錄的是數據，AOF記錄的是指令
RDB和AOF到底該如何選擇？
1.不要僅僅使用 RDB，因為那樣會導致你丟失很多數據，因為RDB是隔一段時間來備份數據
2.也不要僅僅使用 AOF，因為那樣有兩個問題，第一，通過 AOF 做冷備沒有RDB恢復速度快; 第二，RDB 每次簡單粗暴生成數據快照，更加健壯，可以避免 AOF 這種複雜的備份和恢復機制的 bug
3.用RDB恢復內存狀態會丟失很多數據，重放AOP日誌又很慢。Redis4.0推出了混合持久化來解決這個問題。將 rdb 文件的內容和增量的 AOF 日誌文件存在一起。這裡的 AOF 日誌不再是全量的日誌，而是自持久化開始到持久化結束的這段時間發生的增量 AOF 日誌，通常這部分 AOF 日誌很小。於是在 Redis 重啟的時候，可以先加載 rdb 的內容，然後再重放增量 AOF 日誌就可以完全替代之前的 AOF 全量文件重放，重啟效率因此大幅得到提升。
緩存雪崩和緩存穿透
緩存雪崩是什麼？
假設有如下一個系統，高峰期請求為5000次/秒，4000次走了緩存，只有1000次落到了數據庫上，數據庫每秒1000的併發是一個正常的指標，完全可以正常工作，但如果緩存宕機了，每秒5000次的請求會全部落到數據庫上，數據庫立馬就死掉了，因為數據庫一秒最多抗2000個請求，如果DBA重啟數據庫，立馬又會被新的請求打死了，這就是緩存雪崩。
如何解決緩存雪崩
事前：redis高可用，主從+哨兵，redis cluster，避免全盤崩潰
事中：本地ehcache緩存 + hystrix限流&降級，避免MySQL被打死
事後：redis持久化，快速恢復緩存數據
緩存穿透是什麼？
假如客戶端每秒發送5000個請求，其中4000個為黑客的惡意攻擊，即在數據庫中也查不到。舉個例子，用戶id為正數，黑客構造的用戶id為負數，
如果黑客每秒一直髮送這4000個請求，緩存就不起作用，數據庫也很快被打死。
如何解決緩存穿透
查詢不到的數據也放到緩存，value為空，如set -999 “”
總而言之，緩存雪崩就是緩存失效，請求全部全部打到數據庫，數據庫瞬間被打死。緩存穿透就是查詢了一個一定不存在的數據，並且從存儲層查不到的數據沒有寫入緩存，這將導致這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義
想免費學習Java工程化、分佈式架構、高併發、高性能、深入淺出、微服務架構、Spring，MyBatis，Netty源碼分析等技術的朋友，可以加群：956058372，群裡有阿里大牛直播講解技術，以及Java大型互聯網技術的視頻免費分享給大家，歡迎進群一起深入交流學習。
