硬核!15張圖解Redis為什麼這麼快
作為一名服務端工程師,工作中你肯定和 Redis 打過交道。Redis 為什麼快,這點想必你也知道,至少為了面試也做過準備。很多人知道 Redis 快僅僅因為它是基於記憶體實現的,對於其它原因倒是模稜兩可。
那麼今天就和小萊一起看看:
圖注:- 思維導圖 -
基於記憶體實現
這點在一開始就提到過了,這裡再簡單說說。
Redis 是基於記憶體的資料庫,那不可避免的就要與磁碟資料庫做對比。對於磁碟資料庫來說,是需要將資料讀取到記憶體裡的,這個過程會受到磁碟 I/O 的限制。
而對於記憶體資料庫來說,本身資料就存在於記憶體裡,也就沒有了這方面的開銷。
高效的資料結構
Redis 中有多種資料型別,每種資料型別的底層都由一種或多種資料結構來支援。正是因為有了這些資料結構,Redis 在儲存與讀取上的速度才不受阻礙。這些資料結構有什麼特別的地方,各位看官接著往下看:
1、簡單動態字串
這個名詞可能你不熟悉,換成 SDS 肯定就知道了。這是用來處理字串的。瞭解 C 語言的都知道,它是有處理字串方法的。而 Redis 就是 C 語言實現的,那為什麼還要重複造輪子?我們從以下幾點來看:
(1)字串長度處理
這個圖是字串在 C 語言中的儲存方式,想要獲取 「Redis」的長度,需要從頭開始遍歷,直到遇到 '\0' 為止。
Redis 中怎麼操作呢?用一個 len 欄位記錄當前字串的長度。想要獲取長度只需要獲取 len 欄位即可。你看,差距不言自明。前者遍歷的時間複雜度為 O(n),Redis 中 O(1) 就能拿到,速度明顯提升。
(2)記憶體重新分配
C 語言中涉及到修改字串的時候會重新分配記憶體。修改地越頻繁,記憶體分配也就越頻繁。而記憶體分配是會消耗效能的,那麼效能下降在所難免。
而 Redis 中會涉及到字串頻繁的修改操作,這種記憶體分配方式顯然就不適合了。於是 SDS 實現了兩種優化策略:
-
空間預分配
對 SDS 修改及空間擴充時,除了分配所必須的空間外,還會額外分配未使用的空間。
具體分配規則是這樣的:SDS 修改後,len 長度小於 1M,那麼將會額外分配與 len 相同長度的未使用空間。如果修改後長度大於 1M,那麼將分配1M的使用空間。
-
惰性空間釋放
當然,有空間分配對應的就有空間釋放。
SDS 縮短時,並不會回收多餘的記憶體空間,而是使用 free 欄位將多出來的空間記錄下來。如果後續有變更操作,直接使用 free 中記錄的空間,減少了記憶體的分配。
(3)二進位制安全
你已經知道了 Redis 可以儲存各種資料型別,那麼二進位制資料肯定也不例外。但二進位制資料並不是規則的字串格式,可能會包含一些特殊的字元,比如 '\0' 等。
前面我們提到過,C 中字串遇到 '\0' 會結束,那 '\0' 之後的資料就讀取不上了。但在 SDS 中,是根據 len 長度來判斷字串結束的。
看,二進位制安全的問題就解決了。
2、雙端連結串列
列表 List 更多是被當作佇列或棧來使用的。佇列和棧的特性一個先進先出,一個先進後出。雙端連結串列很好的支援了這些特性。
圖注:- 雙端連結串列 -
(1)前後節點
連結串列裡每個節點都帶有兩個指標,prev 指向前節點,next 指向後節點。這樣在時間複雜度為 O(1) 內就能獲取到前後節點。
(2)頭尾節點
你可能注意到了,頭節點裡有 head 和 tail 兩個引數,分別指向頭節點和尾節點。這樣的設計能夠對雙端節點的處理時間複雜度降至 O(1) ,對於佇列和棧來說再適合不過。同時連結串列迭代時從兩端都可以進行。
(3)連結串列長度
頭節點裡同時還有一個引數 len,和上邊提到的 SDS 裡類似,這裡是用來記錄連結串列長度的。因此獲取連結串列長度時不用再遍歷整個連結串列,直接拿到 len 值就可以了,這個時間複雜度是 O(1)。
你看,這些特性都降低了 List 使用時的時間開銷。
3、壓縮列表
雙端連結串列我們已經熟悉了。不知道你有沒有注意到一個問題:如果在一個連結串列節點中儲存一個小資料,比如一個位元組。那麼對應的就要儲存頭節點,前後指標等額外的資料。
這樣就浪費了空間,同時由於反覆申請與釋放也容易導致記憶體碎片化。這樣記憶體的使用效率就太低了。
於是,壓縮列表上場了!
它是經過特殊編碼,專門為了提升記憶體使用效率設計的。所有的操作都是通過指標與解碼出來的偏移量進行的。
並且壓縮列表的記憶體是連續分配的,遍歷的速度很快。
4、字典
Redis 作為 K-V 型資料庫,所有的鍵值都是用字典來儲存的。
日常學習中使用的字典你應該不會陌生,想查詢某個詞通過某個字就可以直接定位到,速度非常快。這裡所說的字典原理上是一樣的,通過某個 key 可以直接獲取到對應的value。
字典又稱為雜湊表,這點沒什麼可說的。雜湊表的特性大家都很清楚,能夠在 O(1) 時間複雜度內取出和插入關聯的值。
5、跳躍表
作為 Redis 中特有的資料結構-跳躍表,其在連結串列的基礎上增加了多級索引來提升查詢效率。
這是跳躍表的簡單原理圖,每一層都有一條有序的連結串列,最底層的連結串列包含了所有的元素。這樣跳躍表就可以支援在 O(logN) 的時間複雜度裡查詢到對應的節點。
下面這張是跳錶真實的儲存結構,和其它資料結構一樣,都在頭節點裡記錄了相應的資訊,減少了一些不必要的系統開銷。
合理的資料編碼
對於每一種資料型別來說,底層的支援可能是多種資料結構,什麼時候使用哪種資料結構,這就涉及到了編碼轉化的問題。
那我們就來看看,不同的資料型別是如何進行編碼轉化的:
- String:儲存數字的話,採用int型別的編碼,如果是非數字的話,採用 raw 編碼;
- List:字串長度及元素個數小於一定範圍使用 ziplist 編碼,任意條件不滿足,則轉化為 linkedlist 編碼;
- Hash:hash 物件儲存的鍵值對內的鍵和值字串長度小於一定值及鍵值對;
- Set:儲存元素為整數及元素個數小於一定範圍使用 intset 編碼,任意條件不滿足,則使用 hashtable 編碼;
- Zset:zset 物件中儲存的元素個數小於及成員長度小於一定值使用 ziplist 編碼,任意條件不滿足,則使用 skiplist 編碼。
合適的執行緒模型
Redis 快的原因還有一個是因為使用了合適的執行緒模型:
1、I/O多路複用模型
-
I/O :網路 I/O
-
多路:多個 TCP 連線
-
複用:共用一個執行緒或程序
生產環境中的使用,通常是多個客戶端連線 Redis,然後各自發送命令至 Redis 伺服器,最後服務端處理這些請求返回結果。
應對大量的請求,Redis 中使用 I/O 多路複用程式同時監聽多個套接字,並將這些事件推送到一個佇列裡,然後逐個被執行。最終將結果返回給客戶端。
2、避免上下文切換
你一定聽說過,Redis 是單執行緒的。那麼單執行緒的 Redis 為什麼會快呢?
因為多執行緒在執行過程中需要進行 CPU 的上下文切換,這個操作比較耗時。Redis 又是基於記憶體實現的,對於記憶體來說,沒有上下文切換效率就是最高的。多次讀寫都在一個CPU 上,對於記憶體來說就是最佳方案。
3、單執行緒模型
順便提一下,為什麼 Redis 是單執行緒的。
Redis 中使用了 Reactor 單執行緒模型,你可能對它並不熟悉。沒關係,只需要大概瞭解一下即可。
這張圖裡,接收到使用者的請求後,全部推送到一個佇列裡,然後交給檔案事件分派器,而它是單執行緒的工作方式。Redis 又是基於它工作的,所以說 Redis 是單執行緒的。
總結
基於記憶體實現
-
資料都儲存在記憶體裡,減少了一些不必要的 I/O 操作,操作速率很快。
高效的資料結構
-
底層多種資料結構支援不同的資料型別,支援 Redis 儲存不同的資料;
-
不同資料結構的設計,使得資料儲存時間複雜度降到最低。
合理的資料編碼
-
根據字串的長度及元素的個數適配不同的編碼格式。
合適的執行緒模型
-
I/O 多路複用模型同時監聽客戶端連線;
-
單執行緒在執行過程中不需要進行上下文切換,減少了耗時。
關於作者
作者:大家好,我是萊烏,BAT搬磚工一枚。從小公司進入大廠,一路走來收穫良多,想將這些經驗分享給有需要的人,因此建立了公眾號「IT界農民工」。定時更新,希望能幫助到你