為什麼我們做分布式使用Redis？

絕大部分寫業務的程式員，在實際開發中使用 Redis 的時候，隻會 Set Value 和 Get Value 兩個操作，對 Redis 整體缺乏一個認知。這裡對 Redis 常見問題做一個總結，解決大家的知識盲點。

1、為什麼使用 Redis

在項目中使用 Redis，主要考慮兩個角度：性能和并發。如果隻是為了分布式鎖這些其他功能，還有其他中間件 Zookpeer 等代替，并非一定要使用 Redis。 

性能：

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

特别是在秒殺系統，在同一時間，幾乎所有人都在點，都在下單。。。執行的是同一操作———向資料庫查資料。

根據互動效果的不同，響應時間沒有固定标準。在理想狀态下，我們的頁面跳轉需要在瞬間解決，對于頁内操作則需要在刹那間解決。

并發：

如下圖所示，在大并發的情況下，所有的請求直接通路資料庫，資料庫會出現連接配接異常。這個時候，就需要使用 Redis 做一個緩沖操作，讓請求先通路到 Redis，而不是直接通路資料庫。

使用 Redis 的常見問題

• 緩存和資料庫雙寫一緻性問題
• 緩存雪崩問題
• 緩存擊穿問題
• 緩存的并發競争問題

2、單線程的 Redis 為什麼這麼快

這個問題是對 Redis 内部機制的一個考察。很多人都不知道 Redis 是單線程工作模型。

原因主要是以下三點：

• 純記憶體操作
• 單線程操作，避免了頻繁的上下文切換
• 采用了非阻塞 I/O 多路複用機制

仔細說一說 I/O 多路複用機制，打一個比方：小名在 A 城開了一家快餐店店，負責同城快餐服務。小明因為資金限制，雇傭了一批配送員，然後小曲發現資金不夠了，隻夠買一輛車送快遞。加君羊：874811168即可免費領取架構資料一份。

經營方式一

客戶每下一份訂單，小明就讓一個配送員盯着，然後讓人開車去送。慢慢的小曲就發現了這種經營方式存在下述問題：

• 時間都花在了搶車上了，大部配置設定送員都處在閑置狀态，搶到車才能去送。
• 随着下單的增多，配送員也越來越多，小明發現快遞店裡越來越擠，沒辦法雇傭新的配送員了。
• 配送員之間的協調很花時間。

綜合上述缺點，小明痛定思痛，提出了經營方式二。

經營方式二

小明隻雇傭一個配送員。當客戶下單，小明按送達地點标注好，依次放在一個地方。最後，讓配送員依次開着車去送，送好了就回來拿下一個。上述兩種經營方式對比，很明顯第二種效率更高。

在上述比喻中：

• 每個配送員→每個線程
• 每個訂單→每個 Socket(I/O 流)
• 訂單的送達地點→Socket 的不同狀态
• 客戶送餐請求→來自用戶端的請求
• 明曲的經營方式→服務端運作的代碼
• 一輛車→CPU 的核數

于是有了如下結論：

• 經營方式一就是傳統的并發模型，每個 I/O 流(訂單)都有一個新的線程(配送員)管理。
• 經營方式二就是 I/O 多路複用。隻有單個線程(一個配送員)，通過跟蹤每個 I/O 流的狀态(每個配送員的送達地點)，來管理多個 I/O 流。

下面類比到真實的 Redis 線程模型，如圖所示：

Redis-client 在操作的時候，會産生具有不同僚件類型的 Socket。在服務端，有一段 I/O 多路複用程式，将其置入隊列之中。然後，檔案事件分派器，依次去隊列中取，轉發到不同的事件處理器中。

3、Redis 的資料類型及使用場景

一個合格的程式員，這五種類型都會用到。

String

最正常的 set/get 操作，Value 可以是 String 也可以是數字。一般做一些複雜的計數功能的緩存。

Hash

這裡 Value 存放的是結構化的對象，比較友善的就是操作其中的某個字段。我在做單點登入的時候，就是用這種資料結構存儲使用者資訊，以 CookieId 作為 Key，設定 30 分鐘為緩存過期時間，能很好的模拟出類似 Session 的效果。

List

使用 List 的資料結構，可以做簡單的消息隊列的功能。另外，可以利用 lrange 指令，做基于 Redis 的分頁功能，性能極佳，使用者體驗好。

Set

