Redis面試題X50，全網最全（上）

文章目錄

1、什麼是 Redis?

Redis 是完全開源免費的，遵守 BSD 協議，是一個高性能的 key-value 數據庫。
Redis 與其他 key - value 緩存產品有以下三個特點：
Redis 支持數據的持久化，可以將內存中的數據保存在磁盤中，重啓的時候可以再次加載進行使用。
Redis 不僅僅支持簡單的 key-value 類型的數據，同時還提供 list，set，zset，hash 等數據結構的存儲。
Redis 支持數據的備份，即 master-slave 模式的數據備份。
Redis 優勢
性能極高 – Redis 能讀的速度是 110000 次/s,寫的速度是 81000 次/s 。豐富的數據類型 – Redis 支持二進制案例的 Strings, Lists, Hashes,
Sets 及Ordered Sets 數據類型操作。
原子 – Redis 的所有操作都是原子性的，意思就是要麼成功執行要麼失敗完全不執行。單個操作是原子性的。多個操作也支持事務，即原子性，通過 MULTI 和 EXEC指令包起來。
豐富的特性 – Redis 還支持 publish/subscribe, 通知, key 過期等等特性。

2、Redis 與其他 key-value 存儲有什麼不同？

Redis 有着更爲複雜的數據結構並且提供對他們的原子性操作，這是一個不同於其他數據庫的進化路徑。Redis 的數據類型都是基於基本數據結構的同時對程序員透明，無需進行額外的抽象。Redis 運行在內存中但是可以持久化到磁盤，所以在對不同數據集進行高速讀寫時需要權衡內存，因爲數據量不能大於硬件內存。在內存數據庫方面的另一個優點是，相比在磁盤上相同的複雜的數據結構，在內存中操作起來非常簡單，這樣 Redis可以做很多內部複雜性很強的事情。同時，在磁盤格式方面他們是緊湊的以追加的方式產生的，因爲他們並不需要進行隨機訪問。

3、Redis 的數據類型？

Redis 支持五種數據類型：string（字符串），hash（哈希），list（列表），set（集合）及 zsetsorted set：有序集合)。
我們實際項目中比較常用的是 string，hash 如果你是 Redis 中高級用戶，還需要加上下面幾種數據結構 HyperLogLog、Geo、Pub/Sub。如果你說還玩過 Redis Module，像 BloomFilter，RedisSearch，Redis-ML，面試官得眼睛就開始發亮了。

4、使用 Redis 有哪些好處？

速度快，因爲數據存在內存中，類似於 HashMap，HashMap 的優勢就是查找和操作的時間複雜度都是 O1)
支持豐富數據類型，支持 string，list，set，Zset，hash 等
支持事務，操作都是原子性，所謂的原子性就是對數據的更改要麼全部執行，要麼全部不執行
豐富的特性：可用於緩存，消息，按 key 設置過期時間，過期後將會自動刪除

5、Redis 相比 Memcached 有哪些優勢？

Memcached 所有的值均是簡單的字符串，redis 作爲其替代者，支持更爲豐富的數據類
Redis 的速度比 Memcached 快很
Redis 可以持久化其數據

6、Memcache 與 Redis 的區別都有哪些？

存儲方式 Memecache 把數據全部存在內存之中，斷電後會掛掉，數據不能超過內存大小。 Redis 有部份存在硬盤上，這樣能保證數據的持久性。
數據支持類型 Memcache 對數據類型支持相對簡單。 Redis 有複雜的數據類型。
使用底層模型不同它們之間底層實現方式以及與客戶端之間通信的應用協議不一樣。 Redis 直接自己構建了 VM 機制，因爲一般的系統調用系統函數的話，會浪費一定的時間去移動和請求。

7、Redis 是單進程單線程的？

Redis 是單進程單線程的，redis 利用隊列技術將併發訪問變爲串行訪問，消除了傳統數據庫串行控制的開銷。

8、一個字符串類型的值能存儲最大容量是多少？

512M

9、Redis持久化機制

