來源：CSDN-_睶_
本文的面試題如下：
Redis 持久化機制緩存雪崩、緩存穿透、緩存預熱、緩存更新、緩存降級等問題熱點數據和冷數據是什麼Memcache與Redis的區別都有哪些？單線程的redis為什麼這麼快redis的數據類型，以及每種數據類型的使用場景，Redis 內部結構redis的過期策略以及內存淘汰機制【～】Redis 為什麼是單線程的，優點如何解決redis的並發競爭key問題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 （跳躍表） 跳表是一種實現起來很簡單，單層多指針的鍊表，它查找效率很高，堪比優化過的二叉平衡樹，且比平衡樹的實現，quicklistziplist 壓縮表 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…
往期面試題匯總：001期~150期匯總
講解下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 「當前系統時間+鎖持有的時間」組合的命令就可以實現。