說說Redis基本數據類型有哪些吧
- 字符串:redis沒有直接使用C語言傳統(tǒng)的字符串表示,而是自己實現的叫做簡單動態(tài)字符串SDS的抽象類型。C語言的字符串不記錄自身的長度信息,而SDS則保存了長度信息,這樣將獲取字符串長度的時間由O(N)降低到了O(1),同時可以避免緩沖區(qū)溢出和減少修改字符串長度時所需的內存重分配次數。
- 鏈表linkedlist:redis鏈表是一個雙向無環(huán)鏈表結構,很多發(fā)布訂閱、慢查詢、監(jiān)視器功能都是使用到了鏈表來實現,每個鏈表的節(jié)點由一個listNode結構來表示,每個節(jié)點都有指向前置節(jié)點和后置節(jié)點的指針,同時表頭節(jié)點的前置和后置節(jié)點都指向NULL。
- 字典hashtable:用于保存鍵值對的抽象數據結構。redis使用hash表作為底層實現,每個字典帶有兩個hash表,供平時使用和rehash時使用,hash表使用鏈地址法來解決鍵沖突,被分配到同一個索引位置的多個鍵值對會形成一個單向鏈表,在對hash表進行擴容或者縮容的時候,為了服務的可用性,rehash的過程不是一次性完成的,而是漸進式的。
- 跳躍表skiplist:跳躍表是有序集合的底層實現之一,redis中在實現有序集合鍵和集群節(jié)點的內部結構中都是用到了跳躍表。redis跳躍表由zskiplist和zskiplistNode組成,zskiplist用于保存跳躍表信息(表頭、表尾節(jié)點、長度等),zskiplistNode用于表示表跳躍節(jié)點,每個跳躍表的層高都是1-32的隨機數,在同一個跳躍表中,多個節(jié)點可以包含相同的分值,但是每個節(jié)點的成員對象必須是唯一的,節(jié)點按照分值大小排序,如果分值相同,則按照成員對象的大小排序。
- 整數集合intset:用于保存整數值的集合抽象數據結構,不會出現重復元素,底層實現為數組。
- 壓縮列表ziplist:壓縮列表是為節(jié)約內存而開發(fā)的順序性數據結構,他可以包含多個節(jié)點,每個節(jié)點可以保存一個字節(jié)數組或者整數值。
基于這些基礎的數據結構,redis 封裝了自己的對象系統(tǒng),包含字符串對象string、列表對象list、哈希對象hash、集合對象set、有序集合對象zset,每種對象都用到了至少一種基礎的數據結構。
redis 通過encoding屬性設置對象的編碼形式來提升靈活性和效率,基于不同的場景redis會自動做出優(yōu)化。不同對象的編碼如下:
- 字符串對象string:int整數、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 的幾十倍。速度快的原因主要有幾點:
- 完全基于內存操作
- C語言實現,優(yōu)化過的數據結構,基于幾種基礎的數據結構,redis做了大量的優(yōu)化,性能極高
- 使用單線程,無上下文的切換成本
- 基于非阻塞的IO多路復用機制
那為什么Redis6.0之后又改用多線程呢?
redis 使用多線程并非是完全摒棄單線程,redis 還是使用單線程模型來處理客戶端的請求,只是使用多線程來處理數據的讀寫和協(xié)議解析,執(zhí)行命令還是使用單線程。
這樣做的目的是因為 redis 的性能瓶頸在于網絡IO而非CPU,使用多線程能提升IO讀寫的效率,從而整體提高 redis 的性能。
知道什么是熱key嗎?熱key問題怎么解決?
所謂熱key問題就是,突然有幾十萬的請求去訪問 redis 上的某個特定key,那么這樣會造成流量過于集中,達到物理網卡上限,從而導致這臺redis的服務器宕機引發(fā)雪崩。
針對熱key的解決方案:
- 提前把熱key打散到不同的服務器,降低壓力
- 加入二級緩存,提前加載熱key數據到內存中,如果 redis 宕機,走內存查詢
什么是緩存擊穿、緩存穿透、緩存雪崩?
緩存擊穿
緩存擊穿的概念就是單個key并發(fā)訪問過高,過期時導致所有請求直接打到db上,這個和熱key的問題比較類似,只是說的點在于過期導致請求全部打到DB上而已。
解決方案:
- 加鎖更新,比如請求查詢A,發(fā)現緩存中沒有,對A這個key加鎖,同時去數據庫查詢數據,寫入緩存,再返回給用戶,這樣后面的請求就可以從緩存中拿到數據了。
- 將過期時間組合寫在value中,通過異步的方式不斷的刷新過期時間,防止此類現象。
緩存穿透
緩存穿透是指查詢不存在緩存中的數據,每次請求都會打到DB,就像緩存不存在一樣。
針對這個問題,加一層布隆過濾器。布隆過濾器的原理是在你存入數據的時候,會通過散列函數將它映射為一個位數組中的K個點,同時把他們置為1。
這樣當用戶再次來查詢A,而A在布隆過濾器值為0,直接返回,就不會產生擊穿請求打到DB了。
顯然,使用布隆過濾器之后會有一個問題就是誤判,因為它本身是一個數組,可能會有多個值落到同一個位置,那么理論上來說只要我們的數組長度夠長,誤判的概率就會越低,這種問題就根據實際情況來就好了。
緩存雪崩
當某一時刻發(fā)生大規(guī)模的緩存失效的情況,比如你的緩存服務宕機了,會有大量的請求進來直接打到DB上,這樣可能導致整個系統(tǒng)的崩潰,稱為雪崩。雪崩和擊穿、熱key的問題不太一樣的是,他是指大規(guī)模的緩存都過期失效了。
針對雪崩幾個解決方案:
- 針對不同key設置不同的過期時間,避免同時過期
- 限流,如果redis宕機,可以限流,避免同時刻大量請求打崩DB
- 二級緩存,同熱key的方案。
Redis的過期策略有哪些?
redis主要有2種過期刪除策略
惰性刪除
惰性刪除指的是當我們查詢key的時候才對key進行檢測,如果已經達到過期時間,則刪除。顯然,他有一個缺點就是如果這些過期的key沒有被訪問,那么他就一直無法被刪除,而且一直占用內存。
定期刪除
定期刪除指的是redis每隔一段時間對數據庫做一次檢查,刪除里面的過期key。由于不可能對所有key去做輪詢來刪除,所以redis會每次隨機取一些key去做檢查和刪除。
那么定期+惰性都沒有刪除過期的key怎么辦?
假設redis每次定期隨機查詢key的時候沒有刪掉,這些key也沒有做查詢的話,就會導致這些key一直保存在redis里面無法被刪除,這時候就會走到redis的內存淘汰機制。
- volatile-lru:從已設置過期時間的key中,移出最近最少使用的key進行淘汰
- volatile-ttl:從已設置過期時間的key中,移出將要過期的key
- volatile-random:從已設置過期時間的key中隨機選擇key淘汰
- allkeys-lru:從key中選擇最近最少使用的進行淘汰
- allkeys-random:從key中隨機選擇key進行淘汰
- noeviction:當內存達到閾值的時候,新寫入操作報錯
持久化方式有哪些?有什么區(qū)別?
redis持久化方案分為RDB和AOF兩種。
RDB
RDB持久化可以手動執(zhí)行也可以根據配置定期執(zhí)行,它的作用是將某個時間點上的數據庫狀態(tài)保存到RDB文件中,RDB文件是一個壓縮的二進制文件,通過它可以還原某個時刻數據庫的狀態(tài)。由于RDB文件是保存在硬盤上的,所以即使redis崩潰或者退出,只要RDB文件存在,就可以用它來恢復還原數據庫的狀態(tài)。
可以通過SAVE或者BGSAVE來生成RDB文件。
SAVE命令會阻塞redis進程,直到RDB文件生成完畢,在進程阻塞期間,redis不能處理任何命令請求,這顯然是不合適的。
BGSAVE則是會fork出一個子進程,然后由子進程去負責生成RDB文件,父進程還可以繼續(xù)處理命令請求,不會阻塞進程。
AOF
AOF和RDB不同,AOF是通過保存redis服務器所執(zhí)行的寫命令來記錄數據庫狀態(tài)的。
AOF通過追加、寫入、同步三個步驟來實現持久化機制。
- 當AOF持久化處于激活狀態(tài),服務器執(zhí)行完寫命令之后,寫命令將會被追加append到aof_buf緩沖區(qū)的末尾
- 在服務器每結束一個事件循環(huán)之前,將會調用flushAppendOnlyFile函數決定是否要將aof_buf的內容保存到AOF文件中,可以通過配置appendfsync來決定。
always ##aof_buf內容寫入并同步到AOF文件
everysec ##將aof_buf中內容寫入到AOF文件,如果上次同步AOF文件時間距離現在超過1秒,則再次對AOF文件進行同步
no ##將aof_buf內容寫入AOF文件,但是并不對AOF文件進行同步,同步時間由操作系統(tǒng)決定
如果不設置,默認選項將會是everysec,因為always來說雖然最安全(只會丟失一次事件循環(huán)的寫命令),但是性能較差,而everysec模式只不過會可能丟失1秒鐘的數據,而no模式的效率和everysec相仿,但是會丟失上次同步AOF文件之后的所有寫命令數據。
怎么實現Redis的高可用?
要想實現高可用,一臺機器肯定是不夠的,而redis要保證高可用,有2個可選方案。
主從架構
主從模式是最簡單的實現高可用的方案,核心就是主從同步。主從同步的原理如下:
- slave發(fā)送sync命令到master
- master收到sync之后,執(zhí)行bgsave,生成RDB全量文件
- master把slave的寫命令記錄到緩存
- bgsave執(zhí)行完畢之后,發(fā)送RDB文件到slave,slave執(zhí)行
- master發(fā)送緩存中的寫命令到slave,slave執(zhí)行
這里我寫的這個命令是sync,但是在redis2.8版本之后已經使用psync來替代sync了,原因是sync命令非常消耗系統(tǒng)資源,而psync的效率更高。
哨兵
基于主從方案的缺點還是很明顯的,假設master宕機,那么就不能寫入數據,那么slave也就失去了作用,整個架構就不可用了,除非你手動切換,主要原因就是因為沒有自動故障轉移機制。而哨兵(sentinel)的功能比單純的主從架構全面的多了,它具備自動故障轉移、集群監(jiān)控、消息通知等功能。
哨兵可以同時監(jiān)視多個主從服務器,并且在被監(jiān)視的master下線時,自動將某個slave提升為master,然后由新的master繼續(xù)接收命令。整個過程如下:
- 初始化sentinel,將普通的redis代碼替換成sentinel專用代碼
- 初始化masters字典和服務器信息,服務器信息主要保存ip:port,并記錄實例的地址和ID
- 創(chuàng)建和master的兩個連接,命令連接和訂閱連接,并且訂閱sentinel:hello頻道
- 每隔10秒向master發(fā)送info命令,獲取master和它下面所有slave的當前信息
- 當發(fā)現master有新的slave之后,sentinel和新的slave同樣建立兩個連接,同時每個10秒發(fā)送info命令,更新master信息
- sentinel每隔1秒向所有服務器發(fā)送ping命令,如果某臺服務器在配置的響應時間內連續(xù)返回無效回復,將會被標記為下線狀態(tài)
- 選舉出領頭sentinel,領頭sentinel需要半數以上的sentinel同意
- 領頭sentinel從已下線的的master所有slave中挑選一個,將其轉換為master
- 讓所有的slave改為從新的master復制數據
- 將原來的master設置為新的master的從服務器,當原來master重新回復連接時,就變成了新master的從服務器
sentinel會每隔1秒向所有實例(包括主從服務器和其他sentinel)發(fā)送ping命令,并且根據回復判斷是否已經下線,這種方式叫做主觀下線。當判斷為主觀下線時,就會向其他監(jiān)視的sentinel詢問,如果超過半數的投票認為已經是下線狀態(tài),則會標記為客觀下線狀態(tài),同時觸發(fā)故障轉移。
能說說redis集群的原理嗎?
如果說依靠哨兵可以實現redis的高可用,如果還想在支持高并發(fā)同時容納海量的數據,那就需要redis集群。redis集群是redis提供的分布式數據存儲方案,集群通過數據分片sharding來進行數據的共享,同時提供復制和故障轉移的功能。
節(jié)點
一個redis集群由多個節(jié)點node組成,而多個node之間通過cluster meet命令來進行連接,節(jié)點的握手過程:
- 節(jié)點A收到客戶端的cluster meet命令
- A根據收到的IP地址和端口號,向B發(fā)送一條meet消息
- 節(jié)點B收到meet消息返回pong
- A知道B收到了meet消息,返回一條ping消息,握手成功
- 最后,節(jié)點A將會通過gossip協(xié)議把節(jié)點B的信息傳播給集群中的其他節(jié)點,其他節(jié)點也將和B進行握手
槽slot
redis通過集群分片的形式來保存數據,整個集群數據庫被分為16384個slot,集群中的每個節(jié)點可以處理0-16384個slot,當數據庫16384個slot都有節(jié)點在處理時,集群處于上線狀態(tài),反之只要有一個slot沒有得到處理都會處理下線狀態(tài)。通過cluster addslots命令可以將slot指派給對應節(jié)點處理。
slot是一個位數組,數組的長度是16384/8=2048,而數組的每一位用1表示被節(jié)點處理,0表示不處理,如圖所示的話表示A節(jié)點處理0-7的slot。
當客戶端向節(jié)點發(fā)送命令,如果剛好找到slot屬于當前節(jié)點,那么節(jié)點就執(zhí)行命令,反之,則會返回一個MOVED命令到客戶端指引客戶端轉向正確的節(jié)點。(MOVED過程是自動的)
如果增加或者移出節(jié)點,對于slot的重新分配也是非常方便的,redis提供了工具幫助實現slot的遷移,整個過程是完全在線的,不需要停止服務。
故障轉移
如果節(jié)點A向節(jié)點B發(fā)送ping消息,節(jié)點B沒有在規(guī)定的時間內響應pong,那么節(jié)點A會標記節(jié)點B為pfail疑似下線狀態(tài),同時把B的狀態(tài)通過消息的形式發(fā)送給其他節(jié)點,如果超過半數以上的節(jié)點都標記B為pfail狀態(tài),B就會被標記為fail下線狀態(tài),此時將會發(fā)生故障轉移,優(yōu)先從復制數據較多的從節(jié)點選擇一個成為主節(jié)點,并且接管下線節(jié)點的slot,整個過程和哨兵非常類似,都是基于Raft協(xié)議做選舉。
了解Redis事務機制嗎?
redis 通過MULTI、EXEC、WATCH等命令來實現事務機制,事務執(zhí)行過程將一系列多個命令按照順序一次性執(zhí)行,并且在執(zhí)行期間,事務不會被中斷,也不會去執(zhí)行客戶端的其他請求,直到所有命令執(zhí)行完畢。事務的執(zhí)行過程如下:
- 服務端收到客戶端請求,事務以MULTI開始
- 如果客戶端正處于事務狀態(tài),則會把事務放入隊列同時返回給客戶端QUEUED,反之則直接執(zhí)行這個命令
- 當收到客戶端EXEC命令時,WATCH命令監(jiān)視整個事務中的key是否有被修改,如果有則返回空回復到客戶端表示失敗,否則redis會遍歷整個事務隊列,執(zhí)行隊列中保存的所有命令,最后返回結果給客戶端
WATCH的機制本身是一個CAS的機制,被監(jiān)視的key會被保存到一個鏈表中,如果某個key被修改,那么REDIS_DIRTY_CAS標志將會被打開,這時服務器會拒絕執(zhí)行事務。
文章來源于公眾號:科技繆繆 ,作者科技繆繆
以上就是W3Cschool編程獅
關于面試官最愛問的 11道 Redis 面試題,我替你整理好了的相關介紹了,希望對大家有所幫助。