有人說互聯網用戶是用腳投票的，這句話其實也從側面說明了，用戶體驗是多麼的重要；這就要求在軟件架構設計時，不但要注重可靠性、安全性、可擴展性以及可維護性等等的一些指標，更要注重用戶的體驗，用戶體驗分很多方面，但是有一點非常重要就是對用戶操作的響應一定要快；怎樣提高用戶訪問的響應速度，這就是擺在架構設計中必須要解決的問題；說道提高服務的響應速度就不得不說緩存了；
從系統的層面說，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中存在就沒必要再查詢數據庫了；由於沒有了磁盤IO操作，並且redis所有數據都在內存操作，所以速度回大大提升；
我們上面用到的緩存是redis，其實常用的還有memcache等，它們都提供了集羣模式，並且都是直接內存操作，所以速度特別快，也是目前業內使用的比較熱門的技術；redis相對於memcache提供了更豐富的數據類型，根據不同的業務場景可以選在不同的數據類型；redis本身也提供了主從模式、集羣模式；也有第三方的比如codis提供了redis集羣解決方案；這次咱們主要聊緩存在架構設計中的作用，等有機會詳細介紹redis的使用；
總之一句話，要想提高系統的性能，儘量減少IO的操作，特別是磁盤IO的操作；使用緩存可以有效的避免這種情況；所以在架構設計過程中，社交到查詢數據庫的時候，應該考慮一下是不是考慮使用緩存技術來提高系統的性能，並且降低數據庫的負載。
轉載於：http://blog.csdn.net/weis_2007/article/details/50678281