Redis面試題
Redis面試題
1.什么是Redis?
- Redis 是一個使用 C 語言寫成的，開源的高性能key-value非關系緩存數據庫。
- 它支持存儲的value類型相對更多，包括string(字符串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）
- Redis的數據都基于緩存的，所以很快，每秒可以處理超過 10萬次讀寫操作，是已知性能最快的Key-Value DB。
- Redis也可以實現數據寫入磁盤中，保證了數據的安全不丟失，而且Redis的操作是原子性的。
2.Redis有哪些優缺點？
優點
- 讀寫性能優異， Redis能讀的速度是110000次/s，寫的速度是81000次/s。
- 支持數據持久化，支持AOF和RDB兩種持久化方式。
- 支持事務，Redis的所有操作都是原子性的，同時Redis還支持對幾個操作合并后的原子性執行。
- 數據結構豐富，除了支持string類型的value外還支持hash、set、zset、list等數據結構。
- 支持主從復制，主機會自動將數據同步到從機，可以進行讀寫分離。
缺點
- 數據庫容量受到物理內存的限制，不能用作海量數據的高性能讀寫，因此Redis適合的場景主要局限在較小數據量的高性能操作和運算上。
- Redis 不具備自動容錯和恢復功能，主機從機的宕機都會導致前端部分讀寫請求失敗，需要等待機器重啟或者手動切換前端的IP才能恢復。
- 主機宕機，宕機前有部分數據未能及時同步到從機，切換IP后還會引入數據不一致的問題，降低了系統的可用性。
- Redis 較難支持在線擴容，在集群容量達到上限時在線擴容會變得很復雜。為避免這一問題，運維人員在系統上線時必須確保有足夠的空間，這對資源造成了很大的浪費。
3.為什么要用 Redis 而不用 map/guava 做緩存?
- 緩存分為本地緩存和分布式緩存。以 Java 為例，使用自帶的 map 或者 guava 實現的是本地緩存，最主要的特點是輕量以及快速，生命周期隨著 jvm 的銷毀而結束，并且在多實例的情況下，
每個實例都需要各自保存一份緩存，緩存不具有一致性。
- 使用 redis 或 memcached 之類的稱為分布式緩存，在多實例的情況下，各實例共用一份緩存數據，緩存具有一致性。缺點是需要保持 redis 或 memcached服務的高可用，整個程序架構上較為
復雜。
4. Redis為什么這么快?
- 完全基于內存，絕大部分請求是純粹的內存操作，非常快速。
- 數據結構簡單，對數據操作也簡單，Redis 中的數據結構是專門進行設計的；
- 采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU，不用去考慮各種鎖的問題， 不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的性能消耗；
- 使用多路 I/O 復用模型，非阻塞 IO；
- 使用底層模型不同，它們之間底層實現方式以及與客戶端之間通信的應用協議不一樣，Redis直接自己構建了 VM 機制 ，因為一般的系統調用系統函數的話，
會浪費一定的時間去移動和請求
5.Redis有哪些數據類型
數據類型 可以存儲的值 操作 應用場景
String 字符串、整數或者浮點數 對整個字符串或者字符串的其中一部分執行操作，對整數和浮點數執行自增或者自減操作 做簡單的鍵值對緩存
List 列表 從兩端亞茹或者彈出元素，對單個或者多個元素進行修剪，只保留一個范圍內的元素 存儲一些列表型的數據結構，類似粉絲列表，文章的評論列表之類的數據
Set 無序集合 添加、獲取、移除單個元素，檢查一個元素是否存在于集合中，計算交集、并集、差集，從集合里面隨機獲取元素 交集、并集、差集的操作，比如交集，可以把兩個人的粉絲列表整一個交集
Hash 包含鍵值對的無序散列表 添加、獲取、溢出單個鍵值對，獲取所有鍵值對，檢查某個鍵值是否存在 結構化的數據，比如一個對象
ZSet 有序集合 各級分值范圍或者成員來獲取元素，計算一個鍵的排名 去重但可以排序，如獲取排名前幾名的用戶
6.Redis的應用場景
計數器
可以對 String 進行自增自減運算，從而實現計數器功能。Redis 這種內存型數據庫的讀寫性能非常高，很適合存儲頻繁讀寫的計數量。緩存
將熱點數據放到內存中，設置內存的最大使用量以及淘汰策略來保證緩存的命中率。
會話緩存
可以使用 Redis 來統一存儲多臺應用服務器的會話信息。當應用服務器不再存儲用戶的會話信息，也就
不再具有狀態，一個用戶可以請求任意一個應用服務器，從而更容易實現高可用性以及可伸縮性。
全頁緩存（FPC）
除基本的會話token之外，Redis還提供很簡便的FPC平臺。以Magento為例，Magento提供一個插件
來使用Redis作為全頁緩存后端。此外，對WordPress的用戶來說，Pantheon有一個非常好的插件 wpredis，這個插件能幫助你以最快速度加載你曾瀏覽過的頁面。
查找表
例如 DNS 記錄就很適合使用 Redis 進行存儲。查找表和緩存類似，也是利用了 Redis 快速的查找特
性。但是查找表的內容不能失效，而緩存的內容可以失效，因為緩存不作為可靠的數據來源。
消息隊列(發布/訂閱功能)
List 是一個雙向鏈表，可以通過 lpush 和 rpop 寫入和讀取消息。不過最好使用 Kafka、
RabbitMQ 等消息中間件。
分布式鎖實現
在分布式場景下，無法使用單機環境下的鎖來對多個節點上的進程進行同步。可以使用 Redis 自帶的
SETNX 命令實現分布式鎖，除此之外，還可以使用官方提供的 RedLock 分布式鎖實現。
7.Redis 的持久化機制是什么？各自的優缺點？
Redis 提供兩種持久化機制 RDB（默認） 和 AOF 機制:
RDB：是Redis DataBase縮寫快照
RDB是Redis默認的持久化方式。按照一定的時間將內存的數據以快照的形式保存到硬盤中，對應
產生的數據文件為dump.rdb。通過配置文件中的save參數來定義快照的周期。
優點：
- 只有一個文件 dump.rdb，方便持久化。
- 容災性好，一個文件可以保存到安全的磁盤。
- 性能最大化，fork 子進程來完成寫操作，讓主進程繼續處理命令，所以是 IO 最大化。使用單獨子進程來進行持久化，主進程不會進行任何 IO 操作，保證了 redis 的高性能
- 相對于數據集大時，比 AOF 的啟動效率更高。
缺點：
- 數據安全性低。RDB 是間隔一段時間進行持久化，如果持久化之間 redis 發生故障，會發生數據丟失。所以這種方式更適合數據要求不嚴謹的時候)
AOF（Append-only file)持久化方式： 是指所有的命令行記錄以 redis 命令請 求協議的格式完全持久化存儲)保存為 aof 文件。
AOF：持久化
AOF持久化(即Append Only File持久化)，則是將Redis執行的每次寫命令記錄到單獨的日志文件
中，當重啟Redis會重新將持久化的日志中文件恢復數據。
當兩種方式同時開啟時，數據恢復Redis會優先選擇AOF恢復
優點：
- 數據安全，aof 持久化可以配置 appendfsync 屬性，有 always，每進行一次 命令操作就記錄到 aof 文件中一次。
- 通過 append 模式寫文件，即使中途服務器宕機，可以通過 redis-check-aof 工具解決數據一致性問題。
- AOF 機制的 rewrite 模式。AOF 文件沒被 rewrite 之前（文件過大時會對命令 進行合并重寫），可以刪除其中的某些命令（比如誤操作的 flushall）)
缺點：
- AOF 文件比 RDB 文件大，且恢復速度慢。
- 數據集大的時候，比 rdb 啟動效率低。
8.如何選擇合適的持久化方式?
- 一般來說， 如果想達到足以媲美PostgreSQL的數據安全性，你應該同時使用兩種持久化功能。在這種情況下，當 Redis 重啟的時候會優先載入AOF文件來恢復原始的數據，
因為在通常情況下AOF文件保存的數據集要比RDB文件保存的數據集要完整。
- 如果你非常關心你的數據， 但仍然可以承受數分鐘以內的數據丟失，那么你可以只使用RDB持久化。
- 有很多用戶都只使用AOF持久化，但并不推薦這種方式，因為定時生成RDB快照（snapshot）非常便于進行數據庫備份， 并且 RDB 恢復數據集的速度也要比AOF恢復的速度要快，
除此之外，使用RDB還可以避免AOF程序的bug。
- 如果你只希望你的數據在服務器運行的時候存在，你也可以不使用任何持久化方式。
9.Redis的過期鍵的刪除策略
過期策略通常有以下三種：
- 定時過期：每個設置過期時間的key都需要創建一個定時器，到過期時間就會立即清除。該策略可以立即清除過期的數據，對內存很友好；但是會占用大量的CPU資源去處理過期的數據，
從而影響緩存的響應時間和吞吐量。
- 惰性過期：只有當訪問一個key時，才會判斷該key是否已過期，過期則清除。該策略可以最大化地節省CPU資源，卻對內存非常不友好。極端情況可能出現大量的過期key沒有再次被訪問，
從而不會被清除，占用大量內存。
- 定期過期：每隔一定的時間，會掃描一定數量的數據庫的expires字典中一定數量的key，并清除其中已過期的key。該策略是前兩者的一個折中方案。
通過調整定時掃描的時間間隔和每次掃描的限定耗時，可以在不同情況下使得CPU和內存資源達到最優的平衡效果。 (expires字典會保存所有設置了過期時間的key的過期時間數據，
其中，key是指向鍵空間中的某個鍵的指針，value是該鍵的毫秒精度的UNIX時間戳表示的過期時間。鍵空間是指該Redis集群中保存的所有鍵。)Redis中同時使用了惰性過期和定期過期兩種過期策略。
10.Redis的內存淘汰策略有哪些
Redis的內存淘汰策略是指在Redis的用于緩存的內存不足時，怎么處理需要新寫入且需要申請額外空間的數據。
全局的鍵空間選擇性移除
- noeviction：當內存不足以容納新寫入數據時，新寫入操作會報錯。
- allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的key。（這個是最常用的）
- allkeys-random：當內存不足以容納新寫入數據時，在鍵空間中，隨機移除某個key。設置過期時間的鍵空間選擇性移除
- volatile-lru：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，移除最近最少使用的key。
- volatile-random：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，隨機移除某個key。
- volatile-ttl：當內存不足以容納新寫入數據時，在設置了過期時間的鍵空間中，有更早過期時間的key優先移除。
總結
Redis的內存淘汰策略的選取并不會影響過期的key的處理。內存淘汰策略用于處理內存不足時的需要申請額外空間的數據；過期策略用于處理過期的緩存數據。
11. Redis線程模型
- Redis基于Reactor模式開發了網絡事件處理器，這個處理器被稱為文件事件處理器（file eventhandler）。它的組成結構為4部分：多個套接字、IO多路復用程序、文件事件分派器、事件處理器。
因為文件事件分派器隊列的消費是單線程的，所以Redis才叫單線程模型。
- 文件事件處理器使用 I/O 多路復用（multiplexing）程序來同時監聽多個套接字， 并根據套接字目前執行的任務來為套接字關聯不同的事件處理器。
- 當被監聽的套接字準備好執行連接應答（accept）、讀取（read）、寫入（write）、關閉（close）等操作時， 與操作相對應的文件事件就會產生， 這時文件事件處理器就會調用套接字之
前關聯好的事件處理器來處理這些事件。
- 雖然文件事件處理器以單線程方式運行， 但通過使用 I/O 多路復用程序來監聽多個套接字， 文件事件處理器既實現了高性能的網絡通信模型， 又可以很好地與 redis 服務器中其他同樣以單線程方式運行的
模塊進行對接， 這保持了 Redis 內部單線程設計的簡單性。
12.官方Redis Cluster 方案(服務端路由查詢)
Redis Cluster是一種服務端Sharding技術，3.0版本開始正式提供。Redis Cluster并沒有使用一致性hash，而是采用slot(槽)的概念，一共分成16384個槽。將請求發送到任意節點，接收到請求的
節點會將查詢請求發送到正確的節點上執行
方案說明
- 通過哈希的方式，將數據分片，每個節點均分存儲一定哈希槽(哈希值)區間的數據，默認分配了16384 個槽位
- 每份數據分片會存儲在多個互為主從的多節點上數據寫入先寫主節點，再同步到從節點(支持配置為阻塞同步)
- 同一分片多個節點間的數據不保持一致性
- 讀取數據時，當客戶端操作的key沒有分配在該節點上時，redis會返回轉向指令，指向正確的節點擴容時時需要需要把舊節點的數據遷移一部分到新節點
- 在 redis cluster 架構下，每個 redis 要放開兩個端口號，比如一個是 6379，另外一個就是 加1w的端口號，比如 16379。
- 16379 端口號是用來進行節點間通信的，也就是 cluster bus 的東西，cluster bus 的通信，用來進行故障檢測、配置更新、故障轉移授權。cluster bus 用了另外一種二進制的協議，
- gossip 協議，用于節點間進行高效的數據交換，占用更少的網絡帶寬和處理時間。節點間的內部通信機制
基本通信原理
集群元數據的維護有兩種方式：集中式、Gossip 協議。redis cluster 節點間采用 gossip 協議進行通信。
分布式尋址算法
- hash 算法（大量緩存重建）
- 一致性 hash 算法（自動緩存遷移）+ 虛擬節點（自動負載均衡）
- redis cluster 的 hash slot 算法
優點
- 無中心架構，支持動態擴容，對業務透明
- 具備Sentinel的監控和自動Failover(故障轉移)能力
- 客戶端不需要連接集群所有節點，連接集群中任何一個可用節點即可
- 高性能，客戶端直連redis服務，免去了proxy代理的損耗
缺點
- 運維也很復雜，數據遷移需要人工干預
- 只能使用0號數據庫
- 不支持批量操作(pipeline管道操作)
- 分布式邏輯和存儲模塊耦合等
13.Redis 主從架構
- 單機的 redis，能夠承載的 QPS 大概就在上萬到幾萬不等。對于緩存來說，一般都是用來支撐讀高并發的。
- 因此架構做成主從(master-slave)架構，一主多從，主負責寫，并且將數據復制到其它的slave 節點，從節點負責讀。所有的讀請求全部走從節點。
- 這樣也可以很輕松實現水平擴容，支撐讀高并發。
redis replication 的核心機制
redis 采用異步方式復制數據到 slave 節點，不過 redis2.8 開始，slave node 會周期性地確認自己每次復制的數據量；
- 一個 master node 是可以配置多個 slave node 的；
- slave node 也可以連接其他的 slave node；
- slave node 做復制的時候，不會 block master node 的正常工作；
- slave node 在做復制的時候，也不會 block 對自己的查詢操作，它會用舊的數據集來提供服務；
- 但是復制完成的時候，需要刪除舊數據集，加載新數據集，這個時候就會暫停對外服務了；
- slave node 主要用來進行橫向擴容，做讀寫分離，擴容的 slave node 可以提高讀的吞吐量。
redis 主從復制的核心原理
- 當啟動一個 slave node 的時候，它會發送一個 PSYNC 命令給 master node。
- 如果這是 slave node 初次連接到 master node，那么會觸發一次 full resynchronization 全量復制。此時 master 會啟動一個后臺線程，開始生成一份 RDB 快照文件，
- 同時還會將從客戶端 client 新收到的所有寫命令緩存在內存中。 RDB 文件生成完畢后， master會將這個 RDB 發送給 slave，slave 會先寫入本地磁盤，然后再從本地磁盤加載到內存中，
接著 master 會將內存中緩存的寫命令發送到 slave，slave 也會同步這些數據。
- slave node 如果跟 master node 有網絡故障，斷開了連接，會自動重連，連接之后 master node僅會復制給 slave 部分缺少的數據。
過程原理
- 當從庫和主庫建立MS關系后，會向主數據庫發送SYNC命令
- 主庫接收到SYNC命令后會開始在后臺保存快照(RDB持久化過程)，并將期間接收到的寫命令緩存起來
- 當快照完成后，主Redis會將快照文件和所有緩存的寫命令發送給從Redis
- 從Redis接收到后，會載入快照文件并且執行收到的緩存的命令
- 之后，主Redis每當接收到寫命令時就會將命令發送從Redis，從而保證數據的一致
14.Redis實現分布式鎖
- Redis為單進程單線程模式，采用隊列模式將并發訪問變成串行訪問，且多客戶端對Redis的連接并不存在競爭關系Redis中可以使用setNx命令實現分布式鎖。
- 當且僅當 key 不存在，將 key 的值設為 value。 若給定的 key 已經存在，則 setNx不做任何動作SETNX 是『SET if Not eXists』(如果不存在，則 SET)的簡寫。
- 返回值：設置成功，返回 1 。設置失敗，返回 0 。
15.什么是redis穿透？
就是用戶請求透過redis去請求mysql服務器，導致mysql壓力過載。但一個web服務里，極容易出現瓶頸的就是mysql，所以才讓redis去分擔mysql 的壓力，所以這種問題是萬萬要避免的
解決方法：
從緩存取不到的數據，在數據庫中也沒有取到，這時也可以將key-value對寫為key-null，緩存有效時間可以設置短點，如30秒（設置太長會導致正常情況也沒法使用）。這樣可以防止攻擊用戶反復用同一個id暴力攻擊
接口層增加校驗，如用戶鑒權校驗，id做基礎校驗，id<=0的直接攔截；
采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的 bitmap 中，一個一定不存在的數據會被這個 bitmap 攔截掉，從而避免了對底層存儲系統的查詢壓力
16.什么是redis雪崩？
就是redis服務由于負載過大而宕機，導致mysql的負載過大也宕機，最終整個系統癱瘓
解決方法：
- redis集群，將原來一個人干的工作，分發給多個人干
- 緩存預熱（關閉外網訪問，先開啟mysql，通過預熱腳本將熱點數據寫入緩存中，啟動緩存。開啟外網服務）
- 數據不要設置相同的生存時間，不然過期時，redis壓力會大
17.什么是redis穿透？
高并發下，由于一個key失效，而導致多個線程去mysql查同一業務數據并存到redis（并發下，存了多份數據），而一段時間后，多份數據同時失效。導致壓力驟增
解決方法：
- 分級緩存
- 鎖機制
18.緩存預熱
緩存預熱就是系統上線后，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據庫，然后再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！
解決方案
- 直接寫個緩存刷新頁面，上線時手工操作一下；
- 數據量不大，可以在項目啟動的時候自動進行加載；
- 定時刷新緩存；
浙公網安備 33010602011771號