面試：Redis爲何快呢？查詢爲什麼會變慢呢？

越努力，越幸運，
本文已收藏在GitHub中 JavaCommunity, 裏面有面試分享、源碼分析系列文章，歡迎收藏，點贊
https://github.com/Ccww-lx/Ja...

在實際開發，Redis使用會頻繁，那麼在使用過程當中咱們該如何正確抉擇數據類型呢？哪些場景下適用哪些數據類型。並且在面試中也很常會被面試官問到Redis數據結構方面的問題：

• Redis爲何快呢？
• 爲何查詢操做會變慢了？
• Redis Hash rehash過程
• 爲何使用哈希表做爲Redis的索引

當咱們分析理解了Redis數據結構，能夠爲了咱們在使用Redis的時候，正確抉擇數據類型使用，提高系統性能。

Redis底層數據結構

Redis 是一個內存鍵值key-value 數據庫，且鍵值對數據保存在內存中，所以Redis基於內存的數據操做，其效率高，速度快；

其中，Key是String類型，Redis 支持的 value 類型包括了 String、List 、 Hash 、 Set 、 Sorted Set 、BitMap等。Redis 可以之因此可以普遍地適用衆多的業務場景，基於其多樣化類型的value。

而Redis的Value的數據類型是基於爲Redis自定義的對象系統redisObject實現的，

typedef struct redisObject{
    //類型
    unsigned type:4;
    //編碼
    unsigned encoding:4;
    //指向底層實現數據結構的指針
    void *ptr;
    ….. 
}

redisObject除了記錄實際數據，還須要額外的內存空間記錄數據長度、空間使用等元數據信息，其中包含了 8 字節的元數據和一個 8 字節指針，指針指向具體數據類型的實際數據所在位置：

​

其中，指針指向的就是基於Redis的底層數據結構存儲數據的位置，Redis的底層數據結構：SDS，雙向鏈表、跳錶，哈希表，壓縮列表、整數集合實現的。

那麼Redis底層數據結構是怎麼實現的呢？

Redis底層數據結構實現

咱們先來看看Redis比較簡單的SDS,雙向鏈表，整數集合。

SDS、雙向鏈表和整數集合

SDS，使用len字段記錄已使用的字節數，將獲取字符串長度複雜度下降爲O(1)，並且SDS是惰性釋放空間的，你free了空間，系統把數據記錄下來下次想用時候可直接使用。不用新申請空間。

整數集合，在內存中分配一塊地址連續的空間，數據元素會挨着存放，不須要額外指針帶來空間開銷，其特色爲內存緊湊節省內存空間，查詢複雜度爲O(1)效率高，其餘操做複雜度爲O(N)；

雙向鏈表， 在內存上能夠爲非連續、非順序空間，經過額外的指針開銷前驅/後驅指針串聯元素之間的順序。

其特色爲節插入/更新數據複雜度爲O(1)效率高，查詢複雜度爲O(N)；

Hash哈希表

哈希表，其實相似是一個數組，數組的每一個元素稱爲一個哈希桶，每一個哈希桶中保存了鍵值對數據，且哈希桶中的元素使用dictEntry結構，

所以，哈希桶元素保存的並非鍵值對值自己，而是指向具體值的指針，因此在保存每一個鍵值對的時候會額外空間開銷，至少有增長24個字節，特別是Value爲String的鍵值對，每個鍵值對就須要額外開銷24個字節空間。當保存數據小，額外開銷比數據還大時，這時爲了節省空間，考慮換數據結構。

那來看看全局哈希表全圖：

雖然哈希表操做很快，但Redis數據變大後，就會出現一個潛在的風險：哈希表的衝突問題和 rehash開銷問題，這能夠解釋爲何哈希表操做變慢了？

當往哈希表中寫入更多數據時，哈希衝突是不可避免的問題 ， Redis 解決哈希衝突的方式，就是鏈式哈希，同一個哈希桶中的多個元素用一個鏈表來保存，它們之間依次用指針鏈接，如圖所示：

當哈希衝突也會愈來愈多，這就會致使某些哈希衝突鏈過長，進而致使這個鏈上的元素查找耗時長，效率下降。

爲了解決哈希衝突帶了的鏈過長的問題，進行rehash操做，增長現有的哈希桶數量，分散單桶元素數量。那麼rehash過程怎麼樣執行的呢？

Rehash

爲了使rehash 操做更高效，使用兩個全局哈希表：哈希表 1 和哈希表 2，具體以下：

