1. 程式人生 > >當我們使用Redis的時候,必須要知道什麽?

當我們使用Redis的時候,必須要知道什麽?

全部 實的 詳細 www bbs 計算 緩存 redis3 論壇

當我們在開發過程中需要用到分布式緩存Redis的時候,我們首先要明白緩存在系統中用來做什麽?

  1. 少量數據存儲,高速讀寫訪問。通過數據全部in-momery 的方式來保證高速訪問,同時提供數據落地的功能,實際這正是Redis最主要的適用場景。

  2. 海量數據存儲,分布式系統支持,數據一致性保證,方便的集群節點添加/刪除。Redis3.0以後開始支持集群,實現了半自動化的數據分片,不過需要smart-client的支持。

華為雲分布式緩存Redis,目前已經進入Redis5.0公測階段,公測階段註冊既能免費使用,那麽我們在開發過程中需要用到Redisde 時候,需要明白哪些問題呢?

下面小編給大家一一道來。

一、為什麽使用 Redis?
我覺得在項目中使用 Redis,主要是從兩個角度去考慮:性能和並發。

當然,Redis 還具備可以做分布式鎖等其他功能,但是如果只是為了分布式鎖這些其他功能,完全還有其他中間件,如 ZooKpeer 等代替,並不是非要使用 Redis。因此,這個問題主要從性能和並發兩個角度去答。

性能:
如下圖所示,我們在碰到需要執行耗時特別久,且結果不頻繁變動的 SQL,就特別適合將運行結果放入緩存。這樣,後面的請求就去緩存中讀取,使得請求能夠迅速響應。

題外話:忽然想聊一下這個迅速響應的標準。根據交互效果的不同,這個響應時間沒有固定標準。

不過曾經有人這麽告訴我:"在理想狀態下,我們的頁面跳轉需要在瞬間解決,對於頁內操作則需要在剎那間解決。

另外,超過一彈指的耗時操作要有進度提示,並且可以隨時中止或取消,這樣才能給用戶最好的體驗。"

那麽瞬間、剎那、一彈指具體是多少時間呢?

根據《摩訶僧祗律》記載:

一剎那者為一念,二十念為一瞬,二十瞬為一彈指,二十彈指為一羅預,二十羅預為一須臾,一日一夜有三十須臾。

那麽,經過周密的計算,一瞬間為 0.36 秒、一剎那有 0.018 秒、一彈指長達 7.2 秒。

並發:
如下圖所示,在大並發的情況下,所有的請求直接訪問數據庫,數據庫會出現連接異常。
技術分享圖片

這個時候,就需要使用 Redis 做一個緩沖操作,讓請求先訪問到 Redis,而不是直接訪問數據庫。

二、使用 Redis 有什麽缺點?
大家用 Redis 這麽久,這個問題是必須要了解的,基本上使用 Redis 都會碰到一些問題,常見的也就幾個。

回答主要是四個問題:

◆緩存和數據庫雙寫一致性問題

◆緩存雪崩問題

◆緩存擊穿問題

◆緩存的並發競爭問題

這四個問題,我個人覺得在項目中是常遇見的,具體解決方案,後文給出。

三、單線程的 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 等多路復用函數庫,大家可以自行去了解。

當然以上三點只是皮毛而已,但卻是最基本的,如果想了解更多詳細的操作細則,可以去華為雲官方論壇與各路大手子交流經驗,大咖雲集必能學到很多東西。

文中內容轉載至公眾號“程序之心”

當我們使用Redis的時候,必須要知道什麽?