[[347497]]

本文轉(zhuǎn)載自微信公眾號(hào)「IT界農(nóng)民工」，作者萊烏 。轉(zhuǎn)載本文請(qǐng)聯(lián)系IT界農(nóng)民工公眾號(hào)。  

作為一名服務(wù)端工程師，工作中你肯定和 Redis 打過交道。Redis 為什么快，這點(diǎn)想必你也知道，至少為了面試也做過準(zhǔn)備。很多人知道 Redis 快僅僅因?yàn)樗腔趦?nèi)存實(shí)現(xiàn)的，對(duì)于其它原因倒是模棱兩可。

那么今天就和小萊一起看看：

 

- 思維導(dǎo)圖 -

基于內(nèi)存實(shí)現(xiàn)

這點(diǎn)在一開始就提到過了，這里再簡單說說。

Redis 是基于內(nèi)存的數(shù)據(jù)庫，那不可避免的就要與磁盤數(shù)據(jù)庫做對(duì)比。對(duì)于磁盤數(shù)據(jù)庫來說，是需要將數(shù)據(jù)讀取到內(nèi)存里的，這個(gè)過程會(huì)受到磁盤 I/O 的限制。

而對(duì)于內(nèi)存數(shù)據(jù)庫來說，本身數(shù)據(jù)就存在于內(nèi)存里，也就沒有了這方面的開銷。

高效的數(shù)據(jù)結(jié)構(gòu)

Redis 中有多種數(shù)據(jù)類型，每種數(shù)據(jù)類型的底層都由一種或多種數(shù)據(jù)結(jié)構(gòu)來支持。正是因?yàn)橛辛诉@些數(shù)據(jù)結(jié)構(gòu)，Redis 在存儲(chǔ)與讀取上的速度才不受阻礙。這些數(shù)據(jù)結(jié)構(gòu)有什么特別的地方，各位看官接著往下看：

 

1、簡單動(dòng)態(tài)字符串

這個(gè)名詞可能你不熟悉，換成 SDS 肯定就知道了。這是用來處理字符串的。了解 C 語言的都知道，它是有處理字符串方法的。而 Redis 就是 C 語言實(shí)現(xiàn)的，那為什么還要重復(fù)造輪子?我們從以下幾點(diǎn)來看：

(1)字符串長度處理

 

這個(gè)圖是字符串在 C 語言中的存儲(chǔ)方式，想要獲取 「Redis」的長度，需要從頭開始遍歷，直到遇到 '\0' 為止。

 

Redis 中怎么操作呢?用一個(gè) len 字段記錄當(dāng)前字符串的長度。想要獲取長度只需要獲取 len 字段即可。你看，差距不言自明。前者遍歷的時(shí)間復(fù)雜度為 O(n)，Redis 中 O(1) 就能拿到，速度明顯提升。

(2)內(nèi)存重新分配

C 語言中涉及到修改字符串的時(shí)候會(huì)重新分配內(nèi)存。修改地越頻繁，內(nèi)存分配也就越頻繁。而內(nèi)存分配是會(huì)消耗性能的，那么性能下降在所難免。

而 Redis 中會(huì)涉及到字符串頻繁的修改操作，這種內(nèi)存分配方式顯然就不適合了。于是 SDS 實(shí)現(xiàn)了兩種優(yōu)化策略：

• 空間預(yù)分配

對(duì) SDS 修改及空間擴(kuò)充時(shí)，除了分配所必須的空間外，還會(huì)額外分配未使用的空間。

具體分配規(guī)則是這樣的：SDS 修改后，len 長度小于 1M，那么將會(huì)額外分配與 len 相同長度的未使用空間。如果修改后長度大于 1M，那么將分配1M的使用空間。

• 惰性空間釋放

當(dāng)然，有空間分配對(duì)應(yīng)的就有空間釋放。

SDS 縮短時(shí)，并不會(huì)回收多余的內(nèi)存空間，而是使用 free 字段將多出來的空間記錄下來。如果后續(xù)有變更操作，直接使用 free 中記錄的空間，減少了內(nèi)存的分配。

(3)二進(jìn)制安全

你已經(jīng)知道了 Redis 可以存儲(chǔ)各種數(shù)據(jù)類型，那么二進(jìn)制數(shù)據(jù)肯定也不例外。但二進(jìn)制數(shù)據(jù)并不是規(guī)則的字符串格式，可能會(huì)包含一些特殊的字符，比如 '\0' 等。

