redis 實際應(yīng)用中的緩存作用

有人說互聯(lián)網(wǎng)用戶是用腳投票的，這句話其實也從側(cè)面說明了，用戶體驗是多么的重要；這就要求在軟件架構(gòu)設(shè)計時，不但要注重可靠性、安全性、可擴展性以及可維護性等等的一些指標，更要注重用戶的體驗，用戶體驗分很多方面，但是有一點非常重要就是對用戶操作的響應(yīng)一定要快；怎樣提高用戶訪問的響應(yīng)速度，這就是擺在架構(gòu)設(shè)計中必須要解決的問題；說道提高服務(wù)的響應(yīng)速度就不得不說緩存了；

從系統(tǒng)的層面說，CPU的速度遠遠高于磁盤IO的速度；所以要想提高響應(yīng)速度，必須減少磁盤IO的操作，但是有很多信息又是存在數(shù)據(jù)庫當中的，每次查詢數(shù)據(jù)庫就是一次IO操作；比如查詢用戶信息的例子，通常如下圖：

?

請求響應(yīng)時間等于網(wǎng)絡(luò)響應(yīng)時間和服務(wù)器響應(yīng)時間；網(wǎng)絡(luò)我們控制不了，服務(wù)器響應(yīng)時間包括CPU計算時間和磁盤IO時間，其中CPU計算時間這個有硬件資源決定的，我們盡量減少算法的復(fù)雜度來減少它，磁盤IO時間，這個時間是非常慢的，應(yīng)該盡量減少；

當客戶端調(diào)用getUser接口的查詢用戶信息的時候，執(zhí)行順序1、2、3、4；由于用戶信息存放在DB中，所以2、3就有一次磁盤IO；這個看似非常簡單業(yè)務(wù)邏輯，但是當你做架構(gòu)設(shè)計的時候往往要考慮最壞的場景，或者當成千上萬的用戶頻繁的調(diào)用這個接口應(yīng)該怎么處理？如果按照上圖這樣的架構(gòu)處理，這個看似簡單業(yè)務(wù)的接口會使整個系統(tǒng)變慢，這樣用戶的請求就會長時間得不到響應(yīng)；這樣的問題怎么解決那，這時候就該緩存登場了；

談到緩存有幾種形式，其中最簡單的是在每個進程中開辟一塊內(nèi)存，存放緩存的信息，每次先從內(nèi)存查… … ?但是在一個分布式或者集群的環(huán)境中，getUser的接口可能會部署多套，每個進程的的內(nèi)存是不能共享、相互獨立的，這就悲劇了；還有一種使用一個第三方的緩存也叫公共緩存（比如redis、memcache等）；不論部署多少個包含getUser接口的服務(wù)，都去訪問同一套緩存，那結(jié)果就不一樣了，看一下下面這幅圖：

?

當用客戶端調(diào)用getUser接口查詢用戶信息的時候，getUser接口直接去redis中查詢，如果redis中有該用戶信息，直接返回，避免查詢DB，從而避免了磁盤IO操作；如果redis中沒有該用戶信息，則從DB查詢，并且把該用戶信息存放到redis中；這樣在服務(wù)接口（getUser）和DB中間，增加了一個緩存層；看似邏輯增加了，其實當面對高并發(fā)的時候，比如上邊提到的頻繁查詢用戶信息的情況，只有第一次查詢有磁盤IO操作，以后只要redis中存在就沒必要再查詢數(shù)據(jù)庫了；由于沒有了磁盤IO操作，并且redis所有數(shù)據(jù)都在內(nèi)存操作，所以速度回大大提升；

我們上面用到的緩存是redis，其實常用的還有memcache等，它們都提供了集群模式，并且都是直接內(nèi)存操作，所以速度特別快，也是目前業(yè)內(nèi)使用的比較熱門的技術(shù)；redis相對于memcache提供了更豐富的數(shù)據(jù)類型，根據(jù)不同的業(yè)務(wù)場景可以選在不同的數(shù)據(jù)類型；redis本身也提供了主從模式、集群模式；也有第三方的比如codis提供了redis集群解決方案；這次咱們主要聊緩存在架構(gòu)設(shè)計中的作用，等有機會詳細介紹redis的使用；

總之一句話，要想提高系統(tǒng)的性能，盡量減少IO的操作，特別是磁盤IO的操作；使用緩存可以有效的避免這種情況；所以在架構(gòu)設(shè)計過程中，社交到查詢數(shù)據(jù)庫的時候，應(yīng)該考慮一下是不是考慮使用緩存技術(shù)來提高系統(tǒng)的性能，并且降低數(shù)據(jù)庫的負載。

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的redis 实际应用中的缓存作用的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。