Redis的面試題目及答案有哪些

說說Redis基本資料型別有哪些吧

1. 字串：redis沒有直接使用C語言傳統的字串表示，而是自己實作的叫做簡單動態字串SDS的抽象類型。 C語言的字串不記錄自身的長度信息，而SDS則保存了長度信息，這樣將獲取字符串長度的時間由O(N)降低到了O(1)，同時可以避免緩衝區溢出和減少修改字符串長時所需的記憶體重新分配次數。

2. 鍊錶linkedlist：redis鍊錶是一個雙向無環鍊錶結構，很多發布訂閱、慢查詢、監視器功能都是使用到了鍊錶來實現，每個鍊錶的節點由一個listNode結構來表示，每個節點都有指向前置節點和後置節點的指針，同時表頭節點的前置和後置節點都指向NULL。

3. 字典hashtable：用於保存鍵值對的抽象資料結構。 redis使用hash表作為底層實現，每個字典帶有兩個hash表，供平時使用和rehash時使用，hash表使用鏈地址法來解決鍵衝突，被分配到同一個索引位置的多個鍵值對會形成一個單向鍊錶，在對hash表進行擴容或縮容的時候，為了服務的可用性，rehash的過程不是一次性完成的，而是漸進式的。

4. 跳躍表skiplist：跳躍表是有序集合的底層實作之一，redis中在實作有序集合鍵和群集節點的內部結構中都是用到了跳躍表。 redis跳躍表由zskiplist和zskiplistNode組成，zskiplist用於保存跳躍表資訊（表頭、表尾節點、長度等），zskiplistNode用於表示表跳躍節點，每個跳躍表的層高都是1-32的隨機數，在同一個跳躍表中，多個節點可以包含相同的分值，但是每個節點的成員物件必須是唯一的，節點按照分數大小排序，如果分數相同，則按照成員物件的大小排序。

5. 整數集合intset：用於保存整數值的集合抽象資料結構，不會出現重複元素，底層實作為陣列。

6. 壓縮列表ziplist：壓縮列表是為節約記憶體而開發的順序性資料結構，他可以包含多個節點，每個節點可以保存一個位元組數組或整數值。

基於這些基礎的資料結構，redis 封裝了自己的物件系統，包含字串物件string、清單物件list、雜湊物件hash、集合物件set、有序集合對象zset，每個物件都用到了至少一種基礎的資料結構。

redis 透過encoding屬性設定物件的編碼形式來提升靈活性和效率，基於不同的場景redis會自動做出最佳化。不同物件的編碼如下：

1. 字串物件string：int整數、embstr編碼的簡單動態字串、raw簡單動態字串

1. 清單物件list：ziplist、linkedlist

1. #雜湊物件hash：ziplist、hashtable

1. 集合物件set：intset、hashtable

#有序集合物件zset：ziplist、skiplist
4. #Redis為什麼快呢？

redis  的速度非常的快，單機的 redis 就可以支撐每秒10幾萬的並發，相對於 mysql 來說，效能是 mysql 的幾十倍。速度快的原因主要有幾點：

完全基於記憶體操作

#C語言實現，優化的資料結構，基於幾種基礎的資料結構，redis做了大量的最佳化，效能極高

使用單線程，無上下文的切換成本

基於非阻塞的IO多工機制

1. 那為什麼Redis6.0之後又改用多執行緒呢?

2. redis  使用多執行緒並非是完全摒棄單線程，redis  還是使用單線程模型來處理客戶端的請求，只是使用多線程來處理資料的讀寫和協定解析，執行命令還是使用單線程。

   ###這樣做的目的是因為 redis  的效能瓶頸在於網路IO而非CPU，使用多執行緒能提升IO讀寫的效率，進而整體提升 redis 的效能。 #########知道什麼是熱key嗎？熱key問題怎麼解決？ #########所謂熱key問題就是，突然有數十萬的請求去訪問redis  上的某個特定key，那麼這樣會造成流量過於集中，達到實體網卡上限，從而導致這台redis的伺服器宕機引發雪崩。 ######針對熱key的解決方案：############提前把熱key打散到不同的伺服器，降低壓力############加入二級緩存，提前載入熱key資料到記憶體中，如果redis 宕機，走記憶體查詢###

