redis相關知識點及面試點有哪些

這篇文章主要介紹了redis相關知識點及面試點有哪些的相關知識，內容詳細易懂，操作簡單快捷，具有一定借鑒價值，相信大家閱讀完這篇redis相關知識點及面試點有哪些文章都會有所收獲，下面我們一起來看看吧。

四、Redis為什么這么快

1、完全基于內存，絕大部分請求是純粹的內存操作，非常快速。數據存在內存中，類似于HashMap，HashMap的優勢就是查找和操作的時間復雜度都是O(1)；

2、數據結構簡單，對數據操作也簡單，Redis中的數據結構是專門進行設計的；

3、采用單線程，避免了不必要的上下文切換和競爭條件，也不存在多進程或者多線程導致的切換而消耗 CPU，不用去考慮各種鎖的問題，不存在加鎖釋放鎖操作，沒有因為可能出現死鎖而導致的性能消耗；

4、使用多路I/O復用模型，非阻塞IO；

5、使用底層模型不同，它們之間底層實現方式以及與客戶端之間通信的應用協議不一樣，Redis直接自己構建了VM 機制 ，因為一般的系統調用系統函數的話，會浪費一定的時間去移動和請求；

以上幾點都比較好理解，下邊我們針對多路 I/O 復用模型進行簡單的探討：

（1）多路 I/O 復用模型

多路I/O復用模型是利用 select、poll、epoll 可以同時監察多個流的 I/O 事件的能力，在空閑的時候，會把當前線程阻塞掉，當有一個或多個流有 I/O 事件時，就從阻塞態中喚醒，于是程序就會輪詢一遍所有的流（epoll 是只輪詢那些真正發出了事件的流），并且只依次順序的處理就緒的流，這種做法就避免了大量的無用操作。

這里“多路”指的是多個網絡連接，“復用”指的是復用同一個線程。采用多路 I/O 復用技術可以讓單個線程高效的處理多個連接請求（盡量減少網絡 IO 的時間消耗），且 Redis 在內存中操作數據的速度非常快，也就是說內存內的操作不會成為影響Redis性能的瓶頸，主要由以上幾點造就了 Redis 具有很高的吞吐量。

緩存穿透：緩存當中沒有 數據庫當中也沒有

解決方法：緩存空對象 布隆過濾器

緩存空對象：如果redis中沒有，數據庫中也沒查到，就在redis中填加一個這個key對應的空對象。下次判斷的時候 如果在redis中查到這個空對象，就說明查詢不到數據。缺點：會創造大量的空對象，并且還要設置過期時間。

布隆過濾器：

輸入太白  進行三次hash 將得到的值標記為1 其他的以此類推 等以后找的時候也是三次hash 能找到就是可能存在 有一個找不到就是絕對不存在

如果你輸入一個不存在的 但是三次hash都為1 還是可能存在的  這時候就屬于誤觸了

誤觸率跟hash次數和長度有關  布隆過濾器缺點：需要維護 ；不能刪除

redis底層保存的數據是位數組

點贊需求以及使用redis的解決思路。第一種點贊需求是比較常規的點贊需求，類似于微博那種點贊模式，用戶可以對某條信息點贊、取消點贊、查詢是否點贊、被點贊次數等等；第二種點贊稍微特殊，用戶可以在一天內對任意用戶點贊，取消點贊后不可以再次對同用戶點贊，第二天限制解除，可以重新對同一玩家點贊（也就是說點贊是可以累加的），然后還有一個需求是要求可以實時查用戶獲贊次數全局的排行情況。

需求一解決思路

對于需求一，采用的是redis bitmap來實現。

bitmap簡介

bitmap

bitmap是一連串的二進制數字(0,1)，每一位所在的位置為偏移(offset)，在bitmap上可以執行AND,OR,XOR以及其他操作。

位圖計數

位圖計數的意思是統計bitmap中值為1的位的個數，位圖計數的效率是很高的。

redis bitmap

redis中允許使用二進制的Key和二進制的Value，bitmap就是二進制的Value。

點贊/取消點贊

假設用戶的數字id為1000，對照片id為100的照片點贊。首先根據照片id生成贊數據存儲的redis key，比如生成策略為like_photo:{photo_id}，id為1000的用戶點贊，只需要將like_photo:100的第1000位置為1即可（取消贊則置為0）。

redis setbit操作的時間復雜度為O(1)，所以這種點贊方式十分高效。

123