Redis是一個支持持久化的內存數據庫，通過持久化機制把內存中的數據同步到硬盤文件來保證數據持久化。當Redis重啓後通過把硬盤文件重新加載到內存，就能達到恢復數據的目的。
實現：單獨創建fork()一個子進程，將當前父進程的數據庫數據複製到子進程的內存中，然後由子進程寫入到臨時文件中，持久化的過程結束了，再用這個臨時文件替換上次的快照文件，然後子進程退出，內存釋放。
RDB是Redis默認的持久化方式。按照一定的時間週期策略把內存的數據以快照的形式保存到硬盤的二進制文件。即Snapshot快照存儲，對應產生的數據文件爲dump.rdb，通過配置文件中的save參數來定義快照的週期。（快照可以是其所表示的數據的一個副本，也可以是數據的一個複製品。）
AOF：Redis會將每一個收到的寫命令都通過Write函數追加到文件最後，類似於MySQL的binlog。當Redis重啓是會通過重新執行文件中保存的寫命令來在內存中重建整個數據庫的內容。當兩種方式同時開啓時，數據恢復Redis會優先選擇AOF恢復。

10、緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級等問題

一、緩存雪崩
我們可以簡單的理解爲：由於原有緩存失效，新緩存未到期間(例如：我們設置緩存時採用了相同的過期時間，在同一時刻出現大面積的緩存過期)，所有原本應該訪問緩存的請求都去查詢數據庫了，而對數據庫CPU和內存造成巨大壓力，嚴重的會造成數據庫宕機。從而形成一系列連鎖反應，造成整個系統崩潰。
解決辦法：
大多數系統設計者考慮用加鎖（最多的解決方案）或者隊列的方式保證來保證不會有大量的線程對數據庫一次性進行讀寫，從而避免失效時大量的併發請求落到底層存儲系統上。還有一個簡單方案就時講緩存失效時間分散開。
二、緩存穿透
緩存穿透是指用戶查詢數據，在數據庫沒有，自然在緩存中也不會有。這樣就導致用戶查詢的時候，在緩存中找不到，每次都要去數據庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢）。這樣請求就繞過緩存直接查數據庫，這也是經常提的緩存命中率問題。
解決辦法;
最常見的則是採用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。另外也有一個更爲簡單粗暴的方法，如果一個查詢返回的數據爲空（不管是數據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘。通過這個直接設置的默認值存放到緩存，這樣第二次到緩衝中獲取就有值了，而不會繼續訪問數據庫，這種辦法最簡單粗暴。
5TB的硬盤上放滿了數據，請寫一個算法將這些數據進行排重。如果這些數據是一些32bit大小的數據該如何解決？如果是64bit的呢？
對於空間的利用到達了一種極致，那就是Bitmap和布隆過濾器(Bloom Filter)。
Bitmap：典型的就是哈希表
缺點是，Bitmap對於每個元素只能記錄1bit信息，如果還想完成額外的功能，恐怕只能靠犧牲更多的空間、時間來完成了

布隆過濾器（推薦）
就是引入了k(k>1)k(k>1)個相互獨立的哈希函數，保證在給定的空間、誤判率下，完成元素判重的過程。它的優點是空間效率和查詢時間都遠遠超過一般的算法，缺點是有一定的誤識別率和刪除困難。
Bloom-Filter算法的核心思想就是利用多個不同的Hash函數來解決“衝突”。
Hash存在一個衝突（碰撞）的問題，用同一個Hash得到的兩個URL的值有可能相同。爲了減少衝突，我們可以多引入幾個Hash，如果通過其中的一個Hash值我們得出某元素不在集合中，那麼該元素肯定不在集合中。只有在所有的Hash函數告訴我們該元素在集合中時，才能確定該元素存在於集合中。這便是Bloom-Filter的基本思想。
Bloom-Filter一般用於在大數據量的集合中判定某元素是否存在。
三、緩存預熱
緩存預熱這個應該是一個比較常見的概念，相信很多小夥伴都應該可以很容易的理解，緩存預熱就是系統上線後，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據庫，然後再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！
解決思路：
1、直接寫個緩存刷新頁面，上線時手工操作下；
2、數據量不大，可以在項目啓動的時候自動進行加載；
3、定時刷新緩存
四、緩存更新
除了緩存服務器自帶的緩存失效策略之外（Redis默認的有6中策略可供選擇），我們還可以根據具體的業務需求進行自定義的緩存淘汰，常見的策略有兩種：
（1）定時去清理過期的緩存；
（2）當有用戶請求過來時，再判斷這個請求所用到的緩存是否過期，過期的話就去底層系統得到新數據並更新緩存。
兩者各有優劣，第一種的缺點是維護大量緩存的key是比較麻煩的，第二種的缺點就是每次用戶請求過來都要判斷緩存失效，邏輯相對比較複雜！具體用哪種方案，大家可以根據自己的應用場景來權衡
五、緩存降級
當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵數據進行自動降級，也可以配置開關實現人工降級。
降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。以參考日誌級別設置預案：
（1）一般：比如有些服務偶爾因爲網絡抖動或者服務正在上線而超時，可以自動降級；
（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，併發送告警；
（3）錯誤：比如可用率低於90%，或者數據庫連接池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；
（4）嚴重錯誤：比如因爲特殊原因數據錯誤了，此時需要緊急人工降級。服務降級的目的，是爲了防止Redis服務故障，導致數據庫跟着一起發生雪崩問題。因此，對於不重要的緩存數據，可以採取服務降級策略，例如一個比較常見的做法就是，Redis出現問題，不去數據庫查詢，而是直接返回默認值給用戶

