前言
現在大家的工作生活基本已經是迴歸正軌了，最近也是迎來了跳槽面試季，有些人已經拿到了一兩個offer了。
這段時間收集了阿里、騰訊、百度、京東、美團、位元組跳動等公司的Java面試題，總結了Redis系列的高頻面試題：
1、Redis持久化機制
2、快取雪崩、快取穿透、快取預熱、快取更新、快取降級等問題
3、熱點資料和冷資料是什麼
4、Memcache與Redis的區別都有哪些？
5、單執行緒的redis為什麼這麼快
6、redis的資料型別，以及每種資料型別的使用場景
7、redis的過期策略以及記憶體淘汰機制
8、Redis 為什麼是單執行緒的
9、Redis 常見效能問題和解決方案？
10、為什麼Redis的操作是原子性的，怎麼保證原子性的？
11、Redis事務
Redis系列高頻面試題解析
Redis持久化機制
Redis是一個支援持久化的記憶體資料庫，通過持久化機制把記憶體中的資料同步到硬碟檔案來保證資料持久化。當Redis重啟後通過把硬碟檔案重新載入到記憶體，就能達到恢復資料的目的。
實現：單獨建立fork()一個子程式，將當前父程式的資料庫資料複製到子程式的記憶體中，然後由子程式
寫入到臨時檔案中，持久化的過程結束了，再用這個臨時檔案替換上次的快照檔案，然後子程式退出，
記憶體釋放。
RDB是Redis預設的持久化方式。按照一定的時間週期策略把記憶體的資料以快照的形式儲存到硬碟的二
進位制檔案。即Snapshot快照儲存，對應產生的資料檔案為dump.rdb，通過配置檔案中的save引數來定
義快照的週期。（ 快照可以是其所表示的資料的一個副本，也可以是資料的一個複製品。）
AOF：Redis會將每一個收到的寫命令都通過Write函式追加到檔案最後，類似於MySQL的binlog。當
Redis重啟是會通過重新執行檔案中儲存的寫命令來在記憶體中重建整個資料庫的內容。
當兩種方式同時開啟時，資料恢復Redis會優先選擇AOF恢復。
快取雪崩、快取穿透、快取預熱、快取更新、快取降級等問題
1、快取雪崩
我們可以簡單的理解為：由於原有快取失效，新快取未到期間
(例如：我們設定快取時採用了相同的過期時間，在同一時刻出現大面積的快取過期)，所有原本應該訪
問快取的請求都去查詢資料庫了，而對資料庫CPU和記憶體造成巨大壓力，嚴重的會造成資料庫當機。從而形成一系列連鎖反應，造成整個系統崩潰。
解決辦法：
大多數系統設計者考慮用加鎖（ 最多的解決方案）或者佇列的方式保證來保證不會有大量的執行緒對資料庫一次性進行讀寫，從而避免失效時大量的併發請求落到底層儲存系統上。還有一個簡單方案就時講快取失效時間分散開。
2、快取穿透
快取穿透是指使用者查詢資料，在資料庫沒有，自然在快取中也不會有。這樣就導致使用者查詢的時候，在
快取中找不到，每次都要去資料庫再查詢一遍，然後返回空（相當於進行了兩次無用的查詢）。這樣請
求就繞過快取直接查資料庫，這也是經常提的快取命中率問題。
解決辦法;
最常見的則是採用布隆過濾器，將所有可能存在的資料雜湊到一個足夠大的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一般用於在大資料量的集合中判定某元素是否存在。
3、快取預熱
快取預熱這個應該是一個比較常見的概念，相信很多小夥伴都應該可以很容易的理解，快取預熱就是系
統上線後，將相關的快取資料直接載入到快取系統。這樣就可以避免在使用者請求的時候，先查詢資料
庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！
解決思路：
（1）直接寫個快取重新整理頁面，上線時手工操作下；
（2）資料量不大，可以在專案啟動的時候自動進行載入；
（3）定時重新整理快取；
（4）快取更新
除了快取伺服器自帶的快取失效策略之外（Redis預設的有6中策略可供選擇），我們還可以根據具體的
業務需求進行自定義的快取淘汰，常見的策略有兩種：
（1）定時去清理過期的快取；
（2）當有使用者請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新數
據並更新快取。
兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次使用者請求過
來都要判斷快取失效，邏輯相對比較複雜！具體用哪種方案，大家可以根據自己的應用場景來權衡。
5、快取降級
當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的效能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵資料進行自動降級，也可以配置開關實現人工降級。
降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。
以參考日誌級別設定預案：
（1）一般：比如有些服務偶爾因為網路抖動或者服務正在上線而超時，可以自動降級；
（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，併傳送告警；
（3）錯誤：比如可用率低於90%，或者資料庫連線池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；
（4）嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級。
服務降級的目的，是為了防止Redis服務故障，導致資料庫跟著一起發生雪崩問題。因此，對於不重要的快取資料，可以採取服務降級策略，例如一個比較常見的做法就是，Redis出現問題，不去資料庫查詢，而是直接返回預設值給使用者。
熱點資料和冷資料是什麼
熱點資料，快取才有價值
對於冷資料而言，大部分資料可能還沒有再次訪問到就已經被擠出記憶體，不僅佔用記憶體，而且價值不場景。
對於熱點資料，比如我們的某IM產品，生日祝福模組，當天的壽星列表，快取以後可能讀取數十萬次。
再舉個例子，某導航產品，我們將導航資訊，快取以後可能讀取數百萬次。
資料更新前至少讀取兩次，快取才有意義。這個是最基本的策略，如果快取還沒有起作用就失效了，那
就沒有太大價值了。
那存不存在，修改頻率很高，但是又不得不考慮快取的場景呢？有！比如，這個讀取介面對資料庫的壓
力很大，但是又是熱點資料，這個時候就需要考慮通過快取手段，減少資料庫的壓力，比如我們的某助
手產品的，點贊數，收藏數，分享數等是非常典型的熱點資料，但是又不斷變化，此時就需要將資料同
步儲存到Redis快取，減少資料庫壓力。
Memcache與Redis的區別都有哪些？
1、儲存方式 Memecache把資料全部存在記憶體之中，斷電後會掛掉，資料不能超過記憶體大小。 Redis
有部份存在硬碟上，redis可以持久化其資料
2、資料支援型別 memcached所有的值均是簡單的字串，redis作為其替代者，支援更為豐富的資料
型別 ，提供list，set，zset，hash等資料結構的儲存
3、使用底層模型不同 它們之間底層實現方式 以及與客戶端之間通訊的應用協議不一樣。 Redis直接自
己構建了VM 機制 ，因為一般的系統呼叫系統函式的話，會浪費一定的時間去移動和請求。
4、 value 值大小不同：Redis 最大可以達到 1gb；memcache 只有 1mb。
5、redis的速度比memcached快很多
6、Redis支援資料的備份，即master-slave模式的資料備份。
單執行緒的redis為什麼這麼快
1、純記憶體操作
2、單執行緒操作，避免了頻繁的上下文切換
3、採用了非阻塞I/O多路複用機制
redis的資料型別，以及每種資料型別的使用場景
回答：一共五種
1、String
這個其實沒啥好說的，最常規的set/get操作，value可以是String也可以是數字。一般做一些複雜的計
數功能的快取。
2、hash
這裡value存放的是結構化的物件，比較方便的就是操作其中的某個欄位。博主在做單點登入的時候，
就是用這種資料結構儲存使用者資訊，以cookieId作為key，設定30分鐘為快取過期時間，能很好的模擬
出類似session的效果。
3、list
使用List的資料結構，可以做簡單的訊息佇列的功能。另外還有一個就是，可以利用lrange命令，做基
於redis的分頁功能，效能極佳，使用者體驗好。本人還用一個場景，很合適—取行情資訊。就也是個生產者和消費者的場景。LIST可以很好的完成排隊，先進先出的原則。
4、set
因為set堆放的是一堆不重複值的集合。所以可以做全域性去重的功能。為什麼不用JVM自帶的Set進行去
重？因為我們的系統一般都是叢集部署，使用JVM自帶的Set，比較麻煩，難道為了一個做一個全域性去
重，再起一個公共服務，太麻煩了。
另外，就是利用交集、並集、差集等操作，可以計算共同喜好，全部的喜好，自己獨有的喜好等功能。
5、sorted set
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(不刪除) 基本上一致。
Redis 為什麼是單執行緒的
官方FAQ表示，因為Redis是基於記憶體的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器記憶體的大小或者網路頻寬。既然單執行緒容易實現，而且CPU不會成為瓶頸，那就順理成章地採用單執行緒的方案了（畢竟採用多執行緒會有很多麻煩！）Redis利用佇列技術將併發訪問變為序列訪問
1、絕大部分請求是純粹的記憶體操作（非常快速）
2、採用單執行緒,避免了不必要的上下文切換和競爭條件
3、非阻塞IO優點：
（1）速度快，因為資料存在記憶體中，類似於HashMap，HashMap的優勢就是查詢和操作的時間複雜度都是O(1)
（2）支援豐富資料型別，支援string，list，set，sorted set，hash
（3）支援事務，操作都是原子性，所謂的原子性就是對資料的更改要麼全部執行，要麼全部不執行
（4）豐富的特性：可用於快取，訊息，按key設定過期時間，過期後將會自動刪除如何解決redis的併發競爭key問題
同時有多個子系統去set一個key。這個時候要注意什麼呢？ 不推薦使用redis的事務機制。因為我們的生產環境，基本都是redis叢集環境，做了資料分片操作。你一個事務中有涉及到多個key操作的時候，這多個key不一定都儲存在同一個redis-server上。因此，redis的事務機制，十分雞肋。
(1)如果對這個key操作，不要求順序： 準備一個分散式鎖，大家去搶鎖，搶到鎖就做set操作即可作了。以此類推。
(2) 利用佇列，將set方法變成序列訪問也可以redis遇到高併發，如果保證讀寫key的一致性對redis的操作都是具有原子性的,是執行緒安全的操作,你不用考慮併發問題,redis內部已經幫你處理好併發的問題了。
Redis 常見效能問題和解決方案？
1、Master 最好不要做任何持久化工作，如 RDB 記憶體快照和 AOF 日誌檔案
2、 如果資料比較重要，某個 Slave 開啟 AOF 備份資料，策略設定為每秒同步一次
3、為了主從複製的速度和連線的穩定性， Master 和 Slave 最好在同一個區域網內
4、儘量避免在壓力很大的主庫上增加從庫
5、主從複製不要用圖狀結構，用單向連結串列結構更為穩定，即： Master <- Slave1 <- Slave2 <-Slave3…
為什麼Redis的操作是原子性的，怎麼保證原子性的？
對於Redis而言，命令的原子性指的是：一個操作的不可以再分，操作要麼執行，要麼不執行。
Redis的操作之所以是原子性的，是因為Redis是單執行緒的。
Redis本身提供的所有API都是原子操作，Redis中的事務其實是要保證批量操作的原子性。
多個命令在併發中也是原子性的嗎？
不一定， 將get和set改成單命令操作，incr 。使用Redis的事務，或者使用Redis+Lua==的方式實現.
Redis事務
Redis事務功能是通過MULTI、EXEC、DISCARD和WATCH 四個原語實現的
Redis會將一個事務中的所有命令序列化，然後按順序執行。
1、redis 不支援回滾“Redis 在事務失敗時不進行回滾，而是繼續執行餘下的命令”， 所以 Redis 的內部可
以保持簡單且快速。
2、如果在一個事務中的命令出現錯誤，那麼所有的命令都不會執行；
3、如果在一個事務中出現執行錯誤，那麼正確的命令會被執行。
（1）MULTI命令用於開啟一個事務，它總是返回OK。 MULTI執行之後，客戶端可以繼續向伺服器傳送任意多條命令，這些命令不會立即被執行，而是被放到一個佇列中，當EXEC命令被呼叫時，所有佇列中的命令才會被執行。
（2）EXEC：執行所有事務塊內的命令。返回事務塊內所有命令的返回值，按命令執行的先後順序排列。當操作被打斷時，返回空值 nil 。
（3）通過呼叫DISCARD，客戶端可以清空事務佇列，並放棄執行事務， 並且客戶端會從事務狀態中退出。
（4）WATCH 命令可以為 Redis 事務提供 check-and-set （CAS）行為。 可以監控一個或多個鍵，一旦其中有一個鍵被修改（或刪除），之後的事務就不會執行，監控一直持續到EXEC命令。
歡迎關注公眾號：程式設計師追風，回覆66 ，領取一份300頁pdf文件的Java核心知識點總結！
這些資料的內容都是面試時面試官必問的知識點，篇章包括了很多知識點，其中包括了有基礎知識、Java集合、JVM、多執行緒併發、spring原理、微服務、Netty 與RPC 、Kafka、日記、設計模式、Java演算法、資料庫、Zookeeper、分散式快取、資料結構等等。
最後
歡迎大家一起交流，喜歡文章記得關注我點個贊喲，感謝支援！