Redis高頻40問

Redis連環40問，絕對夠全！

Redis是什麼？

Redis（Remote Dictionary Server）是一個使用 C 語言編寫的，高效能非關係型的鍵值對資料庫。與傳統資料庫不同的是，Redis 的資料是存在記憶體中的，所以讀寫速度非常快，被廣泛應用於快取方向。Redis可以將資料寫入磁碟中，保證了資料的安全不丟失，而且Redis的操作是原子性的。

Redis優缺點？

優點：

基於記憶體操作，記憶體讀寫速度快。
支援多種資料型別，包括String、Hash、List、Set、ZSet等。
支援持久化。Redis支援RDB和AOF兩種持久化機制，持久化功能可以有效地避免資料丟失問題。
支援事務。Redis的所有操作都是原子性的，同時Redis還支援對幾個操作合併後的原子性執行。
支援主從複製。主節點會自動將資料同步到從節點，可以進行讀寫分離。
Redis命令的處理是單執行緒的。Redis6.0引入了多執行緒，需要注意的是，多執行緒用於處理網路資料的讀寫和協議解析，Redis命令執行還是單執行緒的。

缺點：

對結構化查詢的支援比較差。
資料庫容量受到實體記憶體的限制，不適合用作海量資料的高效能讀寫，因此Redis適合的場景主要侷限在較小資料量的操作。
Redis 較難支援線上擴容，在叢集容量達到上限時線上擴容會變得很複雜。

Redis為什麼這麼快？

基於記憶體：Redis是使用記憶體儲存，沒有磁碟IO上的開銷。資料存在記憶體中，讀寫速度快。
IO多路複用模型：Redis 採用 IO 多路複用技術。Redis 使用單執行緒來輪詢描述符，將資料庫的操作都轉換成了事件，不在網路I/O上浪費過多的時間。
高效的資料結構：Redis 每種資料型別底層都做了最佳化，目的就是為了追求更快的速度。

本文已經收錄到Github倉庫，該倉庫包含計算機基礎、Java基礎、多執行緒、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分散式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~
Github地址：https://github.com/Tyson0314/Java-learning
如果訪問不了Github，可以訪問gitee地址。
gitee地址：https://gitee.com/tysondai/Java-learning

既然Redis那麼快，為什麼不用它做主資料庫，只用它做快取？

雖然Redis非常快，但它也有一些侷限性，不能完全替代主資料庫。有以下原因：

事務處理：Redis只支援簡單的事務處理，對於複雜的事務無能為力，比如跨多個鍵的事務處理。

資料持久化：Redis是記憶體資料庫，資料儲存在記憶體中，如果伺服器崩潰或斷電，資料可能丟失。雖然Redis提供了資料持久化機制，但有一些限制。

資料處理：Redis只支援一些簡單的資料結構，比如字串、列表、雜湊表等。如果需要處理複雜的資料結構，比如關係型資料庫中的表，那麼Redis可能不是一個好的選擇。

資料安全：Redis沒有提供像主資料庫那樣的安全機制，比如使用者認證、訪問控制等等。

因此，雖然Redis非常快，但它還有一些限制，不能完全替代主資料庫。所以，使用Redis作為快取是一種很好的方式，可以提高應用程式的效能，並減少資料庫的負載。

講講Redis的執行緒模型？

Redis基於Reactor模式開發了網路事件處理器，這個處理器被稱為檔案事件處理器。它的組成結構為4部分：多個套接字、IO多路複用程式、檔案事件分派器、事件處理器。因為檔案事件分派器佇列的消費是單執行緒的，所以Redis才叫單執行緒模型。

檔案事件處理器使用I/O多路複用（multiplexing）程式來同時監聽多個套接字，並根據套接字目前執行的任務來為套接字關聯不同的事件處理器。
當被監聽的套接字準備好執行連線accept、read、write、close等操作時，與操作相對應的檔案事件就會產生，這時檔案事件處理器就會呼叫套接字之前關聯好的事件處理器來處理這些事件。

雖然檔案事件處理器以單執行緒方式執行，但透過使用 I/O 多路複用程式來監聽多個套接字，檔案事件處理器既實現了高效能的網路通訊模型，又可以很好地與 redis 伺服器中其他同樣以單執行緒方式執行的模組進行對接，這保持了 Redis 內部單執行緒設計的簡單性。

Redis應用場景有哪些？

快取熱點資料，緩解資料庫的壓力。
利用 Redis 原子性的自增操作，可以實現計數器的功能，比如統計使用者點贊數、使用者訪問數等。
分散式鎖。在分散式場景下，無法使用單機環境下的鎖來對多個節點上的程式進行同步。可以使用 Redis 自帶的 SETNX 命令實現分散式鎖，除此之外，還可以使用官方提供的 RedLock 分散式鎖實現。
簡單的訊息佇列，可以使用Redis自身的釋出/訂閱模式或者List來實現簡單的訊息佇列，實現非同步操作。
限速器，可用於限制某個使用者訪問某個介面的頻率，比如秒殺場景用於防止使用者快速點選帶來不必要的壓力。
好友關係，利用集合的一些命令，比如交集、並集、差集等，實現共同好友、共同愛好之類的功能。

最全面的Java面試網站

Memcached和Redis的區別？

MemCached 資料結構單一，僅用來快取資料，而 Redis 支援多種資料型別。
MemCached 不支援資料持久化，重啟後資料會消失。Redis 支援資料持久化。
Redis 提供主從同步機制和 cluster 叢集部署能力，能夠提供高可用服務。Memcached 沒有提供原生的叢集模式，需要依靠客戶端實現往叢集中分片寫入資料。
Redis 的速度比 Memcached 快很多。
Redis 使用單執行緒的多路 IO 複用模型，Memcached使用多執行緒的非阻塞 IO 模型。（Redis6.0引入了多執行緒IO，用來處理網路資料的讀寫和協議解析，但是命令的執行仍然是單執行緒）
value 值大小不同：Redis 最大可以達到 512M；memcache 只有 1mb。