• 將哈希表 2 分配更大的空間，
• 把哈希表 1 中的數據從新映射並拷貝到哈希表 2 中；
• 釋放哈希表 1 的空間

但因爲表1和表2在從新映射覆制時數據大，若是一次性把哈希表 1 中的數據都遷移完，會形成 Redis 線程阻塞，沒法服務其餘請求。

爲了不這個問題，保證Redis能正常處理客戶端請求，Redis 採用了漸進式 rehash。

每處理一個請求時，從哈希表 1 中依次將索引位置上的全部 entries 拷貝到哈希表 2 中，把一次性大量拷貝的開銷，分攤到了屢次處理請求的過程當中，避免了耗時操做，保證了數據的快速訪問。

在理解完Hash哈希表相關知識點後，看看不常見的壓縮列表和跳錶。

壓縮列表與跳錶

壓縮列表，在數組基礎上，在壓縮列表在表頭有三個字段 zlbytes、zltail 和 zllen，分別表示列表長度、列表尾的偏移量和列表中的 entry 個數；壓縮列表在表尾還有一個 zlend，表示列表結束。

優勢：內存緊湊節省內存空間，內存中分配一塊地址連續的空間，數據元素會挨着存放，不須要額外指針帶來空間開銷；查找定位第一個元素和最後一個元素，能夠經過表頭三個字段的長度直接定位，複雜度是 O(1)。

跳錶 ，在鏈表的基礎上，增長了多級索引，經過索引位置的幾個跳轉，實現數據的快速定位，以下圖所示：

好比查詢33

特色：當數據量很大時，跳錶的查找複雜度爲O(logN)。

綜上所述，能夠得知底層數據結構的時間複雜度：

數據結構類型	時間複雜度
哈希表	O(1)
整數數組	O(N)
雙向鏈表	O(N)
壓縮列表	O(N)
跳錶	O(logN)

Redis自定義的對象系統類型即爲Redis的Value的數據類型，Redis的數據類型是基於底層數據結構實現的，那數據類型有哪些呢？

Redis數據類型

String、List、Hash、Sorted Set、Set比較常見的類型，其與底層數據結構對應關係以下：

數據類型	數據結構
String	SDS(簡單動態字符串)
List	雙向鏈表 壓縮列表
Hash	壓縮列表<br/>哈希表
Sorted Set	壓縮列表<br/>跳錶
Set	哈希表<br/>整數數組

數據類型對應特色跟其實現的底層數據結構差很少，性質也是同樣的,且

String，基於SDS實現，適用於簡單key-value存儲、setnx key value實現分佈式鎖、計數器(原子性)、分佈式全局惟一ID。

List， 按照元素進入List 的順序進行排序的，遵循FIFO(先進先出)規則，通常使用在 排序統計以及簡單的消息隊列。

Hash， 是字符串key和字符串value之間的映射，十分適合用來表示一個對象信息 ，特色添加和刪除操做複雜度都是O(1)。

Set，是String 類型元素的無序集合，集合成員是惟一的，這就意味着集合中不能出現重複的數據。 基於哈希表實現的，因此添加，刪除，查找的複雜度都是 O(1)。

Sorted Set， 是Set的類型的升級， 不一樣的是每一個元素都會關聯一個 double 類型的分數，經過分數排序，能夠範圍查詢。

那咱們再來看看這些數據類型，Redis Geo、HyperLogLog、BitMap？

Redis Geo， 將地球看做爲近似爲球體，基於GeoHash 將二維的經緯度轉換成字符串，來實現位置的劃分跟指定距離的查詢。特色通常使用在跟位置有關的應用。

HyperLogLog， 是一種機率數據結構，它使用機率算法來統計集合的近似基數 ， 錯誤率大概在0.81%。 當集合元素數量很是多時，它計算基數所需的空間老是固定的，並且還很小，適合使用作 UV 統計。

BitMap ，用一個比特位來映射某個元素的狀態， 只有 0 和 1 兩種狀態，很是典型的二值狀態，且其自己是用 String 類型做爲底層數據結構實現的一種統計二值狀態的數據類型 ，優點大量節省內存空間，但是使用在二值統計場景。

在理解上述知識後，咱們接下來討論一下根據哪些策略選擇相對應的應用場景下的Redis數據類型？

選擇合適的Redis數據類型策略

