Redis基本數(shù)據(jù)類型有哪些

 

字符串：redis沒有直接使用C語言傳統(tǒng)的字符串表示，而是自己實現(xiàn)的叫做簡單動態(tài)字符串SDS的抽象類型。C語言的字符串不記錄自身的長度信息，而SDS則保存了長度信息，這樣將獲取字符串長度的時間由O（N）降低到了O（1），同時可以避免緩沖區(qū)溢出和減少修改字符串長度時所需的內(nèi)存重分配次數(shù)。

 

 

鏈表linkedlist：redis鏈表是一個雙向無環(huán)鏈表結(jié)構(gòu)，很多發(fā)布訂閱、慢查詢、監(jiān)視器功能都是使用到了鏈表來實現(xiàn)，每個鏈表的節(jié)點由一個listNode結(jié)構(gòu)來表示，每個節(jié)點都有指向前置節(jié)點和后置節(jié)點的指針，同時表頭節(jié)點的前置和后置節(jié)點都指向NULL。

 

字典hashtable：用于保存鍵值對的抽象數(shù)據(jù)結(jié)構(gòu)。redis使用hash表作為底層實現(xiàn)，每個字典帶有兩個hash表，供平時使用和rehash時使用，hash表使用鏈地址法來解決鍵沖突，被分配到同一個索引位置的多個鍵值對會形成一個單向鏈表，在對hash表進行擴容或者縮容的時候，為了服務的可用性，rehash的過程不是一次性完成的，而是漸進式的。

 

跳躍表skiplist：跳躍表是有序集合的底層實現(xiàn)之一，redis中在實現(xiàn)有序集合鍵和集群節(jié)點的內(nèi)部結(jié)構(gòu)中都是用到了跳躍表。redis跳躍表由zskiplist和zskiplistNode組成，zskiplist用于保存跳躍表信息（表頭、表尾節(jié)點、長度等），zskiplistNode用于表示表跳躍節(jié)點，每個跳躍表的層高都是1-32的隨機數(shù)，在同一個跳躍表中，多個節(jié)點可以包含相同的分值，但是每個節(jié)點的成員對象必須是唯一的，節(jié)點按照分值大小排序，如果分值相同，則按照成員對象的大小排序。

 

整數(shù)集合intset：用于保存整數(shù)值的集合抽象數(shù)據(jù)結(jié)構(gòu)，不會出現(xiàn)重復元素，底層實現(xiàn)為數(shù)組。

 

壓縮列表ziplist：壓縮列表是為節(jié)約內(nèi)存而開發(fā)的順序性數(shù)據(jù)結(jié)構(gòu)，他可以包含多個節(jié)點，每個節(jié)點可以保存一個字節(jié)數(shù)組或者整數(shù)值。

 

基于這些基礎的數(shù)據(jù)結(jié)構(gòu)，redis封裝了自己的對象系統(tǒng)，包含字符串對象string、列表對象list、哈希對象hash、集合對象set、有序集合對象zset，每種對象都用到了至少一種基礎的數(shù)據(jù)結(jié)構(gòu)。

 

redis通過encoding屬性設置對象的編碼形式來提升靈活性和效率，基于不同的場景redis會自動做出優(yōu)化。不同對象的編碼如下：

 

字符串對象string：int整數(shù)、embstr編碼的簡單動態(tài)字符串、raw簡單動態(tài)字符串

 

列表對象list：ziplist、linkedlist

 

哈希對象hash：ziplist、hashtable

 

集合對象set：intset、hashtable

 

有序集合對象zset：ziplist、skiplist

 

Redis為什么快呢？

 

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

 

完全基于內(nèi)存操作

 

C語言實現(xiàn)，優(yōu)化過的數(shù)據(jù)結(jié)構(gòu)，基于幾種基礎的數(shù)據(jù)結(jié)構(gòu)，redis做了大量的優(yōu)化，性能極高

 

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

 

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

 

那為什么Redis6.0之后又改用多線程呢？

 

redis使用多線程并非是完全摒棄單線程，redis還是使用單線程模型來處理客戶端的請求，只是使用多線程來處理數(shù)據(jù)的讀寫和協(xié)議解析，執(zhí)行命令還是使用單線程。

 

這樣做的目的是因為redis的性能瓶頸在于網(wǎng)絡IO而非CPU，使用多線程能提升IO讀寫的效率，從而整體提高redis的性能。

 

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

 

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

 

針對熱key的解決方案：

 

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

 

加入二級緩存，提前加載熱key數(shù)據(jù)到內(nèi)存中，如果redis宕機，走內(nèi)存查詢

 

什么是緩存擊穿、緩存穿透、緩存雪崩？

 

緩存擊穿

 

緩存擊穿的概念就是單個key并發(fā)訪問過高，過期時導致所有請求直接打到db上，這個和熱key的問題比較類似，只是說的點在于過期導致請求全部打到DB上而已。解決方案：

