本文的面試題如下：
-
Redis 持久化機制
-
快取雪崩、快取穿透、快取預熱、快取更新、快取降級等問題
-
熱點資料和冷資料是什么
-
Memcache與Redis的區別都有哪些？
-
單執行緒的redis為什么這么快
-
redis的資料型別，以及每種資料型別的使用場景，Redis 內部結構
-
redis的過期策略以及記憶體淘汰機制
-
Redis 為什么是單執行緒的，優點
-
如何解決redis的并發競爭key問題
-
Redis 集群方案應該怎么做？都有哪些方案？
-
有沒有嘗試進行多機redis 的部署？如何保證資料一致的？
-
對于大量的請求怎么樣處理
-
Redis 常見性能問題和解決方案？
-
講解下Redis執行緒模型
-
為什么Redis的操作是原子性的，怎么保證原子性的？
-
Redis事務
-
Redis實作分布式鎖
-
總結
小編在這里整理了一套大廠Redis高頻面試題 需要的朋友關注公眾號：程式員白楠楠
Redis 持久化機制
Redis是一個支持持久化的記憶體資料庫，通過持久化機制把記憶體中的資料同步到硬碟檔案來保證資料持久化，當Redis重啟后通過把硬碟檔案重新加載到記憶體，就能達到恢復資料的目的，
實作：單獨創建fork()一個子行程，將當前父行程的資料庫資料復制到子行程的記憶體中，然后由子行程寫入到臨時檔案中，持久化的程序結束了，再用這個臨時檔案替換上次的快照檔案，然后子行程退出，記憶體釋放，
RDB是Redis默認的持久化方式，按照一定的時間周期策略把記憶體的資料以快照的形式保存到硬碟的二進制檔案，即Snapshot快照存盤，對應產生的資料檔案為dump.rdb，通過組態檔中的save引數來定義快照的周期，（ 快照可以是其所表示的資料的一個副本，也可以是資料的一個復制品，） AOF：Redis會將每一個收到的寫命令都通過Write函式追加到檔案最后，類似于MySQL的binlog，當Redis重啟是會通過重新執行檔案中保存的寫命令來在記憶體中重建整個資料庫的內容，
當兩種方式同時開啟時，資料恢復Redis會優先選擇AOF恢復，
快取雪崩、快取穿透、快取預熱、快取更新、快取降級等問題
快取雪崩
快取雪崩我們可以簡單的理解為：由于原有快取失效，新快取未到期間
(例如：我們設定快取時采用了相同的過期時間，在同一時刻出現大面積的快取過期)，所有原本應該訪問快取的請求都去查詢資料庫了，而對資料庫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一般用于在大資料量的集合中判定某元素是否存在，
快取穿透與快取擊穿的區別
快取擊穿：是指一個key非常熱點，在不停的扛著大并發，大并發集中對這一個點進行訪問，當這個key在失效的瞬間，持續的大并發就穿破快取，直接請求資料，
解決方案：在訪問key之前，采用SETNX（set if not exists）來設定另一個短期key來鎖住當前key的訪問，訪問結束再洗掉該短期key，
給一個我公司處理的案例：背景雙機拿token，token在存一份到redis，保證系統在token過期時都只有一個執行緒去獲取token;線上環境有兩臺機器，故使用分布式鎖實作，
快取預熱
快取預熱這個應該是一個比較常見的概念，相信很多小伙伴都應該可以很容易的理解，快取預熱就是系統上線后，將相關的快取資料直接加載到快取系統，這樣就可以避免在用戶請求的時候，先查詢資料庫，然后再將資料快取的問題！用戶直接查詢事先被預熱的快取資料！
解決思路：
-
直接寫個快取重繪頁面，上線時手工操作下；
-
資料量不大，可以在專案啟動的時候自動進行加載；
-
定時重繪快取；
快取更新
除了快取服務器自帶的快取失效策略之外（Redis默認的有6中策略可供選擇），我們還可以根據具體的業務需求進行自定義的快取淘汰，常見的策略有兩種：
-
定時去清理過期的快取；
-
當有用戶請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料并更新快取，
兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次用戶請求過來都要判斷快取失效，邏輯相對比較復雜！具體用哪種方案，大家可以根據自己的應用場景來權衡，
快取降級
當訪問量劇增、服務出現問題（如回應時間慢或不回應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務，系統可以根據一些關鍵資料進行自動降級，也可以配置開關實作人工降級，
降級的最終目的是保證核心服務可用，即使是有損的，而且有些服務是無法降級的（如加入購物車、結算），
以參考日志級別設定預案：
-
一般：比如有些服務偶爾因為網路抖動或者服務正在上線而超時，可以自動降級；
-
警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，并發送告警；
-
錯誤：比如可用率低于90%，或者資料庫連接池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；
-
嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級，
服務降級的目的，是為了防止Redis服務故障，導致資料庫跟著一起發生雪崩問題，因此，對于不重要的快取資料，可以采取服務降級策略，例如一個比較常見的做法就是，Redis出現問題，不去資料庫查詢，而是直接回傳默認值給用戶，
熱點資料和冷資料是什么
熱點資料，快取才有價值
對于冷資料而言，大部分資料可能還沒有再次訪問到就已經被擠出記憶體，不僅占用記憶體，而且價值不大，頻繁修改的資料，看情況考慮使用快取
對于上面兩個例子，壽星串列、導航資訊都存在一個特點，就是資訊修改頻率不高，讀取通常非常高的場景，
對于熱點資料，比如我們的某IM產品，生日祝福模塊，當天的壽星串列，快取以后可能讀取數十萬次，再舉個例子，某導航產品，我們將導航資訊，快取以后可能讀取數百萬次，
資料更新前至少讀取兩次， 快取才有意義，這個是最基本的策略，如果快取還沒有起作用就失效了，那就沒有太大價值了，
那存不存在，修改頻率很高，但是又不得不考慮快取的場景呢？有！比如，這個讀取介面對資料庫的壓力很大，但是又是熱點資料，這個時候就需要考慮通過快取手段，減少資料庫的壓力，比如我們的某助手產品的，點贊數，收藏數，分享數等是非常典型的熱點資料，但是又不斷變化，此時就需要將資料同步保存到Redis快取，減少資料庫壓力，
Memcache與Redis的區別都有哪些？
1)、存盤方式 Memecache把資料全部存在記憶體之中，斷電后會掛掉，資料不能超過記憶體大小，Redis有部份存在硬碟上，redis可以持久化其資料
2)、資料支持型別 memcached所有的值均是簡單的字串，redis作為其替代者，支持更為豐富的資料型別 ，提供list，set，zset，hash等資料結構的存盤
3)、使用底層模型不同 它們之間底層實作方式 以及與客戶端之間通信的應用協議不一樣，Redis直接自己構建了VM 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求，
4). value 值大小不同：Redis 最大可以達到 512M；memcache 只有 1mb，
5）redis的速度比memcached快很多
6）Redis支持資料的備份，即master-slave模式的資料備份，
單執行緒的redis為什么這么快
(一)純記憶體操作
(二)單執行緒操作，避免了頻繁的背景關系切換
(三)采用了非阻塞I/O多路復用機制
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操作，
Redis 內部結構
-
dict 本質上是為了解決演算法中的查找問題（Searching）是一個用于維護key和value映射關系的資料結構，與很多語言中的Map或dictionary類似，本質上是為了解決演算法中的查找問題（Searching）
-
sds sds就等同于char * 它可以存盤任意二進制資料，不能像C語言字串那樣以字符’\0’來標識字串的結 束，因此它必然有個長度欄位，
-
skiplist （跳躍表） 跳表是一種實作起來很簡單，單層多指標的鏈表，它查找效率很高，堪比優化過的二叉平衡樹，且比平衡樹的實作，
-
quicklist
-
ziplist 壓縮表 ziplist是一個編碼后的串列，是由一系列特殊編碼的連續記憶體塊組成的順序型資料結構，
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-lru1
復制代碼該配置就是配記憶體淘汰策略的(什么，你沒配過？好好反省一下自己)
-
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(不洗掉) 基本上一致，
Redis 為什么是單執行緒的
官方FAQ表示，因為Redis是基于記憶體的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器記憶體的大小或者網路帶寬，
既然單執行緒容易實作，而且CPU不會成為瓶頸，那就順理成章地采用單執行緒的方案了（畢竟采用多執行緒會有很多麻煩！）Redis利用佇列技術將并發訪問變為串行訪問
1）絕大部分請求是純粹的記憶體操作（非常快速）
2）采用單執行緒,避免了不必要的背景關系切換和競爭條件
3）非阻塞IO優點：
-
速度快，因為資料存在記憶體中，類似于HashMap，HashMap的優勢就是查找和操作的時間復雜度都是O(1)
-
支持豐富資料型別，支持string，list，set，sorted set，hash
-
支持事務，操作都是原子性，所謂的原子性就是對資料的更改要么全部執行，要么全部不執行
-
豐富的特性：可用于快取，訊息，按key設定過期時間，過期后將會自動洗掉如何解決redis的并發競爭key問題
同時有多個子系統去set一個key，這個時候要注意什么呢？
不推薦使用redis的事務機制，因為我們的生產環境，基本都是redis集群環境，做了資料分片操作，你一個事務中有涉及到多個key操作的時候，這多個key不一定都存盤在同一個redis-server上，因此，redis的事務機制，十分雞肋，
-
如果對這個key操作，不要求順序：準備一個分布式鎖，大家去搶鎖，搶到鎖就做set操作即可
-
如果對這個key操作，要求順序：分布式鎖+時間戳，假設這會系統B先搶到鎖，將key1設定為{valueB 3:05}，接下來系統A搶到鎖，發現自己的valueA的時間戳早于快取中的時間戳，那就不做set操作了，以此類推，
-
利用佇列，將set方法變成串行訪問也可以redis遇到高并發，如果保證讀寫key的一致性
對redis的操作都是具有原子性的,是執行緒安全的操作,你不用考慮并發問題,redis內部已經幫你處理好并發的問題了，
Redis 集群方案應該怎么做？都有哪些方案？
1.twemproxy，大概概念是，它類似于一個代理方式， 使用時在本需要連接 redis 的地方改為連接 twemproxy， 它會以一個代理的身份接收請求并使用一致性 hash 演算法，將請求轉接到具體 redis，將結果再回傳 twemproxy，
缺點：twemproxy 自身單埠實體的壓力，使用一致性 hash 后，對 redis 節點數量改變時候的計算值的改變，資料無法自動移動到新的節點，
2.codis，目前用的最多的集群方案，基本和 twemproxy 一致的效果，但它支持在 節點數量改變情況下，舊節點資料可恢復到新 hash 節點
3.redis cluster3.0 自帶的集群，特點在于他的分布式演算法不是一致性 hash，而是 hash 槽的概念，以及自身支持節點設定從節點，具體看官方檔案介紹，
有沒有嘗試進行多機redis 的部署？如何保證資料一致的？
主從復制，讀寫分離
一類是主資料庫（master）一類是從資料庫（slave），主資料庫可以進行讀寫操作，當發生寫操作的時候自動將資料同步到從資料庫，而從資料庫一般是只讀的，并接收主資料庫同步過來的資料，一個主資料庫可以有多個從資料庫，而一個從資料庫只能有一個主資料庫，
對于大量的請求怎么樣處理
redis是一個單執行緒程式，也就說同一時刻它只能處理一個客戶端請求；
redis是通過IO多路復用（select，epoll, kqueue，依據不同的平臺，采取不同的實作）來處理多個客戶端請求的
Redis 常見性能問題和解決方案？
(1) Master 最好不要做任何持久化作業，如 RDB 記憶體快照和 AOF 日志檔案
(2) 如果資料比較重要，某個 Slave 開啟 AOF 備份資料，策略設定為每秒同步一次
(3) 為了主從復制的速度和連接的穩定性， Master 和 Slave 最好在同一個局域網內
(4) 盡量避免在壓力很大的主庫上增加從庫
(5) 主從復制不要用圖狀結構，用單向鏈表結構更為穩定，即：Master <- Slave1 <- Slave2 <- Slave3…
講解下Redis執行緒模型
檔案事件處理器包括分別是套接字、 I/O 多路復用程式、 檔案事件分派器（dispatcher）、 以及事件處理器，使用 I/O 多路復用程式來同時監聽多個套接字， 并根據套接字目前執行的任務來為套接字關聯不同的事件處理器，
當被監聽的套接字準備好執行連接應答（accept）、讀取（read）、寫入（write）、關閉（close）等操作時， 與操作相對應的檔案事件就會產生， 這時檔案事件處理器就會呼叫套接字之前關聯好的事件處理器來處理這些事件，
I/O 多路復用程式負責監聽多個套接字， 并向檔案事件分派器傳送那些產生了事件的套接字，
作業原理：
I/O 多路復用程式負責監聽多個套接字， 并向檔案事件分派器傳送那些產生了事件的套接字，
盡管多個檔案事件可能會并發地出現， 但 I/O 多路復用程式總是會將所有產生事件的套接字都入隊到一個佇列里面， 然后通過這個佇列， 以有序（sequentially）、同步（synchronously）、每次一個套接字的方式向檔案事件分派器傳送套接字：
當上一個套接字產生的事件被處理完畢之后（該套接字為事件所關聯的事件處理器執行完畢）， I/O 多路復用程式才會繼續向檔案事件分派器傳送下一個套接字，如果一個套接字又可讀又可寫的話， 那么服務器將先讀套接字， 后寫套接字.
為什么Redis的操作是原子性的，怎么保證原子性的？
對于Redis而言，命令的原子性指的是：一個操作的不可以再分，操作要么執行，要么不執行，
Redis的操作之所以是原子性的，是因為Redis是單執行緒的，（Redis新版本已經引入多執行緒，這里基于舊版本的Redis）
Redis本身提供的所有API都是原子操作，Redis中的事務其實是要保證批量操作的原子性，
多個命令在并發中也是原子性的嗎？
不一定， 將get和set改成單命令操作，incr ，使用Redis的事務，或者使用Redis+Lua==的方式實作.
Redis事務
Redis事務功能是通過MULTI、EXEC、DISCARD和WATCH 四個原語實作的
Redis會將一個事務中的所有命令序列化，然后按順序執行，
-
redis 不支持回滾“Redis 在事務失敗時不進行回滾，而是繼續執行余下的命令”， 所以 Redis 的內部可以保持簡單且快速，
-
如果在一個事務中的命令出現錯誤，那么所有的命令都不會執行；
-
如果在一個事務中出現運行錯誤，那么正確的命令會被執行，
注：redis的discard只是結束本次事務,正確命令造成的影響仍然存在.
1）MULTI命令用于開啟一個事務，它總是回傳OK，MULTI執行之后，客戶端可以繼續向服務器發送任意多條命令，這些命令不會立即被執行，而是被放到一個佇列中，當EXEC命令被呼叫時，所有佇列中的命令才會被執行，
2）EXEC：執行所有事務塊內的命令，回傳事務塊內所有命令的回傳值，按命令執行的先后順序排列，當操作被打斷時，回傳空值 nil ，
3）通過呼叫DISCARD，客戶端可以清空事務佇列，并放棄執行事務， 并且客戶端會從事務狀態中退出，
4）WATCH 命令可以為 Redis 事務提供 check-and-set （CAS）行為，可以監控一個或多個鍵，一旦其中有一個鍵被修改（或洗掉），之后的事務就不會執行，監控一直持續到EXEC命令，
Redis實作分布式鎖
Redis為單行程單執行緒模式，采用佇列模式將并發訪問變成串行訪問，且多客戶端對Redis的連接并不存在競爭關系Redis中可以使用SETNX命令實作分布式鎖，
將 key 的值設為 value ，當且僅當 key 不存在，若給定的 key 已經存在，則 SETNX 不做任何動作
解鎖：使用 del key 命令就能釋放鎖
解決死鎖：
-
通過Redis中expire()給鎖設定最大持有時間，如果超過，則Redis來幫我們釋放鎖，
-
使用 setnx key “當前系統時間+鎖持有的時間”和getset key “當前系統時間+鎖持有的時間”組合的命令就可以實作，
總結
歡迎關注公眾號：程式員白楠楠 ，領取pdf檔案的Java核心知識點總結！
這些資料的內容都是面試時面試官必問的知識點，篇章包括了很多知識點，其中包括了有基礎知識、Java集合、JVM、多執行緒并發、spring原理、微服務、Netty 與RPC 、Kafka、日記、設計模式、Java演算法、資料庫、Zookeeper、分布式快取、資料結構等等，
大家一起交流，喜歡文章記得關注我點個贊喲，感謝支持！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/231741.html
標籤：Java