redis面試提問

redis面試提問

轉載:https://blog.csdn.net/uuqaz/article/details/127088333

Redis 是面試中繞不過的檻，只要在簡歷中寫了用過 Redis，肯定逃不過。今天我們就來模擬一下麵試官在 Redis 這個話題上是如何一步一步深入，全面考察候選人對於 Redis 的掌握情況。

小二：面試官，你好。我是來參加面試的。

面試官：你好，小二。我看了你的簡歷，熟練掌握 Redis，那麼我就隨便問你幾個 Redis 相關的問題吧。首先我的問題是，Redis 是單線程還是多線程呢 ？

小二：

Redis 不同版本之間採用的線程模型是不一樣的，在 Redis4.0 版本之前使用的是單線程模型，在 4.0 版本之後增加了多線程的支持。

在 4.0 之前雖然我們說 Redis 是單線程，也只是說它的網路 I/O 線程以及 Set 和 Get 操作是由一個線程完成的。但是 Redis 的持久化、集群同步還是使用其他線程來完成。

4.0 之後添加了多線程的支持，主要是體現在大數據的非同步刪除功能上，例如 unlink key、flushdb async、flushall async 等

面試官：回答的很好，那為什麼 Redis 在 4.0 之前會選擇使用單線程？而且使用單線程還那麼快 ？

小二：

選擇單線程個人覺得主要是使用簡單，不存在鎖競爭，可以在無鎖的情況下完成所有操作，不存在死鎖和線程切換帶來的性能和時間上的開銷，但同時單線程也不能完全發揮出多核 CPU 的性能。

至於為什麼單線程那麼快我覺得主要有以下幾個原因：

Redis 的大部分操作都在記憶體中完成，記憶體中的執行效率本身就很快，並且採用了高效的數據結構，比如哈希表和跳錶。

使用單線程避免了多線程的競爭，省去了多線程切換帶來的時間和性能開銷，並且不會出現死鎖。

採用 I/O 多路復用機制處理大量客戶端的 Socket 請求，因為這是基於非阻塞的 I/O 模型，這就讓 Redis 可以高效地進行網路通信，I/O 的讀寫流程也不再阻塞。

面試官：不錯，那 Redis 是如何實現數據不丟失的呢 ？

小二：

Redis 數據是存儲在記憶體中的，為了保證 Redis 數據不丟失，那就要把數據從記憶體存儲到磁碟上，以便在伺服器重啟後還能夠從磁碟中恢複原有數據，這就是 Redis 的數據持久化。Redis 數據持久化有三種方式。

1）AOF 日誌（Append Only File，文件追加方式） ：記錄所有的操作命令，並以文本的形式追加到文件中。

2）RDB 快照（Redis DataBase） ：將某一個時刻的記憶體數據，以二進位的方式寫入磁碟。

3）混合持久化方式 ：Redis 4.0 新增了混合持久化的方式，集成了 RDB 和 AOF 的優點。

面試官：那你分別說說 AOF 和 RDB 的實現原理 吧。

小二：

AOF 採用的是寫後日誌的方式，Redis 先執行命令把數據寫入記憶體，然後再記錄日誌到文件中。AOF 日誌記錄的是操作命令，不是實際的數據，如果採用 AOF 方法做故障恢復時需要將全量日誌都執行一遍。

RDB 採用的是記憶體快照的方式，它記錄的是某一時刻的數據，而不是操作，所以採用 RDB 方法做故障恢復時只需要直接把 RDB 文件讀入記憶體即可，實現快速恢復。

面試官：你剛提到了 AOF 採用的是 “寫後日誌” 的方式，我們平時用的 MySQL 則採用的是 “寫前日誌”，那 Redis 為什麼要先執行命令，再把數據寫入日誌呢 ？

小二：這個主要是由於 Redis 在寫入日誌之前，不對命令進行語法檢查，所以只記錄執行成功的命令，避免出現記錄錯誤命令的情況，而且在命令執行後再寫日誌不會阻塞當前的寫操作。

面試官：那後寫日誌又有什麼風險呢 ？

小二：我... 這個我不會。

面試官：

好吧，後寫日誌主要有兩個風險可能會發生：

數據可能會丟失 ：如果 Redis 剛執行完命令，此時發生故障宕機，會導致這條命令存在丟失的風險。

可能阻塞其他操作 ：AOF 日誌其實也是在主線程中執行，所以當 Redis 把日誌文件寫入磁碟的時候，還是會阻塞後續的操作無法執行。