11、熱點數據和冷數據是什麼

熱點數據，緩存才有價值
對於冷數據而言，大部分數據可能還沒有再次訪問到就已經被擠出內存，不僅佔用內存，而且價值不大。頻繁修改的數據，看情況考慮使用緩存
對於上面兩個例子，壽星列表、導航信息都存在一個特點，就是信息修改頻率不高，讀取通常非常高的場景。
對於熱點數據，比如我們的某IM產品，生日祝福模塊，當天的壽星列表，緩存以後可能讀取數十萬次。再舉個例子，某導航產品，我們將導航信息，緩存以後可能讀取數百萬次。
數據更新前至少讀取兩次，緩存纔有意義。這個是最基本的策略，如果緩存還沒有起作用就失效了，那就沒有太大價值了。
那存不存在，修改頻率很高，但是又不得不考慮緩存的場景呢？有！比如，這個讀取接口對數據庫的壓力很大，但是又是熱點數據，這個時候就需要考慮通過緩存手段，減少數據庫的壓力，比如我們的某助手產品的，點贊數，收藏數，分享數等是非常典型的熱點數據，但是又不斷變化，此時就需要將數據同步保存到Redis緩存，減少數據庫壓力

12、單線程的redis爲什麼這麼快

純內存操作
單線程操作，避免了頻繁的上下文切換
採用了非阻塞I/O多路複用機制

13、redis的數據類型，以及每種數據類型的使用場景

一共五種

String
這個其實沒啥好說的，最常規的set/get操作，value可以是String也可以是數字。一般做一些複雜的計數功能的緩存。
hash
這裏value存放的是結構化的對象，比較方便的就是操作其中的某個字段。博主在做單點登錄的時候，就是用這種數據結構存儲用戶信息，以cookieId作爲key，設置30分鐘爲緩存過期時間，能很好的模擬出類似session的效果。
list
使用List的數據結構，可以做簡單的消息隊列的功能。另外還有一個就是，可以利用lrange命令，做基於redis的分頁功能，性能極佳，用戶體驗好。本人還用一個場景，很合適—取行情信息。就也是個生產者和消費者的場景。LIST可以很好的完成排隊，先進先出的原則。
set
因爲set堆放的是一堆不重複值的集合。所以可以做全局去重的功能。爲什麼不用JVM自帶的Set進行去重？因爲我們的系統一般都是集羣部署，使用JVM自帶的Set，比較麻煩，難道爲了一個做一個全局去重，再起一個公共服務，太麻煩了。
另外，就是利用交集、並集、差集等操作，可以計算共同喜好，全部的喜好，自己獨有的喜好等功能。
sorted set
sorted set多了一個權重參數score,集合中的元素能夠按score進行排列。可以做排行榜應用，取TOP N操作

14、redis的過期策略以及內存淘汰機制

redis採用的是定期刪除+惰性刪除策略。
爲什麼不用定時刪除策略?
定時刪除,用一個定時器來負責監視key,過期則自動刪除。雖然內存及時釋放，但是十分消耗CPU資源。在大併發請求下，CPU要將時間應用在處理請求，而不是刪除key,因此沒有采用這一策略.
定期刪除+惰性刪除是如何工作的呢?
定期刪除，redis默認每個100ms檢查，是否有過期的key,有過期key則刪除。需要說明的是，redis不是每個100ms將所有的key檢查一次，而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查，redis豈不是卡死)。因此，如果只採用定期刪除策略，會導致很多key到時間沒有刪除。於是，惰性刪除派上用場。也就是說在你獲取某個key的時候，redis會檢查一下，這個key如果設置了過期時間那麼是否過期了？如果過期了此時就會刪除。
採用定期刪除+惰性刪除就沒其他問題了麼?
不是的，如果定期刪除沒刪除key。然後你也沒即時去請求key，也就是說惰性刪除也沒生效。這樣，redis的內存會越來越高。那麼就應該採用內存淘汰機制。在redis.conf中有一行配置

maxmemory-policy volatile-lru