什麼是快取擊穿、快取穿透、快取雪崩？

快取擊穿

快取擊穿的概念就是單一key並發存取過高，過期時導致所有請求直接打到db上，這個和熱key的問題比較類似，只是說的點在於過期導致請求全部打到DB上而已。

解決方案：

1. 加鎖更新，例如請求查詢A，發現快取中沒有，對A這個key加鎖，同時去資料庫查詢數據，寫入緩存，再返回給用戶，這樣後面的請求就可以從快取中拿到資料了。

2. 將過期時間組合寫在value中，透過非同步的方式不斷的刷新過期時間，防止此類現象。

快取穿透

快取穿透是指查詢不存在快取中的數據，每次要求都會打到DB，就像快取不存在一樣。

針對這個問題，加一層布隆過濾器。布隆過濾器的操作步驟是，將資料透過雜湊函數對應為位數組中的K個點，並將這些點設為1，用於儲存資料。

這樣當使用者再來查詢A，而A在布隆過濾器值為0，直接傳回，就不會產生擊穿請求打到DB了。

顯然，使用布隆過濾器之後會有一個問題就是誤判，因為它本身就是一個數組，可能會有多個值落到同一個位置，那麼理論上只要我們的數組長度夠長，誤判的機率就會越低，這種問題就根據實際情況來就好了。

快取雪崩

當某一時刻發生大規模的快取失效的情況，例如你的快取服務宕機了，會有大量的請求進來直接打到DB上，這樣可能導致整個系統的崩潰，稱為雪崩。與擊穿和熱key問題不同的是，雪崩問題指的是大規模快取同時過期失效。

針對雪崩幾個解決方案：

1. 針對不同key設定不同的過期時間，避免同時過期

2. 。流，如果redis宕機，可以限流，避免同時刻大量請求打崩DB

3. 二級緩存，同熱key的方案。

Redis的過期策略有哪些？

redis主要有2種過期刪除策略

惰性刪除

#惰性刪除是指在查詢key時才對其進行檢測，如果已過期則進行刪除。如果這些過期的鍵沒有被訪問，他的一個明顯缺點就是會一直佔用記憶體且無法被刪除。

定期刪除

在Redis中，定期刪除是指定時檢查資料庫中的鍵值對，將過期的鍵值對刪除。 Redis在刪除操作時無法對所有鍵執行輪詢，因此會隨機選擇一些鍵進行檢查和刪除。

那麼定期 惰性都沒有刪除過期的key怎麼辦？

假設redis每次定期隨機查詢key的時候沒有刪掉，這些key也沒有做查詢的話，就會導致這些key一直保存在redis裡面無法被刪除，這時候就會走到redis的記憶體淘汰機制。

1. volatile-lru：從已設定過期時間的key中，移出最近最少使用的key進行淘汰

2. volatile-ttl：從已設定過期時間的key中，移出將要過期的key

3. volatile-random：從已設定過期時間的key中隨機選擇key淘汰

4. #allkeys-lru：從key中選擇最近最少使用的進行淘汰

5. allkeys-random：從key中隨機選擇key進行淘汰

#noeviction：當記憶體達到門檻的時候，新寫入操作報錯

持久化方式有哪些？有什麼區別？

redis持久化方案分為RDB和AOF兩種。

RDB

RDB持久化可以手動執行也可以根據設定定期執行，它的作用是將某個時間點上的資料庫狀態儲存到RDB檔案中，RDB檔案是一個壓縮的二進位文件，透過它可以還原某個時刻資料庫的狀態。由於RDB檔案是保存在硬碟上的，所以即使redis崩潰或退出，只要RDB檔案存在，就可以用它來恢復還原資料庫的狀態。