為什麼要用 Redis 而不用 map/guava 做快取?

使用自帶的 map 或者 guava 實現的是本地快取，最主要的特點是輕量以及快速，生命週期隨著 jvm 的銷燬而結束，並且在多例項的情況下，每個例項都需要各自儲存一份快取，快取不具有一致性。

使用 redis 或 memcached 之類的稱為分散式快取，在多例項的情況下，各例項共用一份快取資料，快取具有一致性。

Redis 資料型別有哪些？

基本資料型別：

1、String：最常用的一種資料型別，String型別的值可以是字串、數字或者二進位制，但值最大不能超過512MB。

2、Hash：Hash 是一個鍵值對集合。

3、Set：無序去重的集合。Set 提供了交集、並集等方法，對於實現共同好友、共同關注等功能特別方便。

4、List：有序可重複的集合，底層是依賴雙向連結串列實現的。

5、SortedSet：有序Set。內部維護了一個score的引數來實現。適用於排行榜和帶權重的訊息佇列等場景。

特殊的資料型別：

1、Bitmap：點陣圖，可以認為是一個以位為單位陣列，陣列中的每個單元只能存0或者1，陣列的下標在 Bitmap 中叫做偏移量。Bitmap的長度與集合中元素個數無關，而是與基數的上限有關。

2、Hyperloglog。HyperLogLog 是用來做基數統計的演算法，其優點是，在輸入元素的數量或者體積非常非常大時，計算基數所需的空間總是固定的、並且是很小的。典型的使用場景是統計獨立訪客。

3、Geospatial ：主要用於儲存地理位置資訊，並對儲存的資訊進行操作，適用場景如定位、附近的人等。

SortedSet和List異同點？

相同點：

都是有序的；
都可以獲得某個範圍內的元素。

不同點：

列表基於連結串列實現，獲取兩端元素速度快，訪問中間元素速度慢；
有序集合基於雜湊表和跳躍表實現，訪問中間元素時間複雜度是OlogN；
列表不能簡單的調整某個元素的位置，有序列表可以（更改元素的分數）；
有序集合更耗記憶體。

Redis的記憶體用完了會怎樣？

如果達到設定的上限，Redis的寫命令會返回錯誤資訊（但是讀命令還可以正常返回）。

也可以配置記憶體淘汰機制，當Redis達到記憶體上限時會沖刷掉舊的內容。

Redis如何做記憶體最佳化？

可以好好利用Hash,list,sorted set,set等集合型別資料，因為通常情況下很多小的Key-Value可以用更緊湊的方式存放到一起。儘可能使用雜湊表（hashes），雜湊表（是說雜湊表裡面儲存的數少）使用的記憶體非常小，所以你應該儘可能的將你的資料模型抽象到一個雜湊表裡面。比如你的web系統中有一個使用者物件，不要為這個使用者的名稱，姓氏，郵箱，密碼設定單獨的key，而是應該把這個使用者的所有資訊儲存到一張雜湊表裡面。

keys命令存在的問題？

redis的單執行緒的。keys指令會導致執行緒阻塞一段時間，直到執行完畢，服務才能恢復。scan採用漸進式遍歷的方式來解決keys命令可能帶來的阻塞問題，每次scan命令的時間複雜度是O(1)，但是要真正實現keys的功能，需要執行多次scan。

scan的缺點：在scan的過程中如果有鍵的變化（增加、刪除、修改），遍歷過程可能會有以下問題：新增的鍵可能沒有遍歷到，遍歷出了重複的鍵等情況，也就是說scan並不能保證完整的遍歷出來所有的鍵。

Redis事務

事務的原理是將一個事務範圍內的若干命令傳送給Redis，然後再讓Redis依次執行這些命令。

事務的生命週期：

使用MULTI開啟一個事務
在開啟事務的時候，每次操作的命令將會被插入到一個佇列中，同時這個命令並不會被真的執行
EXEC命令進行提交事務

一個事務範圍內某個命令出錯不會影響其他命令的執行，不保證原子性：

127.0.0.1:6379> multi
OK
127.0.0.1:6379> set a 1
QUEUED
127.0.0.1:6379> set b 1 2
QUEUED
127.0.0.1:6379> set c 3
QUEUED
127.0.0.1:6379> exec
1) OK
2) (error) ERR syntax error
3) OK

WATCH命令

WATCH命令可以監控一個或多個鍵，一旦其中有一個鍵被修改，之後的事務就不會執行（類似於樂觀鎖）。執行EXEC命令之後，就會自動取消監控。

127.0.0.1:6379> watch name
OK
127.0.0.1:6379> set name 1
OK
127.0.0.1:6379> multi
OK
127.0.0.1:6379> set name 2
QUEUED
127.0.0.1:6379> set gender 1
QUEUED
127.0.0.1:6379> exec
(nil)
127.0.0.1:6379> get gender
(nil)

比如上面的程式碼中：

watch name開啟了對name這個key的監控
修改name的值
開啟事務a
在事務a中設定了name和gender的值
使用EXEC命令進提交事務
使用命令get gender發現不存在，即事務a沒有執行

使用UNWATCH可以取消WATCH命令對key的監控，所有監控鎖將會被取消。

Redis事務支援隔離性嗎？

Redis 是單程式程式，並且它保證在執行事務時，不會對事務進行中斷，事務可以執行直到執行完所有事務佇列中的命令為止。因此，Redis 的事務是總是帶有隔離性的。

