考慮到絕大部分寫業務的程式設計師，在實際開發中使用 Redis 的時候，只會 Set Value 和 Get Value 兩個操作，對 Redis 整體缺乏一個認知。所以我斗膽以 Redis 為題材，對 Redis 常見問題做一個總結，希望能夠彌補大家的知識盲點。

本文圍繞以下幾點進行闡述：

• 為什麼使用 Redis

• 使用 Redis 有什麼缺點

• 單執行緒的 Redis 為什麼這麼快

• Redis 的資料型別，以及每種資料型別的使用場景

• Redis 的過期策略以及記憶體淘汰機制

• Redis 和資料庫雙寫一致性問題

• 如何應對快取穿透和快取雪崩問題

• 如何解決 Redis 的併發競爭 Key 問題

為什麼使用 Redis

我覺得在專案中使用 Redis，主要是從兩個角度去考慮：效能和併發。

當然，Redis 還具備可以做分散式鎖等其他功能，但是如果只是為了分散式鎖這些其他功能，完全還有其他中介軟體，如 ZooKpeer 等代替，並不是非要使用 Redis。因此，這個問題主要從效能和併發兩個角度去答。點選這裡檢視Redis面試題彙總。

性 能

如下圖所示，我們在碰到需要執行耗時特別久，且結果不頻繁變動的 SQL，就特別適合將執行結果放入快取。這樣，後面的請求就去快取中讀取，使得請求能夠迅速響應。

題外話：忽然想聊一下這個迅速響應的標準。根據互動效果的不同，這個響應時間沒有固定標準。

不過曾經有人這麼告訴我："在理想狀態下，我們的頁面跳轉需要在瞬間解決，對於頁內操作則需要在剎那間解決。

另外，超過一彈指的耗時操作要有進度提示，並且可以隨時中止或取消，這樣才能給使用者最好的體驗。"

那麼瞬間、剎那、一彈指具體是多少時間呢？

根據《摩訶僧祗律》記載：

一剎那者為一念，二十念為一瞬，二十瞬為一彈指，二十彈指為一羅預，二十羅預為一須臾，一日一夜有三十須臾。

那麼，經過周密的計算，一瞬間為 0.36 秒、一剎那有 0.018 秒、一彈指長達 7.2 秒。

並 發

如下圖所示，在大併發的情況下，所有的請求直接訪問資料庫，資料庫會出現連線異常。

這個時候，就需要使用 Redis 做一個緩衝操作，讓請求先訪問到 Redis，而不是直接訪問資料庫。點選這裡檢視Redis面試題彙總。

使用 Redis 有什麼缺點

大家用 Redis 這麼久，這個問題是必須要了解的，基本上使用 Redis 都會碰到一些問題，常見的也就幾個。

回答主要是四個問題：

• 快取和資料庫雙寫一致性問題

• 快取雪崩問題

• 快取擊穿問題

• 快取的併發競爭問題

這四個問題，我個人覺得在專案中是常遇見的，具體解決方案，後文給出。

單執行緒的 Redis 為什麼這麼快

這個問題是對 Redis 內部機制的一個考察。根據我的面試經驗，很多人都不知道 Redis 是單執行緒工作模型。所以，這個問題還是應該要複習一下的。

回答主要是以下三點：

• 純記憶體操作

• 單執行緒操作，避免了頻繁的上下文切換

• 採用了非阻塞 I/O 多路複用機制

題外話：我們現在要仔細的說一說 I/O 多路複用機制，因為這個說法實在是太通俗了，通俗到一般人都不懂是什麼意思。

打一個比方：小曲在 S 城開了一家快遞店，負責同城快送服務。小曲因為資金限制，僱傭了一批快遞員，然後小曲發現資金不夠了，只夠買一輛車送快遞。

經 營 方 式 一

客戶每送來一份快遞，小曲就讓一個快遞員盯著，然後快遞員開車去送快遞。

慢慢的小曲就發現了這種經營方式存在下述問題：

• 幾十個快遞員基本上時間都花在了搶車上了，大部分快遞員都處在閒置狀態，誰搶到了車，誰就能去送快遞。

• 隨著快遞的增多，快遞員也越來越多，小曲發現快遞店裡越來越擠，沒辦法僱傭新的快遞員了。

• 快遞員之間的協調很花時間。

綜合上述缺點，小曲痛定思痛，提出了下面的經營方式。

經 營 方 式 二

小曲只僱傭一個快遞員。然後呢，客戶送來的快遞，小曲按送達地點標註好，然後依次放在一個地方。

最後，那個快遞員依次的去取快遞，一次拿一個，然後開著車去送快遞，送好了就回來拿下一個快遞。

上述兩種經營方式對比，是不是明顯覺得第二種，效率更高，更好呢？

在上述比喻中：

• 每個快遞員→每個執行緒

• 每個快遞→每個 Socket(I/O 流)

• 快遞的送達地點→Socket 的不同狀態

• 客戶送快遞請求→來自客戶端的請求

• 小曲的經營方式→服務端執行的程式碼