在實際開發應用中，Redis能夠適用於衆多的業務場景，但咱們須要怎麼選擇數據類型存儲呢？

主要依據就是時間/空間複雜度，在實際的開發中能夠考慮如下幾個點：

• 數據量，數據自己大小
• 集合類型統計模式
• 支持單點查詢/範圍查詢
• 特殊使用場景

數據量，數據自己大小

當數據量比較大，數據自己比較小，使用String就會使用額外的空間大大增長，由於使用哈希表保存鍵值對，使用dictEntry結構保存，會致使保存每一個鍵值對時額外保存dictEntry的三個指針的開銷，這樣就會致使數據自己小於額外空間開銷，最終會致使存儲空間數據大小遠大於本來數據存儲大小。

可使用基於整數數組和壓縮列表實現了 List、Hash 和 Sorted Set ，由於整數數組和壓縮列表在內存中都是分配一塊地址連續的空間，而後把集合中的元素一個接一個地放在這塊空間內，很是緊湊，不用再經過額外的指針把元素串接起來，這就避免了額外指針帶來的空間開銷。並且採用集合類型時，一個 key 就對應一個集合的數據，能保存的數據多了不少，但也只用了一個 dictEntry，這樣就節省了內存。

集合類型統計模式

Redis集合類型統計模式常見的有：

• 聚合統計（ 交集、差集、並集統計 ）： 對多個集合進行聚合計算時，能夠選擇Set；
• 排序統計（要求集合類型能對元素保序）： Redis中List 和 Sorted Set是有序集合，List是按照元素進入 List 的順序進行排序的，Sorted Set 能夠根據元素的權重來排序；
• 二值狀態統計（ 集合元素的取值就只有 0 和 1 兩種 ）：Bitmap 自己是用 String 類型做爲底層數據結構實現的一種統計二值狀態的數據類型 ， Bitmap經過 BITOP 按位 與、或、異或的操做後使用 BITCOUNT 統計 1 的個數。
• 基數統計（ 統計一個集合中不重複的元素的個數 ）：HyperLogLog 是一種用於統計基數的數據集合類型 ，統計結果是有必定偏差的，標準誤算率是 0.81% 。須要精確統計結果的話，用 Set 或 Hash 類型。

Set類型，適用統計用戶/好友/關注/粉絲/感興趣的人集合聚合操做，好比

• 統計手機APP天天的新增用戶數
• 兩個用戶的共同好友

Redis中List 和 Sorted Set是有序集合，使用應對集合元素排序需求 ，好比

• 最新評論列表
• 排行榜

Bitmap二值狀態統計，適用數據量大，且可使用二值狀態表示的統計，好比：

• 簽到打卡，當天用戶簽到數
• 用戶周活躍
• 用戶在線狀態

HyperLogLog 是一種用於統計基數的數據集合類型， 統計一個集合中不重複的元素個數 ，好比

• 統計網頁的 UV ， 一個用戶一天內的屢次訪問只能算做一次

支持單點查詢/範圍查詢

Redis中List 和 Sorted Set是有序集合支持範圍查詢，可是Hash是不支持範圍查詢的

特殊使用場景

消息隊列，使用Redis做爲消息隊列的實現，要消息的基本要求消息保序、處理重複的消息和保證消息可靠性，方案有以下：

• 基於 List 的消息隊列解決方案
• 基於 Streams 的消息隊列解決方案

	基於List	基於Strems
消息保序	使用LPUSH/RPOP	使用XADD/XREAD
阻塞讀取	使用BRPOP	使用XREAD block
重複消息處理	生產者自行實現全局惟一ID	Streams自動生成全局惟一ID
消息可靠性	使用BRPOPLPUSH	使用PENDING List自動留存消息
適用場景	消息總量小	消息總量大，須要消費組形式讀取數據

基於位置 LBS 服務，使用Redis的特定GEO數據類型實現，GEO 能夠記錄經緯度形式的地理位置信息，被普遍地應用在 LBS 服務中。 好比:打車軟件是怎麼基於位置提供服務的。

總結

Redis之因此那麼快，是由於其基於內存的數據操做和使用Hash哈希表做爲索引，其效率高，速度快，並且得益於其底層數據多樣化使得其能夠適用於衆多場景，不一樣場景中選擇合適的數據類型能夠提高其查詢性能。

謝謝各位點贊，沒點讚的點個贊支持支持 最後，微信搜《Ccww技術博客》觀看更多文章，也歡迎關注一波。