前面我們提到過，C 中字符串遇到 '\0' 會(huì)結(jié)束，那 '\0' 之后的數(shù)據(jù)就讀取不上了。但在 SDS 中，是根據(jù) len 長度來判斷字符串結(jié)束的。

看，二進(jìn)制安全的問題就解決了。

2、雙端鏈表

列表 List 更多是被當(dāng)作隊(duì)列或棧來使用的。隊(duì)列和棧的特性一個(gè)先進(jìn)先出，一個(gè)先進(jìn)后出。雙端鏈表很好的支持了這些特性。

 

- 雙端鏈表 -

(1)前后節(jié)點(diǎn)

 

鏈表里每個(gè)節(jié)點(diǎn)都帶有兩個(gè)指針，prev 指向前節(jié)點(diǎn)，next 指向后節(jié)點(diǎn)。這樣在時(shí)間復(fù)雜度為 O(1) 內(nèi)就能獲取到前后節(jié)點(diǎn)。

(2)頭尾節(jié)點(diǎn)

 

你可能注意到了，頭節(jié)點(diǎn)里有 head 和 tail 兩個(gè)參數(shù)，分別指向頭節(jié)點(diǎn)和尾節(jié)點(diǎn)。這樣的設(shè)計(jì)能夠?qū)﹄p端節(jié)點(diǎn)的處理時(shí)間復(fù)雜度降至 O(1) ，對(duì)于隊(duì)列和棧來說再適合不過。同時(shí)鏈表迭代時(shí)從兩端都可以進(jìn)行。

(3)鏈表長度

頭節(jié)點(diǎn)里同時(shí)還有一個(gè)參數(shù) len，和上邊提到的 SDS 里類似，這里是用來記錄鏈表長度的。因此獲取鏈表長度時(shí)不用再遍歷整個(gè)鏈表，直接拿到 len 值就可以了，這個(gè)時(shí)間復(fù)雜度是 O(1)。

你看，這些特性都降低了 List 使用時(shí)的時(shí)間開銷。

3、壓縮列表

雙端鏈表我們已經(jīng)熟悉了。不知道你有沒有注意到一個(gè)問題：如果在一個(gè)鏈表節(jié)點(diǎn)中存儲(chǔ)一個(gè)小數(shù)據(jù)，比如一個(gè)字節(jié)。那么對(duì)應(yīng)的就要保存頭節(jié)點(diǎn)，前后指針等額外的數(shù)據(jù)。

這樣就浪費(fèi)了空間，同時(shí)由于反復(fù)申請(qǐng)與釋放也容易導(dǎo)致內(nèi)存碎片化。這樣內(nèi)存的使用效率就太低了。

于是，壓縮列表上場了!

 

它是經(jīng)過特殊編碼，專門為了提升內(nèi)存使用效率設(shè)計(jì)的。所有的操作都是通過指針與解碼出來的偏移量進(jìn)行的。

并且壓縮列表的內(nèi)存是連續(xù)分配的，遍歷的速度很快。

4、字典

Redis 作為 K-V 型數(shù)據(jù)庫，所有的鍵值都是用字典來存儲(chǔ)的。

日常學(xué)習(xí)中使用的字典你應(yīng)該不會(huì)陌生，想查找某個(gè)詞通過某個(gè)字就可以直接定位到，速度非?？臁＿@里所說的字典原理上是一樣的，通過某個(gè) key 可以直接獲取到對(duì)應(yīng)的value。

字典又稱為哈希表，這點(diǎn)沒什么可說的。哈希表的特性大家都很清楚，能夠在 O(1) 時(shí)間復(fù)雜度內(nèi)取出和插入關(guān)聯(lián)的值。

5、跳躍表

作為 Redis 中特有的數(shù)據(jù)結(jié)構(gòu)-跳躍表，其在鏈表的基礎(chǔ)上增加了多級(jí)索引來提升查找效率。

 

這是跳躍表的簡單原理圖，每一層都有一條有序的鏈表，最底層的鏈表包含了所有的元素。這樣跳躍表就可以支持在 O(logN) 的時(shí)間復(fù)雜度里查找到對(duì)應(yīng)的節(jié)點(diǎn)。

下面這張是跳表真實(shí)的存儲(chǔ)結(jié)構(gòu)，和其它數(shù)據(jù)結(jié)構(gòu)一樣，都在頭節(jié)點(diǎn)里記錄了相應(yīng)的信息，減少了一些不必要的系統(tǒng)開銷。

 

