Redis為什么這么快？

前言

作為一名后端軟件工程師，工作中你肯定和 Redis 打過交道。但是Redis 為什么快呢？很多人只能答出Redis 因?yàn)樗腔趦?nèi)存實(shí)現(xiàn)的，但是對于其它原因都是模棱兩可。

那么今天就一起來看看是Redis 為什么快吧：

Redis 為什么這么快？

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

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

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

?

?

二、高效存儲結(jié)構(gòu)

為了實(shí)現(xiàn)從鍵到值的快速訪問，Redis 使用了一個(gè)哈希表來保存所有鍵值對。一個(gè)哈希表，其實(shí)就是一個(gè)數(shù)組，數(shù)組的每個(gè)元素稱為一個(gè)哈希桶。所以，我們常說，一個(gè)哈希表是由多個(gè)哈希桶組成的，每個(gè)哈希桶中保存了鍵值對數(shù)據(jù)。

全局哈希表

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

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

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

哈希表的哈希沖突

Redis 解決哈希沖突的方式，就是鏈?zhǔn)焦！ｆ準(zhǔn)焦Ｒ埠苋菀桌斫?，就是指同一個(gè)哈希桶中的多個(gè)元素用一個(gè)鏈表來保存，它們之間依次用指針連接。

三、單線程避免了上下文前切換

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

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

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

epoll 模型

五、漸進(jìn)式ReHash

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

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

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

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

2、把哈希表 1 中的數(shù)據(jù)重新映射并拷貝到哈希表 2 中

3、釋放哈希表 1 的空間

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

　　　　　　　　　　　　　　漸進(jìn)式rehash

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

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

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

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

這樣就巧妙地把一次性大量拷貝的開銷，分?jǐn)偟搅硕啻翁幚碚埱蟮倪^程中，避免了耗時(shí)操作，保證了數(shù)據(jù)的快速訪問。

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

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

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

六、緩存時(shí)間戳

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

審核編輯：黃飛

?