作為一名服務(wù)端工程師橄教，工作中你肯定和 Redis 打過交道。Redis 為什么快喘漏，這點想必你也知道颤陶，至少為了面試也做過準(zhǔn)備。很多人知道 Redis 快僅僅因為它是基于內(nèi)存實現(xiàn)的陷遮，對于其它原因倒是模棱兩可。
那么今天就和小萊一起看看：
- 思維導(dǎo)圖 -
基于內(nèi)存實現(xiàn)
這點在一開始就提到過了垦江，這里再簡單說說帽馋。
Redis 是基于內(nèi)存的數(shù)據(jù)庫，那不可避免的就要與磁盤數(shù)據(jù)庫做對比比吭。對于磁盤數(shù)據(jù)庫來說绽族，是需要將數(shù)據(jù)讀取到內(nèi)存里的，這個過程會受到磁盤 I/O 的限制衩藤。
而對于內(nèi)存數(shù)據(jù)庫來說吧慢，本身數(shù)據(jù)就存在于內(nèi)存里，也就沒有了這方面的開銷赏表。
高效的數(shù)據(jù)結(jié)構(gòu)
Redis 中有多種數(shù)據(jù)類型检诗，每種數(shù)據(jù)類型的底層都由一種或多種數(shù)據(jù)結(jié)構(gòu)來支持。正是因為有了這些數(shù)據(jù)結(jié)構(gòu)瓢剿，Redis 在存儲與讀取上的速度才不受阻礙逢慌。這些數(shù)據(jù)結(jié)構(gòu)有什么特別的地方，各位看官接著往下看：
1间狂、簡單動態(tài)字符串
這個名詞可能你不熟悉攻泼，換成 SDS 肯定就知道了。這是用來處理字符串的。了解 C 語言的都知道忙菠，它是有處理字符串方法的何鸡。而 Redis 就是 C 語言實現(xiàn)的，那為什么還要重復(fù)造輪子牛欢？我們從以下幾點來看：
（1）字符串長度處理
這個圖是字符串在 C 語言中的存儲方式骡男，想要獲取 「Redis」的長度，需要從頭開始遍歷氢惋，直到遇到 '\0' 為止洞翩。
Redis 中怎么操作呢？用一個 len 字段記錄當(dāng)前字符串的長度焰望。想要獲取長度只需要獲取 len 字段即可骚亿。你看，差距不言自明熊赖。前者遍歷的時間復(fù)雜度為 O(n)来屠，Redis 中 O(1) 就能拿到，速度明顯提升震鹉。
（2）內(nèi)存重新分配
C 語言中涉及到修改字符串的時候會重新分配內(nèi)存俱笛。修改地越頻繁，內(nèi)存分配也就越頻繁传趾。而內(nèi)存分配是會消耗性能的迎膜，那么性能下降在所難免。
而 Redis 中會涉及到字符串頻繁的修改操作浆兰，這種內(nèi)存分配方式顯然就不適合了磕仅。于是 SDS 實現(xiàn)了兩種優(yōu)化策略：
- 空間預(yù)分配
對 SDS 修改及空間擴充時，除了分配所必須的空間外簸呈，還會額外分配未使用的空間榕订。
具體分配規(guī)則是這樣的：SDS 修改后，len 長度小于 1M蜕便，那么將會額外分配與 len 相同長度的未使用空間劫恒。如果修改后長度大于 1M，那么將分配1M的使用空間轿腺。
- 惰性空間釋放
當(dāng)然两嘴，有空間分配對應(yīng)的就有空間釋放。
SDS 縮短時族壳，并不會回收多余的內(nèi)存空間溶诞，而是使用 free 字段將多出來的空間記錄下來。如果后續(xù)有變更操作决侈，直接使用 free 中記錄的空間螺垢，減少了內(nèi)存的分配喧务。
（3）二進(jìn)制安全
你已經(jīng)知道了 Redis 可以存儲各種數(shù)據(jù)類型，那么二進(jìn)制數(shù)據(jù)肯定也不例外枉圃。但二進(jìn)制數(shù)據(jù)并不是規(guī)則的字符串格式功茴，可能會包含一些特殊的字符，比如 '\0' 等孽亲。
前面我們提到過坎穿，C 中字符串遇到 '\0' 會結(jié)束，那 '\0' 之后的數(shù)據(jù)就讀取不上了返劲。但在 SDS 中玲昧，是根據(jù) len 長度來判斷字符串結(jié)束的。
看篮绿，二進(jìn)制安全的問題就解決了孵延。
2、雙端鏈表
列表 List 更多是被當(dāng)作隊列或棧來使用的亲配。隊列和棧的特性一個先進(jìn)先出尘应，一個先進(jìn)后出。雙端鏈表很好的支持了這些特性吼虎。
- 雙端鏈表 -
（1）前后節(jié)點
鏈表里每個節(jié)點都帶有兩個指針犬钢，prev 指向前節(jié)點，next 指向后節(jié)點思灰。這樣在時間復(fù)雜度為 O(1) 內(nèi)就能獲取到前后節(jié)點玷犹。
（2）頭尾節(jié)點
你可能注意到了，頭節(jié)點里有 head 和 tail 兩個參數(shù)洒疚，分別指向頭節(jié)點和尾節(jié)點箱舞。這樣的設(shè)計能夠?qū)﹄p端節(jié)點的處理時間復(fù)雜度降至 O(1) ，對于隊列和棧來說再適合不過拳亿。同時鏈表迭代時從兩端都可以進(jìn)行。
（3）鏈表長度
頭節(jié)點里同時還有一個參數(shù) len愿伴，和上邊提到的 SDS 里類似肺魁，這里是用來記錄鏈表長度的。因此獲取鏈表長度時不用再遍歷整個鏈表隔节，直接拿到 len 值就可以了鹅经，這個時間復(fù)雜度是 O(1)。
你看怎诫，這些特性都降低了 List 使用時的時間開銷瘾晃。
3、壓縮列表
雙端鏈表我們已經(jīng)熟悉了幻妓。不知道你有沒有注意到一個問題：如果在一個鏈表節(jié)點中存儲一個小數(shù)據(jù)蹦误，比如一個字節(jié)。那么對應(yīng)的就要保存頭節(jié)點，前后指針等額外的數(shù)據(jù)强胰。
這樣就浪費了空間舱沧，同時由于反復(fù)申請與釋放也容易導(dǎo)致內(nèi)存碎片化。這樣內(nèi)存的使用效率就太低了偶洋。
于是熟吏，壓縮列表上場了！
它是經(jīng)過特殊編碼玄窝，專門為了提升內(nèi)存使用效率設(shè)計的牵寺。所有的操作都是通過指針與解碼出來的偏移量進(jìn)行的。
并且壓縮列表的內(nèi)存是連續(xù)分配的恩脂，遍歷的速度很快帽氓。
4、字典
Redis 作為 K-V 型數(shù)據(jù)庫东亦，所有的鍵值都是用字典來存儲的杏节。
日常學(xué)習(xí)中使用的字典你應(yīng)該不會陌生，想查找某個詞通過某個字就可以直接定位到典阵，速度非撤苡妫快。這里所說的字典原理上是一樣的壮啊，通過某個 key 可以直接獲取到對應(yīng)的value嫉鲸。
字典又稱為哈希表，這點沒什么可說的歹啼。哈希表的特性大家都很清楚玄渗，能夠在 O(1) 時間復(fù)雜度內(nèi)取出和插入關(guān)聯(lián)的值。
5狸眼、跳躍表
作為 Redis 中特有的數(shù)據(jù)結(jié)構(gòu)-跳躍表藤树，其在鏈表的基礎(chǔ)上增加了多級索引來提升查找效率。
這是跳躍表的簡單原理圖拓萌，每一層都有一條有序的鏈表岁钓，最底層的鏈表包含了所有的元素。這樣跳躍表就可以支持在 O(logN) 的時間復(fù)雜度里查找到對應(yīng)的節(jié)點微王。
下面這張是跳表真實的存儲結(jié)構(gòu)屡限，和其它數(shù)據(jù)結(jié)構(gòu)一樣，都在頭節(jié)點里記錄了相應(yīng)的信息炕倘，減少了一些不必要的系統(tǒng)開銷钧大。
合理的數(shù)據(jù)編碼
對于每一種數(shù)據(jù)類型來說，底層的支持可能是多種數(shù)據(jù)結(jié)構(gòu)罩旋，什么時候使用哪種數(shù)據(jù)結(jié)構(gòu)啊央，這就涉及到了編碼轉(zhuǎn)化的問題眶诈。
那我們就來看看，不同的數(shù)據(jù)類型是如何進(jìn)行編碼轉(zhuǎn)化的：
String：存儲數(shù)字的話劣挫，采用int類型的編碼册养，如果是非數(shù)字的話，采用 raw 編碼压固；
List：字符串長度及元素個數(shù)小于一定范圍使用 ziplist 編碼球拦，任意條件不滿足，則轉(zhuǎn)化為 linkedlist 編碼帐我；
Hash：hash 對象保存的鍵值對內(nèi)的鍵和值字符串長度小于一定值及鍵值對坎炼；
Set：保存元素為整數(shù)及元素個數(shù)小于一定范圍使用 intset 編碼，任意條件不滿足拦键，則使用 hashtable 編碼谣光；
Zset：zset 對象中保存的元素個數(shù)小于及成員長度小于一定值使用 ziplist 編碼，任意條件不滿足芬为，則使用 skiplist 編碼萄金。
合適的線程模型
Redis 快的原因還有一個是因為使用了合適的線程模型：
1、I/O多路復(fù)用模型
I/O ：網(wǎng)絡(luò) I/O
多路：多個 TCP 連接
復(fù)用：共用一個線程或進(jìn)程
生產(chǎn)環(huán)境中的使用媚朦，通常是多個客戶端連接 Redis氧敢，然后各自發(fā)送命令至 Redis 服務(wù)器，最后服務(wù)端處理這些請求返回結(jié)果询张。
應(yīng)對大量的請求孙乖，Redis 中使用 I/O 多路復(fù)用程序同時監(jiān)聽多個套接字，并將這些事件推送到一個隊列里份氧，然后逐個被執(zhí)行唯袄。最終將結(jié)果返回給客戶端。
2蜗帜、避免上下文切換
你一定聽說過恋拷，Redis 是單線程的。那么單線程的 Redis 為什么會快呢厅缺？
因為多線程在執(zhí)行過程中需要進(jìn)行 CPU 的上下文切換蔬顾，這個操作比較耗時。Redis 又是基于內(nèi)存實現(xiàn)的店归，對于內(nèi)存來說，沒有上下文切換效率就是最高的酪我。多次讀寫都在一個CPU 上消痛，對于內(nèi)存來說就是最佳方案。
3都哭、單線程模型
順便提一下秩伞，為什么 Redis 是單線程的
Redis 中使用了 Reactor 單線程模型逞带，你可能對它并不熟悉。沒關(guān)系纱新，只需要大概了解一下即可展氓。
這張圖里，接收到用戶的請求后脸爱，全部推送到一個隊列里遇汞，然后交給文件事件分派器，而它是單線程的工作方式簿废。Redis 又是基于它工作的空入，所以說 Redis 是單線程的。
總結(jié)
基于內(nèi)存實現(xiàn)
- 數(shù)據(jù)都存儲在內(nèi)存里族檬，減少了一些不必要的 I/O 操作歪赢，操作速率很快。
高效的數(shù)據(jù)結(jié)構(gòu)
底層多種數(shù)據(jù)結(jié)構(gòu)支持不同的數(shù)據(jù)類型单料，支持 Redis 存儲不同的數(shù)據(jù)埋凯；
不同數(shù)據(jù)結(jié)構(gòu)的設(shè)計，使得數(shù)據(jù)存儲時間復(fù)雜度降到最低扫尖。
合理的數(shù)據(jù)編碼
- 根據(jù)字符串的長度及元素的個數(shù)適配不同的編碼格式白对。
合適的線程模型
I/O 多路復(fù)用模型同時監(jiān)聽客戶端連接；
單線程在執(zhí)行過程中不需要進(jìn)行上下文切換藏斩，減少了耗時躏结。
推薦閱讀：
MySQL從入門到進(jìn)階教程，主講老師：馬士兵狰域、連鵬舉
字節(jié)跳動總結(jié)的設(shè)計模式 PDF 火了媳拴，完整版開放分享
刷Github時發(fā)現(xiàn)了一本阿里大神的算法筆記！標(biāo)星70.5K
如果能聽懂這個網(wǎng)約車實戰(zhàn)兆览，哪怕接私活你都可以月入40K
為什么阿里巴巴的程序員成長速度這么快屈溉，看完他們的內(nèi)部資料我懂了
看完三件事??
如果你覺得這篇內(nèi)容對你還蠻有幫助抬探，我想邀請你幫我三個小忙：
點贊子巾，轉(zhuǎn)發(fā)，有你們的 『點贊和評論』小压，才是我創(chuàng)造的動力线梗。
關(guān)注公眾號 『 Java斗帝 』，不定期分享原創(chuàng)知識怠益。
同時可以期待后續(xù)文章ing??
