溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編給大家分享一下硬核Redis高頻面試題有哪些，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！
1、Redis 是單線程還是多線程？
2、為什么 Redis 是單線程？
3、Redis 為什么使用單進程、單線程也很快
4、Redis 在項目中的使用場景
5、Redis 常見的數據結構
6、Redis 的字符串（SDS）和C語言的字符串區別
7、Sorted Set底層數據結構
8、Sorted Set 為什么同時使用字典和跳躍表？
9、Sorted Set 為什么使用跳躍表，而不是紅黑樹？
10、Hash 對象底層結構
11、Hash 對象的擴容流程
12、漸進式 rehash 的優點
13、rehash 流程在數據量大的時候會有什么問題嗎（Hash 對象的擴容流程在數據量大的時候會有什么問題嗎）
14、Redis 的網絡事件處理器（Reactor 模式）
15、Redis 刪除過期鍵的策略（緩存失效策略、數據過期策略）
16、Redis 的內存淘汰（驅逐）策略
17、Redis 的 LRU 算法怎么實現的？
18、Redis 的持久化機制有哪幾種，各自的實現原理和優缺點？
19、為什么需要 AOF 重寫
20、介紹下 AOF 重寫的過程、AOF 后臺重寫存在的問題、如何解決 AOF 后臺重寫存在的數據不一致問題
21、RDB、AOF、混合持久，我應該用哪一個？
22、同時開啟RDB和AOF，服務重啟時如何加載
23、Redis 怎么保證高可用、有哪些集群模式
24、主從復制
25、哨兵
26、集群模式
27、集群選舉
28、如何保證集群在線擴容的安全性？（Redis 集群要增加分片，槽的遷移怎么保證無損）
29、Redis 事務的實現
30、Redis 的 Java 客戶端有哪些？官方推薦哪個？
31、Redis 里面有1億個 key，其中有 10 個 key 是包含 java，如何將它們全部找出來？
32、使用過 Redis 做消息隊列么？
33、Redis 和 Memcached 的比較
34、Redis 實現分布式鎖
35、Redis 分布式鎖過期了，還沒處理完怎么辦
36、守護線程續命的方案有什么問題嗎
37、RedLock
38、使用緩存時，先操作數據庫 or 先操作緩存
39、為什么是讓緩存失效，而不是更新緩存
40、如何保證數據庫和緩存的數據一致性
41、緩存穿透
42、布隆過濾器
43、緩存擊穿
44、緩存雪崩
這個問題應該已經看到過無數次了，最近 redis 6 出來之后又被翻出來了。
redis 4.0 之前，redis 是完全單線程的。
redis 4.0 時，redis 引入了多線程，但是額外的線程只是用于后臺處理，例如：刪除對象，核心流程還是完全單線程的。這也是為什么有些人說 4.0 是單線程的，因為他們指的是核心流程是單線程的。
這邊的核心流程指的是 redis 正常處理客戶端請求的流程，通常包括：接收命令、解析命令、執行命令、返回結果等。
而在最近，redis 6.0 版本又一次引入了多線程概念，與 4.0 不同的是，這次的多線程會涉及到上述的核心流程。
redis 6.0 中，多線程主要用于網絡 I/O 階段，也就是接收命令和寫回結果階段，而在執行命令階段，還是由單線程串行執行。由于執行時還是串行，因此無需考慮并發安全問題。
值得注意的時，redis 中的多線程組不會同時存在“讀”和“寫”，這個多線程組只會同時“讀”或者同時“寫”。
redis 6.0 加入多線程 I/O 之后，處理命令的核心流程如下:
1、當有讀事件到來時，主線程將該客戶端連接放到全局等待讀隊列
2、讀取數據：1）主線程將等待讀隊列的客戶端連接通過輪詢調度算法分配給 I/O 線程處理；2）同時主線程也會自己負責處理一個客戶端連接的讀事件；3）當主線程處理完該連接的讀事件后，會自旋等待所有 I/O 線程處理完畢
3、命令執行：主線程按照事件被加入全局等待讀隊列的順序（這邊保證了執行順序是正確的），串行執行客戶端命令，然后將客戶端連接放到全局等待寫隊列
4、寫回結果：跟等待讀隊列處理類似，主線程將等待寫隊列的客戶端連接使用輪詢調度算法分配給 I/O 線程處理，同時自己也會處理一個，當主線程處理完畢后，會自旋等待所有 I/O 線程處理完畢，最后清空隊列。
大致流程圖如下：
在 redis 6.0 之前，redis 的核心操作是單線程的。
因為 redis 是完全基于內存操作的，通常情況下CPU不會是redis的瓶頸，redis 的瓶頸最有可能是機器內存的大小或者網絡帶寬。
既然CPU不會成為瓶頸，那就順理成章地采用單線程的方案了，因為如果使用多線程的話會更復雜，同時需要引入上下文切換、加鎖等等，會帶來額外的性能消耗。
而隨著近些年互聯網的不斷發展，大家對于緩存的性能要求也越來越高了，因此 redis 也開始在逐漸往多線程方向發展。
最近的 6.0 版本就對核心流程引入了多線程，主要用于解決 redis 在網絡 I/O 上的性能瓶頸。而對于核心的命令執行階段，目前還是單線程的。
主要有以下幾點：
1、基于內存的操作
2、使用了 I/O 多路復用模型，select、epoll 等，基于 reactor 模式開發了自己的網絡事件處理器
3、單線程可以避免不必要的上下文切換和競爭條件，減少了這方面的性能消耗。
4、以上這三點是 redis 性能高的主要原因，其他的還有一些小優化，例如：對數據結構進行了優化，簡單動態字符串、壓縮列表等。
緩存（核心）、分布式鎖（set + lua 腳本）、排行榜（zset）、計數（incrby）、消息隊列（stream）、地理位置（geo）、訪客統計（hyperloglog）等。
基礎的5種：
String：字符串，最基礎的數據類型。
List：列表。
Hash：哈希對象。
Set：集合。
Sorted Set：有序集合，Set 的基礎上加了個分值。
高級的4種：
HyperLogLog：通常用于基數統計。使用少量固定大小的內存，來統計集合中唯一元素的數量。統計結果不是精確值，而是一個帶有0.81%標準差（standard error）的近似值。所以，HyperLogLog適用于一些對于統計結果精確度要求不是特別高的場景，例如網站的UV統計。
Geo：redis 3.2 版本的新特性。可以將用戶給定的地理位置信息儲存起來， 并對這些信息進行操作：獲取2個位置的距離、根據給定地理位置坐標獲取指定范圍內的地理位置集合。
Bitmap：位圖。
Stream：主要用于消息隊列，類似于 kafka，可以認為是 pub/sub 的改進版。提供了消息的持久化和主備復制功能，可以讓任何客戶端訪問任何時刻的數據，并且能記住每一個客戶端的訪問位置，還能保證消息不丟失。
C字符串 | SDS |
|---|---|
獲取字符串長度的復雜度為O(N) | 獲取字符串長度的復雜度為O(1) |
API是不安全的，可能會造成緩沖區溢出 | API是安全的，不會造成緩沖區溢出 |
修改字符串長度N次必然需要執行N次內存重分配 | 修改字符串長度N次最多需要執行N次內存重分配 |
只能保存文本數據 | 可以保存文本數據或者二進制數據 |
可以使用所有的<string.h>庫中的函數 | 可以使用一部分<string.h>庫中的函數 |
Sorted Set（有序集合）當前有兩種編碼：ziplist、skiplist
ziplist：使用壓縮列表實現，當保存的元素長度都小于64字節，同時數量小于128時，使用該編碼方式，否則會使用 skiplist。這兩個參數可以通過 zset-max-ziplist-entries、zset-max-ziplist-value 來自定義修改。
skiplist：zset實現，一個zset同時包含一個字典（dict）和一個跳躍表（zskiplist）
主要是為了提升性能。
單獨使用字典：在執行范圍型操作，比如 zrank、zrange，字典需要進行排序，至少需要 O(NlogN) 的時間復雜度及額外 O(N) 的內存空間。
單獨使用跳躍表：根據成員查找分值操作的復雜度從 O(1) 上升為 O(logN)。
主要有以下幾個原因：
1）跳表的性能和紅黑樹差不多。
2）跳表更容易實現和調試。
網上有同學說是因為作者不會紅黑樹，我覺得挺有可能的。
Hash 對象當前有兩種編碼：ziplist、hashtable
ziplist：使用壓縮列表實現，每當有新的鍵值對要加入到哈希對象時，程序會先將保存了鍵的節點推入到壓縮列表的表尾，然后再將保存了值的節點推入到壓縮列表表尾。
因此：1）保存了同一鍵值對的兩個節點總是緊挨在一起，保存鍵的節點在前，保存值的節點在后；2）先添加到哈希對象中的鍵值對會被放在壓縮列表的表頭方向，而后來添加的會被放在表尾方向。
hashtable：使用字典作為底層實現，哈希對象中的每個鍵值對都使用一個字典鍵值來保存，跟 java 中的 HashMap 類似。
hash 對象在擴容時使用了一種叫“漸進式 rehash”的方式，步驟如下：
1）計算新表 size、掩碼，為新表 ht[1] 分配空間，讓字典同時持有 ht[0] 和 ht[1] 兩個哈希表。
2）將 rehash 索引計數器變量 rehashidx 的值設置為0，表示 rehash 正式開始。
3）在 rehash 進行期間，每次對字典執行添加、刪除、査找、更新操作時，程序除了執行指定的操作以外，還會觸發額外的 rehash 操作，在源碼中的 _dictRehashStep 方法。
_dictRehashStep：從名字也可以看出來，大意是 rehash 一步，也就是 rehash 一個索引位置。
該方法會從 ht[0] 表的 rehashidx 索引位置上開始向后查找，找到第一個不為空的索引位置，將該索引位置的所有節點 rehash 到 ht[1]，當本次 rehash 工作完成之后，將 ht[0] 索引位置為 rehashidx 的節點清空，同時將 rehashidx 屬性的值加一。
4）將 rehash 分攤到每個操作上確實是非常妙的方式，但是萬一此時服務器比較空閑，一直沒有什么操作，難道 redis 要一直持有兩個哈希表嗎？
答案當然不是的。我們知道，redis 除了文件事件外，還有時間事件，redis 會定期觸發時間事件，這些時間事件用于執行一些后臺操作，其中就包含 rehash 操作：當 redis 發現有字典正在進行 rehash 操作時，會花費1毫秒的時間，一起幫忙進行 rehash。
5）隨著操作的不斷執行，最終在某個時間點上，ht[0] 的所有鍵值對都會被 rehash 至 ht[1]，此時 rehash 流程完成，會執行最后的清理工作：釋放 ht[0] 的空間、將 ht[0] 指向 ht[1]、重置 ht[1]、重置 rehashidx 的值為 -1。
漸進式 rehash 的好處在于它采取分而治之的方式，將 rehash 鍵值對所需的計算工作均攤到對字典的每個添加、刪除、查找和更新操作上，從而避免了集中式 rehash 而帶來的龐大計算量。
在進行漸進式 rehash 的過程中，字典會同時使用 ht[0] 和 ht[1] 兩個哈希表， 所以在漸進式 rehash 進行期間，字典的刪除、査找、更新等操作會在兩個哈希表上進行。例如，要在字典里面査找一個鍵的話，程序會先在 ht[0] 里面進行査找，如果沒找到的話，就會繼續到 ht[1] 里面進行査找，諸如此類。
另外，在漸進式 rehash 執行期間，新增的鍵值對會被直接保存到 ht[1], ht[0] 不再進行任何添加操作，這樣就保證了 ht[0] 包含的鍵值對數量會只減不增，并隨著 rehash 操作的執行而最終變成空表。
1）擴容期開始時，會先給 ht[1] 申請空間，所以在整個擴容期間，會同時存在 ht[0] 和 ht[1]，會占用額外的空間。
2）擴容期間同時存在 ht[0] 和 ht[1]，查找、刪除、更新等操作有概率需要操作兩張表，耗時會增加。
3）redis 在內存使用接近 maxmemory 并且有設置驅逐策略的情況下，出現 rehash 會使得內存占用超過 maxmemory，觸發驅逐淘汰操作，導致 master/slave 均有有大量的 key 被驅逐淘汰，從而出現 master/slave 主從不一致。
redis 基于 reactor 模式開發了自己的網絡事件處理器，由4個部分組成：套接字、I/O 多路復用程序、文件事件分派器（dispatcher）、以及事件處理器。
套接字：socket 連接，也就是客戶端連接。當一個套接字準備好執行連接、寫入、讀取、關閉等操作時， 就會產生一個相應的文件事件。因為一個服務器通常會連接多個套接字， 所以多個文件事件有可能會并發地出現。
I/O 多路復用程序：提供 select、epoll、evport、kqueue 的實現，會根據當前系統自動選擇最佳的方式。負責監聽多個套接字，當套接字產生事件時，會向文件事件分派器傳送那些產生了事件的套接字。當多個文件事件并發出現時， I/O 多路復用程序會將所有產生事件的套接字都放到一個隊列里面，然后通過這個隊列，以有序、同步、每次一個套接字的方式向文件事件分派器傳送套接字：當上一個套接字產生的事件被處理完畢之后，才會繼續傳送下一個套接字。
文件事件分派器：接收 I/O 多路復用程序傳來的套接字， 并根據套接字產生的事件的類型， 調用相應的事件處理器。
事件處理器：事件處理器就是一個個函數， 定義了某個事件發生時， 服務器應該執行的動作。例如：建立連接、命令查詢、命令寫入、連接關閉等等。
定時刪除：在設置鍵的過期時間的同時，創建一個定時器，讓定時器在鍵的過期時間來臨時，立即執行對鍵的刪除操作。對內存最友好，對 CPU 時間最不友好。
惰性刪除：放任鍵過期不管，但是每次獲取鍵時，都檢査鍵是否過期，如果過期的話，就刪除該鍵；如果沒有過期，就返回該鍵。對 CPU 時間最優化，對內存最不友好。
定期刪除：每隔一段時間，默認100ms，程序就對數據庫進行一次檢査，刪除里面的過期鍵。至 于要刪除多少過期鍵，以及要檢査多少個數據庫，則由算法決定。前兩種策略的折中，對 CPU 時間和內存的友好程度較平衡。
Redis 使用惰性刪除和定期刪除。
當 redis 的內存空間（maxmemory 參數配置）已經用滿時，redis 將根據配置的驅逐策略（maxmemory-policy 參數配置），進行相應的動作。
網上很多資料都是寫 6 種，但是其實當前 redis 的淘汰策略已經有 8 種了，多余的兩種是 Redis 4.0 新增的，基于 LFU（Least Frequently Used）算法實現的。
noeviction：默認策略，不淘汰任何 key，直接返回錯誤
allkeys-lru：在所有的 key 中，使用 LRU 算法淘汰部分
keyallkeys-lfu：在所有的 key 中，使用 LFU 算法淘汰部分 key，該算法于 Redis 4.0 新增
allkeys-random：在所有的 key 中，隨機淘汰部分
keyvolatile-lru：在設置了過期時間的 key 中，使用 LRU 算法淘汰部分
keyvolatile-lfu：在設置了過期時間的 key 中，使用 LFU 算法淘汰部分 key，該算法于 Redis 4.0 新增
volatile-random：在設置了過期時間的 key 中，隨機淘汰部分 keyvolatile-ttl：在設置了過期時間的 key 中，挑選 TTL（time to live，剩余時間）短的 key 淘汰
Redis 在 redisObject 結構體中定義了一個長度 24 bit 的 unsigned 類型的字段（unsigned lru:LRU_BITS），在 LRU 算法中用來存儲對象最后一次被命令程序訪問的時間。
具體的 LRU 算法經歷了兩個版本。
版本1：隨機選取 N 個淘汰法。
最初 Redis 是這樣實現的：隨機選 N（默認5） 個 key，把空閑時間（idle time）最大的那個 key 移除。這邊的 N 可通過 maxmemory-samples 配置項修改。
就是這么簡單，簡單得讓人不敢相信了，而且十分有效。
但是這個算法有個明顯的缺點：每次都是隨機從 N 個里選擇 1 個，并沒有利用前一輪的歷史信息。其實在上一輪移除 key 的過程中，其實是知道了 N 個 key 的 idle time 的情況的，那在下一輪移除 key 時，其實可以利用上一輪的這些信息。這也是 Redis 3.0 的優化思想。
版本2：Redis 3.0 對 LRU 算法進行改進，引入了緩沖池（pool，默認16）的概念。
當每一輪移除 key 時，拿到了 N（默認5）個 key 的 idle time，遍歷處理這 N 個 key，如果 key 的 idle time 比 pool 里面的 key 的 idle time 還要大，就把它添加到 pool 里面去。
當 pool 放滿之后，每次如果有新的 key 需要放入，需要將 pool 中 idle time 最小的一個 key 移除。這樣相當于 pool 里面始終維護著還未被淘汰的 idle time 最大的 16 個 key。
當我們每輪要淘汰的時候，直接從 pool 里面取出 idle time 最大的 key（只取1個），將之淘汰掉。
整個流程相當于隨機取 5 個 key 放入 pool，然后淘汰 pool 中空閑時間最大的 key，然后再隨機取 5 個 key放入 pool，繼續淘汰 pool 中空閑時間最大的 key，一直持續下去。
在進入淘汰前會計算出需要釋放的內存大小，然后就一直循環上述流程，直至釋放足夠的內存。
Redis 的持久化機制有：RDB、AOF、混合持久化（RDB+AOF，Redis 4.0引入）。
1）RDB
描述：類似于快照。在某個時間點，將 Redis 在內存中的數據庫狀態（數據庫的鍵值對等信息）保存到磁盤里面。RDB 持久化功能生成的 RDB 文件是經過壓縮的二進制文件。
命令：有兩個 Redis 命令可以用于生成 RDB 文件，一個是 SAVE，另一個是 BGSAVE。
開啟：使用 save point 配置，滿足 save point 條件后會觸發 BGSAVE 來存儲一次快照，這邊的 save point 檢查就是在上文提到的 serverCron 中進行。
save point 格式：save <seconds> <changes>，含義是 Redis 如果在 seconds 秒內數據發生了 changes 次改變，就保存快照文件。例如 Redis 默認就配置了以下3個：
save 900 1 #900秒內有1個key發生了變化，則觸發保存RDB文件 save 300 10 #300秒內有10個key發生了變化，則觸發保存RDB文件 save 60 10000 #60秒內有10000個key發生了變化，則觸發保存RDB文件
關閉：1）注釋掉所有save point 配置可以關閉 RDB 持久化。2）在所有 save point 配置后增加：save ""，該配置可以刪除所有之前配置的 save point。
save ""
SAVE：生成 RDB 快照文件，但是會阻塞主進程，服務器將無法處理客戶端發來的命令請求，所以通常不會直接使用該命令。
BGSAVE：fork 子進程來生成 RDB 快照文件，阻塞只會發生在 fork 子進程的時候，之后主進程可以正常處理請求，詳細過程如下圖：
fork：在 Linux 系統中，調用 fork() 時，會創建出一個新進程，稱為子進程，子進程會拷貝父進程的 page table。如果進程占用的內存越大，進程的 page table 也會越大，那么 fork 也會占用更多的時間。如果 Redis 占用的內存很大，那么在 fork 子進程時，則會出現明顯的停頓現象。
RDB 的優點
1）RDB 文件是是經過壓縮的二進制文件，占用空間很小，它保存了 Redis 某個時間點的數據集，很適合用于做備份。 比如說，你可以在最近的 24 小時內，每小時備份一次 RDB 文件，并且在每個月的每一天，也備份一個 RDB 文件。這樣的話，即使遇上問題，也可以隨時將數據集還原到不同的版本。
2）RDB 非常適用于災難恢復（disaster recovery）：它只有一個文件，并且內容都非常緊湊，可以（在加密后）將它傳送到別的數據中心。
3）RDB 可以最大化 redis 的性能。父進程在保存 RDB 文件時唯一要做的就是 fork 出一個子進程，然后這個子進程就會處理接下來的所有保存工作，父進程無須執行任何磁盤 I/O 操作。
4）RDB 在恢復大數據集時的速度比 AOF 的恢復速度要快。
RDB 的缺點
1）RDB 在服務器故障時容易造成數據的丟失。RDB 允許我們通過修改 save point 配置來控制持久化的頻率。但是，因為 RDB 文件需要保存整個數據集的狀態， 所以它是一個比較重的操作，如果頻率太頻繁，可能會對 Redis 性能產生影響。所以通常可能設置至少5分鐘才保存一次快照，這時如果 Redis 出現宕機等情況，則意味著最多可能丟失5分鐘數據。
2）RDB 保存時使用 fork 子進程進行數據的持久化，如果數據比較大的話，fork 可能會非常耗時，造成 Redis 停止處理服務N毫秒。如果數據集很大且 CPU 比較繁忙的時候，停止服務的時間甚至會到一秒。
3）Linux fork 子進程采用的是 copy-on-write 的方式。在 Redis 執行 RDB 持久化期間，如果 client 寫入數據很頻繁，那么將增加 Redis 占用的內存，最壞情況下，內存的占用將達到原先的2倍。剛 fork 時，主進程和子進程共享內存，但是隨著主進程需要處理寫操作，主進程需要將修改的頁面拷貝一份出來，然后進行修改。極端情況下，如果所有的頁面都被修改，則此時的內存占用是原先的2倍。
2）AOF
描述：保存 Redis 服務器所執行的所有寫操作命令來記錄數據庫狀態，并在服務器啟動時，通過重新執行這些命令來還原數據集。
開啟：AOF 持久化默認是關閉的，可以通過配置：appendonly yes 開啟。
關閉：使用配置 appendonly no 可以關閉 AOF 持久化。
AOF 持久化功能的實現可以分為三個步驟：命令追加、文件寫入、文件同步。
命令追加：當 AOF 持久化功能打開時，服務器在執行完一個寫命令之后，會將被執行的寫命令追加到服務器狀態的 aof 緩沖區（aof_buf）的末尾。
文件寫入與文件同步：可能有人不明白為什么將 aof_buf 的內容寫到磁盤上需要兩步操作，這邊簡單解釋一下。
Linux 操作系統中為了提升性能，使用了頁緩存（page cache）。當我們將 aof_buf 的內容寫到磁盤上時，此時數據并沒有真正的落盤，而是在 page cache 中，為了將 page cache 中的數據真正落盤，需要執行 fsync / fdatasync 命令來強制刷盤。這邊的文件同步做的就是刷盤操作，或者叫文件刷盤可能更容易理解一些。
在文章開頭，我們提過 serverCron 時間事件中會觸發 flushAppendOnlyFile 函數，該函數會根據服務器配置的 appendfsync 參數值，來決定是否將 aof_buf 緩沖區的內容寫入和保存到 AOF 文件。
appendfsync 參數有三個選項：
always：每處理一個命令都將 aof_buf 緩沖區中的所有內容寫入并同步到AOF 文件，即每個命令都刷盤。everysec：將 aof_buf 緩沖區中的所有內容寫入到 AOF 文件，如果上次同步 AOF 文件的時間距離現在超過一秒鐘， 那么再次對 AOF 文件進行同步， 并且這個同步操作是異步的，由一個后臺線程專門負責執行，即每秒刷盤1次。no：將 aof_buf 緩沖區中的所有內容寫入到 AOF 文件， 但并不對 AOF 文件進行同步， 何時同步由操作系統來決定。即不執行刷盤，讓操作系統自己執行刷盤。
AOF 的優點
AOF 比 RDB可靠。你可以設置不同的 fsync 策略：no、everysec 和 always。默認是 everysec，在這種配置下，redis 仍然可以保持良好的性能，并且就算發生故障停機，也最多只會丟失一秒鐘的數據。AOF文件是一個純追加的日志文件。即使日志因為某些原因而包含了未寫入完整的命令（比如寫入時磁盤已滿，寫入中途停機等等）， 我們也可以使用 redis-check-aof 工具也可以輕易地修復這種問題。當 AOF文件太大時，Redis 會自動在后臺進行重寫：重寫后的新 AOF 文件包含了恢復當前數據集所需的最小命令集合。整個重寫是絕對安全，因為重寫是在一個新的文件上進行，同時 Redis 會繼續往舊的文件追加數據。當新文件重寫完畢，Redis 會把新舊文件進行切換，然后開始把數據寫到新文件上。AOF 文件有序地保存了對數據庫執行的所有寫入操作以 Redis 協議的格式保存， 因此 AOF 文件的內容非常容易被人讀懂， 對文件進行分析（parse）也很輕松。如果你不小心執行了 FLUSHALL 命令把所有數據刷掉了，但只要 AOF 文件沒有被重寫，那么只要停止服務器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重啟 Redis ， 就可以將數據集恢復到 FLUSHALL 執行之前的狀態。
AOF 的缺點
對于相同的數據集，AOF 文件的大小一般會比 RDB 文件大。根據所使用的 fsync 策略，AOF 的速度可能會比 RDB 慢。通常 fsync 設置為每秒一次就能獲得比較高的性能，而關閉 fsync 可以讓 AOF 的速度和 RDB 一樣快。AOF 在過去曾經發生過這樣的 bug ：因為個別命令的原因，導致 AOF 文件在重新載入時，無法將數據集恢復成保存時的原樣。（舉個例子，阻塞命令 BRPOPLPUSH 就曾經引起過這樣的 bug ） 。雖然這種 bug 在 AOF 文件中并不常見， 但是相較而言， RDB 幾乎是不可能出現這種 bug 的。
3）混合持久化
描述：混合持久化并不是一種全新的持久化方式，而是對已有方式的優化。混合持久化只發生于 AOF 重寫過程。使用了混合持久化，重寫后的新 AOF 文件前半段是 RDB 格式的全量數據，后半段是 AOF 格式的增量數據。
整體格式為：[RDB file][AOF tail]
開啟：混合持久化的配置參數為 aof-use-rdb-preamble，配置為 yes 時開啟混合持久化，在 redis 4 剛引入時，默認是關閉混合持久化的，但是在 redis 5 中默認已經打開了。
關閉：使用 aof-use-rdb-preamble no 配置即可關閉混合持久化。
混合持久化本質是通過 AOF 后臺重寫（bgrewriteaof 命令）完成的，不同的是當開啟混合持久化時，fork 出的子進程先將當前全量數據以 RDB 方式寫入新的 AOF 文件，然后再將 AOF 重寫緩沖區（aof_rewrite_buf_blocks）的增量命令以 AOF 方式寫入到文件，寫入完成后通知主進程將新的含有 RDB 格式和 AOF 格式的 AOF 文件替換舊的的 AOF 文件。
優點：結合 RDB 和 AOF 的優點, 更快的重寫和恢復。
缺點：AOF 文件里面的 RDB 部分不再是 AOF 格式，可讀性差。
AOF 持久化是通過保存被執行的寫命令來記錄數據庫狀態的，隨著寫入命令的不斷增加，AOF 文件中的內容會越來越多，文件的體積也會越來越大。
如果不加以控制，體積過大的 AOF 文件可能會對 Redis 服務器、甚至整個宿主機造成影響，并且 AOF 文件的體積越大，使用 AOF 文件來進行數據還原所需的時間就越多。
舉個例子， 如果你對一個計數器調用了 100 次 INCR ， 那么僅僅是為了保存這個計數器的當前值， AOF 文件就需要使用 100 條記錄。
然而在實際上， 只使用一條 SET 命令已經足以保存計數器的當前值了， 其余 99 條記錄實際上都是多余的。
為了處理這種情況， Redis 引入了 AOF 重寫：可以在不打斷服務端處理請求的情況下， 對 AOF 文件進行重建（rebuild）。
描述：Redis 生成新的 AOF 文件來代替舊 AOF 文件，這個新的 AOF 文件包含重建當前數據集所需的最少命令。具體過程是遍歷所有數據庫的所有鍵，從數據庫讀取鍵現在的值，然后用一條命令去記錄鍵值對，代替之前記錄這個鍵值對的多條命令。
命令：有兩個 Redis 命令可以用于觸發 AOF 重寫，一個是 BGREWRITEAOF 、另一個是 REWRITEAOF 命令；
開啟：AOF 重寫由兩個參數共同控制，auto-aof-rewrite-percentage 和 auto-aof-rewrite-min-size，同時滿足這兩個條件，則觸發 AOF 后臺重寫 BGREWRITEAOF。
// 當前AOF文件比上次重寫后的AOF文件大小的增長比例超過100 auto-aof-rewrite-percentage 100 // 當前AOF文件的文件大小大于64MB auto-aof-rewrite-min-size 64mb
關閉：auto-aof-rewrite-percentage 0，指定0的百分比，以禁用自動AOF重寫功能。
auto-aof-rewrite-percentage 0
REWRITEAOF：進行 AOF 重寫，但是會阻塞主進程，服務器將無法處理客戶端發來的命令請求，通常不會直接使用該命令。
BGREWRITEAOF：fork 子進程來進行 AOF 重寫，阻塞只會發生在 fork 子進程的時候，之后主進程可以正常處理請求。
REWRITEAOF 和 BGREWRITEAOF 的關系與 SAVE 和 BGSAVE 的關系類似。
AOF 后臺重寫存在的問題
AOF 后臺重寫使用子進程進行從寫，解決了主進程阻塞的問題，但是仍然存在另一個問題：子進程在進行 AOF 重寫期間，服務器主進程還需要繼續處理命令請求，新的命令可能會對現有的數據庫狀態進行修改，從而使得當前的數據庫狀態和重寫后的 AOF 文件保存的數據庫狀態不一致。
如何解決 AOF 后臺重寫存在的數據不一致問題
為了解決上述問題，Redis 引入了 AOF 重寫緩沖區（aof_rewrite_buf_blocks），這個緩沖區在服務器創建子進程之后開始使用，當 Redis 服務器執行完一個寫命令之后，它會同時將這個寫命令追加到 AOF 緩沖區和 AOF 重寫緩沖區。
這樣一來可以保證：
1、現有 AOF 文件的處理工作會如常進行。這樣即使在重寫的中途發生停機，現有的 AOF 文件也還是安全的。
2、從創建子進程開始，也就是 AOF 重寫開始，服務器執行的所有寫命令會被記錄到 AOF 重寫緩沖區里面。
這樣，當子進程完成 AOF 重寫工作后，父進程會在 serverCron 中檢測到子進程已經重寫結束，則會執行以下工作：
1、將 AOF 重寫緩沖區中的所有內容寫入到新 AOF 文件中，這時新 AOF 文件所保存的數據庫狀態將和服務器當前的數據庫狀態一致。
2、對新的 AOF 文件進行改名，原子的覆蓋現有的 AOF 文件，完成新舊兩個 AOF 文件的替換。
之后，父進程就可以繼續像往常一樣接受命令請求了。
一般來說， 如果想盡量保證數據安全性， 你應該同時使用 RDB 和 AOF 持久化功能，同時可以開啟混合持久化。
如果你非常關心你的數據， 但仍然可以承受數分鐘以內的數據丟失， 那么你可以只使用 RDB 持久化。
如果你的數據是可以丟失的，則可以關閉持久化功能，在這種情況下，Redis 的性能是最高的。
使用 Redis 通常都是為了提升性能，而如果為了不丟失數據而將 appendfsync 設置為 always 級別時，對 Redis 的性能影響是很大的，在這種不能接受數據丟失的場景，其實可以考慮直接選擇 MySQL 等類似的數據庫。
簡單來說，如果同時啟用了 AOF 和 RDB，Redis 重新啟動時，會使用 AOF 文件來重建數據集，因為通常來說， AOF 的數據會更完整。
而在引入了混合持久化之后，使用 AOF 重建數據集時，會通過文件開頭是否為“REDIS”來判斷是否為混合持久化。
完整流程如下圖所示：
主從復制、哨兵模式、集群模式。
在當前最新的 Redis 6.0 中，主從復制的完整過程如下：
1）開啟主從復制
通常有以下三種方式：
在 slave 直接執行命令：slaveof <masterip> <masterport>在 slave 配置文件中加入：slaveof <masterip> <masterport>使用啟動命令：--slaveof <masterip> <masterport>
注：在 Redis 5.0 之后，slaveof 相關命令和配置已經被替換成 replicaof，例如 replicaof <masterip> <masterport>。為了兼容舊版本，通過配置的方式仍然支持 slaveof，但是通過命令的方式則不行了。
2）建立套接字（socket）連接
slave 將根據指定的 IP 地址和端口，向 master 發起套接字（socket）連接，master 在接受（accept） slave 的套接字連接之后，為該套接字創建相應的客戶端狀態，此時連接建立完成。
3）發送PING命令
slave 向 master 發送一個 PING 命令，以檢査套接字的讀寫狀態是否正常、 master 能否正常處理命令請求。
4）身份驗證
slave 向 master 發送 AUTH password 命令來進行身份驗證。
5）發送端口信息
在身份驗證通過后后， slave 將向 master 發送自己的監聽端口號， master 收到后記錄在 slave 所對應的客戶端狀態的 slave_listening_port 屬性中。
6）發送IP地址
如果配置了 slave_announce_ip，則 slave 向 master 發送 slave_announce_ip 配置的 IP 地址， master 收到后記錄在 slave 所對應的客戶端狀態的 slave_ip 屬性。
該配置是用于解決服務器返回內網 IP 時，其他服務器無法訪問的情況。可以通過該配置直接指定公網 IP。
7）發送CAPA
CAPA 全稱是 capabilities，這邊表示的是同步復制的能力。slave 會在這一階段發送 capa 告訴 master 自己具備的（同步）復制能力， master 收到后記錄在 slave 所對應的客戶端狀態的 slave_capa 屬性。
8）數據同步
slave 將向 master 發送 PSYNC 命令， master 收到該命令后判斷是進行部分重同步還是完整重同步，然后根據策略進行數據的同步。
9）命令傳播
當完成了同步之后，就會進入命令傳播階段，這時 master 只要一直將自己執行的寫命令發送給 slave ，而 slave 只要一直接收并執行 master 發來的寫命令，就可以保證 master 和 slave 一直保持一致了。
以部分重同步為例，主從復制的核心步驟流程圖如下：
哨兵（Sentinel） 是 Redis 的高可用性解決方案：由一個或多個 Sentinel 實例組成的 Sentinel 系統可以監視任意多個主服務器，以及這些主服務器屬下的所有從服務器。
Sentinel 可以在被監視的主服務器進入下線狀態時，自動將下線主服務器的某個從服務器升級為新的主服務器，然后由新的主服務器代替已下線的主服務器繼續處理命令請求。
1）哨兵故障檢測
檢查主觀下線狀態
在默認情況下，Sentinel 會以每秒一次的頻率向所有與它創建了命令連接的實例（包括主服務器、從服務器、其他 Sentinel 在內）發送 PING 命令，并通過實例返回的 PING 命令回復來判斷實例是否在線。
如果一個實例在 down-after-miliseconds 毫秒內，連續向 Sentinel 返回無效回復，那么 Sentinel 會修改這個實例所對應的實例結構，在結構的 flags 屬性中設置 SRI_S_DOWN 標識，以此來表示這個實例已經進入主觀下線狀態。
檢查客觀下線狀態
當 Sentinel 將一個主服務器判斷為主觀下線之后，為了確定這個主服務器是否真的下線了，它會向同樣監視這一服務器的其他 Sentinel 進行詢問，看它們是否也認為主服務器已經進入了下線狀態（可以是主觀下線或者客觀下線）。
當 Sentinel 從其他 Sentinel 那里接收到足夠數量（quorum，可配置）的已下線判斷之后，Sentinel 就會將服務器置為客觀下線，在 flags 上打上 SRI_O_DOWN 標識，并對主服務器執行故障轉移操作。
2）哨兵故障轉移流程
當哨兵監測到某個主節點客觀下線之后，就會開始故障轉移流程。核心流程如下：
發起一次選舉，選舉出領頭 Sentinel領頭 Sentinel 在已下線主服務器的所有從服務器里面，挑選出一個從服務器，并將其升級為新的主服務器。領頭 Sentinel 將剩余的所有從服務器改為復制新的主服務器。領頭 Sentinel 更新相關配置信息，當這個舊的主服務器重新上線時，將其設置為新的主服務器的從服務器。
哨兵模式最大的缺點就是所有的數據都放在一臺服務器上，無法較好的進行水平擴展。
為了解決哨兵模式存在的問題，集群模式應運而生。在高可用上，集群基本是直接復用的哨兵模式的邏輯，并且針對水平擴展進行了優化。
集群模式具備的特點如下：
采取去中心化的集群模式，將數據按槽存儲分布在多個 Redis 節點上。集群共有 16384 個槽，每個節點負責處理部分槽。使用 CRC16 算法來計算 key 所屬的槽：crc16(key,keylen) & 16383。所有的 Redis 節點彼此互聯，通過 PING-PONG 機制來進行節點間的心跳檢測。分片內采用一主多從保證高可用，并提供復制和故障恢復功能。在實際使用中，通常會將主從分布在不同機房，避免機房出現故障導致整個分片出問題，下面的架構圖就是這樣設計的。客戶端與 Redis 節點直連，不需要中間代理層（proxy）。客戶端不需要連接集群所有節點，連接集群中任何一個可用節點即可。
集群的架構圖如下所示：
故障轉移的第一步就是選舉出新的主節點，以下是集群選舉新的主節點的方法：
1）當從節點發現自己正在復制的主節點進入已下線狀態時，會發起一次選舉：將 currentEpoch（配置紀元）加1，然后向集群廣播一條 CLUSTERMSG_TYPE_FAILOVER_AUTH_REQUEST 消息，要求所有收到這條消息、并且具有投票權的主節點向這個從節點投票。
2）其他節點收到消息后，會判斷是否要給發送消息的節點投票，判斷流程如下：
當前節點是 slave，或者當前節點是 master，但是不負責處理槽，則當前節點沒有投票權，直接返回。請求節點的 currentEpoch 小于當前節點的 currentEpoch，校驗失敗返回。因為發送者的狀態與當前集群狀態不一致，可能是長時間下線的節點剛剛上線，這種情況下，直接返回即可。當前節點在該 currentEpoch 已經投過票，校驗失敗返回。請求節點是 master，校驗失敗返回。請求節點的 master 為空，校驗失敗返回。請求節點的 master 沒有故障，并且不是手動故障轉移，校驗失敗返回。因為手動故障轉移是可以在 master 正常的情況下直接發起的。上一次為該master的投票時間，在cluster_node_timeout的2倍范圍內，校驗失敗返回。這個用于使獲勝從節點有時間將其成為新主節點的消息通知給其他從節點，從而避免另一個從節點發起新一輪選舉又進行一次沒必要的故障轉移請求節點宣稱要負責的槽位，是否比之前負責這些槽位的節點，具有相等或更大的 configEpoch，如果不是，校驗失敗返回。
如果通過以上所有校驗，那么主節點將向要求投票的從節點返回一條 CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK 消息，表示這個主節點支持從節點成為新的主節點。
3）每個參與選舉的從節點都會接收 CLUSTERMSG_TYPE_FAILOVER_AUTH_ACK 消息，并根據自己收到了多少條這種消息來統計自己獲得了多少個主節點的支持。
4）如果集群里有N個具有投票權的主節點，那么當一個從節點收集到大于等于N/2+1 張支持票時，這個從節點就會當選為新的主節點。因為在每一個配置紀元里面，每個具有投票權的主節點只能投一次票，所以如果有 N個主節點進行投票，那么具有大于等于 N/2+1 張支持票的從節點只會有一個，這確保了新的主節點只會有一個。
5）如果在一個配置紀元里面沒有從節點能收集到足夠多的支持票，那么集群進入一個新的配置紀元，并再次進行選舉，直到選出新的主節點為止。
這個選舉新主節點的方法和選舉領頭 Sentinel 的方法非常相似，因為兩者都是基于 Raft 算法的領頭選舉（leader election）方法來實現的。
例如：集群已經對外提供服務，原來有3分片，準備新增2個分片，怎么在不下線的情況下，無損的從原有的3個分片指派若干個槽給這2個分片？
Redis 使用了 ASK 錯誤來保證在線擴容的安全性。
在槽的遷移過程中若有客戶端訪問，依舊先訪問源節點，源節點會先在自己的數據庫里面査找指定的鍵，如果找到的話，就直接執行客戶端發送的命令。
如果沒找到，說明該鍵可能已經被遷移到目標節點了，源節點將向客戶端返回一個 ASK 錯誤，該錯誤會指引客戶端轉向正在導入槽的目標節點，并再次發送之前想要執行的命令，從而獲取到結果。
ASK錯誤
在進行重新分片期間，源節點向目標節點遷移一個槽的過程中，可能會出現這樣一種情況：屬于被遷移槽的一部分鍵值對保存在源節點里面，而另一部分鍵值對則保存在目標節點里面。
當客戶端向源節點發送一個與數據庫鍵有關的命令，并且命令要處理的數據庫鍵恰好就屬于正在被遷移的槽時。源節點會先在自己的數據庫里面査找指定的鍵，如果找到的話，就直接執行客戶端發送的命令。
否則，這個鍵有可能已經被遷移到了目標節點，源節點將向客戶端返回一個 ASK 錯誤，指引客戶端轉向正在導入槽的目標節點，并再次發送之前想要執行的命令，從而獲取到結果。
一個事務從開始到結束通常會經歷以下3個階段：
1）事務開始：multi 命令將執行該命令的客戶端從非事務狀態切換至事務狀態，底層通過 flags 屬性標識。
2）命令入隊：當客戶端處于事務狀態時，服務器會根據客戶端發來的命令執行不同的操作：
exec、discard、watch、multi 命令會被立即執行其他命令不會立即執行，而是將命令放入到一個事務隊列，然后向客戶端返回 QUEUED 回復。
3）事務執行：當一個處于事務狀態的客戶端向服務器發送 exec 命令時，服務器會遍歷事務隊列，執行隊列中的所有命令，最后將結果全部返回給客戶端。
不過 redis 的事務并不推薦在實際中使用，如果要使用事務，推薦使用 Lua 腳本，redis 會保證一個 Lua 腳本里的所有命令的原子性。
Redis 官網展示的 Java 客戶端如下圖所示，其中官方推薦的是標星的3個：Jedis、Redisson 和 lettuce。
1）keys *java* 命令，該命令性能很好，但是在數據量特別大的時候會有性能問題
2）scan 0 MATCH *java* 命令，基于游標的迭代器，更好的選擇
SCAN 命令是一個基于游標的迭代器（cursor based iterator）： SCAN 命令每次被調用之后， 都會向用戶返回一個新的游標， 用戶在下次迭代時需要使用這個新游標作為 SCAN 命令的游標參數， 以此來延續之前的迭代過程。
當 SCAN 命令的游標參數被設置為 0 時， 服務器將開始一次新的迭代， 而當服務器向用戶返回值為 0 的游標時， 表示迭代已結束。
Redis 本身提供了一些組件來實現消息隊列的功能，但是多多少少都存在一些缺點，相比于市面上成熟的消息隊列，例如 Kafka、Rocket MQ 來說并沒有優勢，因此目前我們并沒有使用 Redis 來做消息隊列。
關于 Redis 做消息隊列的常見方案主要有以下：
1）Redis 5.0 之前可以使用 List（blocking）、Pub/Sub 等來實現輕量級的消息發布訂閱功能組件，但是這兩種實現方式都有很明顯的缺點，兩者中相對完善的 Pub/Sub 的主要缺點就是消息無法持久化，如果出現網絡斷開、Redis 宕機等，消息就會被丟棄。
2）為了解決 Pub/Sub 模式等的缺點，Redis 在 5.0 引入了全新的 Stream，Stream 借鑒了很多 Kafka 的設計思想，有以下幾個特點：
提供了消息的持久化和主備復制功能，可以讓任何客戶端訪問任何時刻的數據，并且能記住每一個客戶端的訪問位置，還能保證消息不丟失。引入了消費者組的概念，不同組接收到的數據完全一樣（前提是條件一樣），但是組內的消費者則是競爭關系。
Redis Stream 相比于 pub/sub 已經有很明顯的改善，但是相比于 Kafka，其實沒有優勢，同時存在：尚未經過大量驗證、成本較高、不支持分區（partition）、無法支持大規模數據等問題。
1）數據結構：memcached 支持簡單的 key-value 數據結構，而 redis 支持豐富的數據結構：String、List、Set、Hash、SortedSet 等。
2）數據存儲：memcached 和 redis 的數據都是全部在內存中。
網上有一種說法 “當物理內存用完時，Redis可以將一些很久沒用到的 value 交換到磁盤，同時在內存中清除”，這邊指的是 redis 里的虛擬內存（Virtual Memory）功能，該功能在 Redis 2.0 被引入，但是在 Redis 2.4 中被默認關閉，并標記為廢棄，而在后續版中被完全移除。
3）持久化：memcached 不支持持久化，redis 支持將數據持久化到磁盤
4）災難恢復：實例掛掉后，memcached 數據不可恢復，redis 可通過 RDB、AOF 恢復，但是還是會有數據丟失問題
5）事件庫：memcached 使用 Libevent 事件庫，redis 自己封裝了簡易事件庫 AeEvent
6）過期鍵刪除策略：memcached 使用惰性刪除，redis 使用惰性刪除+定期刪除
7）內存驅逐（淘汰）策略：memcached 主要為 LRU 算法，redis 當前支持8種淘汰策略，見本文第16題
8）性能比較
按“CPU 單核” 維度比較：由于 Redis 只使用單核，而 Memcached 可以使用多核，所以在比較上：在處理小數據時，平均每一個核上 Redis 比 Memcached 性能更高，而在 100k 左右的大數據時， Memcached 性能要高于 Redis。按“實例”維度進行比較：由于 Memcached 多線程的特性，在 Redis 6.0 之前，通常情況下 Memcached 性能是要高于 Redis 的，同時實例的 CPU 核數越多，Memcached 的性能優勢越大。至于網上說的 redis 的性能比 memcached 快很多，這個說法就離譜。
1）加鎖
加鎖通常使用 set 命令來實現，偽代碼如下：
set key value PX milliseconds NX
幾個參數的意義如下：
key、value：鍵值對
PX milliseconds：設置鍵的過期時間為 milliseconds 毫秒。
NX：只在鍵不存在時，才對鍵進行設置操作。SET key value NX 效果等同于 SETNX key value。
PX、expireTime 參數則是用于解決沒有解鎖導致的死鎖問題。因為如果沒有過期時間，萬一程序員寫的代碼有 bug 導致沒有解鎖操作，則就出現了死鎖，因此該參數起到了一個“兜底”的作用。
NX 參數用于保證在多個線程并發 set 下，只會有1個線程成功，起到了鎖的“唯一”性。
2）解鎖
解鎖需要兩步操作：
1）查詢當前“鎖”是否還是我們持有，因為存在過期時間，所以可能等你想解鎖的時候，“鎖”已經到期，然后被其他線程獲取了，所以我們在解鎖前需要先判斷自己是否還持有“鎖”
2）如果“鎖”還是我們持有，則執行解鎖操作，也就是刪除該鍵值對，并返回成功；否則，直接返回失敗。
由于當前 Redis 還沒有原子命令直接支持這兩步操作，所以當前通常是使用 Lua 腳本來執行解鎖操作，Redis 會保證腳本里的內容執行是一個原子操作。
腳本代碼如下，邏輯比較簡單：
public Object getData(String key) throws InterruptedException {
Object value = redis.get(key);
// 緩存值過期
if (value == null) {
// lockRedis：專門用于加鎖的redis；
// "empty"：加鎖的值隨便設置都可以
if (lockRedis.set(key, "empty", "PX", lockExpire, "NX")) {
try {
// 查詢數據庫，并寫到緩存，讓其他線程可以直接走緩存
value = getDataFromDb(key);
redis.set(key, value, "PX", expire);
} catch (Exception e) {
// 異常處理
} finally {
// 釋放鎖
lockRedis.delete(key);
}
} else {
// sleep50ms后，進行重試
Thread.sleep(50);
return getData(key);
}
}
return value;
}兩個參數的意義如下：
KEYS[1]：我們要解鎖的 key
ARGV[1]：我們加鎖時的 value，用于判斷當“鎖”是否還是我們持有，如果被其他線程持有了，value 就會發生變化。
上述方法是 Redis 當前實現分布式鎖的主流方法，可能會有一些小優區別，但是核心都是這個思路。看著好像沒啥毛病，但是真的是這個樣子嗎？讓我們繼續往下看。
為了防止死鎖，我們會給分布式鎖加一個過期時間，但是萬一這個時間到了，我們業務邏輯還沒處理完，怎么辦？
首先，我們在設置過期時間時要結合業務場景去考慮，盡量設置一個比較合理的值，就是理論上正常處理的話，在這個過期時間內是一定能處理完畢的。
之后，我們再來考慮對這個問題進行兜底設計。
關于這個問題，目前常見的解決方法有兩種：
守護線程“續命”：額外起一個線程，定期檢查線程是否還持有鎖，如果有則延長過期時間。Redisson 里面就實現了這個方案，使用“看門狗”定期檢查（每1/3的鎖時間檢查1次），如果線程還持有鎖，則刷新過期時間。超時回滾：當我們解鎖時發現鎖已經被其他線程獲取了，說明此時我們執行的操作已經是“不安全”的了，此時需要進行回滾，并返回失敗。
同時，需要進行告警，人為介入驗證數據的正確性，然后找出超時原因，是否需要對超時時間進行優化等等。
Redisson 使用看門狗（守護線程）“續命”的方案在大多數場景下是挺不錯的，也被廣泛應用于生產環境，但是在極端情況下還是會存在問題。
問題例子如下：
線程1首先獲取鎖成功，將鍵值對寫入 redis 的 master 節點在 redis 將該鍵值對同步到 slave 節點之前，master 發生了故障redis 觸發故障轉移，其中一個 slave 升級為新的 master此時新的 master 并不包含線程1寫入的鍵值對，因此線程2嘗試獲取鎖也可以成功拿到鎖此時相當于有兩個線程獲取到了鎖，可能會導致各種預期之外的情況發生，例如最常見的臟數據
解決方法：上述問題的根本原因主要是由于 redis 異步復制帶來的數據不一致問題導致的，因此解決的方向就是保證數據的一致。
當前比較主流的解法和思路有兩種：
1）Redis 作者提出的 RedLock；2）Zookeeper 實現的分布式鎖。
首先，該方案也是基于文章開頭的那個方案（set加鎖、lua腳本解鎖）進行改良的，所以 antirez 只描述了差異的地方，大致方案如下。
假設我們有 N 個 Redis 主節點，例如 N = 5，這些節點是完全獨立的，我們不使用復制或任何其他隱式協調系統，為了取到鎖，客戶端應該執行以下操作:
獲取當前時間，以毫秒為單位。依次嘗試從5個實例，使用相同的 key 和隨機值（例如UUID）獲取鎖。當向Redis 請求獲取鎖時，客戶端應該設置一個超時時間，這個超時時間應該小于鎖的失效時間。例如你的鎖自動失效時間為10秒，則超時時間應該在 5-50 毫秒之間。這樣可以防止客戶端在試圖與一個宕機的 Redis 節點對話時長時間處于阻塞狀態。如果一個實例不可用，客戶端應該盡快嘗試去另外一個Redis實例請求獲取鎖。客戶端通過當前時間減去步驟1記錄的時間來計算獲取鎖使用的時間。當且僅當從大多數（N/2+1，這里是3個節點）的Redis節點都取到鎖，并且獲取鎖使用的時間小于鎖失效時間時，鎖才算獲取成功。如果取到了鎖，其真正有效時間等于初始有效時間減去獲取鎖所使用的時間（步驟3計算的結果）。如果由于某些原因未能獲得鎖（無法在至少N/2+1個Redis實例獲取鎖、或獲取鎖的時間超過了有效時間），客戶端應該在所有的Redis實例上進行解鎖（即便某些Redis實例根本就沒有加鎖成功，防止某些節點獲取到鎖但是客戶端沒有得到響應而導致接下來的一段時間不能被重新獲取鎖）。
可以看出，該方案為了解決數據不一致的問題，直接舍棄了異步復制，只使用 master 節點，同時由于舍棄了 slave，為了保證可用性，引入了 N 個節點，官方建議是 5。
該方案看著挺美好的，但是實際上我所了解到的在實際生產上應用的不多，主要有兩個原因：1）該方案的成本似乎有點高，需要使用5個實例；2）該方案一樣存在問題。
該方案主要存以下問題：
嚴重依賴系統時鐘。如果線程1從3個實例獲取到了鎖，但是這3個實例中的某個實例的系統時間走的稍微快一點，則它持有的鎖會提前過期被釋放，當他釋放后，此時又有3個實例是空閑的，則線程2也可以獲取到鎖，則可能出現兩個線程同時持有鎖了。如果線程1從3個實例獲取到了鎖，但是萬一其中有1臺重啟了，則此時又有3個實例是空閑的，則線程2也可以獲取到鎖，此時又出現兩個線程同時持有鎖了。
針對以上問題其實后續也有人給出一些相應的解法，但是整體上來看還是不夠完美，所以目前實際應用得不是那么多。
1）先操作數據庫
案例如下，有兩個并發的請求，一個寫請求，一個讀請求，流程如下：
可能存在的臟數據時間范圍：更新數據庫后，失效緩存前。這個時間范圍很小，通常不會超過幾毫秒。
2）先操作緩存
案例如下，有兩個并發的請求，一個寫請求，一個讀請求，流程如下：
可能存在的臟數據時間范圍：更新數據庫后，下一次對該數據的更新前。這個時間范圍不確定性很大，情況如下：
如果下一次對該數據的更新馬上就到來，那么會失效緩存，臟數據的時間就很短。如果下一次對該數據的更新要很久才到來，那這期間緩存保存的一直是臟數據，時間范圍很長。
結論：通過上述案例可以看出，先操作數據庫和先操作緩存都會存在臟數據的情況。但是相比之下，先操作數據庫，再操作緩存是更優的方式，即使在并發極端情況下，也只會出現很小量的臟數據。
1）更新緩存
案例如下，有兩個并發的寫請求，流程如下：
分析：數據庫中的數據是請求B的，緩存中的數據是請求A的，數據庫和緩存存在數據不一致。
2）失效（刪除）緩存
案例如下，有兩個并發的寫請求，流程如下：
分析：由于是刪除緩存，所以不存在數據不一致的情況。
結論：通過上述案例，可以很明顯的看出，失效緩存是更優的方式。
在上文的案例中，無論是先操作數據庫，還是先操作緩存，都會存在臟數據的情況，有辦法避免嗎？
答案是有的，由于數據庫和緩存是兩個不同的數據源，要保證其數據一致性，其實就是典型的分布式事務場景，可以引入分布式事務來解決，常見的有：2PC、TCC、MQ事務消息等。
但是引入分布式事務必然會帶來性能上的影響，這與我們當初引入緩存來提升性能的目的是相違背的。
所以在實際使用中，通常不會去保證緩存和數據庫的強一致性，而是做出一定的犧牲，保證兩者數據的最終一致性。
如果是實在無法接受臟數據的場景，則比較合理的方式是放棄使用緩存，直接走數據庫。
保證數據庫和緩存數據最終一致性的常用方案如下：
1）更新數據庫，數據庫產生 binlog。
2）監聽和消費 binlog，執行失效緩存操作。
3）如果步驟2失效緩存失敗，則引入重試機制，將失敗的數據通過MQ方式進行重試，同時考慮是否需要引入冪等機制。
兜底：當出現未知的問題時，及時告警通知，人為介入處理。
人為介入是終極大法，那些外表看著光鮮艷麗的應用，其背后大多有一群苦逼的程序員，在不斷的修復各種臟數據和bug。
描述：訪問一個緩存和數據庫都不存在的 key，此時會直接打到數據庫上，并且查不到數據，沒法寫緩存，所以下一次同樣會打到數據庫上。
此時，緩存起不到作用，請求每次都會走到數據庫，流量大時數據庫可能會被打掛。此時緩存就好像被“穿透”了一樣，起不到任何作用。
解決方案：
1）接口校驗。在正常業務流程中可能會存在少量訪問不存在 key 的情況，但是一般不會出現大量的情況，所以這種場景最大的可能性是遭受了非法攻擊。可以在最外層先做一層校驗：用戶鑒權、數據合法性校驗等，例如商品查詢中，商品的ID是正整數，則可以直接對非正整數直接過濾等等。
2）緩存空值。當訪問緩存和DB都沒有查詢到值時，可以將空值寫進緩存，但是設置較短的過期時間，該時間需要根據產品業務特性來設置。
3）布隆過濾器。使用布隆過濾器存儲所有可能訪問的 key，不存在的 key 直接被過濾，存在的 key 則再進一步查詢緩存和數據庫。
布隆過濾器的特點是判斷不存在的，則一定不存在；判斷存在的，大概率存在，但也有小概率不存在。并且這個概率是可控的，我們可以讓這個概率變小或者變高，取決于用戶本身的需求。
布隆過濾器由一個 bitSet 和 一組 Hash 函數（算法）組成，是一種空間效率極高的概率型算法和數據結構，主要用來判斷一個元素是否在集合中存在。
在初始化時，bitSet 的每一位被初始化為0，同時會定義 Hash 函數，例如有3組 Hash 函數：hash2、hash3、hash4。
寫入流程
當我們要寫入一個值時，過程如下，以“jionghui”為例：
1）首先將“jionghui”跟3組 Hash 函數分別計算，得到 bitSet 的下標為：1、7、10。
2）將 bitSet 的這3個下標標記為1。
假設我們還有另外兩個值：java 和 diaosi，按上面的流程跟 3組 Hash 函數分別計算，結果如下：
java：Hash 函數計算 bitSet 下標為：1、7、11
diaosi：Hash 函數計算 bitSet 下標為：4、10、11
查詢流程
當我們要查詢一個值時，過程如下，同樣以“jionghui”為例：：
1）首先將“jionghui”跟3組 Hash 函數分別計算，得到 bitSet 的下標為：1、7、10。
2）查看 bitSet 的這3個下標是否都為1，如果這3個下標不都為1，則說明該值必然不存在，如果這3個下標都為1，則只能說明可能存在，并不能說明一定存在。
其實上圖的例子已經說明了這個問題了，當我們只有值“jionghui”和“diaosi”時，bitSet 下標為1的有：1、4、7、10、11。
當我們又加入值“java”時，bitSet 下標為1的還是這5個，所以當 bitSet 下標為1的為：1、4、7、10、11 時，我們無法判斷值“java”存不存在。
其根本原因是，不同的值在跟 Hash 函數計算后，可能會得到相同的下標，所以某個值的標記位，可能會被其他值給標上了。
這也是為啥布隆過濾器只能判斷某個值可能存在，無法判斷必然存在的原因。但是反過來，如果該值根據 Hash 函數計算的標記位沒有全部都為1，那么則說明必然不存在，這個是肯定的。
降低這種誤判率的思路也比較簡單：
一個是加大 bitSet 的長度，這樣不同的值出現“沖突”的概率就降低了，從而誤判率也降低。提升 Hash 函數的個數，Hash 函數越多，每個值對應的 bit 越多，從而誤判率也降低。
布隆過濾器的誤判率還有專門的推導公式，有興趣的可以去搜相關的文章和論文查看。
描述：某一個熱點 key，在緩存過期的一瞬間，同時有大量的請求打進來，由于此時緩存過期了，所以請求最終都會走到數據庫，造成瞬時數據庫請求量大、壓力驟增，甚至可能打垮數據庫。
解決方案：
1）加互斥鎖。在并發的多個請求中，只有第一個請求線程能拿到鎖并執行數據庫查詢操作，其他的線程拿不到鎖就阻塞等著，等到第一個線程將數據寫入緩存后，直接走緩存。
關于互斥鎖的選擇，網上看到的大部分文章都是選擇 Redis 分布式鎖（可以參考我之前的文章：面試必問的分布式鎖，你懂了嗎？），因為這個可以保證只有一個請求會走到數據庫，這是一種思路。
但是其實仔細想想的話，這邊其實沒有必要保證只有一個請求走到數據庫，只要保證走到數據庫的請求能大大降低即可，所以還有另一個思路是 JVM 鎖。
JVM 鎖保證了在單臺服務器上只有一個請求走到數據庫，通常來說已經足夠保證數據庫的壓力大大降低，同時在性能上比分布式鎖更好。
需要注意的是，無論是使用“分布式鎖”，還是“JVM 鎖”，加鎖時要按 key 維度去加鎖。
我看網上很多文章都是使用一個“固定的 key”加鎖，這樣會導致不同的 key 之間也會互相阻塞，造成性能嚴重損耗。
使用 redis 分布式鎖的偽代碼，僅供參考：
public Object getData(String key) throws InterruptedException {
Object value = redis.get(key);
// 緩存值過期
if (value == null) {
// lockRedis：專門用于加鎖的redis；
// "empty"：加鎖的值隨便設置都可以
if (lockRedis.set(key, "empty", "PX", lockExpire, "NX")) {
try {
// 查詢數據庫，并寫到緩存，讓其他線程可以直接走緩存
value = getDataFromDb(key);
redis.set(key, value, "PX", expire);
} catch (Exception e) {
// 異常處理
} finally {
// 釋放鎖
lockRedis.delete(key);
}
} else {
// sleep50ms后，進行重試
Thread.sleep(50);
return getData(key);
}
}
return value;
}2）熱點數據不過期。直接將緩存設置為不過期，然后由定時任務去異步加載數據，更新緩存。
這種方式適用于比較極端的場景，例如流量特別特別大的場景，使用時需要考慮業務能接受數據不一致的時間，還有就是異常情況的處理，不要到時候緩存刷新不上，一直是臟數據，那就涼了。
描述：大量的熱點 key 設置了相同的過期時間，導在緩存在同一時刻全部失效，造成瞬時數據庫請求量大、壓力驟增，引起雪崩，甚至導致數據庫被打掛。
緩存雪崩其實有點像“升級版的緩存擊穿”，緩存擊穿是一個熱點 key，緩存雪崩是一組熱點 key。
解決方案：
1）過期時間打散。既然是大量緩存集中失效，那最容易想到就是讓他們不集中生效。可以給緩存的過期時間時加上一個隨機值時間，使得每個 key 的過期時間分布開來，不會集中在同一時刻失效。
2）熱點數據不過期。該方式和緩存擊穿一樣，也是要著重考慮刷新的時間間隔和數據異常如何處理的情況。
3）加互斥鎖。該方式和緩存擊穿一樣，按 key 維度加鎖，對于同一個 key，只允許一個線程去計算，其他線程原地阻塞等待第一個線程的計算結果，然后直接走緩存即可。
以上是“硬核Redis高頻面試題有哪些”這篇文章的所有內容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內容對大家有所幫助，如果還想學習更多知識，歡迎關注億速云行業資訊頻道！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