鎖定和更新，比如請求查詢A，發(fā)現(xiàn)不在緩存中，鎖定密鑰A，同時查詢數(shù)據(jù)庫中的數(shù)據(jù)，寫入緩存，然后返回給用戶，這樣以后的請求就可以從緩存中獲取數(shù)據(jù)。

將到期時間的組合寫入值中，并以異步方式不斷刷新到期時間，以防止這種現(xiàn)象。

緩存穿透

緩存穿透指的是查詢緩存中不存在的數(shù)據(jù)，每個請求都會命中DB，就好像緩存不存在一樣。

為了解決這個問題，添加一層布隆過濾器。Bloom  filter的原理是當你存儲數(shù)據(jù)時，會通過hash函數(shù)映射到一個位數(shù)組中的K個點，同時將它們設置為1。

這樣，當用戶再次查詢A，而A在Bloom過濾器中為0，直接返回時，就不會有對DB的細分請求。

顯然，使用Bloom  filter后，會出現(xiàn)誤判的問題，因為它本身就是一個數(shù)組，可能會有多個值落到同一個位置。理論上，只要我們的陣列足夠長，誤判的概率就會更低，這種問題要根據(jù)實際情況來定。

緩存雪崩

當某個時刻發(fā)生大規(guī)模的緩存故障，比如你的緩存服務宕機，就會有大量的請求進來，直接打到DB，可能導致整個系統(tǒng)崩潰，這就叫雪崩。與雪崩擊穿和熱鍵問題不同，他的意思是大規(guī)模緩存已經(jīng)過期。

雪崩的幾種解決方案：

為不同的密鑰設置不同的到期時間，以避免同時到期。

限流，如果redis宕機，您可以前往限流，從而避免同時出現(xiàn)大量崩潰DB的請求。

二級緩存，同樣的熱鍵方案。

Redis的到期政策有哪些？

Redis主要有兩種過期刪除策略。

惰性缺失

惰性刪除是指我們查詢密鑰時檢測到密鑰，如果已經(jīng)到了過期時間，則刪除密鑰。顯然，他的一個缺點是，如果這些過期的密鑰不被訪問，那么它們就不能一直被刪除，而且它們總是會占用內(nèi)存。

定期刪除

定期刪除意味著redis每隔一段時間檢查一次數(shù)據(jù)庫，刪除其中過期的密鑰。因為不可能輪詢所有鍵來刪除它們，所以redis會隨機選擇一些鍵來一次檢查和刪除。

過期的鑰匙沒有被常規(guī)慣性刪除怎么辦？

假設redis定期隨機查詢時每次都沒有刪除密鑰，并且這些密鑰沒有被查詢，會導致這些密鑰被保存在redis中，無法刪除。這時候就要去redis的內(nèi)存消除機制了。

Volatile-lru:從設置了清除過期時間的密鑰中刪除最近最少使用的密鑰。

Volatile-ttl:從已設置過期時間的密鑰中刪除將要過期的密鑰。

Volatile-random:從設置了過期時間的密鑰中隨機選擇密鑰剔除。

Allkeys-lru:選擇最近最少使用的鍵進行消除。

Allkeys-random:從按鍵中隨機選擇按鍵以消除它們。

注意：當內(nèi)存達到閾值時，新的寫操作會報告一個錯誤。

堅持的方式有哪些？有什么區(qū)別？

Redis持久性方案分為RDB和AOF。

關(guān)系數(shù)據(jù)庫

RDB持久性可以根據(jù)配置手動或定期執(zhí)行。它的功能是將某個時間點的數(shù)據(jù)庫狀態(tài)保存到一個RDB文件中，這是一個壓縮的二進制文件，通過它可以恢復某個時刻的數(shù)據(jù)庫狀態(tài)。因為RDB文件存儲在硬盤上，所以即使redis崩潰或退出，只要RDB文件存在，它就可以用于恢復已恢復數(shù)據(jù)庫的狀態(tài)。

您可以通過保存或保存來生成RDB文件。

SAVE將阻止redis進程，直到生成RDB文件。在進程阻塞期間，redis不能處理任何命令請求，這顯然是不合適的。

BGSAVE會分叉出一個子進程，然后子進程負責生成RDB文件，父進程可以繼續(xù)處理命令請求，而不會阻塞進程。

吖啶橙熒光檢查法

與RDB不同，AOF通過保存redis服務器執(zhí)行的寫命令來記錄數(shù)據(jù)庫狀態(tài)。

AOF通過三個步驟實現(xiàn)持久性機制：追加、寫入和同步。

當AOF持久性處于活動狀態(tài)時，在服務器執(zhí)行寫命令后，寫命令將被追加到aof_buf緩沖區(qū)的末尾。

在服務器結(jié)束事件循環(huán)之前，它將調(diào)用flushAppendOnlyFile函數(shù)來決定是否將aof_buf的內(nèi)容保存在aof文件中，這可以通過配置appendfsync來決定。

總是##aof_buf內(nèi)容被寫入并同步到aof文件

Everysec  ##將aof_buf的內(nèi)容寫入aof文件，如果上次同步AOF文件的時間超過一秒鐘，請再次同步AOF文件。

