1.說說 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簡單動態字串

2.串列物件list：ziplist、linkedlist

3.哈希物件hash：ziplist、hashtable

4.集合物件set：intset、hashtable

5.有序集合物件zset：ziplist、skiplist

2.Redis 為什么快呢？

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

1.完全基于記憶體操作

2.C語言實作，優化過的資料結構，基于幾種基礎的資料結構，redis做了大量的優化，性能極高

3.使用單執行緒，無背景關系的切換成本

4.基于非阻塞的IO多路復用機制

3.那為什么 Redis6.0 之后又改用多執行緒呢?

redis使用多執行緒并非是完全摒棄單執行緒，redis還是使用單執行緒模型來處理客戶端的請求，只是使用多執行緒來處理資料的讀寫和協議決議，執行命令還是使用單執行緒，

這樣做的目的是因為redis的性能瓶頸在于網路IO而非CPU，使用多執行緒能提升IO讀寫的效率，從而整體提高redis的性能，

4.知道什么是熱 key 嗎？熱 key 問題怎么解決？

所謂熱key問題就是，突然有幾十萬的請求去訪問redis上的某個特定key，那么這樣會造成流量過于集中，達到物理網卡上限，從而導致這臺redis的服務器宕機引發雪崩，

針對熱key的解決方案：

1.提前把熱key打散到不同的服務器，降低壓力

2.加入二級快取，提前加載熱key資料到記憶體中，如果redis宕機，走記憶體查詢

5.什么是快取擊穿、快取穿透、快取雪崩？

快取擊穿

快取擊穿的概念就是單個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的方案，

6.Redis 的過期策略有哪些？

redis主要有2種過期洗掉策略

惰性洗掉

惰性洗掉指的是當我們查詢key的時候才對key進行檢測，如果已經達到過期時間，則洗掉，顯然，他有一個缺點就是如果這些過期的key沒有被訪問，那么他就一直無法被洗掉，而且一直占用記憶體，

定期洗掉

定期洗掉指的是redis每隔一段時間對資料庫做一次檢查，洗掉里面的過期key，由于不可能對所有key去做輪詢來洗掉，所以redis會每次隨機取一些key去做檢查和洗掉，

7.那么定期+惰性都沒有洗掉過期的 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進行淘汰

6.noeviction：當記憶體達到閾值的時候，新寫入操作報錯

8.持久化方式有哪些？有什么區別？

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

RDB

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

可以通過SAVE或者BGSAVE來生成RDB檔案，

SAVE命令會阻塞redis行程，直到RDB檔案生成完畢，在行程阻塞期間，redis不能處理任何命令請求，這顯然是不合適的，

BGSAVE則是會fork出一個子行程，然后由子行程去負責生成RDB檔案，父行程還可以繼續處理命令請求，不會阻塞行程，

AOF

AOF和RDB不同，AOF是通過保存redis服務器所執行的寫命令來記錄資料庫狀態的，

AOF通過追加、寫入、同步三個步驟來實作持久化機制，

1.當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檔案之后的所有寫命令資料，

9.怎么實作 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詢問，如果超過半數的投票認為已經是下線狀態，則會標記為客觀下線狀態，同時觸發故障轉移，

10.能說說 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-16383個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協議做選舉，

11.了解 Redis 事務機制嗎？

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

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

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

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

WATCH的機制本身是一個CAS的機制，被監視的key會被保存到一個鏈表中，如果某個key被修改，那么REDIS_DIRTY_CAS標志將會被打開，這時服務器會拒絕執行事務，

 作者 | 科技繆繆

本文來自博客園，作者：古道輕風，轉載請注明原文鏈接：https://www.cnblogs.com/88223100/p/Redis-Interview-Questions.html

標籤：其他

上一篇：計算機視覺崗社招面經

下一篇：力扣02 兩數相加