1、為什么要使用Redis做緩存？

緩存的好處

使用緩存的目的就是提升讀寫性能。而實際業務場景下，更多的是為了提升讀性能，帶來更高的并發量。

Redis的好處

• 讀取速度快，單機輕松10W+并發。
• 支持多種數據結構，包括字符串、列表、集合、有序集合、哈希等
• 擁有其他豐富的功能，主從復制、集群、數據持久化等
• 可以實現其他功能，消息隊列、分布式鎖等

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

• 項目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

2、為什么Redis單線程模型效率也能那么高？

• C語言實現，效率高： C語言程序運行時要比其他語言編寫的程序快得多，因為它“離底層機器很近”
• 單線程的優勢： 使用了單線程后可以省去多線程的CPU上下文會切換的時間，也不用去考慮鎖導致的性能消耗等問題，可維護性高
• Pipeline： Redis主要受限于內存和網絡，幾乎不會占用太多CPU。利用pipeline操作，減少命令在網絡上的傳輸時間，將多次網絡IO縮減為一次網絡IO
• 存儲實現優化： Redis的基礎數據結構每一種至少有2種及2種以上的實現，在不同的大小或長度下選用適合的數據類型，達到極致的存儲效率，從而提高寫入和讀取速度

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

• 項目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

3、Redis6.0為什么要引入多線程呢？

多線程只是針對IO線程，執行命令還是單線程。

Redis服務器可以處理80,000到100,000QPS，對于80%的公司來說，單線程的Redis已經足夠使用了。但隨著越來越復雜的業務場景，有些公司動不動就上億的交易量，因此需要更大的QPS。

所以Redis作者在6.0引入了多線程，性能提升至少一倍以上。當然集群方案也可以解決更大QPS的問題，但是集群方案還是有一些問題的：

• 常見集群方案是對數據進行分區并采用多個服務器，但該方案有非常大的缺點，例如要管理的Redis服務器太多，維護代價大
• 某些適用于單個Redis服務器的命令不適用于數據分區
• 數據分區無法解決熱點讀/寫問題；數據傾斜、重新分配變得更加復雜等等

4、Redis常見數據結構以及使用場景

字符串（String）

使用場景

• 計數： 使用Redis 作為計數的基礎工具，它可以實現快速計數、查詢緩存的功能，同時數據可以異步落地到其他數據源
• 共享Session： 使用Redis將用戶的Session進行集中管理，避免在訪問分布式服務時Session不存在導致重新登錄
• 限速： 短信接口不被頻繁訪問,例如一分鐘不能超過5次

哈希(Hash)

Java里提供了HashMap，Redis中也有類似的數據結構，就是哈希類型。但是要注意，哈希類型中的映射關系叫作field-value，注意這里的value是指field對應的值，不是鍵對應的值。

使用場景

哈希類型比較適宜存放對象類型的數據，我們可以比較下，如果數據庫中表記錄user為：

使用String類型

setuser:1{"id":1,"name":"test1","age":18};

優點：簡單直觀，每個鍵對應一個值

缺點：鍵數過多，占用內存多，用戶信息過于分散

使用hash類型

hmsetuser:1nametest1age18
hmsetuser:2nametest2age20

優點：簡單直觀，使用合理可減少內存空間消耗

列表（list）

列表( list)類型是用來存儲多個有序的字符串，a、b、c、c、b四個元素從左到右組成了一個有序的列表,列表中的每個字符串稱為元素(element)，一個列表最多可以存儲(2^32-1)個元素(4294967295)。

使用場景

• 每個用戶有屬于自己的文章列表，需要分頁展示文章列表。
• 消息隊列，Redis的lpush+rpop命令組合即可實現阻塞隊列。

集合（set）

