本文的面試題如下：

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在失效的瞬間，持續的大併發就穿破快取，直接請求資料。

給一個我公司處理的案例：背景雙機拿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採用的是定期刪除+惰性刪除策略。

在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，客戶端可以清空事務佇列，並放棄執行事務， 並且客戶端會從事務狀態中退出。

Redis實現分散式鎖

Redis為單程序單執行緒模式，採用佇列模式將併發訪問變成序列訪問，且多客戶端對Redis的連線並不存在競爭關係Redis中可以使用SETNX命令實現分散式鎖。

將 key 的值設為 value ，當且僅當 key 不存在。若給定的 key 已經存在，則 SETNX 不做任何動作

解鎖：使用 del key 命令就能釋放鎖

解決死鎖：

連結：cnblogs.com/bainannan/p/14105761.html