我也要談談大型網站架構之系列(3)——死了都要說的緩存

我也要談談大型網站架構之系列(3)——死了都要說的緩存

 

  說到緩存,我想你們跟我同樣都很興奮,當咱們遭遇網站性能瓶頸的時候,緩存是一劑強心針,也是一粒緊急媽富隆,從而在優化網站html

性能方面冠上了第必定律的帽子,咱們前年在作淘應用的時候,就遭遇了性能瓶頸,短期內採用緩存緊急優化,給咱們大優化以前爭取了redis

寶貴的時間。算法

 

一:緩存的種類sql

     要說緩存有多少種,太多了,好比瀏覽器緩存,文件緩存,片斷緩存,數據庫緩存等等,合理利用這些緩存則能大幅度的提升系統性能,mongodb

利用很差反而會偷雞不成蝕把米,給服務器形成巨大的壓力,因此這裏就存在一個緩存的使用原則的問題。數據庫

 

二:合理的使用緩存瀏覽器

1.  讀寫小於10:1的狀況下,不適合用緩存,咱們用緩存的目的就是想分攤下數據庫的壓力以及利用內存來提速性能,若是讀寫差很少,或者緩存

     壓根就沒讀過,這樣的死數據就會形成內存資源的浪費。服務器

2.  既然是緩存,就註定了它的資源是有限的,寶貴的,也就註定了咱們必須合理利用它的內存空間,也就被迫的讓咱們清楚的認識到熱點數據,架構

   不易修改的應該放在緩存,反之不宜放。

3.  大公司在緩存方面作的好的地方就是在一個「控」字上,他們會爲緩存專門作一套「緩存系統」,當系統預加載的時候,同時也充當內存數據庫

     使用,將這些元數據加載到緩存系統中,好比「縣市區」,「分類信息」等等做爲預熱數據。

 

三:分佈式緩存

   通常狀況下,會有兩種形式,第一種就是主從複製的模式,第二種就是分片的模式。

1:主從複製模式

  這種模式曾今在項目中也用過,就是一分內存,多處備份,當其中某一個緩存內容中的數據有變化時,會及時通知其餘機器進行緩存更新

或清除,這種模式的缺點在於比較容易受制於單臺機器的內存限制,優勢在於用心跳機制及時用另外一臺緩存機器頂替,那個時候咱們使用120G

的大內存,得益於項目業務規模的限制,不然當機器內存爆滿的時候就比較尷尬了,因此作大型網站仍是謹慎使用吧,畢竟這個也是咱們曾今作

了一些爲了提高性能的嘗試。

 

2:分片的模式

    這種模式在大型網站中仍是被大量使用的,它的特色就是能夠把一大坨數據經過必定的算法和配置分攤到集羣中的若干臺機器上,若是集羣中

的某一臺機器掛了,不要緊,只會影響到該臺機器中的數據,對數據庫不會形成很大的影響。一個典型的應用就是memcache,memcache是一

個很是簡單,實用,高效的分佈式緩存架構,其實memcache最值得一提的就是「路由算法的一致性hash」技術使得咱們的memcache集羣能夠

自由伸縮,不過如今已經有不少的nosql產品,好比redis,couchdb,mongodb等等,讓咱們在這個世界上有了更多的選擇吧。

 

最近看到園子裏面有不少抱怨聲,不要緊,若是以爲本身屈才了,歡迎來攜程試一試,只有你達不到的能力,沒有給不起你的薪資。

相關文章
相關標籤/搜索