前言
現在大家的工作生活基本已經是回歸正軌了，最近也是迎來了跳槽面試季，有些人已經拿到了一兩個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、分布式緩存、資料結構等等。
最後
歡迎大家一起交流，喜歡文章記得關注我點個贊喲，感謝支援！