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 每種資料類型底層都做了優化，目的就是為了追求更快的速度。

講講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 之類的稱為分布式緩存，在多執行個體的情況下，各執行個體共用一份緩存資料，緩存具有一緻性。

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 ：主要用于存儲地理位置資訊，并對存儲的資訊進行操作，适用場景如定位、附近的人等。

本文已經收錄到Github倉庫，該倉庫包含計算機基礎、Java基礎、多線程、JVM、資料庫、Redis、Spring、Mybatis、SpringMVC、SpringBoot、分布式、微服務、設計模式、架構、校招社招分享等核心知識點，歡迎star~

Github位址：https://github.com/Tyson0314/Java-learning

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表示節點數)。是以，插槽數越低，填充率會降低，壓縮率會提高

三天吃透Redis面試八股文