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）

如知乎每個問題的被瀏覽器次數

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有元素時，直接彈出，沒有元素被阻塞，直到等待超時或發現可彈出元素為止，上面例子超時時間為10s
brpop key value 10 
# 實現方式二
rpush key value
blpop key value 10

新浪/Twitter用戶消息列表（list）

假如說小編li關注了2個微博a和b，a發了一條微博（編號為100）就執行如下命令

lpush msg::li 100

b發了一條微博（編號為200）就執行如下命令：

lpush msg::li 200

假如想拿最近的10條消息就可以執行如下命令（最新的消息一定在list的最左邊）：

# 下標從0開始，[start,stop]是閉區間，都包含
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）

每個商品入庫的時候即會建立他的靜態標簽列表如，品牌，尺寸，處理器，內存

# 將拯救者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天生是用來做排行榜的、好友列表, 去重, 歷史記錄等業務需求

# 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 不會繼續服務寫請求 (DEL 請求可以繼續服務)，讀請求可以繼續進行。這樣可以保證不會丟失數據，但是會讓線上的業務不能持續進行。這是默認的淘汰策略。
volatile-lru 嘗試淘汰設置了過期時間的 key，最少使用的 key 優先被淘汰。沒有設置過期時間的 key 不會被淘汰，這樣可以保證需要持久化的數據不會突然丟失。（這個是使用最多的）
volatile-ttl 跟上面一樣，除了淘汰的策略不是 LRU，而是 key 的剩余壽命 ttl 的值，ttl 越小越優先被淘汰。
volatile-random 跟上面一樣，不過淘汰的 key 是過期 key 集合中隨機的 key。
allkeys-lru 區別于 volatile-lru，這個策略要淘汰的 key 對象是全體的 key 集合，而不只是過期的 key 集合。這意味著沒有設置過期時間的 key 也會被淘汰。
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到底該如何選擇？

不要僅僅使用 RDB，因為那樣會導致你丟失很多數據，因為RDB是隔一段時間來備份數據
也不要僅僅使用 AOF，因為那樣有兩個問題，第一，通過 AOF 做冷備沒有RDB恢復速度快; 第二，RDB 每次簡單粗暴生成數據快照，更加健壯，可以避免 AOF 這種復雜的備份和恢復機制的 bug
用RDB恢復內存狀態會丟失很多數據，重放AOP日志又很慢。Redis4.0推出了混合持久化來解決這個問題。將 rdb 文件的內容和增量的 AOF 日志文件存在一起。這里的 AOF 日志不再是全量的日志，而是自持久化開始到持久化結束的這段時間發生的增量 AOF 日志，通常這部分 AOF 日志很小。于是在 Redis 重啟的時候，可以先加載 rdb 的內容，然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放，重啟效率因此大幅得到提升。

緩存雪崩和緩存穿透

緩存雪崩是什么？

假設有如下一個系統，高峰期請求為5000次/秒，4000次走了緩存，只有1000次落到了數據庫上，數據庫每秒1000的并發是一個正常的指標，完全可以正常工作，但如果緩存宕機了，每秒5000次的請求會全部落到數據庫上，數據庫立馬就死掉了，因為數據庫一秒最多抗2000個請求，如果DBA重啟數據庫，立馬又會被新的請求打死了，這就是緩存雪崩。