1. 可以透過SAVE或BGSAVE來產生RDB檔。
   SAVE指令會阻塞redis進程，直到RDB檔案產生完畢，在進程阻塞期間，redis不能處理任何指令要求，這顯然是不合適的。 ######BGSAVE則是會fork出一個子進程，然後由子進程去負責產生RDB文件，父進程還可以繼續處理命令請求，不會阻塞進程。 ######AOF######AOF和RDB不同，AOF是透過保存redis伺服器所執行的寫入指令來記錄資料庫狀態的。 ######AOF透過追加、寫入、同步三個步驟來實現持久化機制。 ############當AOF持久化處於啟動狀態，伺服器執行完寫指令之後，寫入指令將會被追加append到aof_buf緩衝區的結尾###

2. 在伺服器每結束一個事件循環之前，將會呼叫flushAppendOnlyFile函數決定是否要將aof_buf的內容儲存到AOF檔案中，可以透過設定appendfsync來決定。

always ##aof_buf内容写入并同步到AOF文件
everysec ##将aof_buf中内容写入到AOF文件，如果上次同步AOF文件时间距离现在超过1秒，则再次对AOF文件进行同步
no ##将aof_buf内容写入AOF文件，但是并不对AOF文件进行同步，同步时间由操作系统决定

如果不設置，預設選項將會是everysec，因為always來說雖然最安全（只會遺失一次事件循環的寫入命令），但是效能較差，而everysec模式只不過會可能遺失1秒鐘的數據，而no模式的效率和everysec相仿，但是會遺失上次同步AOF檔之後的所有寫指令資料。

怎麼實現Redis的高可用？

要想實現高可用，一台機器肯定是不夠的，而redis要保證高可用，有2個可選方案。

主從架構

主從模式是最簡單的實作高可用的方案，核心就是主從同步。主從同步的原理如下：

1. slave發送sync命令到master

2. #master收到sync之後，執行bgsave，產生RDB全量文件

3. master把slave的寫入指令記錄到快取

4. #bgsave執行完畢之後，發送RDB檔案到slave，slave執行

5. #master發送快取中的寫指令到slave，slave執行

#這裡我寫的這個指令是sync，但是在redis2.8版本之後已經使用psync來取代sync了，原因是sync指令非常消耗系統資源，而psync的效率更高。

哨兵

基於主從方案的缺點還是很明顯的，假設master宕機，那麼就不能寫入數據，那麼slave也就失去了作用，整個架構就不可用了，除非你手動切換，主要原因就是因為沒有自動故障轉移機制。而哨兵(sentinel)的功能比單純的主從架構全面的多了，它具備自動故障轉移、叢集監控、訊息通知等功能。

哨兵可以同時監視多個主從伺服器，並且在被監視的master下線時，自動將某個slave提升為master，然後由新的master繼續接收命令。整個過程如下：

1. 初始化sentinel，將普通的redis程式碼替換成sentinel專用代碼

2. 初始化masters字典和伺服器訊息，伺服器訊息主要保存ip:port，並記錄實例的地址和ID

3. 創建和master的兩個連接，命令連接和訂閱連接，並訂閱sentinel:hello頻道

4. 每隔10秒向master發送info指令，取得master和它下面所有slave的目前資訊

5. 當發現master有新的slave之後，sentinel和新的slave同樣建立兩個連接，同時每個10秒發送info指令，更新master訊息

6. sentinel每隔1秒向所有伺服器發送ping指令，如果某台伺服器在配置的響應時間內連續返回無效回复，將會被標記為下線狀態

7. 選舉出領頭sentinel，領頭sentinel需要半數以上的sentinel同意

8. #領導sentinel從已下線的的master所有slave中挑選一個，將其轉換為master

9. #讓所有的slave改為從新的master複製資料

