為什么要使用Redis做緩存？

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

緩存的好處

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

Redis的好處

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

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

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

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

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

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

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

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

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

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

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

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

4、Redis常見數(shù)據(jù)結構以及使用場景

字符串（String）

使用場景

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

哈希(Hash)

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

使用場景

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

使用String類型

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

優(yōu)點：簡單直觀，每個鍵對應一個值

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

使用hash類型

hmsetuser:1nametest1age18
hmsetuser:2nametest2age20

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

列表（list）

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

使用場景

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

集合（set）

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

使用場景

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

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

有序集合（ZSET）

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

適合場景

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

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

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

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

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

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

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

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

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

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

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

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

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

RDB

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

優(yōu)點：

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

缺點：

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

AOF

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

缺點：

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

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

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

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

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

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

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

傳統(tǒng)數(shù)據(jù)結構HashMap

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

但是 HashMap 的實現(xiàn)也有缺點，例如存儲容量占比高，考慮到負載因子的存在，通常空間是不能被用滿的，舉個例子如果一個1000萬個int類型，會占據(jù)HashMap多少空間呢？1.2個G。實際上，1000萬個int型，只需要40M左右空間，占比3%，1000萬個Integer，需要161M左右空間，占比13.3%?？梢娨坏┲岛芏嗬缟蟽|的時候，那HashMap 占據(jù)的內存大小就變得很可觀了。

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

布隆過濾器

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

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

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

布隆過濾器的誤判問題

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

優(yōu)化方案

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

10、Redis的數(shù)據(jù)結構組織?

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

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

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

11、漸進式rehash是什么？

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

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

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

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

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

審核編輯 ：李倩