我還有個問題是 RDB 做快照時會阻塞線程嗎 ？

小二：Redis 提供了兩個命令來生成 RDB 快照文件，分別是 save 和 bgsave。save 命令在主線程中執行，會導致阻塞。而 bgsave 命令則會創建一個子進程，用於寫入 RDB 文件的操作，避免了對主線程的阻塞，這也是 Redis RDB 的預設配置。

面試官：RDB 做快照的時候數據能修改嗎 ？

小二：save 是同步的會阻塞客戶端命令，bgsave 的時候是可以修改的。

面試官：那 Redis 是怎麼解決在 bgsave 做快照的時候允許數據修改呢 ？

小二：額，這個我不太清楚...

面試官：

這裡主要是利用 bgsave 的子線程實現的，具體操作如下：

如果主線程執行讀操作，則主線程和 bgsave 子進程互相不影響；

如果主線程執行寫操作，則被修改的數據會複製一份副本，然後 bgsave 子進程會把該副本數據寫入 RDB 文件，在這個過程中，主線程仍然可以直接修改原來的數據。

要註意，Redis 對 RDB 的執行頻率非常重要，因為這會影響快照數據的完整性以及 Redis 的穩定性，所以在 Redis 4.0 後，增加了 AOF 和 RDB 混合的數據持久化機制：把數據以 RDB 的方式寫入文件，再將後續的操作命令以 AOF 的格式存入文件，既保證了 Redis 重啟速度，又降低數據丟失風險。

小二：學到了學到了。

面試官：那你再跟我說說 Redis 如何實現高可用 吧？

小二：Redis 實現高可用主要有三種方式：主從複製、哨兵模式，以及 Redis 集群。

1）主從複製

將從前的一臺 Redis 伺服器，同步數據到多台從 Redis 伺服器上，即一主多從的模式，這個跟 MySQL 主從複製的原理一樣。

2）哨兵模式

使用 Redis 主從服務的時候，會有一個問題，就是當 Redis 的主從伺服器出現故障宕機時，需要手動進行恢復，為瞭解決這個問題，Redis 增加了哨兵模式（因為哨兵模式做到了可以監控主從伺服器，並且提供自動容災恢復的功能）。

3）Redis Cluster（集群）

Redis Cluster 是一種分散式去中心化的運行模式，是在 Redis 3.0 版本中推出的 Redis 集群方案，它將數據分佈在不同的伺服器上，以此來降低系統對單主節點的依賴，從而提高 Redis 服務的讀寫性能。

面試官：使用哨兵模式在數據上有副本數據做保證，在可用性上又有哨兵監控，一旦 master 宕機會選舉 salve 節點為 master 節點，這種已經滿足了我們的生產環境需要，那為什麼還需要使用集群模式呢 ？

小二：哨兵模式歸根節點還是主從模式，在主從模式下我們可以通過增加 salve 節點來擴展讀併發能力，但是沒辦法擴展寫能力和存儲能力，存儲能力只能是 master 節點能夠承載的上限。所以為了擴展寫能力和存儲能力，我們就需要引入集群模式。

面試官：集群中那麼多 Master 節點，Redis Cluster 在存儲的時候如何確定選擇哪個節點呢 ？

小二：這應該是使用了某種 hash 演算法，但是我不太清楚。。。

面試官：那好，今天的面試就到這裡吧，你先回去等我們的面試通知。

小二：好的，謝謝面試官，你能告訴我 Redis Cluster 怎麼實現節點選擇的嗎？

面試官：

Redis Cluster 採用的是類一致性哈希演算法實現節點選擇的，至於什麼是一致性哈希演算法你自己回去看看。

Redis Cluster 將自己分成了 16384 個 Slot（槽位），哈希槽類似於數據分區，每個鍵值對都會根據它的 key，被映射到一個哈希槽中，具體執行過程分為兩大步。

1）根據鍵值對的 key，按照 CRC16 演算法計算一個 16 bit 的值。

2）再用 16bit 值對 16384 取模，得到 0~16383 範圍內的模數，每個模數代表一個相應編號的哈希槽。

每個 Redis 節點負責處理一部分槽位，假如你有三個 master 節點 ABC，每個節點負責的槽位如下：

節點 處理槽位
A 0-5000
B 5001 - 10000
C 10001 - 16383
這樣就實現了 cluster 節點的選擇。