Redis事務保證原子性嗎，支援回滾嗎？

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

持久化機制

持久化就是把記憶體的資料寫到磁碟中，防止服務當機導致記憶體資料丟失。

Redis支援兩種方式的持久化，一種是RDB的方式，一種是AOF的方式。前者會根據指定的規則定時將記憶體中的資料儲存在硬碟上，而後者在每次執行完命令後將命令記錄下來。一般將兩者結合使用。

RDB方式

RDB是 Redis 預設的持久化方案。RDB持久化時會將記憶體中的資料寫入到磁碟中，在指定目錄下生成一個dump.rdb檔案。Redis 重啟會載入dump.rdb檔案恢復資料。

bgsave是主流的觸發 RDB 持久化的方式，執行過程如下：

執行BGSAVE命令
Redis 父程式判斷當前是否存在正在執行的子程式，如果存在，BGSAVE命令直接返回。
父程式執行fork操作建立子程式，fork操作過程中父程式會阻塞。
父程式fork完成後，父程式繼續接收並處理客戶端的請求，而子程式開始將記憶體中的資料寫進硬碟的臨時檔案；
當子程式寫完所有資料後會用該臨時檔案替換舊的 RDB 檔案。

Redis啟動時會讀取RDB快照檔案，將資料從硬碟載入記憶體。透過 RDB 方式的持久化，一旦Redis異常退出，就會丟失最近一次持久化以後更改的資料。

觸發 RDB 持久化的方式：

手動觸發：使用者執行SAVE或BGSAVE命令。SAVE命令執行快照的過程會阻塞所有客戶端的請求，應避免在生產環境使用此命令。BGSAVE命令可以在後臺非同步進行快照操作，快照的同時伺服器還可以繼續響應客戶端的請求，因此需要手動執行快照時推薦使用BGSAVE命令。
被動觸發：
- 根據配置規則進行自動快照，如SAVE 100 10，100秒內至少有10個鍵被修改則進行快照。
- 如果從節點執行全量複製操作，主節點會自動執行BGSAVE生成 RDB 檔案併傳送給從節點。
- 預設情況下執行shutdown命令時，如果沒有開啟 AOF 持久化功能則自動執行·BGSAVE·。

優點：

Redis 載入 RDB 恢復資料遠遠快於 AOF 的方式。
使用單獨子程式來進行持久化，主程式不會進行任何 IO 操作，保證了 Redis 的高效能。

缺點：

RDB方式資料無法做到實時持久化。因為BGSAVE每次執行都要執行fork操作建立子程式，屬於重量級操作，頻繁執行成本比較高。
RDB 檔案使用特定二進位制格式儲存，Redis 版本升級過程中有多個格式的 RDB 版本，存在老版本 Redis 無法相容新版 RDB 格式的問題。

AOF方式

AOF（append only file）持久化：以獨立日誌的方式記錄每次寫命令，Redis重啟時會重新執行AOF檔案中的命令達到恢復資料的目的。AOF的主要作用是解決了資料持久化的實時性，AOF 是Redis持久化的主流方式。

預設情況下Redis沒有開啟AOF方式的持久化，可以透過appendonly引數啟用：appendonly yes。開啟AOF方式持久化後每執行一條寫命令，Redis就會將該命令寫進aof_buf緩衝區，AOF緩衝區根據對應的策略向硬碟做同步操作。

預設情況下系統每30秒會執行一次同步操作。為了防止緩衝區資料丟失，可以在Redis寫入AOF檔案後主動要求系統將緩衝區資料同步到硬碟上。可以透過appendfsync引數設定同步的時機。

appendfsync always //每次寫入aof檔案都會執行同步，最安全最慢，不建議配置
appendfsync everysec  //既保證效能也保證安全，建議配置
appendfsync no //由作業系統決定何時進行同步操作

接下來看一下 AOF 持久化執行流程：

所有的寫入命令會追加到 AOP 緩衝區中。
AOF 緩衝區根據對應的策略向硬碟同步。
隨著 AOF 檔案越來越大，需要定期對 AOF 檔案進行重寫，達到壓縮檔案體積的目的。AOF檔案重寫是把Redis程式內的資料轉化為寫命令同步到新AOF檔案的過程。
當 Redis 伺服器重啟時，可以載入 AOF 檔案進行資料恢復。

優點：

AOF可以更好的保護資料不丟失，可以配置 AOF 每秒執行一次fsync操作，如果Redis程式掛掉，最多丟失1秒的資料。
AOF以append-only的模式寫入，所以沒有磁碟定址的開銷，寫入效能非常高。

缺點：

對於同一份檔案AOF檔案比RDB資料快照要大。
資料恢復比較慢。

RDB和AOF如何選擇？

通常來說，應該同時使用兩種持久化方案，以保證資料安全。

如果資料不敏感，且可以從其他地方重新生成，可以關閉持久化。
如果資料比較重要，且能夠承受幾分鐘的資料丟失，比如快取等，只需要使用RDB即可。
如果是用做記憶體資料，要使用Redis的持久化，建議是RDB和AOF都開啟。
如果只用AOF，優先使用everysec的配置選擇，因為它在可靠性和效能之間取了一個平衡。

當RDB與AOF兩種方式都開啟時，Redis會優先使用AOF恢復資料，因為AOF儲存的檔案比RDB檔案更完整。

Redis有哪些部署方案？

單機版：單機部署，單機redis能夠承載的 QPS 大概就在上萬到幾萬不等。這種部署方式很少使用。存在的問題：1、記憶體容量有限 2、處理能力有限 3、無法高可用。

