腳本之家服務器常用軟件

快捷導航

2021年最新Redis面試題匯總(1)

更新時間：2021年07月15日 17:33:07 作者：java李楊勇

在程序員面試過程中redis相關的知識是常被問到的話題。這篇文章主要介紹了幾道Redis面試題，整理一下分享給大家，感興趣的小伙伴們可以參考一下

1、Redis 是單線程還是多線程？
2、為什么 Redis 是單線程？
3、Redis 為什么使用單進程、單線程也很快
4、Redis 在項目中的使用場景
5、Redis 常見的數(shù)據(jù)結(jié)構(gòu)
6、Redis 的字符串（SDS）和C語言的字符串區(qū)別
7、Sorted Set底層數(shù)據(jù)結(jié)構(gòu)
8、Sorted Set 為什么同時使用字典和跳躍表？
9、Sorted Set 為什么使用跳躍表，而不是紅黑樹？
10、Hash 對象底層結(jié)構(gòu)
11、Hash 對象的擴容流程
總結(jié)

1、Redis 是單線程還是多線程？

這個問題應該已經(jīng)看到過無數(shù)次了，最近 redis 6 出來之后又被翻出來了。

redis 4.0 之前，redis 是完全單線程的。

redis 4.0 時，redis 引入了多線程，但是額外的線程只是用于后臺處理，例如：刪除對象，核心流程還是完全單線程的。這也是為什么有些人說 4.0 是單線程的，因為他們指的是核心流程是單線程的。

這邊的核心流程指的是 redis 正常處理客戶端請求的流程，通常包括：接收命令、解析命令、執(zhí)行命令、返回結(jié)果等。

而在最近，redis 6.0 版本又一次引入了多線程概念，與 4.0 不同的是，這次的多線程會涉及到上述的核心流程。

redis 6.0 中，多線程主要用于網(wǎng)絡 I/O 階段，也就是接收命令和寫回結(jié)果階段，而在執(zhí)行命令階段，還是由單線程串行執(zhí)行。由于執(zhí)行時還是串行，因此無需考慮并發(fā)安全問題。

值得注意的時，redis 中的多線程組不會同時存在“讀”和“寫”，這個多線程組只會同時“讀”或者同時“寫”。

redis 6.0 加入多線程 I/O 之后，處理命令的核心流程如下:

1、當有讀事件到來時，主線程將該客戶端連接放到全局等待讀隊列

2、讀取數(shù)據(jù)：1）主線程將等待讀隊列的客戶端連接通過輪詢調(diào)度算法分配給 I/O 線程處理；2）同時主線程也會自己負責處理一個客戶端連接的讀事件；3）當主線程處理完該連接的讀事件后，會自旋等待所有 I/O 線程處理完畢

3、命令執(zhí)行：主線程按照事件被加入全局等待讀隊列的順序（這邊保證了執(zhí)行順序是正確的），串行執(zhí)行客戶端命令，然后將客戶端連接放到全局等待寫隊列

4、寫回結(jié)果：跟等待讀隊列處理類似，主線程將等待寫隊列的客戶端連接使用輪詢調(diào)度算法分配給 I/O 線程處理，同時自己也會處理一個，當主線程處理完畢后，會自旋等待所有 I/O 線程處理完畢，最后清空隊列。

大致流程圖如下：

2、為什么 Redis 是單線程？

在 redis 6.0 之前，redis 的核心操作是單線程的。

因為 redis 是完全基于內(nèi)存操作的，通常情況下CPU不會是redis的瓶頸，redis 的瓶頸最有可能是機器內(nèi)存的大小或者網(wǎng)絡帶寬。

既然CPU不會成為瓶頸，那就順理成章地采用單線程的方案了，因為如果使用多線程的話會更復雜，同時需要引入上下文切換、加鎖等等，會帶來額外的性能消耗。

而隨著近些年互聯(lián)網(wǎng)的不斷發(fā)展，大家對于緩存的性能要求也越來越高了，因此 redis 也開始在逐漸往多線程方向發(fā)展。

最近的 6.0 版本就對核心流程引入了多線程，主要用于解決 redis 在網(wǎng)絡 I/O 上的性能瓶頸。而對于核心的命令執(zhí)行階段，目前還是單線程的。

3、Redis 為什么使用單進程、單線程也很快

主要有以下幾點：

1、基于內(nèi)存的操作

2、使用了 I/O 多路復用模型，select、epoll 等，基于 reactor 模式開發(fā)了自己的網(wǎng)絡事件處理器

3、單線程可以避免不必要的上下文切換和競爭條件，減少了這方面的性能消耗。

4、以上這三點是 redis 性能高的主要原因，其他的還有一些小優(yōu)化，例如：對數(shù)據(jù)結(jié)構(gòu)進行了優(yōu)化，簡單動態(tài)字符串、壓縮列表等。

4、Redis 在項目中的使用場景

緩存（核心）、分布式鎖（set + lua 腳本）、排行榜（zset）、計數(shù)（incrby）、消息隊列（stream）、地理位置（geo）、訪客統(tǒng)計（hyperloglog）等。

5、Redis 常見的數(shù)據(jù)結(jié)構(gòu)

基礎的5種：

String：字符串，最基礎的數(shù)據(jù)類型。
List：列表。
Hash：哈希對象。
Set：集合。
Sorted Set：有序集合，Set 的基礎上加了個分值。