集合( set）類型也是用來保存多個的字符串元素,但和列表類型不一樣的是，集合中不允許有重復元素,并且集合中的元素是無序的,不能通過索引下標獲取元素。

使用場景

集合類型比較典型的使用場景是標簽(tag)。例如一個用戶可能對娛樂、體育比較感興趣，另一個用戶可能對歷史、新聞比較感興趣，這些興趣點就是標簽。有了這些數據就可以得到喜歡同一個標簽的人，以及用戶的共同喜好的標簽，這些數據對于用戶體驗以及增強用戶黏度比較重要。

除此之外，集合還可以通過生成隨機數進行比如抽獎活動，以及社交圖譜等等。

有序集合（ZSET）

有序集合給每個元素設置一個分數(score)作為排序的依據。提供了獲取指定分數和元素范圍查詢、計算成員排名等功能，合理的利用有序集合，能幫助我們在實際開發中解決很多問題。

適合場景

有序集合比較典型的使用場景就是排行榜系統。例如視頻網站需要對用戶上傳的視頻做排行榜，榜單的維度可能是多個方面的:按照時間、按照播放數量、按照獲得的贊數。

5、pipeline有什么好處，為什么要用 pipeline？

Redis客戶端執行一條命令分為如下4個部分:1）發送命令2）命令排隊3）命令執行4）返回結果。

其中1和4花費的時間稱為Round Trip Time (RTT,往返時間)，也就是數據在網絡上傳輸的時間，占用了絕大多的時間。

舉個例子：Redis的客戶端和服務端兩地直線距離約為800公里，那么1次RTT時間=800 x2/ ( 300000×2/3 ) =8毫秒，(光在真空中傳輸速度為每秒30萬公里,這里假設光纖為光速的2/3 )。而Redis命令真正執行的時間通常在微秒(1000微妙=1毫秒)級別，所以才會有Redis性能瓶頸是網絡這樣的說法。

Pipeline（流水線)機制能改善上面這類問題,它能將一組Redis命令進行組裝，通過一次RTT傳輸給Redis，再將這組Redis命令的執行結果按順序返回給客戶端。

非Pipeline和Pipeline執行10000次set操作的效果，在執行時間上的比對如下：

差距有100多倍，可以得到如下兩個結論:

• Pipeline減少了網絡的開銷，執行速度一般比逐條執行要快。
• 客戶端和服務端的網絡延時越大，Pipeline的效果越明顯。

6、Redis官方為什么不提供 Windows版本？

目前Linux版本已經相當穩定，而且用戶量很大，開發windows版本，反而會帶來兼容性等問題。

7、Redis 持久化方式有哪些？以及有什么區別？

Redis 提供兩種持久化機制 RDB 和 AOF 機制

RDB

RDB（Redis DataBase）持久化是把當前進程數據生成快照保存到硬盤的過程。所謂內存快照，就是指內存中的數據在某一個時刻的狀態記錄。

優點：

• 只有一個文件 dump.rdb，方便持久化。
• 容災性好，一個文件可以保存到安全的磁盤。
• 相對于數據集大時，比AOF的啟動效率更高。

缺點：

數據安全性低。RDB是間隔一段時間進行持久化，如果持久化之間Redis發生故障，會發生數據丟失。所以這種方式更適合數據要求不嚴謹的時候。

AOF

AOF(append only file)持久化:以獨立日志的方式記錄每次寫命令，重啟時再重新執行AOF文件中的命令達到恢復數據的目的。AOF的主要作用是解決了數據持久化的實時性，目前已經是Redis持久化的主流方式。

缺點：

• AOF 文件比 RDB 文件大，且恢復速度慢。
• 數據集大的時候，比 RDB 啟動效率低。

8、什么是Redis事務？原理是什么？

Redis 中的事務是一組命令的集合，將一組需要一起執行的命令放到multi和exec兩個命令之間。multi 命令代表事務開始，exec命令代表事務結束。它可以保證一次執行多個命令，每個事務是一個單獨的隔離操作，事務中的所有命令都會序列化、按順序地執行。

但是要注意Redis的事務功能很弱。在事務回滾機制上，Redis只能對基本的語法錯誤進行判斷。

如下，當語法命令錯誤時，會造成整個事務無法執行，事務內的操作都沒有執行:

如下，當命令錯誤時，雖然有異常提示，但是事務執行成功。

9、如何在100個億URL中快速判斷某URL是否存在？

