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/
Redis支持的數據類型？
- String字符串：
格式: set key value
string類型是二進制安全的。意思是redis的string可以包含任何數據。比如jpg圖片或者序列化的對象 。
string類型是Redis最基本的數據類型，一個鍵最大能存儲512MB。
Hash（哈希）
格式: hmset name key1 value1 key2 value2
Redis hash 是一個鍵值(key=>value)對集合。
Redis hash是一個string類型的field和value的映射表，hash特別適合用於存儲對象。
- List（列表）
Redis 列表是簡單的字符串列表，按照插入順序排序。你可以添加一個元素到列表的頭部（左邊）或者尾部（右邊）
格式: lpush name value
在 key 對應 list 的頭部添加字符串元素
格式: rpush name value
在 key 對應 list 的尾部添加字符串元素
格式: lrem name index
key 對應 list 中刪除 count 個和 value 相同的元素
格式: llen name
返回 key 對應 list 的長度
- Set（集合）
格式: sadd name value
Redis的Set是string類型的無序集合。
集合是通過哈希表實現的，所以添加，刪除，查找的複雜度都是O(1)。
- zset(sorted set：有序集合)
格式: zadd name score value
Redis zset 和 set 一樣也是string類型元素的集合,且不允許重複的成員。
不同的是每個元素都會關聯一個double類型的分數。redis正是通過分數來爲集合中的成員進行從小到大的排序。
zset的成員是唯一的,但分數(score)卻可以重複。
什麼是Redis持久化？Redis有哪幾種持久化方式？優缺點是什麼？
持久化就是把內存的數據寫到磁盤中去，防止服務宕機了內存數據丟失。
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 )格式的命令文本存儲。
比較：
- aof文件比rdb更新頻率高，優先使用aof還原數據。
- aof比rdb更安全也更大
- rdb性能比aof好
- 如果兩個都配了優先加載AOF
剛剛上面你有提到redis通訊協議(RESP )，能解釋下什麼是RESP？有什麼特點？
（可以看到很多面試其實都是連環炮，面試官其實在等着你回答到這個點，如果你答上了對你的評價就又加了一分）
RESP 是redis客戶端和服務端之前使用的一種通訊協議；
RESP 的特點：
實現簡單、快速解析、可讀性好
- For Simple Strings the first byte of the reply is "+" 回覆
- For Errors the first byte of the reply is "-" 錯誤
- For Integers the first byte of the reply is ":" 整數
- For Bulk Strings the first byte of the reply is "$" 字符串
- For Arrays the first byte of the reply is "*" 數組
Redis 有哪些架構模式？講講各自的特點
單機版
特點：簡單
問題：
1、內存容量有限 2、處理能力有限 3、無法高可用。
主從複製
Redis 的複製（replication）功能允許用戶根據一個 Redis 服務器來創建任意多個該服務器的複製品，其中被複制的服務器爲主服務器（master），而通過複製創建出來的服務器複製品則爲從服務器（slave）。 只要主從服務器之間的網絡連接正常，主從服務器兩者會具有相同的數據，主服務器就會一直將發生在自己身上的數據更新同步 給從服務器，從而一直保證主從服務器的數據相同。
特點：
- master/slave 角色
- master/slave 數據相同
- 降低 master 讀壓力在轉交從庫
問題：
- 無法保證高可用
- 沒有解決 master 寫的壓力
哨兵
Redis sentinel 是一個分佈式系統中監控 redis 主從服務器，並在主服務器下線時自動進行故障轉移。其中三個特性：
監控（Monitoring）： Sentinel 會不斷地檢查你的主服務器和從服務器是否運作正常。
提醒（Notification）： 當被監控的某個 Redis 服務器出現問題時， Sentinel 可以通過 API 向管理員或者其他應用程序發送通知。
自動故障遷移（Automatic failover）： 當一個主服務器不能正常工作時， Sentinel 會開始一次自動故障遷移操作。
特點：
- 保證高可用
- 監控各個節點
- 自動故障遷移
缺點：主從模式，切換需要時間丟數據
沒有解決 master 寫的壓力
集羣（proxy 型）：
Twemproxy 是一個 Twitter 開源的一個 redis 和 memcache 快速/輕量級代理服務器； Twemproxy 是一個快速的單線程代理程序，支持 Memcached ASCII 協議和 redis 協議。
特點：
- 多種 hash 算法：MD5、CRC16、CRC32、CRC32a、hsieh、murmur、Jenkins
- 支持失敗節點自動刪除
- 後端 Sharding 分片邏輯對業務透明，業務方的讀寫方式和操作單個 Redis 一致
缺點：
- 增加了新的 proxy，需要維護其高可用。
- failover 邏輯需要自己實現，其本身不能支持故障的自動轉移可擴展性差，進行擴縮容都需要手動干預
集羣（直連型）：
從redis 3.0之後版本支持redis-cluster集羣，Redis-Cluster採用無中心結構，每個節點保存數據和整個集羣狀態,每個節點都和其他所有節點連接。
特點：
- 無中心架構（不存在哪個節點影響性能瓶頸），少了 proxy 層。
- 數據按照 slot 存儲分佈在多個節點，節點間數據共享，可動態調整數據分佈。
- 可擴展性，可線性擴展到 1000 個節點，節點可動態添加或刪除。
- 高可用性，部分節點不可用時，集羣仍可用。通過增加 Slave 做備份數據副本
- 實現故障自動 failover，節點之間通過 gossip 協議交換狀態信息，用投票機制完成 Slave到 Master的角色提升。
缺點：
- 資源隔離性較差，容易出現相互影響的情況。
- 數據通過異步複製,不保證數據的強一致性
什麼是一致性哈希算法？什麼是哈希槽？
這兩個問題篇幅過長 網上找了兩個解鎖的不錯的文章
https://www.cnblogs.com/lpfut...
https://blog.csdn.net/z157326...
Redis是基於CAP理論的，什麼是CAP理論？
可以參考我的上一篇文章。
Redis常用命令？
- Keys pattern
表示區配所有
以bit開頭的
查看Exists key是否存在
- Set
設置 key 對應的值爲 string 類型的 value。
- setnx
設置 key 對應的值爲 string 類型的 value。如果 key 已經存在，返回 0，nx 是 not exist 的意思。
刪除某個key
第一次返回1 刪除了 第二次返回0
- Expire
設置過期時間（單位秒）
- TTL
查看剩下多少時間
- Setex
設置 key 對應的值爲 string 類型的 value，並指定此鍵值對應的有效期。
- Mset
一次設置多個 key 的值，成功返回 ok 表示所有的值都設置了，失敗返回 0 表示沒有任何值被設置。
- Getset
設置 key 的值，並返回 key 的舊值。
- Mget
一次獲取多個 key 的值，如果對應 key 不存在，則對應返回 nil。
- Incr
對 key 的值做加加操作,並返回新的值。注意 incr 一個不是 int 的 value 會返回錯誤，incr 一個不存在的 key，則設置 key 爲 1
- incrby
同 incr 類似，加指定值 ，key 不存在時候會設置 key，並認爲原來的 value 是 0
- Decr
對 key 的值做的是減減操作，decr 一個不存在 key，則設置 key 爲-1
- Decrby
同 decr，減指定值。
- Append
給指定 key 的字符串值追加 value,返回新字符串值的長度。
- Strlen
取指定 key 的 value 值的長度。
- persist
取消過期時間
- Select
選擇數據庫
- Randomkey
隨機返回一個key
- Rename
重命名
- Type
返回數據類型
使用過Redis分佈式鎖麼，它是怎麼實現的？
先拿setnx來爭搶鎖，搶到之後，再用expire給鎖加一個過期時間防止鎖忘記了釋放。
如果在setnx之後執行expire之前進程意外crash或者要重啓維護了，那會怎麼樣？
set指令有非常複雜的參數，這個應該是可以同時把setnx和expire合成一條指令來用的！
使用過Redis做異步隊列麼，你是怎麼用的？有什麼缺點？
一般使用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，設置不同的過期時間，讓緩存失效的時間點儘量均勻
內容比較多整理一個腦圖，方便大家記憶。
最近，我組建了個羣聊。學習Java進階技術乾貨、實踐分享，職位內推，一起聊聊理想。志同道合的朋友，歡迎你的加入。
好了，祝大家面試順利！