主從模式：一主多從，主負責寫，並且將資料複製到其它的 slave 節點，從節點負責讀。所有的讀請求全部走從節點。這樣也可以很輕鬆實現水平擴容，支撐讀高併發。master 節點掛掉後，需要手動指定新的 master，可用性不高，基本不用。

哨兵模式：主從複製存在不能自動故障轉移、達不到高可用的問題。哨兵模式解決了這些問題。透過哨兵機制可以自動切換主從節點。master 節點掛掉後，哨兵程式會主動選舉新的 master，可用性高，但是每個節點儲存的資料是一樣的，浪費記憶體空間。資料量不是很多，叢集規模不是很大，需要自動容錯容災的時候使用。

Redis cluster：服務端分片技術，3.0版本開始正式提供。Redis Cluster並沒有使用一致性hash，而是採用slot(槽)的概念，一共分成16384個槽。將請求傳送到任意節點，接收到請求的節點會將查詢請求傳送到正確的節點上執行。主要是針對海量資料+高併發+高可用的場景，如果是海量資料，如果你的資料量很大，那麼建議就用Redis cluster，所有主節點的容量總和就是Redis cluster可快取的資料容量。

主從架構

單機的 redis，能夠承載的 QPS 大概就在上萬到幾萬不等。對於快取來說，一般都是用來支撐讀高併發的。因此架構做成主從(master-slave)架構，一主多從，主負責寫，並且將資料複製到其它的 slave 節點，從節點負責讀。所有的讀請求全部走從節點。這樣也可以很輕鬆實現水平擴容，支撐讀高併發。

Redis的複製功能是支援多個資料庫之間的資料同步。主資料庫可以進行讀寫操作，當主資料庫的資料發生變化時會自動將資料同步到從資料庫。從資料庫一般是隻讀的，它會接收主資料庫同步過來的資料。一個主資料庫可以有多個從資料庫，而一個從資料庫只能有一個主資料庫。

主從複製的原理？

當啟動一個從節點時，它會傳送一個 PSYNC 命令給主節點；
如果是從節點初次連線到主節點，那麼會觸發一次全量複製。此時主節點會啟動一個後臺執行緒，開始生成一份 RDB 快照檔案；
同時還會將從客戶端 client 新收到的所有寫命令快取在記憶體中。RDB 檔案生成完畢後，主節點會將RDB檔案傳送給從節點，從節點會先將RDB檔案寫入本地磁碟，然後再從本地磁碟載入到記憶體中；
接著主節點會將記憶體中快取的寫命令傳送到從節點，從節點同步這些資料；
如果從節點跟主節點之間網路出現故障，連線斷開了，會自動重連，連線之後主節點僅會將部分缺失的資料同步給從節點。

哨兵Sentinel

主從複製存在不能自動故障轉移、達不到高可用的問題。哨兵模式解決了這些問題。透過哨兵機制可以自動切換主從節點。

客戶端連線Redis的時候，先連線哨兵，哨兵會告訴客戶端Redis主節點的地址，然後客戶端連線上Redis並進行後續的操作。當主節點當機的時候，哨兵監測到主節點當機，會重新推選出某個表現良好的從節點成為新的主節點，然後透過釋出訂閱模式通知其他的從伺服器，讓它們切換主機。

工作原理

每個Sentinel以每秒鐘一次的頻率向它所知道的Master，Slave以及其他 Sentinel 例項傳送一個 PING命令。
如果一個例項距離最後一次有效回覆 PING 命令的時間超過指定值，則這個例項會被 Sentine 標記為主觀下線。
如果一個Master被標記為主觀下線，則正在監視這個Master的所有 Sentinel 要以每秒一次的頻率確認Master是否真正進入主觀下線狀態。
當有足夠數量的 Sentinel（大於等於配置檔案指定值）在指定的時間範圍內確認Master的確進入了主觀下線狀態，則Master會被標記為客觀下線。若沒有足夠數量的 Sentinel 同意 Master 已經下線， Master 的客觀下線狀態就會被解除。若 Master重新向 Sentinel 的 PING 命令返回有效回覆， Master 的主觀下線狀態就會被移除。
哨兵節點會選舉出哨兵 leader，負責故障轉移的工作。
哨兵 leader 會推選出某個表現良好的從節點成為新的主節點，然後通知其他從節點更新主節點資訊。

Redis cluster

哨兵模式解決了主從複製不能自動故障轉移、達不到高可用的問題，但還是存在主節點的寫能力、容量受限於單機配置的問題。而cluster模式實現了Redis的分散式儲存，每個節點儲存不同的內容，解決主節點的寫能力、容量受限於單機配置的問題。

Redis cluster叢集節點最小配置6個節點以上（3主3從），其中主節點提供讀寫操作，從節點作為備用節點，不提供請求，只作為故障轉移使用。

Redis cluster採用虛擬槽分割槽，所有的鍵根據雜湊函式對映到0～16383個整數槽內，每個節點負責維護一部分槽以及槽所對映的鍵值資料。

工作原理：

透過雜湊的方式，將資料分片，每個節點均分儲存一定雜湊槽(雜湊值)區間的資料，預設分配了16384 個槽位
每份資料分片會儲存在多個互為主從的多節點上
資料寫入先寫主節點，再同步到從節點(支援配置為阻塞同步)
同一分片多個節點間的資料不保持一致性
讀取資料時，當客戶端操作的key沒有分配在該節點上時，redis會返回轉向指令，指向正確的節點
擴容時時需要需要把舊節點的資料遷移一部分到新節點

在 redis cluster 架構下，每個 redis 要放開兩個埠號，比如一個是 6379，另外一個就是加1w 的埠號，比如 16379。