redis.setbit('like_photo:100', 1000, 1, function(err, ret){    // deal err and ret.});

當前是否點贊

用戶打開圖片的時候需要查詢當前是否點贊過該照片，查詢是否點贊可以通過redis getbit操作來實現。比如查詢用戶id為1000的用戶是否點贊過照片id為100的照片，只需要對like_photo:100bitmap的第1000位取值即可。

redis getbit操作的時間復雜度同樣是O(1)。

1234

redis.getbit('like_photo:100', 1000, function(err, liked){    // deal err.    // if liked==1 liked, liked==0 not like yet.});

查詢點贊總次數

比如需要顯示照片id為100的照片的獲贊次數，只需要對like_photo:100bitmap進行位圖計數操作即可。

redis bitcount操作的時間復雜度雖然是O(N)的，但是大部分數據量的情況下是不需要擔心bitcount效率問題的。

123

redis.bitcount('like_photo:100', function(err, likeCnt){    // deal with err and likeCnt.});

緩存擊穿：數據庫有數據 但是緩存中沒數據或者緩存的數據恰好失效的時候 突然大量的訪問過來  此時會訪問數據造成數據庫崩潰

解決方法  分布式鎖

99個請求過來的時候  先放行一個進去   此時在redis中沒有緩存 然后會新建一個  然后解鎖 這時候剩下的98個就可以讀到緩存了

緩存雪崩  大部分緩存失效 或者redis崩潰了

解決辦法 搭建高可用集群 或者過期時間錯開

如何保持數據庫與緩存一致性

redis和mysql數據一致性的問題

在這里，我們討論三種更新策略：

1. 先更新緩存，再更新數據庫

2. 先更新數據庫，再更新緩存

3. 先刪除緩存，再更新數據庫

4. 先更新數據庫，再刪除緩存

第一種，先更新緩存，再更新數據庫

問題：更新緩存成功，更新數據庫失敗，導致數據不一致。

第二種，先更新數據庫，再更新緩存

問題：

1、A更新數據庫

2、B更新數據庫

3、B寫入緩存

4、A寫入緩存

出現數據不一致。

考慮另一種情況， 有如下兩點：
（1）如果你是一個寫數據庫場景比較多，而讀數據場景比較少的業務需求，采用這種方案就會導致，數據壓根還沒讀到，緩存就被頻繁的更新，浪費性能。
（2）如果你寫入數據庫的值，并不是直接寫入緩存的，而是要經過一系列復雜的計算再寫入緩存。那么，每次寫入數據庫后，都再次計算寫入緩存的值，無疑是浪費性能的。顯然，刪除緩存更為適合。

第三種，先刪除緩存，再更新數據庫。

問題：

1、A刪除緩存

2、B查詢數據庫獲取舊值

3、B更新了緩存

4、A更新數據庫

出現數據不一致的問題

延時雙刪

public void write(String key,Object data){
	redis.delKey(key);
	db.updateData(data);
	Thread.sleep(1000);
	redis.delKey(key);
}

問題一：延時雙刪，演變成了：先更新數據庫，再刪除緩存。。。。

比如：

1、A刪除緩存

2、B查詢數據庫獲取舊值

3、B更新了緩存

4、A更新數據庫

5、A延時刪緩存

1～3步執行后，數據庫和緩存是一致的，相當于沒刪除。

4～5步：先更新數據庫，再刪緩存。

所以延時雙刪演變成了：先更新數據庫，再刪除緩存。問題還是沒解決。。。

為什么？假設，此時，在第4步執行之前，又來了個查詢C，C查詢到舊值。第6步：C將舊值插入緩存。此時出現緩存和數據庫不一致。

延時并不能解決：C插入緩存的操作在第5步后面執行，比如C遇到網絡問題、GC問題等。當然這是小概率，但并不代表不存在。

當然，延時越長，這個問題越能規避。如果業務需求不是非常嚴格，是可以忽略的。

問題二：吞吐量

問題三：數據庫更新后，無法保證下一次查詢，從緩存獲取的值和數據庫是一致的。

第四種，先更新數據庫，再刪除緩存

問題：上面C的查詢，已經說明問題了。

出現數據不一致的概率，比較小。采取這個方案，取決于業務需求。

終極方案

請求串行化

真正靠譜的方案：將訪問操作串行化

1. 先刪緩存，將更新數據庫的操作放進有序隊列中

2. 從緩存查不到的查詢操作，都進入有序隊列

需要解決的問題：

1. 讀請求積壓，大量超時，導致數據庫的壓力：限流、熔斷

2. 如何避免大量請求積壓：將隊列水平拆分，提高并行度。

3. 保證相同請求路由正確。

關于“redis相關知識點及面試點有哪些”這篇文章的內容就介紹到這里，感謝各位的閱讀！相信大家對“redis相關知識點及面試點有哪些”知識都有一定的了解，大家如果還想學習更多知識，歡迎關注億速云行業資訊頻道。