當咱們使用Redis的時候，必需要知道什麼？

時間 2021-01-04

標籤 html 程序員面試 redis 數據庫緩存架構併發分佈式函數欄目 Redis 简体版

原文原文鏈接

當咱們在開發過程當中須要用到分佈式緩存Redis的時候，咱們首先要明白緩存在系統中用來作什麼？html

少許數據存儲，高速讀寫訪問。經過數據所有in-momery 的方式來保證高速訪問，同時提供數據落地的功能，實際這正是Redis最主要的適用場景。
海量數據存儲，分佈式系統支持，數據一致性保證，方便的集羣節點添加/刪除。Redis3.0之後開始支持集羣，實現了半自動化的數據分片，不過須要smart-client的支持。

華爲雲分佈式緩存Redis，目前已經進入Redis5.0公測階段，公測階段註冊既能無償使用，那麼咱們在開發過程當中須要用到Redisde 時候，須要明白哪些問題呢？程序員

下面小編給你們一一道來。面試

1、爲何使用 Redis？

我以爲在項目中使用 Redis，主要是從兩個角度去考慮：性能和併發。redis

固然，Redis 還具有能夠作分佈式鎖等其餘功能，可是若是隻是爲了分佈式鎖這些其餘功能，徹底還有其餘中間件，如 ZooKpeer 等代替，並非非要使用 Redis。所以，這個問題主要從性能和併發兩個角度去答。數據庫

性能：
以下圖所示，咱們在碰到須要執行耗時特別久，且結果不頻繁變更的 SQL，就特別適合將運行結果放入緩存。這樣，後面的請求就去緩存中讀取，使得請求可以迅速響應。緩存

題外話：突然想聊一下這個迅速響應的標準。根據交互效果的不一樣，這個響應時間沒有固定標準。
不過曾經有人這麼告訴我："在理想狀態下，咱們的頁面跳轉須要在瞬間解決，對於頁內操做則須要在剎那間解決。另外，超過一彈指的耗時操做要有進度提示，而且能夠隨時停止或取消，這樣才能給用戶最好的體驗。"
那麼瞬間、剎那、一彈指具體是多少時間呢？
根據《摩訶僧祗律》記載：
一剎那者爲一念，二十念爲一瞬，二十瞬爲一彈指，二十彈指爲一羅預，二十羅預爲一須臾，一日一晚上有三十須臾。
那麼，通過周密的計算，一瞬間爲 0.36 秒、一剎那有 0.018 秒、一彈指長達 7.2 秒。

併發：
以下圖所示，在大併發的狀況下，全部的請求直接訪問數據庫，數據庫會出現鏈接異常。
架構

這個時候，就須要使用 Redis 作一個緩衝操做，讓請求先訪問到 Redis，而不是直接訪問數據庫。併發

2、使用 Redis 有什麼缺點？

你們用 Redis 這麼久，這個問題是必需要了解的，基本上使用 Redis 都會碰到一些問題，常見的也就幾個。分佈式

回答主要是四個問題：函數

這四個問題，我我的以爲在項目中是常碰見的。

3、單線程的 Redis 爲何這麼快？

這個問題是對 Redis 內部機制的一個考察。根據個人面試經驗，不少人都不知道 Redis 是單線程工做模型。因此，這個問題仍是應該要複習一下的。

回答主要是如下三點：

◆純內存操做

◆單線程操做，避免了頻繁的上下文切換

◆採用了非阻塞 I/O 多路複用機制

題外話：咱們如今要仔細的說一說 I/O 多路複用機制，由於這個說法實在是太通俗了，通俗到通常人都不懂是什麼意思。
打一個比方：小曲在 S 城開了一家快遞店，負責同城快送服務。小曲由於資金限制，僱傭了一批快遞員，而後小曲發現資金不夠了，只夠買一輛車送快遞。

經營方式一：

客戶每送來一份快遞，小曲就讓一個快遞員盯着，而後快遞員開車去送快遞。

慢慢的小曲就發現了這種經營方式存在下述問題：

◆幾十個快遞員基本上時間都花在了搶車上了，大部分快遞員都處在閒置狀態，誰搶到了車，誰就能去送快遞。

◆隨着快遞的增多，快遞員也愈來愈多，小曲發現快遞店裏愈來愈擠，沒辦法僱傭新的快遞員了。

◆快遞員之間的協調很花時間。

綜合上述缺點，小曲痛定思痛，提出了下面的經營方式。

經營方式二：

小曲只僱傭一個快遞員。而後呢，客戶送來的快遞，小曲按送達地點標註好，而後依次放在一個地方。

最後，那個快遞員依次的去取快遞，一次拿一個，而後開着車去送快遞，送好了就回來拿下一個快遞。

上述兩種經營方式對比，是否是明顯以爲第二種，效率更高，更好呢？

在上述比喻中：

◆每一個快遞員→每一個線程

◆每一個快遞→每一個 Socket(I/O 流)

◆快遞的送達地點→Socket 的不一樣狀態

◆客戶送快遞請求→來自客戶端的請求

◆小曲的經營方式→服務端運行的代碼

◆一輛車→CPU 的核數

因而咱們有以下結論：

經營方式一就是傳統的併發模型，每一個 I/O 流(快遞)都有一個新的線程(快遞員)管理。

經營方式二就是 I/O 多路複用。只有單個線程(一個快遞員)，經過跟蹤每一個 I/O 流的狀態(每一個快遞的送達地點)，來管理多個 I/O 流。

下面類比到真實的 Redis 線程模型，如圖所示：

簡單來講，就是咱們的 redis-client 在操做的時候，會產生具備不一樣事件類型的 Socket。

在服務端，有一段 I/O 多路複用程序，將其置入隊列之中。而後，文件事件分派器，依次去隊列中取，轉發到不一樣的事件處理器中。

須要說明的是，這個 I/O 多路複用機制，Redis 還提供了 select、epoll、evport、kqueue 等多路複用函數庫，你們能夠自行去了解。

固然以上三點只是皮毛而已，但倒是最基本的，若是想了解更多詳細的操做細則，能夠去華爲雲官方論壇與各路大手子交流經驗，大咖雲集必能學到不少東西。

針對於上面所涉及到的知識點我總結出了有1到5年開發經驗的程序員在面試中涉及到的絕大部分架構面試題及答案作成了文檔和架構視頻資料免費分享給你們（包括Dubbo、Redis、Netty、zookeeper、Spring cloud、分佈式、高併發等架構技術資料），但願能幫助到您面試前的複習且找到一個好的工做，也節省你們在網上搜索資料的時間來學習，也能夠關注我一下之後會有更多幹貨分享。