• 一輛車→CPU 的核數

於是我們有如下結論：

• 經營方式一就是傳統的併發模型，每個 I/O 流(快遞)都有一個新的執行緒(快遞員)管理。

• 經營方式二就是 I/O 多路複用。只有單個執行緒(一個快遞員)，通過跟蹤每個 I/O 流的狀態(每個快遞的送達地點)，來管理多個 I/O 流。

下面類比到真實的 Redis 執行緒模型，如圖所示：

簡單來說，就是我們的 redis-client 在操作的時候，會產生具有不同事件型別的 Socket。

在服務端，有一段 I/O 多路複用程式，將其置入佇列之中。然後，檔案事件分派器，依次去佇列中取，轉發到不同的事件處理器中。

需要說明的是，這個 I/O 多路複用機制，Redis 還提供了 select、epoll、evport、kqueue 等多路複用函式庫，大家可以自行去了解。

Redis 的資料型別，以及每種資料型別的使用場景

是不是覺得這個問題很基礎？我也這麼覺得。然而根據面試經驗發現，至少百分之八十的人答不上這個問題。

建議，在專案中用到後，再類比記憶，體會更深，不要硬記。基本上，一個合格的程式設計師，五種型別都會用到。

String

這個沒啥好說的，最常規的 set/get 操作，Value 可以是 String 也可以是數字。一般做一些複雜的計數功能的快取。

Hash

這裡 Value 存放的是結構化的物件，比較方便的就是操作其中的某個欄位。

我在做單點登入的時候，就是用這種資料結構儲存使用者資訊，以 CookieId 作為 Key，設定 30 分鐘為快取過期時間，能很好的模擬出類似 Session 的效果。

List

使用 List 的資料結構，可以做簡單的訊息佇列的功能。另外還有一個就是，可以利用 lrange 命令，做基於 Redis 的分頁功能，效能極佳，使用者體驗好。

Set

因為 Set 堆放的是一堆不重複值的集合。所以可以做全域性去重的功能。為什麼不用 JVM 自帶的 Set 進行去重？

因為我們的系統一般都是叢集部署，使用 JVM 自帶的 Set，比較麻煩，難道為了一個做一個全域性去重，再起一個公共服務，太麻煩了。

另外，就是利用交集、並集、差集等操作，可以計算共同喜好，全部的喜好，自己獨有的喜好等功能。

Sorted Set

Sorted Set多了一個權重引數 Score，集合中的元素能夠按 Score 進行排列。

可以做排行榜應用，取 TOP N 操作。Sorted Set 可以用來做延時任務。最後一個應用就是可以做範圍查詢。點選這裡檢視Redis面試題彙總。

Redis 的過期策略以及記憶體淘汰機制

這個問題相當重要，到底 Redis 有沒用到家，這個問題就可以看出來。

比如你 Redis 只能存 5G 資料，可是你寫了 10G，那會刪 5G 的資料。怎麼刪的，這個問題思考過麼？

還有，你的資料已經設定了過期時間，但是時間到了，記憶體佔用率還是比較高，有思考過原因麼?

回答：Redis 採用的是定期刪除+惰性刪除策略。

為什麼不用定時刪除策略

定時刪除，用一個定時器來負責監視 Key，過期則自動刪除。雖然記憶體及時釋放，但是十分消耗 CPU 資源。

在大併發請求下，CPU 要將時間應用在處理請求，而不是刪除 Key，因此沒有采用這一策略。

定期刪除+惰性刪除是如何工作

定期刪除，Redis 預設每個 100ms 檢查，是否有過期的 Key，有過期 Key 則刪除。

需要說明的是，Redis 不是每個 100ms 將所有的 Key 檢查一次，而是隨機抽取進行檢查(如果每隔 100ms，全部 Key 進行檢查，Redis 豈不是卡死)。

因此，如果只採用定期刪除策略，會導致很多 Key 到時間沒有刪除。於是，惰性刪除派上用場。

也就是說在你獲取某個 Key 的時候，Redis 會檢查一下，這個 Key 如果設定了過期時間，那麼是否過期了？如果過期了此時就會刪除。

採用定期刪除+惰性刪除就沒其他問題了麼?

不是的，如果定期刪除沒刪除 Key。然後你也沒即時去請求 Key，也就是說惰性刪除也沒生效。這樣，Redis的記憶體會越來越高。那麼就應該採用記憶體淘汰機制。

在 redis.conf 中有一行配置：

# maxmemory-policy volatile-lru

該配置就是配記憶體淘汰策略的(什麼，你沒配過？好好反省一下自己)：

• noeviction：當記憶體不足以容納新寫入資料時，新寫入操作會報錯。應該沒人用吧。

• allkeys-lru：當記憶體不足以容納新寫入資料時，在鍵空間中，移除最近最少使用的 Key。推薦使用，目前專案在用這種。

• allkeys-random：當記憶體不足以容納新寫入資料時，在鍵空間中，隨機移除某個 Key。應該也沒人用吧，你不刪最少使用 Key，去隨機刪。

