緩存指的是將需要頻繁訪問的網絡內容存放在離用戶較近、訪問速度更快的系統中，以提高內容訪問速度的一種技術。緩存服務器就是存放頻繁訪問內容的服務器。

上面的這種說法是一種通俗的說法。在具體的項目架構中，緩存服務，往往指的把一些用戶頻繁訪問的資源放入到內存里面。收到數據快速返還給用戶。舉一個簡單的例子

通過上面的模型我們看出，當用戶量少，這個訪問速度還是可以接受。但是當用戶量上來以后，可能對服務器造成致命性的打擊。大家都知道查詢數據庫或者讀取文件 這是非常耗時的操作。當用戶量少的時候，你或許感覺不出來速度的快慢。但是仔細想想當用戶是成千上萬的時候就會導致數據庫的擁堵從而導致這個服務的宕機。

在上面的模型中我們很容易想到的解決方案是，1.增加數據庫的配置，來滿足更多用戶的同時訪問，2. 想辦法在登錄服務器和數據庫 之間增加一層緩存層，把用戶的熱點數據放到內存里面不需要每次都請求數據庫。

第一種方案仔細想一想是行不通的，因為硬件資源是有限。不能無限制的增加數據庫的配置來滿足我們的需求。

第二種方案使我們目前想到的最優解決方案了。我們可以通過軟件層面的問題來解決一些硬件層面的問題。所以這個請求就會變成下面的這個圖

上面的這個圖目前可以說是我能想到的最優解決方案了，當用戶訪問緩存服務沒有數據的時候就會從數據庫服務拉去數據，同時在緩存服務里面留下緩存，下次用戶再訪問的時候就會從緩存服務直接返回給用戶，因為數據都在內存里面所以速度會很快。

不過這個時候有人會可能看出問題來，那就是數據的一致性問題，因為同一份數據在 緩存和數據庫都有。所以我說這方面目前的方案是最優的但不是最好的。多一個地方存儲數據，肯定會增加數據不一直的風險，這或許就是魚和熊掌不可兼得。不過我們目前用它肯定是利大于弊。因為可以服務更多的用戶。數據的一致性我們可以想很多的方案盡量來減少數據的不一致性。

不過緩存服務對于那些很久都不變一次的數據，絕對是一個利器，比如我們在游戲里面的排行榜，根本不需要做到實時變化。而這個數據又是一個熱點數據，查詢量居多。這個時候就體驗到了 緩存服務帶來的快感。

現在比較成熟的數據服務器 有redis 和 Memcache ，這兩種服務各有優缺點，大家可以根據自己的項目選擇。還有一種就是自己實現的。不過這些需要注意在使用的時候不能亂用，例如大家都知道 現在這種做法其實是拿空間換的時間，這里的空間大多指的是內存，內存也是硬件，所以肯定不能無線擴展。所以一定要定好淘汰策略，來釋放內存。很多情況下需要根據自己的業務來定制這個淘汰策略，例如我們的用戶信息在內存里面是緩存6個小時，這個是通過分析我們的用戶行為之后得到的數據。所以這個度大家一定要把握好。

寫了這么多，其實就是告訴大家項目架構的演化，都是在需求中進化出來。當你在實現一個業務功能的時候可以想的更多。上面的模型其實是很簡單的項目模型了在實際項目中，我們還會出現二級緩存，三級緩存 等等。在開發游戲服務器斷時 能讓用戶多塊拿到數據就多塊，要不整個游戲體驗就感覺特別的卡。