#### Redis 實際應用中的緩存作用 * * * * * 在軟件架構設計時，不但要注重可靠性、安全性、可擴展性以及可維護性等等的一些指標，更要注重用戶的體驗，用戶體驗分很多方面，但是有一點非常重要就是對用戶操作的響應；怎樣提高用戶訪問的響應速度，這就是擺在架構設計中必須要解決的問題；說到提高服務的響應速度就不得不說緩存了；從系統的層面說，CPU的速度遠遠高于磁盤IO的速度；所以要想提高響應速度，必須減少磁盤IO的操作，但是有很多信息又是存在數據庫當中的，每次查詢數據庫就是一次IO操作；比如查詢用戶信息的例子，通常如下圖：  請求響應時間等于網絡響應時間和服務器響應時間；網絡我們控制不了，服務器響應時間包括CPU計算時間和磁盤IO時間，其中CPU計算時間這個有硬件資源決定的，我們盡量減少算法的復雜度來減少它，磁盤IO時間，這個時間是非常慢的，應該盡量減少； 當客戶端調用getUser接口的查詢用戶信息的時候，執行順序1、2、3、4；由于用戶信息存放在DB中，所以2、3就有一次磁盤IO；這個看似非常簡單業務邏輯，但是當你做架構設計的時候往往要考慮最壞的場景，或者當成千上萬的用戶頻繁的調用這個接口應該怎么處理？如果按照上圖這樣的架構處理，這個看似簡單業務的接口會使整個系統變慢，這樣用戶的請求就會長時間得不到響應；這樣的問題怎么解決那，這時候就該緩存登場了； 談到緩存有幾種形式，其中最簡單的是在每個進程中開辟一塊內存，存放緩存的信息，每次先從內存查… … 但是在一個分布式或者集群的環境中，getUser的接口可能會部署多套，每個進程的的內存是不能共享、相互獨立的，這就悲劇了；還有一種使用一個第三方的緩存也叫公共緩存（比如redis、memcache等）；不論部署多少個包含getUser接口的服務，都去訪問同一套緩存，那結果就不一樣了，看一下下面這幅圖：  當用客戶端調用getUser接口查詢用戶信息的時候，getUser接口直接去redis中查詢，如果redis中有該用戶信息，直接返回，避免查詢DB，從而避免了磁盤IO操作；如果redis中沒有該用戶信息，則從DB查詢，并且把該用戶信息存放到redis中；這樣在服務接口（getUser）和DB中間，增加了一個緩存層；看似邏輯增加了，其實當面對高并發，頻繁查詢用戶信息的時候，只有第一次查詢有磁盤IO操作，以后只要redis中存在就沒必要再查詢數據庫了；redis所有數據都在內存操作，由于沒有了磁盤IO操作，所以速度將會大大的提升； 我們上面用到的緩存是redis，其實常用的還有memcache等，它們都提供了集群模式，并且都是直接內存操作，所以速度特別快，也是目前業內使用的比較熱門的技術；redis相對于memcache提供了更豐富的數據類型，根據不同的業務場景可以選在不同的數據類型；redis本身也提供了主從模式、集群模式；也有第三方的比如codis提供了redis集群解決方案；這次咱們主要聊緩存在架構設計中的作用，等有機會詳細介紹redis的使用； 總之一句話，要想提高系統的性能，盡量減少IO的操作，特別是磁盤IO的操作；使用緩存可以有效的避免這種情況；所以在架構設計過程中，社交到查詢數據庫的時候，應該考慮一下是不是考慮使用緩存技術來提高系統的性能，并且降低數據庫的負載。 * * * * * 轉載于：http://blog.csdn.net/weis_2007/article/details/50678281