這是面試題系列第三篇--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簡單動態字串
2. 列表物件list：ziplist、linkedlist
3. 雜湊物件hash：ziplist、hashtable
4. 集合物件set：intset、hashtable
5. 有序集合物件zset：ziplist、skiplist

Redis為什麼快呢？

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

1. 完全基於記憶體操作
2. C語言實現，優化過的資料結構，基於幾種基礎的資料結構，redis做了大量的優化，效能極高
3. 使用單執行緒，無上下文的切換成本
4. 基於非阻塞的IO多路複用機制

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

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

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

知道什麼是熱key嗎？熱key問題怎麼解決？

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

針對熱key的解決方案：

1. 提前把熱key打散到不同的伺服器，降低壓力
2. 加入二級快取，提前載入熱key資料到記憶體中，如果redis宕機，走記憶體查詢

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

快取擊穿

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

解決方案：

1. 加鎖更新，比如請求查詢A，發現快取中沒有，對A這個key加鎖，同時去資料庫查詢資料，寫入快取，再返回給使用者，這樣後面的請求就可以從快取中拿到資料了。
2. 將過期時間組合寫在value中，通過非同步的方式不斷的重新整理過期時間，防止此類現象。

https://tva

快取穿透

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

針對這個問題，加一層布隆過濾器。布隆過濾器的原理是在你存入資料的時候，會通過雜湊函式將它對映為一個位數組中的K個點，同時把他們置為1。

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

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

快取雪崩

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

針對雪崩幾個解決方案：

1. 針對不同key設定不同的過期時間，避免同時過期
2. 限流，如果redis宕機，可以限流，避免同時刻大量請求打崩DB
3. 二級快取，同熱key的方案。

Redis的過期策略有哪些？

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

惰性刪除

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

定期刪除

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

那麼定期+惰性都沒有刪除過期的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：當記憶體達到閾值的時候，新寫入操作報錯

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

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檔案之後的所有寫命令資料。

怎麼實現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標誌將會被開啟，這時伺服器會拒絕執行事務。

- END -