16379 埠號是用來進行節點間通訊的，也就是 cluster bus 的東西，cluster bus 的通訊，用來進行故障檢測、配置更新、故障轉移授權。cluster bus 用了另外一種二進位制的協議，gossip 協議，用於節點間進行高效的資料交換，佔用更少的網路頻寬和處理時間。

優點：

無中心架構，支援動態擴容；
資料按照slot儲存分佈在多個節點，節點間資料共享，可動態調整資料分佈；
高可用性。部分節點不可用時，叢集仍可用。叢集模式能夠實現自動故障轉移（failover），節點之間透過gossip協議交換狀態資訊，用投票機制完成Slave到Master的角色轉換。

缺點：

不支援批次操作（pipeline）。
資料透過非同步複製，不保證資料的強一致性。
事務操作支援有限，只支援多key在同一節點上的事務操作，當多個key分佈於不同的節點上時無法使用事務功能。
key作為資料分割槽的最小粒度，不能將一個很大的鍵值物件如hash、list等對映到不同的節點。
不支援多資料庫空間，單機下的Redis可以支援到16個資料庫，叢集模式下只能使用1個資料庫空間。
只能使用0號資料庫。

雜湊分割槽演算法有哪些？

節點取餘分割槽。使用特定的資料，如Redis的鍵或使用者ID，對節點數量N取餘：hash（key）%N計算出雜湊值，用來決定資料對映到哪一個節點上。
優點是簡單性。擴容時通常採用翻倍擴容，避免資料對映全部被打亂導致全量遷移的情況。

一致性雜湊分割槽。為系統中每個節點分配一個token，範圍一般在0~232，這些token構成一個雜湊環。資料讀寫執行節點查詢操作時，先根據key計算hash值，然後順時針找到第一個大於等於該雜湊值的token節點。
這種方式相比節點取餘最大的好處在於加入和刪除節點隻影響雜湊環中相鄰的節點，對其他節點無影響。

虛擬槽分割槽，所有的鍵根據雜湊函式對映到0~16383整數槽內，計算公式：slot=CRC16（key）&16383。每一個節點負責維護一部分槽以及槽所對映的鍵值資料。Redis Cluser採用虛擬槽分割槽演算法。

過期鍵的刪除策略？

1、被動刪除。在訪問key時，如果發現key已經過期，那麼會將key刪除。

2、主動刪除。定時清理key，每次清理會依次遍歷所有DB，從db隨機取出20個key，如果過期就刪除，如果其中有5個key過期，那麼就繼續對這個db進行清理，否則開始清理下一個db。

3、記憶體不夠時清理。Redis有最大記憶體的限制，透過maxmemory引數可以設定最大記憶體，當使用的記憶體超過了設定的最大記憶體，就要進行記憶體釋放，在進行記憶體釋放的時候，會按照配置的淘汰策略清理記憶體。

記憶體淘汰策略有哪些？

當Redis的記憶體超過最大允許的記憶體之後，Redis 會觸發記憶體淘汰策略，刪除一些不常用的資料，以保證Redis伺服器正常執行。

Redisv4.0前提供 6 種資料淘汰策略：

volatile-lru：LRU（Least Recently Used），最近使用。利用LRU演算法移除設定了過期時間的key
allkeys-lru：當記憶體不足以容納新寫入資料時，從資料集中移除最近最少使用的key
volatile-ttl：從已設定過期時間的資料集中挑選將要過期的資料淘汰
volatile-random：從已設定過期時間的資料集中任意選擇資料淘汰
allkeys-random：從資料集中任意選擇資料淘汰
no-eviction：禁止刪除資料，當記憶體不足以容納新寫入資料時，新寫入操作會報錯

Redisv4.0後增加以下兩種：

volatile-lfu：LFU，Least Frequently Used，最少使用，從已設定過期時間的資料集中挑選最不經常使用的資料淘汰。
allkeys-lfu：當記憶體不足以容納新寫入資料時，從資料集中移除最不經常使用的key。

記憶體淘汰策略可以透過配置檔案來修改，相應的配置項是maxmemory-policy，預設配置是noeviction。

如何保證快取與資料庫雙寫時的資料一致性？

1、先刪除快取再更新資料庫

進行更新操作時，先刪除快取，然後更新資料庫，後續的請求再次讀取時，會從資料庫讀取後再將新資料更新到快取。

存在的問題：刪除快取資料之後，更新資料庫完成之前，這個時間段內如果有新的讀請求過來，就會從資料庫讀取舊資料重新寫到快取中，再次造成不一致，並且後續讀的都是舊資料。

2、先更新資料庫再刪除快取

進行更新操作時，先更新MySQL，成功之後，刪除快取，後續讀取請求時再將新資料回寫快取。

存在的問題：更新MySQL和刪除快取這段時間內，請求讀取的還是快取的舊資料，不過等資料庫更新完成，就會恢復一致，影響相對比較小。

3、非同步更新快取

資料庫的更新操作完成後不直接操作快取，而是把這個操作命令封裝成訊息扔到訊息佇列中，然後由Redis自己去消費更新資料，訊息佇列可以保證資料操作順序一致性，確保快取系統的資料正常。

以上幾個方案都不完美，需要根據業務需求，評估哪種方案影響較小，然後選擇相應的方案。

快取常見問題

快取穿透

快取穿透是指查詢一個不存在的資料，由於快取是不命中時被動寫的，如果從DB查不到資料則不寫入快取，這將導致這個不存在的資料每次請求都要到DB去查詢，失去了快取的意義。在流量大時，可能DB就掛掉了。

怎麼解決？

快取空值，不會查資料庫。
採用布隆過濾器，將所有可能存在的資料雜湊到一個足夠大的bitmap中，查詢不存在的資料會被這個bitmap攔截掉，從而避免了對DB的查詢壓力。

