Redis高頻的面試題有哪些

這篇文章主要介紹“Redis高頻的面試題有哪些”，在日常操作中，相信很多人在Redis高頻的面試題有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Redis高頻的面試題有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

通過面試多家大型互聯網企業，總結了如下的高頻面試題目：

1、redis 過期鍵的刪除策略?

• 定時刪除:在設置鍵的過期時間的同時，創建一個定時器 timer). 讓定時器在鍵 的過期時間來臨時，立即執行對鍵的刪除操作。

• 惰性刪除:放任鍵過期不管，但是每次從鍵空間中獲取鍵時，都檢查取得的鍵是 否過期，如果過期的話，就刪除該鍵;如果沒有過期，就返回該鍵。

• 定期刪除:每隔一段時間程序就對數據庫進行一次檢查，刪除里面的過期鍵

2、Redus的淘汰策略

redis 內存數據集大小上升到一定大小的時候，就會施行 數據淘汰策略 。redis 提供6種數據淘汰策略：

通過淘汰策略也能保證Redis中緩存的都是熱點數據。

一個客戶端運行了新的命令，添加了新的數據。Redi 檢查內存使用情況，如果大于 maxmemory 的限制, 則根據設定好的策略進行回收。

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

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

allkeys-random

3、Redis分布式鎖的實現

Redis的分布式緩存特性使其成為了分布式鎖的一種基礎實現。通過Redis中是否存在某個鎖ID，則可以判斷是否上鎖。為了保證判斷鎖是否存在的原子性，保證只有一個線程獲取同一把鎖，Redis有  SETNX (即SET if Note Exists)和 GETSET (先寫新值，返回舊值，原子性操作，可以用于分辨是不是首次操作)操作。

(1)關于setnx：

• 將 key 的值設為 value ，當且僅當 key 不存在，返回值為1。

• 若給定的 key 已經存在，則setnx不做任何動作，返回值為0。

(2)關于set：一般操作

• ex seconds - seconds：設置失效時長，單位秒

• px - milliseconds：設置失效時長，單位毫秒

• nx - key不存在時設置value，成功返回OK，失敗返回(nil)

• xx - key存在時設置value，成功返回OK，失敗返回(nil)

為了防止主機宕機或網絡斷開之后的死鎖，Redis沒有ZK那種天然的實現方式，只能依賴設置超時時間來規避。所以如果使用setnx來實現分布式鎖，則實現步驟如下：

• 先拿 setnx 來爭搶鎖，搶到之后，再用 expire 給鎖加一個過期時間防止鎖忘記了釋放。

• 如果在 setnx 之后，執行 expire 之前進程意外 crash 或重啟維護, 那么就需要把 setnx 和 expire  合成一條指令來用。

Redis 的 setnx 命令是當 key 不存在時設置 key ，但 setnx 不能同時完成 expire 設置失效時長，不能保證 setnx 和  expire 的原子性。我們可以使用 set 命令完成 setnx 和 expire 的操作，并且這種操作是原子操作。舉個例子如下：

案例：設置name=p7+，失效時長100s，不存在時設置 1.1.1.1:6379> set name p7+ ex 100 nx OK 1.1.1.1:6379> get name "p7+" 1.1.1.1:6379> ttl name (integer) 94

從上面可以看出，多個命令放在同一個 redis 連接中并且 redis 是單線程的，因此上面的操作可以看成 setnx 和 expire  的結合體，是原子性的。

4、Redis的Reactor模式

Redis基于Reactor模式開發了網絡事件處理器，這個處理器被稱為文件事件處理器。它的組成結構為4部分：多個套接字、IO多路復用程序、文件事件分派器、事件處理器。

因為文件事件分派器隊列的消費是單線程的，所以Redis才叫單線程模型。

5、redis支持事務回滾嗎?

“ 不支持回滾動作，redis是支持簡單事務模式，只能discard，不能rollback ”

Redis在執行事務命令的時候，在命令入隊的時候， Redis  就會檢測事務的命令是否正確，如果不正確則會產生錯誤。無論之前和之后的命令都會被事務所回滾，就變為什么都沒有執行。

