Redis是一個很是火的非關係型數據庫,火到什麼程度呢?只要是一個互聯網公司都會使用到。Redis相關的問題能夠說是面試必問的,下面我從我的當面試官的經驗,總結幾個必需要掌握的知識點。
介紹:Redis 是一個開源的使用 ANSI C 語言編寫、遵照 BSD 協議、支持網絡、可基於內存亦可持久化的日誌型、Key-Value 數據庫,並提供多種語言的 API的非關係型數據庫。
傳統數據庫遵循 ACID 規則。而 Nosql(Not Only SQL 的縮寫,是對不一樣於傳統的關係型數據庫的數據庫管理系統的統稱) 通常爲分佈式而分佈式通常遵循 CAP 定理。
Github 源碼:https://github.com/antirez/redis
Redis 官網:https://redis.io/html
持久化就是把內存的數據寫到磁盤中去,防止服務宕機了內存數據丟失。
Redis 提供了兩種持久化方式:RDB(默認) 和AOF
RDB:
rdb是Redis DataBase縮寫
功能核心函數rdbSave(生成RDB文件)和rdbLoad(從文件加載內存)兩個函數
AOF:
Aof是Append-only file縮寫
每當執行服務器(定時)任務或者函數時flushAppendOnlyFile 函數都會被調用, 這個函數執行如下兩個工做
aof寫入保存:
WRITE:根據條件,將 aof_buf 中的緩存寫入到 AOF 文件
SAVE:根據條件,調用 fsync 或 fdatasync 函數,將 AOF 文件保存到磁盤中。
存儲結構:
內容是redis通信協議(RESP )格式的命令文本存儲。
比較:git
(能夠看到不少面試其實都是連環炮,面試官其實在等着你回答到這個點,若是你答上了對你的評價就又加了一分)
RESP 是redis客戶端和服務端以前使用的一種通信協議;
RESP 的特色:
實現簡單、快速解析、可讀性好github
單機版
特色:簡單
問題:
一、內存容量有限 二、處理能力有限 三、沒法高可用。面試
主從複製
Redis 的複製(replication)功能容許用戶根據一個 Redis 服務器來建立任意多個該服務器的複製品,其中被複制的服務器爲主服務器(master),而經過複製建立出來的服務器複製品則爲從服務器(slave)。 只要主從服務器之間的網絡鏈接正常,主從服務器二者會具備相同的數據,主服務器就會一直將發生在本身身上的數據更新同步 給從服務器,從而一直保證主從服務器的數據相同。
特色:redis
問題:算法
哨兵
Redis sentinel 是一個分佈式系統中監控 redis 主從服務器,並在主服務器下線時自動進行故障轉移。其中三個特性:sql
監控(Monitoring): Sentinel 會不斷地檢查你的主服務器和從服務器是否運做正常。數據庫
提醒(Notification): 當被監控的某個 Redis 服務器出現問題時, Sentinel 能夠經過 API 向管理員或者其餘應用程序發送通知。後端
自動故障遷移(Automatic failover): 當一個主服務器不能正常工做時, Sentinel 會開始一次自動故障遷移操做。數組
特色:
缺點:主從模式,切換須要時間丟數據
沒有解決 master 寫的壓力
集羣(proxy 型):
Twemproxy 是一個 Twitter 開源的一個 redis 和 memcache 快速/輕量級代理服務器; Twemproxy 是一個快速的單線程代理程序,支持 Memcached ASCII 協議和 redis 協議。
特色:
缺點:
集羣(直連型):
從redis 3.0以後版本支持redis-cluster集羣,Redis-Cluster採用無中心結構,每一個節點保存數據和整個集羣狀態,每一個節點都和其餘全部節點鏈接。
特色:
缺點:
這兩個問題篇幅過長 網上找了兩個解鎖的不錯的文章
https://blog.csdn.net/z15732621582/article/details/79121213
能夠參考個人上一篇文章。
先拿setnx來爭搶鎖,搶到以後,再用expire給鎖加一個過時時間防止鎖忘記了釋放。
若是在setnx以後執行expire以前進程意外crash或者要重啓維護了,那會怎麼樣?
set指令有很是複雜的參數,這個應該是能夠同時把setnx和expire合成一條指令來用的!
通常使用list結構做爲隊列,rpush生產消息,lpop消費消息。當lpop沒有消息的時候,要適當sleep一會再重試。
缺點:
在消費者下線的狀況下,生產的消息會丟失,得使用專業的消息隊列如rabbitmq等。
能不能生產一次消費屢次呢?
使用pub/sub主題訂閱者模式,能夠實現1:N的消息隊列。
緩存穿透
通常的緩存系統,都是按照key去緩存查詢,若是不存在對應的value,就應該去後端系統查找(好比DB)。一些惡意的請求會故意查詢不存在的key,請求量很大,就會對後端系統形成很大的壓力。這就叫作緩存穿透。
如何避免?
1:對查詢結果爲空的狀況也進行緩存,緩存時間設置短一點,或者該key對應的數據insert了以後清理緩存。
2:對必定不存在的key進行過濾。能夠把全部的可能存在的key放到一個大的Bitmap中,查詢時經過該bitmap過濾。
緩存雪崩
當緩存服務器重啓或者大量緩存集中在某一個時間段失效,這樣在失效的時候,會給後端系統帶來很大壓力。致使系統崩潰。
如何避免?
1:在緩存失效後,經過加鎖或者隊列來控制讀數據庫寫緩存的線程數量。好比對某個key只容許一個線程查詢數據和寫緩存,其餘線程等待。
2:作二級緩存,A1爲原始緩存,A2爲拷貝緩存,A1失效時,能夠訪問A2,A1緩存失效時間設置爲短時間,A2設置爲長期
3:不一樣的key,設置不一樣的過時時間,讓緩存失效的時間點儘可能均勻
好了,祝你們面試順利!拿出手機掃一掃關注~不按期送書