布隆過濾器的原理：當一個元素被加入集合時，透過K個雜湊函式將這個元素對映成一個位陣列中的K個點，把它們置為1。查詢時，將元素透過雜湊函式對映之後會得到k個點，如果這些點有任何一個0，則被檢元素一定不在，直接返回；如果都是1，則查詢元素很可能存在，就會去查詢Redis和資料庫。

布隆過濾器一般用於在大資料量的集合中判定某元素是否存在。

快取雪崩

快取雪崩是指在我們設定快取時採用了相同的過期時間，導致快取在某一時刻同時失效，請求全部轉發到DB，DB瞬時壓力過重掛掉。

解決方法：

在原有的失效時間基礎上增加一個隨機值，使得過期時間分散一些。這樣每一個快取的過期時間的重複率就會降低，就很難引發集體失效的事件。
加鎖排隊可以起到緩衝的作用，防止大量的請求同時運算元據庫，但它的缺點是增加了系統的響應時間，降低了系統的吞吐量，犧牲了一部分使用者體驗。當快取未查詢到時，對要請求的 key 進行加鎖，只允許一個執行緒去資料庫中查，其他執行緒等候排隊。
設定二級快取。二級快取指的是除了 Redis 本身的快取，再設定一層快取，當 Redis 失效之後，先去查詢二級快取。例如可以設定一個本地快取，在 Redis 快取失效的時候先去查詢本地快取而非查詢資料庫。

快取擊穿

快取擊穿：大量的請求同時查詢一個 key 時，此時這個 key 正好失效了，就會導致大量的請求都落到資料庫。快取擊穿是查詢快取中失效的 key，而快取穿透是查詢不存在的 key。

解決方法：

1、加互斥鎖。在併發的多個請求中，只有第一個請求執行緒能拿到鎖並執行資料庫查詢操作，其他的執行緒拿不到鎖就阻塞等著，等到第一個執行緒將資料寫入快取後，直接走快取。可以使用Redis分散式鎖實現，程式碼如下：

public String get(String key) {
    String value = redis.get(key);
    if (value == null) { //快取值過期
        String unique_key = systemId + ":" + key;
        //設定30s的超時
        if (redis.set(unique_key, 1, 'NX', 'PX', 30000) == 1) {  //設定成功
            value = db.get(key);
            redis.set(key, value, expire_secs);
            redis.del(unique_key);
        } else {  //其他執行緒已經到資料庫取值並回寫到快取了，可以重試獲取快取值
            sleep(50);
            get(key);  //重試
        }
    } else {
        return value;
    }
}

2、熱點資料不過期。直接將快取設定為不過期，然後由定時任務去非同步載入資料，更新快取。這種方式適用於比較極端的場景，例如流量特別特別大的場景，使用時需要考慮業務能接受資料不一致的時間，還有就是異常情況的處理，保證快取可以定時重新整理。

快取預熱

快取預熱就是系統上線後，將相關的快取資料直接載入到快取系統。這樣就可以避免在使用者請求的時候，先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！

解決方案：

直接寫個快取重新整理頁面，上線時手工操作一下；
資料量不大，可以在專案啟動的時候自動進行載入；
定時重新整理快取；

快取降級

當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的效能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵資料進行自動降級，也可以配置開關實現人工降級。

快取降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。

在進行降級之前要對系統進行梳理，看看系統是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；比如可以參考日誌級別設定預案：

一般：比如有些服務偶爾因為網路抖動或者服務正在上線而超時，可以自動降級；
警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，併傳送告警；
錯誤：比如可用率低於90%，或者資料庫連線池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；
嚴重錯誤：比如因為特殊原因資料錯誤了，此時需要緊急人工降級。

服務降級的目的，是為了防止Redis服務故障，導致資料庫跟著一起發生雪崩問題。因此，對於不重要的快取資料，可以採取服務降級策略，例如一個比較常見的做法就是，Redis出現問題，不去資料庫查詢，而是直接返回預設值給使用者。

Redis 怎麼實現訊息佇列？

使用list型別儲存資料資訊，rpush生產訊息，lpop消費訊息，當lpop沒有訊息時，可以sleep一段時間，然後再檢查有沒有資訊，如果不想sleep的話，可以使用blpop, 在沒有資訊的時候，會一直阻塞，直到資訊的到來。

BLPOP queue 0  //0表示不限制等待時間

BLPOP和LPOP命令相似，唯一的區別就是當列表沒有元素時BLPOP命令會一直阻塞連線，直到有新元素加入。

redis可以透過pub/sub主題訂閱模式實現一個生產者，多個消費者，當然也存在一定的缺點，當消費者下線時，生產的訊息會丟失。

PUBLISH channel1 hi
SUBSCRIBE channel1
UNSUBSCRIBE channel1 //退訂透過SUBSCRIBE命令訂閱的頻道。

PSUBSCRIBE channel?* 按照規則訂閱。
PUNSUBSCRIBE channel?* 退訂透過PSUBSCRIBE命令按照某種規則訂閱的頻道。其中訂閱規則要進行嚴格的字串匹配，PUNSUBSCRIBE *無法退訂channel?*規則。

Redis 怎麼實現延時佇列

使用sortedset，拿時間戳作為score，訊息內容作為key，呼叫zadd來生產訊息，消費者用zrangebyscore指令獲取N秒之前的資料輪詢進行處理。

pipeline的作用？

redis客戶端執行一條命令分4個過程：傳送命令、命令排隊、命令執行、返回結果。使用pipeline可以批次請求，批次返回結果，執行速度比逐條執行要快。

使用pipeline組裝的命令個數不能太多，不然資料量過大，增加客戶端的等待時間，還可能造成網路阻塞，可以將大量命令的拆分多個小的pipeline命令完成。