合理的數(shù)據(jù)編碼

對(duì)于每一種數(shù)據(jù)類型來說，底層的支持可能是多種數(shù)據(jù)結(jié)構(gòu)，什么時(shí)候使用哪種數(shù)據(jù)結(jié)構(gòu)，這就涉及到了編碼轉(zhuǎn)化的問題。

那我們就來看看，不同的數(shù)據(jù)類型是如何進(jìn)行編碼轉(zhuǎn)化的：

String：存儲(chǔ)數(shù)字的話，采用int類型的編碼，如果是非數(shù)字的話，采用 raw 編碼;

List：字符串長度及元素個(gè)數(shù)小于一定范圍使用 ziplist 編碼，任意條件不滿足，則轉(zhuǎn)化為 linkedlist 編碼;

Hash：hash 對(duì)象保存的鍵值對(duì)內(nèi)的鍵和值字符串長度小于一定值及鍵值對(duì);

Set：保存元素為整數(shù)及元素個(gè)數(shù)小于一定范圍使用 intset 編碼，任意條件不滿足，則使用 hashtable 編碼;

Zset：zset 對(duì)象中保存的元素個(gè)數(shù)小于及成員長度小于一定值使用 ziplist 編碼，任意條件不滿足，則使用 skiplist 編碼。

合適的線程模型

Redis 快的原因還有一個(gè)是因?yàn)槭褂昧撕线m的線程模型：

 

1、I/O多路復(fù)用模型

• I/O ：網(wǎng)絡(luò) I/O
• 多路：多個(gè) TCP 連接
• 復(fù)用：共用一個(gè)線程或進(jìn)程

生產(chǎn)環(huán)境中的使用，通常是多個(gè)客戶端連接 Redis，然后各自發(fā)送命令至 Redis 服務(wù)器，最后服務(wù)端處理這些請(qǐng)求返回結(jié)果。

 

應(yīng)對(duì)大量的請(qǐng)求，Redis 中使用 I/O 多路復(fù)用程序同時(shí)監(jiān)聽多個(gè)套接字，并將這些事件推送到一個(gè)隊(duì)列里，然后逐個(gè)被執(zhí)行。最終將結(jié)果返回給客戶端。

2、避免上下文切換

你一定聽說過，Redis 是單線程的。那么單線程的 Redis 為什么會(huì)快呢?

因?yàn)槎嗑€程在執(zhí)行過程中需要進(jìn)行 CPU 的上下文切換，這個(gè)操作比較耗時(shí)。Redis 又是基于內(nèi)存實(shí)現(xiàn)的，對(duì)于內(nèi)存來說，沒有上下文切換效率就是最高的。多次讀寫都在一個(gè)CPU 上，對(duì)于內(nèi)存來說就是最佳方案。

3、單線程模型

順便提一下，為什么 Redis 是單線程的。

Redis 中使用了 Reactor 單線程模型，你可能對(duì)它并不熟悉。沒關(guān)系，只需要大概了解一下即可。

 

這張圖里，接收到用戶的請(qǐng)求后，全部推送到一個(gè)隊(duì)列里，然后交給文件事件分派器，而它是單線程的工作方式。Redis 又是基于它工作的，所以說 Redis 是單線程的。

總結(jié)

基于內(nèi)存實(shí)現(xiàn)

• 數(shù)據(jù)都存儲(chǔ)在內(nèi)存里，減少了一些不必要的 I/O 操作，操作速率很快。

高效的數(shù)據(jù)結(jié)構(gòu)

• 底層多種數(shù)據(jù)結(jié)構(gòu)支持不同的數(shù)據(jù)類型，支持 Redis 存儲(chǔ)不同的數(shù)據(jù);
• 不同數(shù)據(jù)結(jié)構(gòu)的設(shè)計(jì)，使得數(shù)據(jù)存儲(chǔ)時(shí)間復(fù)雜度降到最低。

合理的數(shù)據(jù)編碼

• 根據(jù)字符串的長度及元素的個(gè)數(shù)適配不同的編碼格式。

合適的線程模型

• I/O 多路復(fù)用模型同時(shí)監(jiān)聽客戶端連接;
• 單線程在執(zhí)行過程中不需要進(jìn)行上下文切換，減少了耗時(shí)。