redis----第二天學習筆記（資料結構：快速的redis有哪些慢操作？）

redis----第二天學習筆記（資料結構：快速的redis有哪些慢操作？）

提到Redis，相信大家腦子裡馬上就會聯想到它的“快”，但大家有考慮過Redis的快，快在哪裡嗎？實際上，這裡有一個重要的表現：它接收到一個鍵值對操作後，能以微妙級別的的速度找到資料，並快速完成操作。

資料庫的種類有這麼多。為什麼Redis能有這麼突出的表現呢？一方面，這是因為它是記憶體資料庫，所有操作都在記憶體上完成；記憶體的訪問速度本身就很快。另一方面，這也歸功於它的資料結構。這是因為鍵值對是按一定的資料結構來組織的，操作鍵值對最終就是對資料結構進行增刪改查操作，所以高效的資料結構是Redis快速處理資料的基礎。本節課就圍繞資料結構進行展開討論。

像String(字串)、List(列表)、Hash(雜湊)、Set（集合）、Sorted Set（有序集合）像這些只是Redis鍵值對中值的資料型別，也就是資料的儲存形式。而這裡，我們說的資料結構，是要去看他們的底層實現。
簡單來說，底層資料結構一共有6種，分別是簡單動態字串、雙向連結串列、壓縮列表、雜湊表、跳錶和整數陣列。它們和資料型別的對應關係如下圖：

可以看到，String型別的底層實現只有一種資料結構，也就是簡單動態字串。而List、Hash、Set和SortSet這四種型別成為集合型別，它們的特點是一個鍵對應了一個集合的資料。
看到這裡，可以討論出一些問題：

• 這些資料結構都是值的底層實現，鍵和值之間用什麼結構組織？
• 為什麼集合型別有那麼多的底層結構，它們都是怎麼樣組織資料的，都很快嗎？
• 什麼是簡單動態字串，和常用的字串是一回事？

鍵和值用什麼結構組織？
為了實現從鍵到值的快速訪問，Redis使用了一個雜湊表來儲存所有鍵值對。
一個雜湊表，其實就是一個陣列，陣列的每個元素稱為一個雜湊桶。所以，我們常說，一個雜湊表是由多個雜湊桶組成的，每個雜湊桶中儲存了鍵值對資料。

看到這裡，有人可能會問：如果值是集合型別的話，作為元素陣列的雜湊桶怎麼來儲存呢？其實，雜湊桶中的元素儲存的並不是值本身，而是指向具體值的指標。這也就是說，不管值是String,還是集合型別，雜湊桶中的元素都是指向它們的指標。

在下圖中，可以看到雜湊桶中的entry元素中儲存了key和value指標，分別指向了實際的鍵和值，這樣一來，即使值是一個集合，也可以通過 *value指標被查詢到。

因為這個雜湊表儲存了所有的鍵值對，所以，我也把它稱為全域性雜湊表。雜湊表的最大好處明顯，就是讓我們可以用O（1）的時間複雜度來快速查詢到鍵值對----我們只需要計算鍵的雜湊值，就可以知道他所對應的雜湊桶位置，然後就可以訪問相應的entry元素。

可以看出，這個查詢過程主要依賴於雜湊計算，和資料量的多少並沒有直接關係。也就是說，不管雜湊表裡有10萬個鍵還是100萬個鍵，我們只需要一次計算就能找到相應的鍵。
但是，如果你只是瞭解了雜湊表的O(1)複雜度和快速查詢特性，那麼當你往Redis裡寫入大量資料後，就可能發現操作有時候會變慢了。這其實是因為你忽略了一個潛在的風險點，那就是雜湊表的衝突問題和rehash可能帶來的操作阻塞。

為什麼雜湊表操作變慢了？
當你往雜湊表中寫入更多資料時，雜湊衝突是不可避免的問題。這裡的雜湊衝突也就是指，兩個key的雜湊值和雜湊桶計算對應關係時，正好落入了同一個雜湊桶中。
Redis解決雜湊衝突的方式，就是鏈式雜湊。鏈式雜湊也很容易理解，就是指同一個雜湊桶中的多個元素泳一個連結串列來儲存，他們之間依次用指標連線。

如下圖所示：entry1、entry2和entry3都需要儲存到雜湊桶3中，導致了雜湊衝突。此時，entry1元素會通過一個next指標指向entry2，同樣，entry2也會通過next指標指向entry3.這樣一來，即使雜湊桶3中的元素有00個，我們也可以通過entry元素中的指標，把它們連線起來。這就形成了一個連結串列，也叫做雜湊衝突鏈。

