Redis詳解高清腦圖：
（點選圖片，放大檢視）

腦圖中連結資源：

Redis Hash資料型別示意圖：

Redis常見面試題及參考回答：

一、 什麼是Redis？
Redis是一個高效能的Key-Value資料庫，是非關係型資料庫。
Redis中 資料存放在記憶體中，存寫速度特別快，所以redis廣泛應用於快取方向。另外rdis也常用來做分散式鎖。
Redis支援多種資料型別，String、Hash、list、set、zset 。
Redis還支援 持久化、叢集、事務等。

二、為什麼要使用Redis？（為什麼要使用快取？）
1. 高效能：

假如使用者第一次訪問資料庫中的某些資料。這個過程會比較慢，因為是從硬碟上讀取的。將該使用者訪問的資料存在數 快取中，這樣下一次再訪問這些資料的時候就可以直接從快取中獲取了。操作快取就是直接操作記憶體，所以速度相當 快。如果資料庫中的對應資料改變的之後，同步改變快取中相應的資料即可！

2. 高併發：

直接操作快取能夠承受的請求是遠遠大於直接訪問資料庫的，所以我們可以考慮把資料庫中的部分資料轉移到快取中 去，這樣使用者的一部分請求會直接到快取這裡而不用經過資料庫。

三、 Redis這麼設定過期時間？過期後如何刪除？（①定期刪除 ②惰性刪除）
過期時間：Redis中有個設定時間過期的功能，即對儲存在 redis 資料庫中的值可以設定一個過期時間。作為一個快取資料庫， 這是非常實用的。如我們一般專案中的 token 或者一些登入資訊，尤其是簡訊驗證碼都是有時間限制的，按照傳統的資料庫處理方式，一般都是自己判斷過期，這樣會嚴重影響專案效能。

所以我們在 set key 的時候，可以給key一個 expire time，就是過期時間，通過過期時間我們可以指定這個 key 可以存活的 時間。存活時間到了，這個key就過期了。

刪除過期key: 兩種方式，1.定期刪除 2.惰性刪除

定期刪除：redis預設是每隔 100ms 就隨機抽取一些設定了過期時間的key，檢查其是否過期，如果過期就刪除。為什麼是隨機抽取？是因為：假設 redis 已經存了幾十萬個 key ，如果此時每隔100ms就遍歷所有的設定了過期時間的 key 的話，就會給 CPU 帶來很大的負載。
惰性刪除：因為定期刪除是隨機抽取，可能會導致很多過期 key 到了時間卻沒有被刪除掉。所以就有了惰性刪除。惰性刪除就是 假如過期 key，靠定期刪除沒有被刪除掉，還停留在記憶體裡，除非你的系統去查一下那個 key，才會被redis給刪除掉，所以稱為惰性刪除。
注意：僅通過設定過期時間是有問題的。如果定期刪除漏掉了很多過期 key，然後你也沒及時去查， 也就沒走惰性刪除，此時會怎麼樣？如果大量過期key堆積在記憶體裡，導致redis記憶體塊耗盡了。

解決的辦法是 Redis 的記憶體淘汰機制。

四、Redis的記憶體淘汰機制?（怎麼保證Redis中的資料都是熱點資料？）
Redis配置檔案中可以通過設定 maxmemory 來指定 Redis 最大記憶體限制，Redis 在啟動時會把資料載入到記憶體中，達到指定的最大記憶體後，Redis 會根據配置的 記憶體淘汰機制 淘汰掉相應的key。

Redis提供瞭如下淘汰機制：

預設淘汰機制是：no-eviction

五、Redis 快取雪崩問題是什麼? 怎麼解決？
快取雪崩：快取在同一時間內大面積的失效，所以，後面的請求都會落到資料庫上，造成資料庫短時間內承受大量請求而崩 掉

解決辦法：

事前：儘量保證整個 redis 叢集的高可用性，發現機器宕機儘快補上。選擇合適的記憶體淘汰策略。

事中：本地ehcache快取 + hystrix限流&降級，避免MySQL崩掉。

事後：利用 redis 持久化機制儲存的資料儘快恢復快取。

六、Redis 快取穿透問題是什麼? 怎麼解決？
快取穿透：大量去請求快取中不存在的資料，導致所有的請求都落到資料庫上，造成資料庫短時間內承受大量請求而崩掉。

解決辦法：

布隆過濾器：將所有可能存在的資料哈 希到一個足夠大的bitmap中，一個一定不存在的資料會被 這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓 力。
簡單粗暴的方法：如果一個查詢返回的資料為空（不管是資料不存在，還是系統故障），我們仍然把這個空結果進行快取，但它的過期時間會很短，最長不超過五分鐘。這樣就避免了資料庫的查詢，且對快取的影響小。
其他方法...

七、Redis 和 Memcached 的有什麼區別？
redis支援更豐富的資料型別（支援更復雜的應用場景）：Redis不僅僅支援簡單的k/v型別的資料，同時還提供 list，set，zset，hash等資料結構的儲存。

memcache支援簡單的資料型別，String。

Redis支援資料的持久化，可以將記憶體中的資料保持在磁碟中，重啟的時候可以再次載入進行使用,而 Memecache把資料全部存在記憶體之中。

