簡介：以上文章講述的是【數據庫性能調優知識與面試知識（詳解四服務器性能剖析）】接下來我總結一下【Redis入門知識點】。覺得我還可以的可以加群一起督促學習探討技術。QQ群：1076570504 個人學習資料庫http://www.aolanghs.com/ 微信公眾號搜索【歡少的成長之路】

• Redis是什么？為什么選擇Redis？
• 與Redis類似的系統有哪些？挑選一個你比較熟悉的簡單講解一下？
• Redis的五大數據類型應用場景都是什么？
• 以上講述了五大類型，Java里完全也可以實現，為什么非要用Redis來替代呢？
• 一直往Redis里加數據，不會溢出嗎？它又是怎么刪除的呢？
• Redis與數據庫作交互，例如MySQL，它有事務，Redis有事務嗎？跟MySQL事務有什么區別？
• 提到Redis很多文章會提壓縮表與跳躍表，這兩個又是什么東東？
• 講述一下Redis的內存淘汰機制？
• 內存打滿或者電腦癱瘓如何保證數據的有效性？
• 應用場景中你遇到過哪些問題呢？ 這些你又是怎么解決的？
• Redis集群有哪幾種模式？可以簡單介紹一下嗎？
• Redis如何解決并發的？
• Redis用在分布式的話又會遇到哪些問題呢？

TIP： 通過這篇文章你能學習到這些知識！想了解的繼續深入，不想了解的趕緊離開，我不想浪費你們的學習時間。找準自己的定位與目標，堅持下去，并且一定要高效。我跟你們一樣非常抵制垃圾文章，雷同文章，胡說八道的文章。

很多人會問，學底層多浪費時間，搞好實現功能不就好了嗎？

可以這樣想一下到了一定的工作年限技術的廣度深度都有一定的造詣了，你寫代碼就這樣了沒辦法優化了，機器配置也是最好的了，那還能優化啥？? 底層，我們都知道所有語言到最后要運行都是變成機器語言的，最后歸根究底都是要去跟機器交互的，那計算機的底層是不是最后還是要關注的東西了！

Redis

Redis是什么？

Redis相當于是一個內存數據庫，說到數據庫，傳統的數據庫都是存在硬盤中，redis的特點是存在內存中，所以讀寫速度非常的快，因此redis主要用于緩存業務。redis支持事務，持久化以及多種集群方案。

Tip：redis不負責編碼工作，put進行什么類型的值，get出去的時候也就是什么類型的值。之間是有一個二進制安全的

為什么選擇Redis？

我們要根據它的特點來論述。高并發，高性能！

我們先從高性能簡單介紹一下，因為是在內存中操作所以它的讀寫能力非常的快，它可以比其他在磁盤上操作數據庫有更高的速度與性能。

高并發主要體現在直接操作內存比操作數據庫的磁盤有著更高的效率與性能，所以它在接受請求的時候往往可以承受更高的并發量。從磁盤讀寫數據都是有磁盤IO的，而內存的話就不需要這一點！

Memcached是什么？區別在哪？

memcached是一套分布式的快取系統，跟redis類似，和redis的區別如下。這里不過多介紹了，今天的主題是redis。

區別

redis支持五大數據類型，Memcached支持的數據類型極少一定程度上根本完成不了業務需求

redis支持事務

memcached沒有原生的集群模式，需要用戶單獨編寫。redis是支持原生cluster模式。

Memcached是多線程，非阻塞IO復用的網絡模型；Redis使用單線程的多路 IO 復用模型。

應用場景

Redis的五大數據類型應用場景都是什么？

hash：因為它的映射關系的特性，特別適合存一些存儲對象。比如用戶詳情，商品詳情，訂單詳情等。

string：是簡單的key-value結構，value不僅可以是string類型也可以是數字，比如生活中常見的關注數，粉絲數等等。

list：是一個鏈表，有序的可重復存儲。它的應用場景非常的多，比如關注列表，分析列表，消息列表，高性能分頁（下拉數據一直不斷刷新的那種）等。這里需要著重強調一下list有單鏈表以及雙鏈表。這里的redis list實現的是雙向鏈表，所以可以支持反向查詢和遍歷。