因為 Set 堆放的是一堆不重複值的集合。是以可以做全局去重的功能。我們的系統一般都是叢集部署，使用 JVM 自帶的 Set 比較麻煩。另外，就是利用交集、并集、差集等操作，可以計算共同喜好，全部的喜好，自己獨有的喜好等功能。

Sorted Set

Sorted Set 多了一個權重參數 Score，集合中的元素能夠按 Score 進行排列。可以做排行榜應用，取 TOP N 操作。Sorted Set 可以用來做延時任務。

4、Redis 的過期政策和記憶體淘汰機制

Redis 是否用到家，從這就能看出來。比如你 Redis 隻能存 5G 資料，可是你寫了 10G，那會删 5G 的資料。怎麼删的，這個問題思考過麼？

正解：Redis 采用的是定期删除+惰性删除政策。

為什麼不用定時删除政策

定時删除，用一個定時器來負責監視 Key，過期則自動删除。雖然記憶體及時釋放，但是十分消耗 CPU 資源。在大并發請求下，CPU 要将時間應用在處理請求，而不是删除 Key，是以沒有采用這一政策。

定期删除+惰性删除如何工作

定期删除，Redis 預設每個 100ms 檢查，有過期 Key 則删除。需要說明的是，Redis 不是每個 100ms 将所有的 Key 檢查一次，而是随機抽取進行檢查。如果隻采用定期删除政策，會導緻很多 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 優先移除。（不推薦）

5、Redis 和資料庫雙寫一緻性問題

一緻性問題還可以再分為最終一緻性和強一緻性。資料庫和緩存雙寫，就必然會存在不一緻的問題。前提是如果對資料有強一緻性要求，不能放緩存。我們所做的一切，隻能保證最終一緻性。

另外，我們所做的方案從根本上來說，隻能降低不一緻發生的機率。是以，有強一緻性要求的資料，不能放緩存。首先，采取正确更新政策，先更新資料庫，再删緩存。其次，因為可能存在删除緩存失敗的問題，提供一個補償措施即可，例如利用消息隊列。

6、如何應對緩存穿透和緩存雪崩問題

這兩個問題，一般中小型傳統軟體企業很難碰到。如果有大并發的項目，流量有幾百萬左右，這兩個問題一定要深刻考慮。緩存穿透，即黑客故意去請求緩存中不存在的資料，導緻所有的請求都怼到資料庫上，進而資料庫連接配接異常。

緩存穿透解決方案：

• 利用互斥鎖，緩存失效的時候，先去獲得鎖，得到鎖了，再去請求資料庫。沒得到鎖，則休眠一段時間重試。
• 采用異步更新政策，無論 Key 是否取到值，都直接傳回。Value 值中維護一個緩存失效時間，緩存如果過期，異步起一個線程去讀資料庫，更新緩存。需要做緩存預熱(項目啟動前，先加載緩存)操作。
• 提供一個能迅速判斷請求是否有效的攔截機制，比如，利用布隆過濾器，内部維護一系列合法有效的 Key。迅速判斷出，請求所攜帶的 Key 是否合法有效。如果不合法，則直接傳回。

緩存雪崩，即緩存同一時間大面積的失效，這個時候又來了一波請求，結果請求都怼到資料庫上，進而導緻資料庫連接配接異常。

緩存雪崩解決方案：

• 給緩存的失效時間，加上一個随機值，避免集體失效。
• 使用互斥鎖，但是該方案吞吐量明顯下降了。
• 雙緩存。我們有兩個緩存，緩存 A 和緩存 B。緩存 A 的失效時間為 20 分鐘，緩存 B 不設失效時間。自己做緩存預熱操作。
• 然後細分以下幾個小點：從緩存 A 讀資料庫，有則直接傳回；A 沒有資料，直接從 B 讀資料，直接傳回，并且異步啟動一個更新線程，更新線程同時更新緩存 A 和緩存 B。

7、如何解決 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 方法變成串行通路也可以。加君羊：874811168即可免費領取架構資料一份。

8、總結

Redis 在國内各大公司都能看到其身影，比如我們熟悉的新浪，阿裡，騰訊，百度，美團，小米等。學習 Redis，這幾方面尤其重要：Redis 用戶端、Redis 進階功能、Redis 持久化和開發運維常用問題探讨、Redis 複制的原理和優化政策、Redis 分布式解決方案等。

本文來自雲栖社群合作夥伴“開源中國”

本文作者：  Ala6 

原文連結