高級的4種：

HyperLogLog：通常用于基數(shù)統(tǒng)計。使用少量固定大小的內(nèi)存，來統(tǒng)計集合中唯一元素的數(shù)量。統(tǒng)計結(jié)果不是精確值，而是一個帶有0.81%標準差（standard error）的近似值。所以，HyperLogLog適用于一些對于統(tǒng)計結(jié)果精確度要求不是特別高的場景，例如網(wǎng)站的UV統(tǒng)計。
Geo：redis 3.2 版本的新特性。可以將用戶給定的地理位置信息儲存起來，并對這些信息進行操作：獲取2個位置的距離、根據(jù)給定地理位置坐標獲取指定范圍內(nèi)的地理位置集合。
Bitmap：位圖。
Stream：主要用于消息隊列，類似于 kafka，可以認為是 pub/sub 的改進版。提供了消息的持久化和主備復制功能，可以讓任何客戶端訪問任何時刻的數(shù)據(jù)，并且能記住每一個客戶端的訪問位置，還能保證消息不丟失。

6、Redis 的字符串（SDS）和C語言的字符串區(qū)別

7、Sorted Set底層數(shù)據(jù)結(jié)構(gòu)

Sorted Set（有序集合）當前有兩種編碼：ziplist、skiplist

ziplist：使用壓縮列表實現(xiàn)，當保存的元素長度都小于64字節(jié)，同時數(shù)量小于128時，使用該編碼方式，否則會使用 skiplist。這兩個參數(shù)可以通過 zset-max-ziplist-entries、zset-max-ziplist-value 來自定義修改。

skiplist：zset實現(xiàn)，一個zset同時包含一個字典（dict）和一個跳躍表（zskiplist）

8、Sorted Set 為什么同時使用字典和跳躍表？

主要是為了提升性能。

單獨使用字典：在執(zhí)行范圍型操作，比如 zrank、zrange，字典需要進行排序，至少需要 O(NlogN) 的時間復雜度及額外 O(N) 的內(nèi)存空間。

單獨使用跳躍表：根據(jù)成員查找分值操作的復雜度從 O(1) 上升為 O(logN)。

9、Sorted Set 為什么使用跳躍表，而不是紅黑樹？

主要有以下幾個原因：

1）跳表的性能和紅黑樹差不多。

2）跳表更容易實現(xiàn)和調(diào)試。

網(wǎng)上有同學說是因為作者不會紅黑樹，我覺得挺有可能的。

10、Hash 對象底層結(jié)構(gòu)

Hash 對象當前有兩種編碼：ziplist、hashtable

ziplist：使用壓縮列表實現(xiàn)，每當有新的鍵值對要加入到哈希對象時，程序會先將保存了鍵的節(jié)點推入到壓縮列表的表尾，然后再將保存了值的節(jié)點推入到壓縮列表表尾。

因此：1）保存了同一鍵值對的兩個節(jié)點總是緊挨在一起，保存鍵的節(jié)點在前，保存值的節(jié)點在后；2）先添加到哈希對象中的鍵值對會被放在壓縮列表的表頭方向，而后來添加的會被放在表尾方向。

hashtable：使用字典作為底層實現(xiàn)，哈希對象中的每個鍵值對都使用一個字典鍵值來保存，跟 java 中的 HashMap 類似。

11、Hash 對象的擴容流程

hash 對象在擴容時使用了一種叫“漸進式 rehash”的方式，步驟如下：

1）計算新表 size、掩碼，為新表 ht[1] 分配空間，讓字典同時持有 ht[0] 和 ht[1] 兩個哈希表。

2）將 rehash 索引計數(shù)器變量 rehashidx 的值設置為0，表示 rehash 正式開始。

3）在 rehash 進行期間，每次對字典執(zhí)行添加、刪除、査找、更新操作時，程序除了執(zhí)行指定的操作以外，還會觸發(fā)額外的 rehash 操作，在源碼中的 _dictRehashStep 方法。

_dictRehashStep：從名字也可以看出來，大意是 rehash 一步，也就是 rehash 一個索引位置。

該方法會從 ht[0] 表的 rehashidx 索引位置上開始向后查找，找到第一個不為空的索引位置，將該索引位置的所有節(jié)點 rehash 到 ht[1]，當本次 rehash 工作完成之后，將 ht[0] 索引位置為 rehashidx 的節(jié)點清空，同時將 rehashidx 屬性的值加一。

4）將 rehash 分攤到每個操作上確實是非常妙的方式，但是萬一此時服務器比較空閑，一直沒有什么操作，難道 redis 要一直持有兩個哈希表嗎？

答案當然不是的。我們知道，redis 除了文件事件外，還有時間事件，redis 會定期觸發(fā)時間事件，這些時間事件用于執(zhí)行一些后臺操作，其中就包含 rehash 操作：當 redis 發(fā)現(xiàn)有字典正在進行 rehash 操作時，會花費1毫秒的時間，一起幫忙進行 rehash。

5）隨著操作的不斷執(zhí)行，最終在某個時間點上，ht[0] 的所有鍵值對都會被 rehash 至 ht[1]，此時 rehash 流程完成，會執(zhí)行最后的清理工作：釋放 ht[0] 的空間、將 ht[0] 指向 ht[1]、重置 ht[1]、重置 rehashidx 的值為 -1。