No  ##將aof_buf的內(nèi)容寫入aof文件，但不同步AOF文件，同步時間由操作系統(tǒng)決定。如果沒有設置，默認選項將是每秒，因為總是最安全的(只丟失一次事件循環(huán)的寫命令)，但它的性能很差，而每秒模式可能只丟失1秒的數(shù)據(jù)，而沒有模式具有與每秒相同的效率，但它將丟失最后一次同步AOF文件后的所有寫命令數(shù)據(jù)。

如何實現(xiàn)Redis的高可用性？

要實現(xiàn)高可用性，一臺機器肯定是不夠的，redis有兩種選擇來保證高可用性。

主從架構(gòu)

主從模式是實現(xiàn)高可用性最簡單的方案，核心是主從同步。主從同步的原理如下：

從機向主機發(fā)送同步命令

收到mastersync后，執(zhí)行bgsave以生成完整的RDB文件。

將主從命令寫入緩存。

BG執(zhí)行后，將RDB文件發(fā)送給從機，從機執(zhí)行。

主機將緩存中的寫命令發(fā)送給從機，從機執(zhí)行該命令。

我這里寫的命令是sync，但是在redis2.8版本之后，用psync代替了sync，因為sync命令消耗了大量的系統(tǒng)資源，psync效率更高。

哨兵

主從方案的缺點很明顯。如果主機宕機，那么數(shù)據(jù)無法寫入，那么從機將失去功能，整個架構(gòu)將不可用。除非手動切換，否則主要原因是沒有自動故障轉(zhuǎn)移機制。Sentinel比簡單的主從架構(gòu)功能更全面，具有自動故障轉(zhuǎn)移、集群監(jiān)控、消息通知等功能。

哨兵可以同時監(jiān)控多個主從服務器，當被監(jiān)控的主服務器離線時，自動將一個從服務器提升為主服務器，然后新的主服務器將繼續(xù)接收命令。整個過程如下：

初始化sentinel，用sentinel特有的代碼替換普通的redis代碼。

初始化主詞典和服務器信息。服務器信息主要存儲ip:port，記錄實例的地址和ID。

用master創(chuàng)建兩個連接，命令連接和訂閱連接，訂閱sentinel:hello頻道。

每10秒向主機發(fā)送一次info命令，獲取主機及其下所有從機的當前信息。

發(fā)現(xiàn)主機有新的從機后，sentinel和新的從機也建立兩個連接，每10秒發(fā)送一個info命令更新主機信息。

Sentinel每1秒鐘向所有服務器發(fā)送ping命令。如果服務器在配置的響應時間內(nèi)連續(xù)返回無效回復，它將被標記為脫機。

選舉領袖哨兵，領袖哨兵需要哨兵同意的一半以上。

領導者哨兵從離線主設備的所有從設備中選擇一個，并將其轉(zhuǎn)換為主設備。

讓所有從機從新主機復制數(shù)據(jù)。

將原主服務器設置為新主服務器的從服務器。當原主服務器再次回復連接時，它將成為新主服務器的從服務器。

Sentinel會每1秒向所有實例(包括主從服務器和其他sentinel)發(fā)送ping命令，并根據(jù)回復判斷是否已經(jīng)離線。這種方法叫主觀下線。當判斷為主觀下線時，會詢問其他監(jiān)控哨。如果超過半數(shù)的選票認為是離線，則標記為客觀離線，觸發(fā)故障轉(zhuǎn)移。

你能告訴我redis集群的原理嗎？

如果依靠sentry可以實現(xiàn)redis的高可用性，如果想支持高并發(fā)同時又能容納大量數(shù)據(jù)，就需要redis集群。Redis集群是redis提供的分布式數(shù)據(jù)存儲方案。群集通過數(shù)據(jù)分片共享數(shù)據(jù)，并提供復制和故障轉(zhuǎn)移功能。

結(jié)節(jié)

redis集群由多個節(jié)點組成，這些節(jié)點通過cluster  meet命令進行連接。節(jié)點的握手過程：

節(jié)點從客戶端接收群集會議命令。

a根據(jù)接收到的IP地址和端口號向B發(fā)送滿足消息。

節(jié)點B接收到滿足消息并返回pong。

知道A和B收到了見面消息，他們返回了ping消息，握手成功。

最后，節(jié)點A會通過流言協(xié)議將節(jié)點B的信息傳播給集群中的其他節(jié)點，其他節(jié)點也會和B握手。

當接收到客戶端EXEC命令時，WATCH命令監(jiān)控整個事務中的鍵是否被修改。如果是，它會向客戶端返回一個空的回復來指示失敗。否則，redis將遍歷整個事務隊列，執(zhí)行存儲在隊列中的所有命令，最后將結(jié)果返回給客戶端。

WATCH機制本身是一個CAS機制。受監(jiān)控的密鑰將保存在鏈接列表中。如果一個密鑰被修改，REDIS_DIRTY_CAS標志將被打開，服務器將拒絕執(zhí)行該事務。