但是這裡依然存在一個問題，雜湊衝突鏈上的元素只能通過指標逐一查詢在操作。如果雜湊表裡寫入的資料越來越多，這就會導致某些雜湊衝突鏈過長，進而導致這個鏈上的元素查詢耗時長，效率較低，對於追求“快”的Redis來說，是不太能接受的。
所以Redis會對雜湊表做rehash操作。rehash也就是增加現有的雜湊桶數量，讓逐漸增多的entry元素能在更多的桶之間分散儲存，減少單個桶中的元素數量，從而減少單個桶中的衝突。那具體怎麼做呢？

其實為了使rehash操作更高效，Redis預設使用了兩個全域性雜湊表：雜湊表1和雜湊表2，一開始，當你剛插入資料時，預設使用雜湊表1，此時的雜湊表2並沒有被分配空間。隨著資料逐步增多。Redis開始執行rehash，這個過程分三步：

1. 給雜湊表2分配更大的空間，例如是當前雜湊表1大小的兩倍；
2. 把雜湊表1的資料重新對映並拷貝到雜湊表2中。
3. 釋放雜湊表1的空間。

到此我們就可以從雜湊表1切換到雜湊表2，用增大的雜湊表2儲存更多資料，而原來的雜湊表1留作下一次rehash擴容備用。

這個過程看似簡單，但是第二部涉及大量的資料拷貝，如果一次性把雜湊表1中的資料都遷移走，會造成redis執行緒阻塞，無法服務其他請求。此時，Redis就無法快速訪問資料了。

為了避免這個問題，Redis採用了漸進式rehash。
簡單來說就是在第二步拷貝資料時，Redis仍然正常處理客戶端請求，每處理一個請求時，從雜湊表1中的第一個索引位置開始，順帶著將這個索引位置上的所有entries拷貝到雜湊表2中；等處理下一個請求時，在順帶拷貝雜湊表1中的下一個索引位置的entries。如下所示：

這樣就巧妙地把一次性大量拷貝的開銷，分攤到了多次處理請求的過程中，避免了耗時操作，保證了資料的快速訪問。

到這裡應該可以理解Redis的鍵和值是怎麼用過雜湊表組織的了。對於String來說，找到雜湊桶就能直接增刪改查，所以雜湊表的O（1）複雜度也就是它的複雜度了。
但是，對於集合型別來說，即使找到雜湊桶了，還要在集合中在進一步操作。接下來我們來看看集合型別的操作效率是怎麼樣的。

集合資料操作效率：
和String型別不同，一個集合型別的值，第一步是通過全域性雜湊表找到對應的雜湊桶位置，第二步時在集合中在增刪改查。那麼集合的操作效率和哪些因素相關呢？

首先，與集合的底層資料結構有關。例如，使用雜湊標配實現的集合，要比使用連結串列實現的集合訪問效率更高。其次，操作效率和這些操作本身的執行特點有關，比如讀寫一個元素對的操作要比讀寫所有元素的效率高。

下面簡單的說一下集合型別的底層資料結構和操作複雜度：

有哪些底層資料結構：