原生批命令（mset和mget）與pipeline對比：

原生批命令是原子性，pipeline是非原子性。pipeline命令中途異常退出，之前執行成功的命令不會回滾。
原生批命令只有一個命令，但pipeline支援多命令。

LUA指令碼

Redis 透過 LUA 指令碼建立具有原子性的命令：當lua指令碼命令正在執行的時候，不會有其他指令碼或 Redis 命令被執行，實現組合命令的原子操作。

在Redis中執行Lua指令碼有兩種方法：eval和evalsha。eval命令使用內建的 Lua 直譯器，對 Lua 指令碼進行求值。

//第一個引數是lua指令碼，第二個引數是鍵名引數個數，剩下的是鍵名引數和附加引數
> eval "return {KEYS[1],KEYS[2],ARGV[1],ARGV[2]}" 2 key1 key2 first second
1) "key1"
2) "key2"
3) "first"
4) "second"

lua指令碼作用

1、Lua指令碼在Redis中是原子執行的，執行過程中間不會插入其他命令。

2、Lua指令碼可以將多條命令一次性打包，有效地減少網路開銷。

應用場景

舉例：限制介面訪問頻率。

在Redis維護一個介面訪問次數的鍵值對，key是介面名稱，value是訪問次數。每次訪問介面時，會執行以下操作：

透過aop攔截介面的請求，對介面請求進行計數，每次進來一個請求，相應的介面訪問次數count加1，存入redis。
如果是第一次請求，則會設定count=1，並設定過期時間。因為這裡set()和expire()組合操作不是原子操作，所以引入lua指令碼，實現原子操作，避免併發訪問問題。
如果給定時間範圍內超過最大訪問次數，則會丟擲異常。

private String buildLuaScript() {
    return "local c" +
        "\nc = redis.call('get',KEYS[1])" +
        "\nif c and tonumber(c) > tonumber(ARGV[1]) then" +
        "\nreturn c;" +
        "\nend" +
        "\nc = redis.call('incr',KEYS[1])" +
        "\nif tonumber(c) == 1 then" +
        "\nredis.call('expire',KEYS[1],ARGV[2])" +
        "\nend" +
        "\nreturn c;";
}

String luaScript = buildLuaScript();
RedisScript<Number> redisScript = new DefaultRedisScript<>(luaScript, Number.class);
Number count = redisTemplate.execute(redisScript, keys, limit.count(), limit.period());

PS：這種介面限流的實現方式比較簡單，問題也比較多，一般不會使用，介面限流用的比較多的是令牌桶演算法和漏桶演算法。

什麼是RedLock？

Redis 官方站提出了一種權威的基於 Redis 實現分散式鎖的方式名叫 Redlock，此種方式比原先的單節點的方法更安全。它可以保證以下特性：

安全特性：互斥訪問，即永遠只有一個 client 能拿到鎖
避免死鎖：最終 client 都可能拿到鎖，不會出現死鎖的情況，即使原本鎖住某資源的 client 掛掉了
容錯性：只要大部分 Redis 節點存活就可以正常提供服務

Redis大key怎麼處理？

通常我們會將含有較大資料或含有大量成員、列表數的Key稱之為大Key。

以下是對各個資料型別大key的描述：

value是STRING型別，它的值超過5MB
value是ZSET、Hash、List、Set等集合型別時，它的成員數量超過1w個

上述的定義並不絕對，主要是根據value的成員數量和大小來確定，根據業務場景確定標準。

怎麼處理：

當vaule是string時，可以使用序列化、壓縮演算法將key的大小控制在合理範圍內，但是序列化和反序列化都會帶來更多時間上的消耗。或者將key進行拆分，一個大key分為不同的部分，記錄每個部分的key，使用multiget等操作實現事務讀取。
當value是list/set等集合型別時，根據預估的資料規模來進行分片，不同的元素計算後分到不同的片。

Redis常見效能問題和解決方案？

Master最好不要做任何持久化工作，包括記憶體快照和AOF日誌檔案，特別是不要啟用記憶體快照做持久化。
如果資料比較關鍵，某個Slave開啟AOF備份資料，策略為每秒同步一次。
為了主從複製的速度和連線的穩定性，Slave和Master最好在同一個區域網內。
儘量避免在壓力較大的主庫上增加從庫
Master呼叫BGREWRITEAOF重寫AOF檔案，AOF在重寫的時候會佔大量的CPU和記憶體資源，導致服務load過高，出現短暫服務暫停現象。
為了Master的穩定性，主從複製不要用圖狀結構，用單向連結串列結構更穩定，即主從關係為：Master<–Slave1<–Slave2<–Slave3…，這樣的結構也方便解決單點故障問題，實現Slave對Master的替換，也即，如果Master掛了，可以立馬啟用Slave1做Master，其他不變。

說說為什麼Redis過期了為什麼記憶體沒釋放？

第一種情況，可能是覆蓋之前的key，導致key過期時間發生了改變。

當一個key在Redis中已經存在了，但是由於一些誤操作使得key過期時間發生了改變，從而導致這個key在應該過期的時間內並沒有過期，從而造成記憶體的佔用。

第二種情況是，Redis過期key的處理策略導致記憶體沒釋放。

一般Redis對過期key的處理策略有兩種：惰性刪除和定時刪除。

先說惰性刪除的情況

當一個key已經確定設定了xx秒過期同時中間也沒有修改它，xx秒之後它確實已經過期了，但是惰性刪除的策略它並不會馬上刪除這個key，而是當再次讀寫這個key時它才會去檢查是否過期，如果過期了就會刪除這個key。也就是說，惰性刪除策略下，就算key過期了，也不會立刻釋放內容，要等到下一次讀寫這個key才會刪除key。