該配置就是配內存淘汰策略的(什麼，你沒配過？好好反省一下自己)
volatile-lru：從已設置過期時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰
volatile-ttl：從已設置過期時間的數據集（server.db[i].expires）中挑選將要過期的數據淘汰
volatile-random：從已設置過期時間的數據集（server.db[i].expires）中任意選擇數據淘汰
allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰
allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰
no-enviction（驅逐）：禁止驅逐數據，新寫入操作會報錯
ps：如果沒有設置 expire 的key, 不滿足先決條件(prerequisites); 那麼 volatile-lru, volatile-random 和volatile-ttl 策略的行爲, 和
noeviction(不刪除) 基本上一致

15、Redis 常見性能問題和解決方案？

Master 最好不要做任何持久化工作，如 RDB 內存快照和 AOF 日誌文件
如果數據比較重要，某個 Slave 開啓 AOF 備份數據，策略設置爲每秒同步一次
爲了主從複製的速度和連接的穩定性， Master 和 Slave 最好在同一個局域網內
儘量避免在壓力很大的主庫上增加從庫
主從複製不要用圖狀結構，用單向鏈表結構更爲穩定，即： Master <- Slave1 <- Slave2 <-Slave3…

16、爲什麼Redis的操作是原子性的，怎麼保證原子性的？

對於Redis而言，命令的原子性指的是：一個操作的不可以再分，操作要麼執行，要麼不執行。
Redis的操作之所以是原子性的，是因爲Redis是單線程的。
Redis本身提供的所有API都是原子操作，Redis中的事務其實是要保證批量操作的原子性。多個命令在併發中也是原子性的嗎？
不一定，將get和set改成單命令操作，incr 。使用Redis的事務，或者使用Redis+Lua==的方式實現。

17、Redis事務

Redis事務功能是通過MULTI、EXEC、DISCARD和WATCH 四個原語實現的
Redis會將一個事務中的所有命令序列化，然後按順序執行。
1.redis 不支持回滾“Redis 在事務失敗時不進行回滾，而是繼續執行餘下的命令”，所以 Redis 的內部可以保持簡單且快速。
2. 如果在一個事務中的命令出現錯誤，那麼所有的命令都不會執行；
3. 如果在一個事務中出現運行錯誤，那麼正確的命令會被執行。

MULTI命令用於開啓一個事務，它總是返回OK。 MULTI執行之後，客戶端可以繼續向服務器發送任意多條命令，這些命令不會立即被執行，而是被放到一個隊列中，當EXEC命令被調用時，所有隊列中的命令纔會被執行。 - EXEC：執行所有事務塊內的命令。返回事務塊內所有命令的返回值，按命令執行的先後順序排列。當操作被打斷時，返回空值 nil 。
通過調用DISCARD，客戶端可以清空事務隊列，並放棄執行事務，並且客戶端會從事務狀態中退出。
WATCH 命令可以爲 Redis 事務提供 check-and-set （CAS）行爲。可以監控一個或多個鍵，一旦其中有一個鍵被修改（或刪除），之後的事務就不會執行，監控一直持續到EXEC命令

18、Redis 的持久化機制是什麼？各自的優缺點？

Redis 提供兩種持久化機制 RDB 和 AOF 機制:
RDBRedis DataBase)持久化方式：是指用數據集快照的方式半持久化模式)記錄 redis 數據庫的所有鍵值對,在某個時間點將數據寫入一個臨時文件，持久化結束後，用這個臨時文件替換上次持久化的文件，達到數據恢復。

優點：

只有一個文件 dump.rdb，方便持久化。
容災性好，一個文件可以保存到安全的磁盤。
性能最大化，fork 子進程來完成寫操作，讓主進程繼續處理命令，所以是 IO最大化。使用單獨子進程來進行持久化，主進程不會進行任何 IO 操作，保證了 redis的高性能) 4.相對於數據集大時，比 AOF 的啓動效率更高。

缺點：

數據安全性低。RDB 是間隔一段時間進行持久化，如果持久化之間 redis 發生故障，會發生數據丟失。所以這種方式更適合數據要求不嚴謹的時候).

AOFAppend-only ﬁle)持久化方式：是指所有的命令行記錄以 redis 命令請求協議的格式完全持久化存儲)保存爲 aof 文件。

優點：

數據安全，aof 持久化可以配置 appendfsync 屬性，有 always，每進行一次命令操作就記錄到 aof 文件中一次。
通過 append 模式寫文件，即使中途服務器宕機，可以通過 redis-check-aof工具解決數據一致性問題。
AOF 機制的 rewrite 模式。AOF 文件沒被 rewrite 之前（文件過大時會對命令進行合併重寫），可以刪除其中的某些命令（比如誤操作的 ﬂushall）)