• volatile-lru：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，移除最近最少使用的 Key。這種情況一般是把 Redis 既當快取，又做持久化儲存的時候才用。不推薦。

• volatile-random：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，隨機移除某個 Key。依然不推薦。

• volatile-ttl：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，有更早過期時間的 Key 優先移除。不推薦。

PS：如果沒有設定 expire 的 Key，不滿足先決條件(prerequisites)；那麼 volatile-lru，volatile-random 和 volatile-ttl 策略的行為，和 noeviction(不刪除) 基本上一致。點選這裡檢視Redis面試題彙總。

Redis 和資料庫雙寫一致性問題

一致性問題是分散式常見問題，還可以再分為最終一致性和強一致性。資料庫和快取雙寫，就必然會存在不一致的問題。

答這個問題，先明白一個前提。就是如果對資料有強一致性要求，不能放快取。我們所做的一切，只能保證最終一致性。

另外，我們所做的方案從根本上來說，只能說降低不一致發生的概率，無法完全避免。因此，有強一致性要求的資料，不能放快取。

回答：首先，採取正確更新策略，先更新資料庫，再刪快取。其次，因為可能存在刪除快取失敗的問題，提供一個補償措施即可，例如利用訊息佇列。

如何應對快取穿透和快取雪崩問題

這兩個問題，說句實在話，一般中小型傳統軟體企業，很難碰到這個問題。如果有大併發的專案，流量有幾百萬左右。這兩個問題一定要深刻考慮。

快取穿透，即黑客故意去請求快取中不存在的資料，導致所有的請求都懟到資料庫上，從而資料庫連線異常。

快取穿透解決方案：

• 利用互斥鎖，快取失效的時候，先去獲得鎖，得到鎖了，再去請求資料庫。沒得到鎖，則休眠一段時間重試。

• 採用非同步更新策略，無論 Key 是否取到值，都直接返回。Value 值中維護一個快取失效時間，快取如果過期，非同步起一個執行緒去讀資料庫，更新快取。需要做快取預熱(專案啟動前，先載入快取)操作。

• 提供一個能迅速判斷請求是否有效的攔截機制，比如，利用布隆過濾器，內部維護一系列合法有效的 Key。迅速判斷出，請求所攜帶的 Key 是否合法有效。如果不合法，則直接返回。

快取雪崩，即快取同一時間大面積的失效，這個時候又來了一波請求，結果請求都懟到資料庫上，從而導致資料庫連線異常。點選這裡檢視Redis面試題彙總。

快取雪崩解決方案：

• 給快取的失效時間，加上一個隨機值，避免集體失效。

• 使用互斥鎖，但是該方案吞吐量明顯下降了。

• 雙快取。我們有兩個快取，快取 A 和快取 B。快取 A 的失效時間為 20 分鐘，快取 B 不設失效時間。自己做快取預熱操作。

  然後細分以下幾個小點：從快取 A 讀資料庫，有則直接返回；A 沒有資料，直接從 B 讀資料，直接返回，並且非同步啟動一個更新執行緒，更新執行緒同時更新快取 A 和快取 B。

如何解決 Redis 的併發競爭 Key 問題

這個問題大致就是，同時有多個子系統去 Set 一個 Key。這個時候大家思考過要注意什麼呢？

需要說明一下，我提前百度了一下，發現答案基本都是推薦用 Redis 事務機制。

我並不推薦使用 Redis 的事務機制。因為我們的生產環境，基本都是 Redis 叢集環境，做了資料分片操作。

你一個事務中有涉及到多個 Key 操作的時候，這多個 Key 不一定都儲存在同一個 redis-server 上。因此，Redis 的事務機制，十分雞肋。

如果對這個 Key 操作，不要求順序

這種情況下，準備一個分散式鎖，大家去搶鎖，搶到鎖就做 set 操作即可，比較簡單。

如果對這個 Key 操作，要求順序

假設有一個 key1，系統 A 需要將 key1 設定為 valueA，系統 B 需要將 key1 設定為 valueB，系統 C 需要將 key1 設定為 valueC。

期望按照 key1 的 value 值按照 valueA > valueB > valueC 的順序變化。這種時候我們在資料寫入資料庫的時候，需要儲存一個時間戳。

假設時間戳如下：

系統A key 1 {valueA  3:00}
系統B key 1 {valueB  3:05}
系統C key 1 {valueC  3:10}

那麼，假設這會系統 B 先搶到鎖，將 key1 設定為{valueB 3:05}。接下來系統 A 搶到鎖，發現自己的 valueA 的時間戳早於快取中的時間戳，那就不做 set 操作了，以此類推。

其他方法，比如利用佇列，將 set 方法變成序列訪問也可以。總之，靈活變通。

總 結

本文對 Redis 的常見問題做了一個總結。大部分是自己在工作中遇到，以及之前面試別人的時候，愛問的一些問題。

另外，不推薦大家臨時抱佛腳，真正碰到一些有經驗的工程師，其實幾下就能把你問懵。最後，希望大家有所收穫吧。