Redis面試常問總結

我是方圓
Redis基於內存，你我基於什麼呢？

1. Memcache和Redis

• Memcache
  支持簡單的數據類型
  不支持數據持久化
  不支持主從
  不支持分片
• Redis
  數據類型豐富
  支持數據磁盤持久化
  支持主從
  支持分片

2. Redis爲什麼這麼快？

• 完全基於內存，請求是基於內存的操作，執行效率高
• 數據結構簡單，對數據操作也簡單
• 採用單線程，單線程也能處理高併發請求
• 使用多路I/O複用模型，非阻塞IO

3. 使用KEYS命令對線上業務的影響

• KEYS pattern 查早所有符合所有pattern的key
  KEYS指令會一次性返回所有匹配的key，鍵的數量過大會使服務器卡頓
• 解決方法 使用 SCAN cursor [MATCH pattern] [COUNT count]
  基於遊標的迭代器，需要基於上一次的遊標延續之前的迭代過程，以0作爲遊標開始新一次的迭代，直到命令返回遊標0完成一次遍歷，不保證每次執行都返回給定數量的元素（只是大概率符合count參數），支持模糊查詢。

4. 如何實現分佈式鎖

1. 使用SETNX key value和EXPIRE key seconds組合
   
   但是，單條命令是原子性的，兩條命令若結合在一起，便不具備原子性，如若在執行完SETNX後，出現宕機，那麼key則成了永久的key，使得其他線程無法對其進行操作
2. 使用SET key value [EX seconds] [PX milliseconds] [NX|XX]
   這一條命令便結合了上方兩條命令，EX是秒，PX是毫秒，NX爲鍵不存在時進行操作，XX只有鍵存在時，才進行操作

5. 大量key同時過期的注意事項

• 集中過期，由於要清理大量的key很耗時，會出現短暫的卡頓現象
• 解決方法：在設置key的時候，給每個key加上隨機的過期時間

6. 如何使用Redis做異步隊列

1. 使用List作爲消息隊列，RPUSH生產消息，LPOP消費消息
缺點：沒有等待機制，隊列裏沒有消息也進行消費
   彌補：可以在應用層引入sleep機制來調用LPOP
2. 對1.的完善，BLPOP key[key...] timeout ：阻塞直到有消息或者等待固定的時間
   缺點：只能供一個消費者進行消費
3. 對2.的完善，使用pub/sub
   
   通過subscribe可以訂閱消息，通過publish來發布消息給訂閱的人
   缺點：消息是無狀態的，無法保證消息一定可達

7. RDB持久化和AOF持久化

7.1 RDB(保存的是某一時間點的全量數據快照)

• SAVE:阻塞Redis的服務進程，直到RDB文件被創建完畢
• BGSAVE:Fork出一個子進程來創建RDB文件，不阻塞服務器進程

7.1.1 自動觸發RDB持久化的方式

1. 根據Rdis配置文件redis.conf中的SAVE m n配置，定時觸發（BGSAVE)
2. 主從複製時，主節點自己插法
3. 執行DeBug Reload
4. 執行ShutDown但沒有開啓AOF時觸發

7.1.2 BGSAVE原理圖

缺點：內存數據全量同步，數據很大由於I/O而嚴重影響性能；可能會因爲服務器宕機而丟失數據

7.1.3 RDB優缺點

7.2 AOF

7.2.1 AOF實現過程

7.2.2 AOF文件生成條件

7.2.3 AOF優缺點

7.3 RDB和AOF共存時，數據恢復過程