10. 將原來的master設定為新的master的從伺服器，當原來master重新回覆連線時，就變成了新master的從伺服器

sentinel會每隔1秒向所有實例（包括主從伺服器和其他sentinel）發送ping命令，並且根據回復判斷是否已經下線，這種方式叫做主觀下線。當判斷為主觀下線時，就會向其他監視的sentinel詢問，如果超過半數的投票認為已經是下線狀態，則會標記為客觀下線狀態，同時觸發故障轉移。

能說說redis集群的原理嗎？

如果說依靠哨兵可以實現redis的高可用，如果還想在支援高並發同時容納海量的數據，那就需要redis集群。 redis叢集是redis提供的分散式資料儲存方案，叢集透過資料分片sharding來進行資料的共享，同時提供複製和故障轉移的功能。

節點

一個redis叢集由多個節點node組成，而多個node之間透過cluster meet指令來進行連接，節點的握手過程：

1. 節點A收到客戶端的cluster meet指令

2. A根據收到的IP位址和連接埠號，向B發送一則meet訊息

3. 節點B收到meet訊息回傳pong

4. A知道B收到了meet訊息，回傳一則ping訊息，握手成功

5. 最後，節點A將會透過gossip協定把節點B的資訊傳播給叢集中的其他節點，其他節點也會和B進行握手

槽slot

redis透過叢集分片的形式來保存數據，整個叢集資料庫被分成16384個slot，叢集中的每個節點可以處理0-16384個slot，當資料庫16384個slot都有節點在處理時，叢集處於上線狀態，反之只要有一個slot沒有處理都會處理下線狀態。使用cluster addslots指令可以將slot指派給對應的節點處理。

slot是一個位數組，數組的長度是16384/8=2048，而數組的每一位用1表示被節點處理，0表示不處理，如圖所示的話表示A節點處理0-7的slot。

當客戶端向節點發送指令，如果剛好找到slot屬於目前節點，那麼節點就執行指令，反之，則會傳回一個MOVED指令到客戶端指引客戶端轉向正確的節點。 （MOVED過程是自動的）

如果增加或移出節點，對於slot的重新分配也是非常方便的，redis提供了工具幫助實現slot的遷移，整個過程是完全在線的，不需要停止服務。

故障轉移

如果節點A向節點B發送ping訊息，節點B沒有在規定的時間內回應pong，那麼節點A會標記節點B為pfail疑似下線狀態，同時把B的狀態透過訊息的形式傳送給其他節點，如果超過半數以上的節點都標記B為pfail狀態，B就會被標記為fail下線狀態，此時將會發生故障轉移，優先從複製資料較多的從節點選擇一個成為主節點，並且接管下線節點的slot，整個過程和哨兵非常類似，都是基於Raft協議做選舉。

了解Redis事務機制嗎？

redis 透過MULTI、EXEC、WATCH等命令來實現事務機制，事務執行程序將一系列多個命令按照順序一次執行，並且在執行期間，事務不會中斷，也不會去執行客戶端的其他請求，直到所有指令執行完畢。交易的執行過程如下：

1. 服務端收到客戶端請求，交易以MULTI開始

2. 如果客戶端正處於交易狀態，則會把事務放入佇列同時回傳給客戶端QUEUED，反之則直接執行這個指令

3. 當收到客戶端EXEC指令時，WATCH指令監視整個事務中的key是否有被修改，如果有則回傳空回客戶端表示失敗，否則redis會遍歷整個交易佇列，執行佇列中保存的所有指令，最後傳回結果給客戶端

WATCH的機製本身就是一個CAS的機制，被監視的key會被保存到一個鍊錶中，如果某個key被修改，那麼REDIS_DIRTY_CAS標誌將會被打開，這時伺服器會拒絕執行事務。

以上是Redis的面試題目及答案有哪些的詳細內容。更多資訊請關注PHP中文網其他相關文章！