缺點：

AOF 文件比 RDB 文件大，且恢復速度慢。
數據集大的時候，比 rdb 啓動效率低。

19、Redis 常見性能問題和解決方案：

Master 最好不要寫內存快照，如果 Master 寫內存快照，save 命令調度 rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務
如果數據比較重要，某個 Slave 開啓 AOF 備份數據，策略設置爲每秒同步一3、爲了主從複製的速度和連接的穩定性，Master 和 Slave
最好在同一個局域網
儘量避免在壓力很大的主庫上增加從
主從複製不要用圖狀結構，用單向鏈表結構更爲穩定，即：Master <- Slave1<- Slave2 <- Slave3…這樣的結構方便解決單點故障問題，實現 Slave 對 Master的替換。如果 Master 掛了，可以立刻啓用 Slave1 做 Master，其他不變。

20、redis 過期鍵的刪除策略？

定時刪除:在設置鍵的過期時間的同時，創建一個定時器 timer). 讓定時器在鍵的過期時間來臨時，立即執行對鍵的刪除操作。
惰性刪除:放任鍵過期不管，但是每次從鍵空間中獲取鍵時，都檢查取得的鍵是否過期，如果過期的話，就刪除該鍵;如果沒有過期，就返回該鍵。
定期刪除:每隔一段時間程序就對數據庫進行一次檢查，刪除裏面的過期鍵。至於要刪除多少過期鍵，以及要檢查多少個數據庫，則由算法決定。

21、Redis 的回收策略（淘汰策略）(重複)?

volatile-lru：從已設置過期時間的數據集（server.db[i].expires）中挑選最近最少使用的數據淘汰
volatile-ttl：從已設置過期時間的數據集（server.db[i].expires）中挑選將要過期的數據淘汰
volatile-random：從已設置過期時間的數據集（server.db[i].expires）中任意選擇數據淘汰
allkeys-lru：從數據集（server.db[i].dict）中挑選最近最少使用的數據淘汰
allkeys-random：從數據集（server.db[i].dict）中任意選擇數據淘汰no-enviction（驅逐）：禁止驅逐數據

注意這裏的 6 種機制，volatile 和 allkeys 規定了是對已設置過期時間的數據集淘汰數據還是從全部數據集淘汰數據，後面的 lru、ttl 以及 random 是三種不同的淘汰策略，再加上一種 no-enviction 永不回收的策略

使用策略規則：

如果數據呈現冪律分佈，也就是一部分數據訪問頻率高，一部分數據訪問頻率低，則使用 allkeys-lru
如果數據呈現平等分佈，也就是所有的數據訪問頻率都相同，則使用allkey

22、爲什麼 edis 需要把所有數據放到內存中？

Redis 爲了達到最快的讀寫速度將數據都讀到內存中，並通過異步的方式將數據寫入磁盤。所以 redis 具有快速和數據持久化的特徵。如果不將數據放在內存中，磁盤 I/O 速度爲嚴重影響 redis 的性能。在內存越來越便宜的今，redis 將會越來越受歡迎。如果設置了最大使用的內存，則數據已有記錄數達到內存限值後不能繼續插入新值。

23、Redis 的同步機制瞭解麼？

Redis 可以使用主從同步，從從同步。第一次同步時，主節點做一次 bgsave，並同時將後續修改操作記錄到內存 buﬀer，待完成後將 rdb 文件全量同步到複製節點，複製節點接受完成後將 rdb 鏡像加載到內存。加載完成後，再通知主節點將期間修改的操作記錄同步到複製節點進行重放就完成了同步過程。

24、Pipeline 有什麼好處，爲什麼要用 pipeline？

可以將多次 IO 往返的時間縮減爲一次，前提是 pipeline 執行的指令之間沒有因果相關性。使用 redis-benchmark 進行壓測的時候可以發現影響 redis 的 QPS峯值的一個重要因素是 pipeline 批次指令的數目。

25、是否使用過 Redis 集羣，集羣的原理是什麼？

Redis Sentinal 着眼於高可用，在 master 宕機時會自動將 slave 提升爲master，繼續提供服務。
Redis Cluster 着眼於擴展性，在單個 redis 內存不足時，使用 Cluster 進行分片存儲。

擴展連接：加粗樣式更多請點擊這裏

博主公衆號程序員小羊只發面試相關推文