當命令格式正確，而因為操作數據結構引起的錯誤 ，則該命令執行出現錯誤，而其之前和之后的命令都會被正常執行。這點和數據庫很不一樣，這是需注意的地方。

對于一些重要的操作，我們必須通過程序去檢測數據的正確性，以保證 Redis 事務的正確執行，避免出現數據不一致的情況。 Redis  之所以保持這樣簡易的事務，完全是為了保證移動互聯網的核心問題一性能。

6、Redis的事務機制及CAS

watch指令在redis事物中提供了CAS的行為。為了檢測被watch的keys在是否有多個clients同時改變引起沖突，這些keys將會被監控。如果至少有一個被監控的key在執行exec命令前被修改，整個事物將會回滾，不執行任何動作，從而保證原子性操作，并且執行exec會得到null的回復。

7、Redis和Memcached的區別

Redis的特性：

• 速度快，因為數據存在內存中，類似于HashMap，HashMap的優勢就是查找和操作的時間復雜度都是O(1)

• 支持豐富數據類型，支持字符串、鏈表、哈希、集合和有序集合

• 支持事務，操作都是原子性，所謂的原子性就是對數據的更改要么全部執行，要么全部不執行

• 豐富的特性：可用于緩存，消息，按key設置過期時間，過期后將會自動刪除

與Memcached的區別在于：

• 存儲方式  Memecache把數據全部存在內存之中，斷電后會掛掉，數據不能超過內存大小。Redis有部分存在硬盤上，這樣能保證數據的持久性。

• 數據支持類型 Memcache對數據類型支持相對簡單。Redis有復雜的數據類型。

• 使用底層模型不同 它們之間底層實現方式 以及與客戶端之間通信的應用協議不一樣。

Redis直接自己構建了VM(Virtual Memory)機制  ，因為一般的系統調用系統函數的話(例如java調用自己的API)，會浪費一定的時間去移動和請求。

8、緩存穿透、緩存擊穿和緩存雪崩

(1)緩存穿透

查詢不存在的數據，緩存中沒有數據，數據庫也沒有數據。因此所有的請求都訪問到了數據庫，給數據庫造成了壓力。解決方法如下：

采用布隆過濾器，將所有可能存在的數據，哈希到一個很大的 bitmap 中，一個一定不存在的數據會被 bitmap  攔截調，從而避免了對數據庫的查詢壓力。

如果查詢的數據為空，那么直接將空數據也緩存起來并設置較短的過期時間。這樣下次訪問的時候，就直接返回空值。

(2)緩存擊穿

緩存擊穿是指緩存過期之后，瞬時間并發客戶端特別多查詢同一條數據的情況下，導致數據庫壓力過大。業界比較常用的做法，是使用mutex。簡單地來說，就是在緩存失效的時候(判斷拿出來的值為空)，不是立即去load  db，

而是先使用緩存工具的某些帶成功操作返回值的操作(比如Redis的SETNX或者Memcache的ADD)去set一個mutex  key，當操作返回成功時，

再進行load db的操作并回設緩存;否則，就重試整個get緩存的方法。類似下面的代碼：