set：無序的，不支持重復存儲。主要通過交并差集操作實現一些類似于微博的共同好友，共同粉絲，隨機事件，抽獎，選名等功能。

sorted set：比set增加了一個權重閾值。也就是參照的意思，第一新增了score分值，rank排名。主要用于一些直播系統中的實時排名信息。包括在線用戶列表，禮物排行列表，彈幕消息列表等功能。

Java里完全也可以實現，為什么非要用Redis來替代呢？

輕量級！

數據放入的是Redis不在本地CPU，所以不會影響當前的程序。如果放在本地數據量到了一定級別的時候有可能數據量已經消耗完了CPU的內存，會超過本地CPU溢出，所以分離了占用的位置。

過期策略

Redis過期是什么

redis可以自己手動設置一些值的過期時間，在我們set一個值的時候都可以規定這個值什么時候過期，這點的好處是極大的提高了數據的可用性。比如我們的短信驗證碼，token登錄信息等功能

Redis的數據是按照什么刪除的？

redis數據的刪除主要分兩種。第一種是定期刪除，第二種是惰性刪除。

顧名思義。

定期刪除就是每隔一段時間定期遍歷數據采用隨機刪除的思想（如果不采用隨機刪除的話那么大的數據量是非常影響性能的）。這樣的話極大的影響了CPU的性能。

惰性刪除是指在定期刪除的基礎上因為采用隨機刪除的關系所以會導致一部分數據經過定期刪除后依然沒有被刪除，所以就有了惰性刪除。假如你的過期key通過定期刪除沒有被刪除，那么惰性刪除要做的就是，客戶端如果再一次訪問這個過期的key，或者系統去查一下這個key才會被redis刪除。這就是所謂的惰性刪除。

如果定期刪除漏掉了很多過期 key，然后你也沒及時去查， 也就沒走惰性刪除，此時會怎么樣？如果大量過期key堆積在內存里，導致redis內存塊耗盡了。怎么解決這個問題 呢？redis 內存淘汰機制展開了。

內存淘汰機制

Redis的數據淘汰策略（暫時簡單介紹吧后續會出一份Redis底層實現的文章）

volatile-lru：從已設置過期時間的數據集中挑選最近最少使用的數據淘汰

volatile-ttl：從已設置過期時間的數據集中挑選將要過期的數據淘汰

volatile-random：從已設置過期時間的數據集中任意選擇數據淘汰

allkeys-lru：當內存不足以容納新寫入數據時，在鍵空間中，移除最近最少使用的key（這個是最常用的）.

allkeys-random：從數據集中任意選擇數據淘汰

no-eviction：禁止驅逐數據，也就是說當內存不足以容納新寫入數據時，新寫入操作會報錯。（這個應該沒人使用吧！）

事務

概念

Redis 事務的本質是一組命令的集合。事務支持一次執行多個命令，一個事務中所有命令都會被序列化。在事務執行過程，會按照順序串行化執行隊列中的命令，其他客戶端提交的命令請求不會插入到事務執行命令序列中。

總結說：redis事務就是一次性、順序性、排他性的執行一個隊列中的一系列命令

Redis事務沒有隔離級別的概念

批量操作在發送 EXEC 命令前被放入隊列緩存，并不會被實際執行，也就不存在事務內的查詢要看到事務里的更新，事務外查詢不能看到

Redis不保證原子性

Redis中，單條命令是原子性執行的，但事務不保證原子性，且沒有回滾。事務中任意命令執行失敗，其余的命令仍會被執行

Redis事務的三個階段

• 開始事務
• 命令入隊
• 執行事務

Redis事務命令操作（本篇文章介紹大概的知識點，比如常用命令自己搜watch，exec命令找案例，不過多介紹了）

• watch key1 key2 … : 監視一或多個key,如果在事務執行之前，被監視的key被其他命令改動，則事務被打斷 （ 類似樂觀鎖 ）
• multi : 標記一個事務塊的開始（ queued ）
• exec : 執行所有事務塊的命令 （ 一旦執行exec后，之前加的監控鎖都會被取消掉 ）
• discard : 取消事務，放棄事務塊中的所有命令
• unwatch : 取消watch對所有key的監控

