三天吃透Redis面試八股文_ZenDei技術網路在線

目錄： Redis是什麼？ Redis優缺點？ Redis為什麼這麼快？講講Redis的線程模型？ Redis應用場景有哪些？ Memcached和Redis的區別？為什麼要用 Redis 而不用 map/guava 做緩存? Redis 數據類型有哪些？ SortedSet和List異同點？ ...

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 較難支持線上擴容，在集群容量達到上限時線上擴容會變得很複雜。

內容摘自我的學習網站：topjavaer.cn

Redis為什麼這麼快？

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

既然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來實現簡單的消息隊列，實現非同步操作。
限速器，可用於限制某個用戶訪問某個介面的頻率，比如秒殺場景用於防止用戶快速點擊帶來不必要的壓力。
好友關係，利用集合的一些命令，比如交集、並集、差集等，實現共同好友、共同愛好之類的功能。

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 之類的稱為分散式緩存，在多實例的情況下，各實例共用一份緩存數據，緩存具有一致性。

本文已經收錄到大彬精心整理的大廠面試手冊，包含電腦基礎、Java基礎、多線程、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分散式、微服務、設計模式、架構、校招社招分享等高頻面試題，非常實用，有小伙伴靠著這份手冊拿過位元組offer~

需要的小伙伴可以自行下載：

http://mp.weixin.qq.com/s?__biz=Mzg2OTY1NzY0MQ==&mid=2247485445&idx=1&sn=1c6e224b9bb3da457f5ee03894493dbc&chksm=ce98f543f9ef7c55325e3bf336607a370935a6c78dbb68cf86e59f5d68f4c51d175365a189f8#rd

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的方式。前者會根據指定的規則定時將記憶體中的數據存儲在硬碟上，而後者在每次執行完命令後將命令記錄下來。一般將兩者結合使用。

分享一本谷歌大佬撰寫的演算法手冊，整整 300 道 LeetCode 題目，並且都是最優解，非常強！這本手冊幫助不少朋友加入大廠，大家加油！

Github瘋傳！谷歌大佬撰寫的演算法手冊開源了

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，避免頻繁的短連接。