推薦學習:《》
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資料持久化有三種方式。
AOF 紀錄檔(Append Only File,檔案追加方式):記錄所有的操作命令,並以文字的形式追加到檔案中。
RDB 快照(Redis DataBase):將某一個時刻的記憶體資料,以二進位制的方式寫入磁碟。
混合持久化方式: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 叢集。
主從複製
將從前的一臺 Redis 伺服器,同步資料到多臺從 Redis 伺服器上,即一主多從的模式,這個跟MySQL主從複製的原理一樣。
哨兵模式
使用 Redis 主從服務的時候,會有一個問題,就是當 Redis 的主從伺服器出現故障宕機時,需要手動進行恢復,為了解決這個問題,Redis 增加了哨兵模式(因為哨兵模式做到了可以監控主從伺服器,並且提供自動容災恢復的功能)。
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,被對映到一個雜湊槽中,具體執行過程分為兩大步。
根據鍵值對的 key,按照 CRC16 演演算法計算一個 16 bit 的值。
再用 16bit 值對 16384 取模,得到 0~16383 範圍內的模數,每個模數代表一個相應編號的雜湊槽。
每個Redis節點負責處理一部分槽位,加入你有三個master節點 ABC,每個節點負責的槽位如下:
這樣就實現了cluster節點的選擇。
推薦學習:《》、《》
以上就是redis面試中常被問到的12個重點(附答案)的詳細內容,更多請關注TW511.COM其它相關文章!