壓縮表與跳躍表

壓縮表與跳躍表之間的關系就是 單個元素過于龐大時，轉換為跳躍表。簡單來說，也就是犧牲空間換速度的一種方案。任何一種便捷的技術都會有弊端的！

持久性

概念

持久化就是把內存的數據寫到磁盤中去，防止服務宕機了內存數據丟失。Redis 提供了兩種持久化方式:RDB（默認） 和AOF

RDB

RDB也就是快照，快照的作用就是在Redis崩掉的時候起到了恢復的作用。快照是保存當前某一個時間點范圍的數據，每個小時保存一次。 例如9點整開啟一次快照，在9點59的時候系統崩掉了。那么就損失了59分鐘的數據。這種的弊端是性能挺好，就是丟失的數據比較多一些。

AOF

AOF是追加文件的方式。AOF實時性更好。這種方式默認是不開啟的。AOF是實時的，所以就算丟失數據頂多只會丟失一秒的數據

持久性的方案

首先利用RDB快照進行整點恢復。然后再利用AOF進行剩余部分的實時恢復。RDB的恢復速度非常快，AOF恢復速度雖然慢一點但是恢復的數據量不大因為最多只會恢復一個小時內的數據量。

還是舉以上的例子：9點鐘利用RDB進行了一次快照保存數據，9點59分的時候來了一個原子彈把服務器炸成灰了。持久化的方案就是利用RDB快照恢復了大部分的數據，但是丟失了59分鐘的數據，因為RDB是一個小時執行一次快照所以RDB解決不了。利用AOF恢復剩下的59分的數據不需要利用AOF恢復整體的數據了。

常見問題

• 緩存穿透
• 緩存雪崩
• 緩存預熱
• 緩存降級

緩存穿透以及解決方案

緩存穿透：一般訪問緩存的流程，如果緩存中存在查詢的商品數據，那么直接返回。 如果緩存中不存在商品數據，就要訪問數據庫。由于不恰當的業務功能實現，或者外部惡意攻擊不斷地請求某些不存在的數據內存，由于緩存中沒有保存該數據，導致所有的請求都會落到數據庫上，對數據庫可能帶來一定的壓力，甚至崩潰。

解決方案：

針對緩存穿透的情況， 簡單的對策就是將不存在的數據訪問結果， 也存儲到緩存中，避免緩存訪問的穿透。最終不存在商品數據的訪問結果也緩存下來。有效的避免緩存穿透的風險

緩存雪崩以及解決方案

緩存雪崩：

當緩存重啟或者大量的緩存在某一時間段失效，這樣就導致大批流量直接訪問數據庫，對 DB 造成壓力， 從而引起 DB 故障，系統崩潰。

舉例來說， 我們在準備一項搶購的促銷運營活動，活動期間將帶來大量的商品信息、庫存等相關信息的查詢。 為了避免商品數據庫的壓力，將商品數據放入緩存中存儲。 不巧的是，搶購活動期間，大量的熱門商品緩存同時失效過期了，導致很大的查詢流量落到了數據庫之上。對于數據庫來說造成很大的壓力。

解決方案：

將商品根據品類熱度分類， 購買比較多的類目商品緩存周期長一些， 購買相對冷門的類目
商品，緩存周期短一些；

在設置商品具體的緩存生效時間的時候， 加上一個隨機的區間因子， 比如說 5~10 分鐘
之間來隨意選擇失效時間；

提前預估 DB 能力， 如果緩存掛掉，數據庫仍可以在一定程度上抗住流量的壓力

這三個策略能夠有效的避免短時間內，大批量的緩存失效的問題

緩存預熱以及解決方案

緩存預熱就是系統上線后，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據庫，然后再將數據緩存的問題。用戶直接查詢事先被預熱的緩存數據。如果不進行預熱， 那么 Redis 初識狀態數據為空，系統上線初期，對于高并發的流量，都會訪問到數據庫中， 對數據庫造成流量的壓力。如圖所示：

