關于Redis的n種妙用，不僅僅是緩存
redis是鍵值對的數據庫，常用的五種數據類型為字符串類型（string），散列類型（hash），列表類型（list），集合類型（set），有序集合類型（zset）。
Redis用作緩存，主要兩個用途：高性能，高并發(fā)，因為內存天然支持高并發(fā)。
應用場景
分布式鎖（string）
setnx key value，當key不存在時，將 key 的值設為 value ，返回1。若給定的 key 已經存在，則setnx不做任何動作，返回0。
當setnx返回1時，表示獲取鎖，做完操作以后del key，表示釋放鎖，如果setnx返回0表示獲取鎖失敗，整體思路大概就是這樣，細節(jié)還是比較多的，有時間單開一篇來講解
計數器（string）
如知乎每個問題的被瀏覽器次數。
- set key 0
- incr key // incr readcount::{帖子id} 每閱讀一次
- get key // get readcount::{帖子id} 獲取閱讀量
分布式全局唯一id（string）
分布式全局唯一id的實現方式有很多，這里只介紹用redis實現。
每次獲取userId的時候，對userId加1再獲取，可以改進為如下形式：
直接獲取一段userId的最大值，緩存到本地慢慢累加，快到了userId的最大值時，再去獲取一段，一個用戶服務宕機了，也頂多一小段userId沒有用到
- set userId 0
- incr usrId //返回1
- incrby userId 1000 //返回10001
消息隊列（list）
在list里面一邊進，一邊出即可
- # 實現方式一
- # 一直往list左邊放
- lpush key value
- # key這個list有元素時，直接彈出，沒有元素被阻塞，直到等待超時或發(fā)現可彈出元素為止，上面例子超時時間為10s
- brpop key value 10
- # 實現方式二
- rpush key value
- blpop key value 10
新浪/Twitter用戶消息列表（list）
假如說小編li關注了2個微博a和b，a發(fā)了一條微博（編號為100）就執(zhí)行如下命令：
- lpush msg::li 100
b發(fā)了一條微博（編號為200）就執(zhí)行如下命令：
- lpush msg::li 200
假如想拿最近的10條消息就可以執(zhí)行如下命令（最新的消息一定在list的最左邊）：
- # 下標從0開始，[start,stop]是閉區(qū)間，都包含
- lrange msg::li 0 9
抽獎活動（set）
- # 參加抽獎活動
- sadd key {userId}
- # 獲取所有抽獎用戶，大輪盤轉起來
- smembers key
- # 抽取count名中獎者，并從抽獎活動中移除
- spop key count
- # 抽取count名中獎者，不從抽獎活動中移除
- srandmember key count
實現點贊，簽到，like等功能(set)
- # 1001用戶給8001帖子點贊
- sadd like::8001 1001
- # 取消點贊
- srem like::8001 1001
- # 檢查用戶是否點過贊
- sismember like::8001 1001
- # 獲取點贊的用戶列表
- smembers like::8001
- # 獲取點贊用戶數
- scard like::8001
- 實現關注模型，可能認識的人（set）
seven關注的人
sevenSub -> {qing, mic, james}
青山關注的人
qingSub->{seven,jack,mic,james}
Mic關注的人
MicSub->{seven,james,qing,jack,tom}
- # 返回sevenSub和qingSub的交集，即seven和青山的共同關注
- sinter sevenSub qingSub -> {mic,james}
- # 我關注的人也關注他,下面例子中我是seven
- # qing在micSub中返回1，否則返回0
- sismember micSub qing
- sismember jamesSub qing
- # 我可能認識的人,下面例子中我是seven
- # 求qingSub和sevenSub的差集，并存在sevenMayKnow集合中
- sdiffstore sevenMayKnow qingSub sevenSub -> {seven,jack}
電商商品篩選（set）
每個商品入庫的時候即會建立他的靜態(tài)標簽列表如，品牌，尺寸，處理器，內存。
- # 將拯救者y700P-001和ThinkPad-T480這兩個元素放到集合brand::lenovo
- sadd brand::lenovo 拯救者y700P-001 ThinkPad-T480
- sadd screenSize::15.6 拯救者y700P-001 機械革命Z2AIR
- sadd processor::i7 拯救者y700P-001 機械革命X8TIPlus
- # 獲取品牌為聯想，屏幕尺寸為15.6，并且處理器為i7的電腦品牌(sinter為獲取集合的交集)
- sinter brand::lenovo screenSize::15.6 processor::i7 -> 拯救者y700P-001
排行版（zset）
redis的zset天生是用來做排行榜的、好友列表, 去重, 歷史記錄等業(yè)務需求。
- # user1的用戶分數為 10
- zadd ranking 10 user1
- zadd ranking 20 user2
- # 取分數最高的3個用戶
- zrevrange ranking 0 2 withscores
過期策略
定期刪除
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提供的內存淘汰策略有如下幾種：
- noeviction 不會繼續(xù)服務寫請求 (DEL 請求可以繼續(xù)服務)，讀請求可以繼續(xù)進行。這樣可以保證不會丟失數據，但是會讓線上的業(yè)務不能持續(xù)進行。這是默認的淘汰策略。
- volatile-lru 嘗試淘汰設置了過期時間的 key，最少使用的 key 優(yōu)先被淘汰。沒有設置過期時間的 key 不會被淘汰，這樣可以保證需要持久化的數據不會突然丟失。（這個是使用最多的）
- volatile-ttl 跟上面一樣，除了淘汰的策略不是 LRU，而是 key 的剩余壽命 ttl 的值，ttl 越小越優(yōu)先被淘汰。
- volatile-random 跟上面一樣，不過淘汰的 key 是過期 key 集合中隨機的 key。
- allkeys-lru 區(qū)別于 volatile-lru，這個策略要淘汰的 key 對象是全體的 key 集合，而不只是過期的 key 集合。這意味著沒有設置過期時間的 key 也會被淘汰。
- allkeys-random 跟上面一樣，不過淘汰的策略是隨機的 key。allkeys-random 跟上面一樣，不過淘汰的策略是隨機的 key。
持久化策略
Redis的數據是存在內存中的，如果Redis發(fā)生宕機，那么數據會全部丟失，因此必須提供持久化機制。
Redis 的持久化機制有兩種，第一種是快照（RDB），第二種是 AOF 日志。快照是一次全量備份，AOF 日志是連續(xù)的增量備份。快照是內存數據的二進制序列化形式，在存儲上非常緊湊，而 AOF 日志記錄的是內存數據修改的指令記錄文本。AOF 日志在長期的運行過程中會變的無比龐大，數據庫重啟時需要加載 AOF 日志進行指令重放，這個時間就會無比漫長。所以需要定期進行 AOF 重寫，給 AOF 日志進行瘦身。
RDB是通過Redis主進程fork子進程，讓子進程執(zhí)行磁盤 IO 操作來進行 RDB 持久化，AOF 日志存儲的是 Redis 服務器的順序指令序列，AOF 日志只記錄對內存進行修改的指令記錄。即RDB記錄的是數據，AOF記錄的是指令
RDB和AOF到底該如何選擇？
- 不要僅僅使用 RDB，因為那樣會導致你丟失很多數據，因為RDB是隔一段時間來備份數據。
- 也不要僅僅使用 AOF，因為那樣有兩個問題，第一，通過 AOF 做冷備沒有RDB恢復速度快; 第二，RDB 每次簡單粗暴生成數據快照，更加健壯，可以避免 AOF 這種復雜的備份和恢復機制的 bug。
- 用RDB恢復內存狀態(tài)會丟失很多數據，重放AOP日志又很慢。Redis4.0推出了混合持久化來解決這個問題。將 rdb 文件的內容和增量的 AOF 日志文件存在一起。這里的 AOF 日志不再是全量的日志，而是自持久化開始到持久化結束的這段時間發(fā)生的增量 AOF 日志，通常這部分 AOF 日志很小。于是在 Redis 重啟的時候，可以先加載 rdb 的內容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重啟效率因此大幅得到提升。
緩存雪崩和緩存穿透
緩存雪崩是什么？
假設有如下一個系統(tǒng)，高峰期請求為5000次/秒，4000次走了緩存，只有1000次落到了數據庫上，數據庫每秒1000的并發(fā)是一個正常的指標，完全可以正常工作，但如果緩存宕機了，每秒5000次的請求會全部落到數據庫上，數據庫立馬就死掉了，因為數據庫一秒最多抗2000個請求，如果DBA重啟數據庫，立馬又會被新的請求打死了，這就是緩存雪崩。
如何解決緩存雪崩
事前：redis高可用，主從+哨兵，redis cluster，避免全盤崩潰。
事中：本地ehcache緩存 + hystrix限流&降級，避免MySQL被打死。
事后：redis持久化，快速恢復緩存數據。
緩存穿透是什么？
假如客戶端每秒發(fā)送5000個請求，其中4000個為黑客的惡意攻擊，即在數據庫中也查不到。舉個例子，用戶id為正數，黑客構造的用戶id為負數，
如果黑客每秒一直發(fā)送這4000個請求，緩存就不起作用，數據庫也很快被打死。
如何解決緩存穿透
查詢不到的數據也放到緩存，value為空，如set -999 “”
總而言之，緩存雪崩就是緩存失效，請求全部全部打到數據庫，數據庫瞬間被打死。緩存穿透就是查詢了一個一定不存在的數據，并且從存儲層查不到的數據沒有寫入緩存，這將導致這個不存在的數據每次請求都要到存儲層去查詢，失去了緩存的意義。
