Redis為什么這么快？

前言

作為一名后端軟件工程師，工作中你肯定和 Redis 打過(guò)交道。但是Redis 為什么快呢？很多人只能答出Redis 因為它是基于內存實(shí)現的，但是對于其它原因都是模棱兩可。

那么今天就一起來(lái)看看是Redis 為什么快吧：

Redis 為什么這么快？

一、基于內存實(shí)現

Redis 是基于內存的數據庫，那不可避免的就要與磁盤(pán)數據庫做對比。對于磁盤(pán)數據庫來(lái)說(shuō)，是需要將數據讀取到內存里的，這個(gè)過(guò)程會(huì )受到磁盤(pán) I/O 的限制。而對于內存數據庫來(lái)說(shuō)，本身數據就存在于內存里，也就沒(méi)有了這方面的開(kāi)銷(xiāo)。

通過(guò)下面的表格我們可以知道讀取內存和讀取磁盤(pán)的性能差距。

?

?

二、高效存儲結構

為了實(shí)現從鍵到值的快速訪(fǎng)問(wèn)，Redis 使用了一個(gè)哈希表來(lái)保存所有鍵值對。一個(gè)哈希表，其實(shí)就是一個(gè)數組，數組的每個(gè)元素稱(chēng)為一個(gè)哈希桶。所以，我們常說(shuō)，一個(gè)哈希表是由多個(gè)哈希桶組成的，每個(gè)哈希桶中保存了鍵值對數據。

全局哈希表

哈希桶中的 entry 元素中保存了key和value指針，分別指向了實(shí)際的鍵和值，因為其value的多樣性，哈希表中存儲的并不是具體的值，而是一個(gè)內存引用地址，在通過(guò)內存引用的地址查找到對應的具體的值。這樣一來(lái)，即使value是一個(gè)集合，也可以通過(guò)*value指針被查找到。因為這個(gè)哈希表保存了所有的鍵值對，所以，我也把它稱(chēng)為全局哈希表。

哈希表的最大好處很明顯，就是讓我們可以用 O(1) 的時(shí)間復雜度來(lái)快速查找到鍵值對：我們只需要計算鍵的哈希值，就可以知道它所對應的哈希桶位置，然后就可以訪(fǎng)問(wèn)相應的 entry 元素。但當你往 Redis 中寫(xiě)入大量數據后，就可能發(fā)現操作有時(shí)候會(huì )突然變慢了。這其實(shí)是因為你忽略了一個(gè)潛在的風(fēng)險點(diǎn)，那就是哈希表的沖突問(wèn)題和 rehash 可能帶來(lái)的操作阻塞。

當你往哈希表中寫(xiě)入更多數據時(shí)，哈希沖突是不可避免的問(wèn)題。這里的哈希沖突，兩個(gè) key 的哈希值和哈希桶計算對應關(guān)系時(shí)，正好落在了同一個(gè)哈希桶中。

哈希表的哈希沖突

Redis 解決哈希沖突的方式，就是鏈式哈希。鏈式哈希也很容易理解，就是指同一個(gè)哈希桶中的多個(gè)元素用一個(gè)鏈表來(lái)保存，它們之間依次用指針連接。

三、單線(xiàn)程避免了上下文前切換

省去了很多上下文切換的時(shí)間以及CPU消耗，不存在競爭條件，不用去考慮各種鎖的問(wèn)題，不存在加鎖釋放鎖操作，也不會(huì )出現死鎖而導致的性能消耗。

四、使用基于IO多路復用機制的線(xiàn)程模型，可以處理并發(fā)的鏈接。

Redis采用了epoll 模型進(jìn)行IO多路復用。Java中也有類(lèi)似的模型比如NIO,才epoll模型之前還有selector、poll這里不多講解，epoll模型可以參考下圖：

epoll 模型

五、漸進(jìn)式ReHash

Redis是當然如果這個(gè)數組一直不變，那么hash沖突會(huì )變很多，這個(gè)時(shí)候檢索效率會(huì )大打折扣，所以Redis就需要把數組進(jìn)行擴容（一般是擴大到原來(lái)的兩倍），但是問(wèn)題來(lái)了，擴容后每個(gè)hash桶的數據會(huì )分散到不同的位置，這里設計到元素的移動(dòng)，必定會(huì )阻塞IO，所以這個(gè)ReHash過(guò)程會(huì )導致很多請求阻塞。

為了避免這個(gè)問(wèn)題，Redis 采用了漸進(jìn)式 rehash。

首先、Redis 默認使用了兩個(gè)全局哈希表：哈希表 1 和哈希表 2。一開(kāi)始，當你剛插入數據時(shí)，默認使用哈希表 1，此時(shí)的哈希表 2 并沒(méi)有被分配空間。隨著(zhù)數據逐步增多，Redis 開(kāi)始執行 rehash。

1、給哈希表 2 分配更大的空間，例如是當前哈希表 1 大小的兩倍

2、把哈希表 1 中的數據重新映射并拷貝到哈希表 2 中

3、釋放哈希表 1 的空間

在上面的第二步涉及大量的數據拷貝，如果一次性把哈希表 1 中的數據都遷移完，會(huì )造成 Redis 線(xiàn)程阻塞，無(wú)法服務(wù)其他請求。此時(shí)，Redis 就無(wú)法快速訪(fǎng)問(wèn)數據了。

　　　　　　　　　　　　　　漸進(jìn)式rehash

在Redis 開(kāi)始執行 rehash，Redis仍然正常處理客戶(hù)端請求，但是要加入一個(gè)額外的處理：

處理第1個(gè)請求時(shí)，把哈希表 1中的第1個(gè)索引位置上的所有 entries 拷貝到哈希表 2 中

處理第2個(gè)請求時(shí)，把哈希表 1中的第2個(gè)索引位置上的所有 entries 拷貝到哈希表 2 中

如此循環(huán)，直到把所有的索引位置的數據都拷貝到哈希表 2 中。

這樣就巧妙地把一次性大量拷貝的開(kāi)銷(xiāo)，分攤到了多次處理請求的過(guò)程中，避免了耗時(shí)操作，保證了數據的快速訪(fǎng)問(wèn)。

所以這里基本上也可以確保根據key找value的操作在O（1）左右。

過(guò)這里要注意，如果Redis中有海量的key值的話(huà)，這個(gè)Rehash過(guò)程會(huì )很長(cháng)很長(cháng)，雖然采用漸進(jìn)式Rehash，但在Rehash的過(guò)程中還是會(huì )導致請求有不小的卡頓。并且像一些統計命令也會(huì )非?？D：比如keys

按照Redis的配置每個(gè)實(shí)例能存儲的最大的key的數量為2的32次方,即2.5億，但是盡量把key的數量控制在千萬(wàn)以下，這樣就可以避免Rehash導致的卡頓問(wèn)題，如果數量確實(shí)比較多，建議采用分區hash存儲。

六、緩存時(shí)間戳

我們平常使用系統時(shí)間戳時(shí)， 常常是不假思索地使用System.currentTimeMillis()或者new?Date() .getTime()?來(lái)獲取系統的毫秒時(shí)間戳。但是Redis不能這樣做，因為每一次獲取系統時(shí)間戳都是一次系統調用，而且每次去系統調用是比較費時(shí)間的，作為單線(xiàn)程的Redis是無(wú)法承受的，所以它需要對于時(shí)間戳進(jìn)行一次緩存，由一個(gè)定時(shí)任務(wù)進(jìn)行每毫秒更新時(shí)間戳，從而獲取時(shí)間戳都是直接從緩存就取出。

審核編輯：黃飛

?