解決方案：

數據量不大的時候，工程啟動的時候進行加載緩存動作；

數據量大的時候，設置一個定時任務腳本，進行緩存的刷新；

數據量太大的時候，優先保證熱點數據進行提前加載到緩存

緩存降級以及解決方案

降級的情況，就是緩存失效或者緩存服務掛掉的情況下，我們也不去訪問數據庫。我們直接訪問內存部分數據緩存或者直接返回默認數據。舉例來說：對于應用的首頁，一般是訪問量非常大的地方，首頁里面往往包含了部分推薦商品的展示信息。這些推薦商品都會放到緩存中進行存儲，同時我們為了避免緩存的異常情況，對熱點商品數據也存儲到了內存中。同時內存中還保留了一些默認的商品信息。

降級一般是有損的操作，所以盡量減少降級對于業務的影響程度。

集群

作為緩存數據庫，肯定要考慮緩存服務穩定性相關的保障機制

持久化機制就是保證系統崩潰的一個機制

內存淘汰機制就是保證系統內數據是否一直有效的一個機制

那么如果單機數據直接掛掉，電腦炸成渣了怎么辦？怎么保證數據的備份呢？ 單點故障！延伸了集群！

Redis集群模式一共有三種

• 主從模式
• 哨兵模式
• cluster模式

解釋一下：

單機模式下如果數據被炸毀，也就是出現了單點故障，可以利用主從復制方式，進行多臺redis數據的全量同步。主從復制集群主要有三種分別是強一致性，弱一致性，最終一致性。強一致性可以保證redis1與redis2數據保證同步，但是真實的場景中往往影響性能。redis3與redis4無法保證數據必須一致，不出意外的話這種方式既可以解決主從復制也可以解決性能的問題所以這種方式是默認的。redis5與redis6利用黑盒最終一致性。

主從復制

顧名思義，Redis服務器分為兩類也就是主服務器(Master)與從數據庫(Slave)。這是為了避免單點故障的數據丟失引出的一個方案。通常的做法就是一臺服務器的數據復制多個副本以部署在不同的服務器上。即使有一臺服務器崩掉了也不至于癱瘓整個服務，另外幾臺服務器依然可以為系統提供服務。

Redis 提供了復制功能。可以實現當一臺數據庫中的數據更新后，自動將更新的數據同步到其他數據庫上。

優點

一個主，可以有多個從，并以非阻塞的方式完成數據同步；

從服務器提供讀服務，分散主服務的壓力，實現讀寫分離；

從服務器之前可以彼此連接和同步請求，減少主服務同步壓力。

缺點

不具備容錯和恢復功能，主服務存在單點風險；

Redis 的主從復制采用全量復制，需要服務器有足夠的空余內存；

主從模式較難支持在線擴容

哨兵模式

Redis 提供的 sentinel（哨兵）機制，通過 sentinel (哨兵)模式啟動redis后，自動監控 主Master/從Slave的運行狀態，基本原理是：心跳機制 + 投票裁決。

簡單來說，哨兵的作用就是監控 Redis 系統的運行狀況。它的功能包括以下兩個：

監控主數據庫和從數據庫是否正常運行；

主數據庫出現故障時自動將從數據庫轉換為主數據庫。

哨兵模式主要有下面幾個內容：

監控（ Monitoring ）：Sentinel 會定期檢查主從服務器是否處于正常工作狀態。

提醒（ Notification ）：當被監控的某個 Redis 服務器出現異常時，Sentinel 可以通過API 向管理員或者其他應用程序發送通知。

自動故障遷移（Automatic failover）：當一個主服務器不能正常工作時，Sentinel 會開始一次自動故障遷移操作，它會將失效主服務器的其中一個從服務器升級為新的主服務器，并讓失效主服務器的其他從服務器改為復制新的主服務器；當客戶端試圖連接失效的主服務器時，集群也會向客戶端返回新主服務器的地址， 使得集群可以使用新主服務器代替失效服務器。