而定時刪除會在一定時間內主動淘汰一部分已經過期的資料，預設的時間是每100ms過期一次。因為定時刪除策略每次只會淘汰一部分過期key，而不是所有的過期key，如果redis中資料比較多的話要是一次性全量刪除對伺服器的壓力比較大，每一次只挑一批進行刪除，所以很可能出現部分已經過期的key並沒有及時的被清理掉，從而導致記憶體沒有即時被釋放。

Redis突然變慢，有哪些原因？

存在bigkey。如果Redis例項中儲存了 bigkey，那麼在淘汰刪除 bigkey 釋放記憶體時，也會耗時比較久。應該避免儲存 bigkey，降低釋放記憶體的耗時。
如果Redis 例項設定了記憶體上限 maxmemory，有可能導致 Redis 變慢。當 Redis 記憶體達到 maxmemory 後，每次寫入新的資料之前，Redis 必須先從例項中踢出一部分資料，讓整個例項的記憶體維持在 maxmemory 之下，然後才能把新資料寫進來。
開啟了記憶體大頁。當 Redis 在執行後臺 RDB 和 AOF rewrite 時，採用 fork 子程式的方式來處理。但主程式 fork 子程式後，此時的主程式依舊是可以接收寫請求的，而進來的寫請求，會採用 Copy On Write（寫時複製）的方式操作記憶體資料。
什麼是寫時複製？
這樣做的好處是，父程式有任何寫操作，並不會影響子程式的資料持久化。
不過，主程式在複製記憶體資料時，會涉及到新記憶體的申請，如果此時作業系統開啟了記憶體大頁，那麼在此期間，客戶端即便只修改 10B 的資料，Redis 在申請記憶體時也會以 2MB 為單位向作業系統申請，申請記憶體的耗時變長，進而導致每個寫請求的延遲增加，影響到 Redis 效能。
解決方案就是關閉記憶體大頁機制。
使用了Swap。作業系統為了緩解記憶體不足對應用程式的影響，允許把一部分記憶體中的資料換到磁碟上，以達到應用程式對記憶體使用的緩衝，這些記憶體資料被換到磁碟上的區域，就是 Swap。當記憶體中的資料被換到磁碟上後，Redis 再訪問這些資料時，就需要從磁碟上讀取，訪問磁碟的速度要比訪問記憶體慢幾百倍。尤其是針對 Redis 這種對效能要求極高、效能極其敏感的資料庫來說，這個操作延時是無法接受的。解決方案就是增加機器的記憶體，讓 Redis 有足夠的記憶體可以使用。或者整理記憶體空間，釋放出足夠的記憶體供 Redis 使用
網路頻寬過載。網路頻寬過載的情況下，伺服器在 TCP 層和網路層就會出現資料包傳送延遲、丟包等情況。Redis 的高效能，除了操作記憶體之外，就在於網路 IO 了，如果網路 IO 存在瓶頸，那麼也會嚴重影響 Redis 的效能。解決方案：1、及時確認佔滿網路頻寬 Redis 例項，如果屬於正常的業務訪問，那就需要及時擴容或遷移例項了，避免因為這個例項流量過大，影響這個機器的其他例項。2、運維層面，需要對 Redis 機器的各項指標增加監控，包括網路流量，在網路流量達到一定閾值時提前報警，及時確認和擴容。
頻繁短連線。頻繁的短連線會導致 Redis 大量時間耗費在連線的建立和釋放上，TCP 的三次握手和四次揮手同樣也會增加訪問延遲。應用應該使用長連線操作 Redis，避免頻繁的短連線。

為什麼 Redis 叢集的最大槽數是 16384 個？

Redis Cluster 採用資料分片機制，定義了 16384個 Slot槽位，叢集中的每個Redis 例項負責維護一部分槽以及槽所對映的鍵值資料。

Redis每個節點之間會定期傳送ping/pong訊息（心跳包包含了其他節點的資料），用於交換資料資訊。

Redis叢集的節點會按照以下規則發ping訊息：

(1)每秒會隨機選取5個節點，找出最久沒有通訊的節點傳送ping訊息
(2)每100毫秒都會掃描本地節點列表，如果發現節點最近一次接受pong訊息的時間大於cluster-node-timeout/2 則立刻傳送ping訊息

心跳包的訊息頭裡面有個myslots的char陣列，是一個bitmap，每一個位代表一個槽，如果該位為1，表示這個槽是屬於這個節點的。

接下來，解答為什麼 Redis 叢集的最大槽數是 16384 個，而不是65536 個。

1、如果採用 16384 個插槽，那麼心跳包的訊息頭佔用空間 2KB （16384/8）；如果採用 65536 個插槽，那麼心跳包的訊息頭佔用空間 8KB (65536/8)。可見採用 65536 個插槽，傳送心跳資訊的訊息頭達8k，比較浪費頻寬。

2、一般情況下一個Redis叢集不會有超過1000個master節點，太多可能導致網路擁堵。

3、雜湊槽是透過一張bitmap的形式來儲存的，在傳輸過程中，會對bitmap進行壓縮。bitmap的填充率越低，壓縮率越高。其中bitmap 填充率 = slots / N (N表示節點數)。所以，插槽數越低，填充率會降低，壓縮率會提高。

最後給大家分享一個Github倉庫，上面有大彬整理的300多本經典的計算機書籍PDF，包括C語言、C++、Java、Python、前端、資料庫、作業系統、計算機網路、資料結構和演算法、機器學習、程式設計人生等，可以star一下，下次找書直接在上面搜尋，倉庫持續更新中~

Github地址：https://github.com/Tyson0314/java-books