public String get(String key) {     String value = redis.get(key);     if (value == null) { // 代表緩存值過期         // 設置3min的超時，防止del操作失敗的時候，下次緩存過期一直不能load db         if (redis.setnx(key_mutex, 1, 3 * 60) == 1) { // 代表設置成功             value = db.get(key);             redis.set(key, value, expire_secs);             redis.del(key_mutex);         }         // 這個時候代表同時候的其他線程已經load db并回設到緩存了，         // 這時候重試獲取緩存值即可         else {             sleep(50);             get(key); // 重試         }     } else {         return value;     } }

(3)緩存雪崩

雪崩就是指緩存中大批量熱點數據過期后系統涌入大量查詢請求，因為大部分數據在Redis層已經失效，請求滲透到數據庫層，大批量請求猶如洪水一般涌入，引起數據庫壓力造成查詢堵塞甚至宕機。

解決辦法：

將緩存失效時間分散開，比如每個key的過期時間是隨機，防止同一時間大量數據過期現象發生，這樣不會出現同一時間全部請求都落在數據庫層，如果緩存數據庫是分布式部署，將熱點數據均勻分布在不同Redis和數據庫中，有效分擔壓力，別一個人扛。

讓Redis數據永不過期(如果業務準許)。

9、Redis數據傾斜

1、存在bigkey：業務層避免創建bigkey，把集合類型的bigkey拆分成多個小集合，分散保存bigkey  保存了大量集合元素(集合類型)，會導致這個實例的數據量增加，內存資源消耗也相應增加。bigkey 的操作一般都會造成實例 IO 線程阻塞，如果 bigkey  的訪問量比較大，就會影響到這個實例上的其它請求被處理的速度。

2、slot手工分配不均勻：避免把較多的slot分配到一個實例上，進行槽的遷移

3、存在熱點數據：采用帶有不同key前綴的多副本方法。 我們把熱點數據復制多份，在每一個數據副本的 key  中增加一個隨機前綴，讓它和其它副本數據不會被映射到同一個 Slot 中。這樣一來， 熱點數據既有多個副本可以同時服務請求，同時，這些副本數據的 key  又不一樣，會被映射到不同的 Slot 中。在給這些 Slot 分配實例時，  我們也要注意把它們分配到不同的實例上，那么，熱點數據的訪問壓力就被分散到不同的實例上了。  熱點數據多副本方法只能針對只讀的熱點數據。如果熱點數據是有讀有寫的話，就不適合采用多副本方法了，因為要保證多副本間的數據一致性，會帶來額外的開銷。

10、為什么Redis單線程模型也能效率這么高?

• 純內存操作;

• 核心是基于非阻塞的IO多路復用機制;

• 底層使用C語言實現,一般來說，C 語言實現的程序"距離"操作系統更近，執行速度相對會更快;

• 單線程同時也避免了多線程的上下文頻繁切換問題,預防了多線程可能產生的競爭問題。

11、Redis做異步和延時隊列?

一般使用 list 結構作為隊列，rpush 生產消息，lpop 消費消息。當 lpop 沒有消息的時候，要適當 sleep  一會再重試。如果對方追問可不可以不用 sleep 呢?list 還有個指令叫 blpop，在沒有消息的時候，它會阻塞住直到消息到來。如果對  方追問能不能生產一次消費多次呢?使用 pub/sub 主題訂閱者模式，可以實現 1:N 的消息隊列。

使用 zset(有序集合)，拿時間戳作為score，消息內容作為 key 調用 zadd 來生產消息，消費者用 zrangebyscore 指令獲取 N  秒之前的數據輪詢進行處理。

12、Redis的集群策略

(1)Redis主從同步Redis的主從結構一主一從，一主多從或級聯結構，復制類型可以根據是否是全量而分為全量同步和增量同步。

(2)Redis哨兵  在主從復制實現之后，如果想對master進行監控，Redis提供了一種哨兵機制，哨兵的含義就是監控Redis系統的運行狀態，并做相應的響應。Redis  Sentinal 著眼于高可用，在 master 宕機時會自動將 slave 提升為master，繼續提供服務。

(3)Redis Cluster 著眼于擴展性，在單個 redis 內存不足時，使用 Cluster  進行分片存儲。在redis-cluster架構中，redis-master節點一般用于接收讀寫，而redis-slave節點則一般只用于備份，其與對應的master擁有相同的slot集合，若某個redis-master意外失效，則再將其對應的slave進行升級為臨時redis-master。

13、 Redis 的同步機制

Redis 可以使用主從同步，從從同步。第一次同步時，主節點做一次 bgsave，并同時將后續修改操作記錄到內存 buffer，待完成后將 rdb  文件全量同步到復制節點，復制節點接受完成后將 rdb 鏡像加載到內存。加載完成后，再通知主節點

將期間修改的操作記錄同步到復制節點進行重放就完成了同步過程。

到此，關于“Redis高頻的面試題有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！