Redis Sentinel 是一個分布式系統，你可以在一個架構中運行多個 Sentinel （哨兵）進程（ progress ）

優點

哨兵模式主從可以切換，具備基本的故障轉移能力；

哨兵模式具備主從模式的所有優點。

缺點

哨兵模式也很難支持在線擴容操作；

集群的配置信息管理比較復雜

cluster模式

Redis Cluster 是一種服務器 Sharding 技術，采用無中心結構，每個節點保存數據和整個集群狀態,每個節點都和其他所有節點連接。

Cluster 集群結構特點：

Redis Cluster 所有的物理節點都映射到 [ 0-16383 ] slot 上（不一定均勻分布），Cluster
負責維護節點、桶、值之間的關系；

在 Redis 集群中放置一個 key-value 時，根據 CRC16(key) mod 16384 的值，從之前
劃分的 16384 個桶中選擇一個；

所有的 Redis 節點彼此互聯（PING-PONG 機制），內部使用二進制協議優化傳輸效率；

超過半數的節點檢測到某個節點失效時則判定該節點失效；

使用端與 Redis 節點鏈接,不需要中間 proxy 層，直接可以操作，使用端不需要連接集群
所有節點，連接集群中任何一個可用節點即可。

優點

無中心架構，節點間數據共享，可動態調整數據分布；

節點可動態添加刪除，擴展性比較靈活；

部分節點異常，不影響整體集群的可用性。

缺點

集群實現比較復雜；

批量操作指令（ mget、mset 等）支持有限；

事務操作支持有限

如何解決并發？

多實例的方式

分布式的話又會遇到哪些問題呢？

redis分布式并發競爭key的問題

所謂 Redis 的并發競爭 Key 的問題也就是多個系統同時對一個 key 進行操作，但是最后執行的順序和我們期望的順序不同，這樣也就導致了結果的不同！

推薦一種方案：分布式鎖（zookeeper 和 redis 都可以實現分布式鎖）。（如果不存在 Redis的并發競爭 Key 問題，不要使用分布式鎖，這樣會影響性能）

基于zookeeper臨時有序節點可以實現的分布式鎖。大致思想為：每個客戶端對某個方法加鎖時，在zookeeper上的與該方法對應的指定節點的目錄下，生成一個唯一的瞬時有序節點。判斷是否獲取鎖的方式很簡單，只需要判斷有序節點中序號最小的一個。當釋放鎖的時候，只需將這個瞬時節點刪除即可。同時，其可以避免服務宕機導致的鎖無法釋放，而產生的死鎖問題。完成業務流程后，刪除對應的子節點釋放鎖。在實踐中，當然是從以可靠性為主。所以首推Zookeeper。參考：https://www.jianshu.com/p/8bddd381de06

如何保證緩存與數據庫雙寫時的數據一致性？

你只要用緩存，就可能會涉及到緩存與數據庫雙存儲雙寫，你只要是雙寫，就一定會有數據一致性的問題，那么你如 何解決一致性問題？

一般來說，就是如果你的系統不是嚴格要求緩存+數據庫必須一致性的話，緩存可以稍微的跟數據庫偶爾有不一致的 情況，最好不要做這個方案，讀請求和寫請求串行化，串到一個內存隊列里去，這樣就可以保證一定不會出現不一致 的情況串行化之后，就會導致系統的吞吐量會大幅度的降低，用比正常情況下多幾倍的機器去支撐線上的一個請求。參考https://zhuanlan.zhihu.com/p/63428500

這篇文章的描述是跟馬士兵教育視頻，敖丙，DeepInThought，問天 學習之后自己優化升級的！感謝這幾位大佬！

知道的越多，不知道的就越多。找準方向，堅持自己的定位！加油向前不斷前行，終會有柳暗花明的一天！
創作不易，你們的支持就是對我最大認可！
文章將持續更新，我們下期見！【下期將更新SpringCloud入門 QQ群：1076570504 微信公眾號搜索【歡少的成長之路】請多多支持！

總結

以上是生活随笔為你收集整理的Redis你能跟面试官聊哪些？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。