• 集合型別的底層資料結構主要有5種：整數陣列、雜湊表、雙向連結串列、壓縮列表和跳錶。
• 其中，雜湊表的操作特點我們已經介紹過了；整數陣列和雙向連結串列也很常見，他們的操作特徵都是順序讀寫，也就是通過陣列下標或者連結串列的指標逐個元素訪問，操作複雜度基本是o(n）,操作效率比較低；壓縮列表和跳錶我們平時也接觸的可能不多，但他們也是redis重要的資料結構，所以特此強調一下：
  壓縮列表實際上類似於一個陣列，陣列中的每一個元素都對應儲存一個資料。和陣列不同的是，壓縮列表在表頭有三個欄位zlbytes\zltail\zllen分別表示列表長度、列表尾的偏移量和列表中的entry個數；壓縮列表在表尾還有個zlend，表示列表結束。

在壓縮列表中，如果我們要查詢定位第一個元素和最後一個元素，可以通過表頭三個欄位的長度直接定位，複雜度是O(1).而查詢其他元素的時候，就沒有這麼高效了，只能逐個查詢，此時的複雜度就是O(N)了。

再繼續瞭解下跳錶，有序連結串列只能逐一查詢元素，導致操作起來非常慢，於是就出現了跳錶。具體來說，跳錶在連結串列的基礎上，增加了多級索引，通過索引位置的幾個跳轉，實現資料的快速定位。如下所示：

如果我們要在連結串列中查詢33這個元素，只能從頭開始遍歷連結串列，查詢6次，直到找到33為止。此時，複雜度是O（N），查詢效率很低。
為了提高查詢速度，我們採用增加一級索引來提高效率，從第一個元素開始，每2個元素選一個出來作為索引。這些索引在通過指標指向原始的連結串列，例如：從前兩個元素中抽取元素11作為一級索引。此時我們只需要4次查詢就可以定位到元素33了

如果我們還想更快，可以再增加二級索引；從一級索引中，在抽取部分元素作為二級索引。例如：從一級索引中抽取1、27、100作為二級索引，二級索引指向一級索引。這樣，我們就只需要三次查詢就可以定位到元素33了。

可以看到，這個查詢過程就是字多級索引上跳來跳去，最後定位到元素。這也正好符合“跳”表的說法，當資料量很大的時候，跳錶的複雜度就是O（logN）。

根據上述，我們可以按照查詢的時間複雜度給這些資料結構分一下類：

不同的操作的複雜度：
集合類的操作型別有很多，有讀寫單個集合元素的，例如HGET/HSET也有操作多個元素的，例如SADD，還有對整個集合進行遍歷操作的；例如SMEMBERS。這麼多操作，他們的複雜度也有不同。而複雜度的高低又是我們選擇型別的重要依據，

有老師總結了一個很經典的“四句口訣”：

• 單元素操作是基礎
• 範圍操作非常好使
• 統計操作通常高效
• 例外情況只有幾個

第一，單元素操作，是指每一種集合型別對單個資料實現增刪改查操作。例如Hash型別的HGET、HSET和HDEL，Set型別的SADD、SREM、SRANDMEMBER等。這些操作的複雜度由集合採用的資料機構決定，例如，HGET、HSET和HDEL是對雜湊表做操作，所以它們的複雜度都是O（1），Set型別用雜湊表作為底層資料結構時，它的SADD、SREM、SRANDMEMBER複雜度也是O（1）。

這裡有個地方需要注意一下，集合型別支援同時對多個元素進行增刪改查操作，例如Hash型別的HMGET和HMSET。Set型別的SADD也支援同時增加多個元素。此時，這些操作的複雜度，就是由單個元素操作複雜度個元素個數決定的。例如。HMSET增加M個元素時，複雜度就從O(1)變成O(M)了。

第二，範圍操作，是指集合型別中的便利操作，可以返回集合中的所有資料，比如Hash型別的HGETALL和SET型別的SMEMBERS，或者返回一個範圍內的部分資料，比如List型別的LRANGE和ZSET型別的ZRANGE，這類操作的複雜度一般是O（N），比較耗時，我們應該儘量避免。

不過Redis從2.8版本開始提供了SCAN操作（包括HSCAN,SSCAN,ZSCAN）這類操作實現了漸進式遍歷，每次返回有限數量的資料，這樣一來，相比於HGETALL,SMEMBERS這類操作來說，就避免了一次性返回所有元素而導致的redis阻塞。

第三，統計操作，是指集合型別對集合中所有元素個數的記錄，例如LLEN和SCARD。這類操作複雜度只有 O(1),這是因為當集合型別採用壓縮列表、雙向連結串列、整數陣列這些資料結構時，這些結構中專門記錄了元素的個數統計，因此可以高效的完成相關操作。

第四，例外情況，是指某些資料結構的特殊記錄，例如壓縮列表和雙向連結串列都會記錄表頭和表尾的偏移量，這樣一來，對於list型別的LPOP、RPOP、LPUSH、RPUSH這四個操作來說，它們是在列表的頭尾刪除元素，這就是可以通過偏移量直接定位，所以它們的操作複雜度也只有O(1)，可以實現快速操作。

小結
本次主要學習了Redis的底層資料結構，這即包括了redis中用來儲存每個鍵和值的全域性雜湊表結構，也包括了支援集合型別實現的雙向連結串列、壓縮列表、整數陣列、雜湊表和跳錶這五大底層結構。

Redis之所以能快速操作鍵值對，一方面是因為O(1)複雜度的雜湊表被廣泛使用，包括String、Hash和Set,它們的操作複雜度基本由雜湊表決定，另一方面，Sorted Set也採用了O(logN)複雜度的跳錶。不過。集合型別的範圍操作，因為要遍歷底層資料結構，複雜度通常是O(N)。因此，我覺得要因地制宜的使用List型別。例如：既然它們的POP/PYSH效率很高，那麼就將它主要用於FIFO佇列場景，而不是作為一個可以隨機讀寫的集合。
使用redis我們通常無法一下子記住所有的操作的複雜值，它的型別豐富，每個型別的操作也很多。所以最好的辦法就是掌握原理，只要掌握了資料結構原理，就可以從原理上推斷不同操作的複雜度。