傳統數據結構HashMap

可以將值映射到 HashMap 的 Key，然后可以在 O(1) 的時間復雜度內返回結果，效率極高。

但是 HashMap 的實現也有缺點，例如存儲容量占比高，考慮到負載因子的存在，通常空間是不能被用滿的，舉個例子如果一個1000萬個int類型，會占據HashMap多少空間呢？1.2個G。實際上，1000萬個int型，只需要40M左右空間，占比3%，1000萬個Integer，需要161M左右空間，占比13.3%。可見一旦值很多例如上億的時候，那HashMap 占據的內存大小就變得很可觀了。

如果整個網頁黑名單系統包含100億個網頁URL，在數據庫查找是很費時的，并且如果每個URL空間為64B，那么需要內存為640GB，一般的服務器很難達到這個需求。

布隆過濾器

1970 年布隆提出了一種布隆過濾器的算法，用來判斷一個元素是否在一個集合中。這種算法由一個二進制數組和一個 Hash 算法組成。

相比于傳統的 List、Set、Map 等數據結構，它更高效、占用空間更少，但是缺點是其返回的結果是概率性的，而不是確切的。

布隆過濾器廣泛應用于網頁黑名單系統、垃圾郵件過濾系統、爬蟲網址判重系統等，Google 著名的分布式數據庫 Bigtable 使用了布隆過濾器來查找不存在的行或列，以減少磁盤查找的IO次數，Google Chrome瀏覽器使用了布隆過濾器加速安全瀏覽服務。

布隆過濾器的誤判問題

• 通過hash計算在數組上，因為hash沖突實際上可能不在，如下圖中的D。
• 通過hash計算在數組上，因為數組中已存在，不能確定在不在，如下圖中的C。

優化方案

• 增大數組(預估適合值)
• 增加hash函數，通過兩次Hash算法，都為1時確定為存在。

10、Redis的數據結構組織?

為了實現從鍵到值的快速訪問，Redis 使用了一個全局哈希表來保存所有鍵值對。一個哈希表，其實就是一個數組，數組的每個元素稱為一個哈希桶。所以，我們常說，一個哈希表是由多個哈希桶組成的，每個哈希桶中保存了鍵值對數據。

哈希表的最大好處很明顯，就是讓我們可以用 O(1) 的時間復雜度來快速查找到鍵值對。但是當往 Redis 中寫入大量數據后，哈希表的沖突問題和 rehash 可能帶來的操作阻塞，這里的哈希沖突，兩個 key 的哈希值和哈希桶計算對應關系時，正好落在了同一個哈希桶中。

Redis 解決哈希沖突的方式，就是鏈式哈希。鏈式哈希也很容易理解，就是指同一個哈希桶中的多個元素用一個鏈表來保存，它們之間依次用指針連接。

11、漸進式rehash是什么？

Redis 默認使用了兩個全局哈希表：哈希表 1 和哈希表 2。一開始，當你剛插入數據時，默認使用哈希表 1，此時的哈希表 2 并沒有被分配空間。隨著數據逐步增多，Redis 開始執行 rehash。

• 給哈希表 2 分配更大的空間，例如是當前哈希表 1 大小的兩倍
• 把哈希表 1 中的數據重新映射并拷貝到哈希表 2 中
• 釋放哈希表 1 的空間

在上面的第二步涉及大量的數據拷貝，如果一次性把哈希表 1 中的數據都遷移完，會造成 Redis 線程阻塞。在Redis 開始執行 rehash，Redis仍然正常處理客戶端請求，但是要加入一個額外的處理：

• 處理第1個請求時，把哈希表 1中的第1個索引位置上的所有 entries 拷貝到哈希表 2 中
• 處理第2個請求時，把哈希表 1中的第2個索引位置上的所有 entries 拷貝到哈希表 2 中

如此循環，直到把所有的索引位置的數據都拷貝到哈希表 2 中。這樣就巧妙地把一次性大量拷貝的開銷，分攤到了多次處理請求的過程中，避免了耗時操作，保證了數據的快速訪問。

審核編輯 ：李倩