叢集模式：memcached沒有原生的叢集模式，需要依靠客戶端來實現往叢集中分片寫入資料；但是 redis 目前 是原生支援 cluster 模式的.

Memcached是多執行緒，非阻塞IO複用的網路模型；Redis使用單執行緒的多路 IO 複用模型

八、 Redis的資料型別有哪些？它們的特點是什麼？以及它們使用場景?
（Redis的5種資料型別、特點及使用場景，腦圖上有，這裡不贅述了。）

九、 Redis 的事務？
在Redis中， 通過 MULTI、EXEC、WATCH 等命令來實現事務(transaction)功能。

事務提供了一種將多個命令請求打包，然後一次性、按順序地執行多個命令的機制，並且在事務執行期間，伺服器不會中斷事務而改去執行其他客戶端的命令 請求，它會將事務中的所有命令都執行完畢，然後才去處理其他客戶端的命令請求。

在傳統的關係式資料庫中，常常用 ACID 性質來檢驗事務功能的可靠性和安全性。在 Redis 中，事務總是具有原子性、一致性和隔離性，並且當 Redis 執行在某種特定的持久化模式下時，事務 也具有永續性。

十、 Redis 的併發競爭Key 的問題？
Redis併發競爭Key問題：多個系統同時對一個 key 進行操作，但是後執行的順序和我們期望的順序不同，這樣也就導致了結果的不同。

解決：使用分散式鎖。

為保證可靠性，一般選擇Zookeeper實現。

基於zookeeper臨時有序節點可以實現的分散式鎖。大概思路為：當每個客戶端對某個方法加鎖時，在zookeeper上的 與該方法對應的指定節點的目錄下，生成一個唯一的瞬時有序節點。 判斷是否獲取鎖的方式很簡單，只需要判斷有序節點中序號小的一個。 當釋放鎖的時候，只需將這個瞬時節點刪除即可。同時，其可以避免服務宕機導致的鎖 無法釋放，而產生的死鎖問題。完成業務流程後，刪除對應的子節點釋放鎖。

注意：若Redis不存在併發競爭Key問題，不要使用分散式鎖，因為會影響效能。

十一、Redis的快取 如何保證和 資料庫中的資料保持一致？

將 讀請求 和 寫請求 序列化，序列化到一個記憶體佇列中，這樣就可以保證一致性。

注意：除非特別必要，不要去讀寫序列化，因為會大幅降低系統的吞吐量，影響效能。

十二、Redis的持久化機制知道嗎？（既使得Redis關閉，不丟失資料，重啟後可以恢復資料。）
持久化：將記憶體中的資料寫入到硬盤裡面；這樣當系統重啟或者故障之後，可以恢復資料。

Redis支援兩種持久化方案：① 快照（snapshotting，RDB） ②只追加檔案（append-only file,AOF）

快照(RDB)：

Redis可以通過建立快照來獲得儲存在記憶體裡面的資料在某個時間點上的副本。Redis建立快照之後，可以對快照進行備份，可以將快照複製到其他伺服器從而建立具有相同資料的伺服器副本（Redis主從結構，主要用來提高Redis性 能），還可以將快照留在原地以便重啟伺服器的時候使用。
Redis預設採用 快照 持久化機制，在配置檔案之可配置相關屬性(save <seconds> <changes>)。

只追加檔案(AOF)：

每執行一條會更改Redis中的資料的命令，Redis就會將該命令寫入硬碟中的AOF檔案。

與快照相比，AOF實時性更好。

預設是關閉的，可以通過修改appendonly引數開啟。

然後Redis還提供三種不同的AOF持久化方案：

appendfsync always #每次有資料修改發生時都會寫入AOF檔案，嚴重降低Redis的速度
appendfsync everysec #每秒鐘同步一次，顯示地將多個寫命令同步到硬碟
appendfsync no #讓作業系統決定何時進行同步，不可控
一般為了兼顧資料和寫入效能，會選用 appendfsync everyse ，這樣Redis不僅效能幾乎沒有影響，而且即使系統崩潰了，最多隻會丟失一秒內的資料，並且當硬碟執行寫入操作繁忙時，Redis還會的放慢自己的速度以便適應硬碟的最大寫入速度。

( AOF檔案的 儲存位置和RDB檔案的位置相同，都是通過dir引數設定的，預設的檔名是appendonly.aof。)

注意：Redis關於持久化機制的優化——混合持久化

Redis 4.0之後， 開始支援 RDB 和 AOF 的混合持久化。

預設關閉，可以通過配置項 aof-use-rdb-preamble 開啟。

混合持久化優點：AOF 重寫的時候就直接把 RDB 的內容寫到 AOF 檔案開頭，可以結合 RDB 和 AOF 的優點, 快速載入同時避免丟失過多的資料。

混合持久化缺點： AOF 裡面的 RDB 部分是壓縮格式，而不是 AOF 格式，可讀性差。
————————————————
版權宣告：本文為CSDN博主「猿兄」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處連結及本宣告。
原文連結：https://blog.csdn.net/love_MyLY/article/details/104190830