海量圖片的分布式存儲設(shè)計與實現(xiàn)

海量圖片的分布式存儲設(shè)計與實現(xiàn)一、爭論背景：性能與資金，二者可兼得？那么問題來了？〔如淘寶、京東等電子商務(wù)網(wǎng)站〕時，網(wǎng)頁中的圖片信息占據(jù)了頁面數(shù)據(jù)流量的很大局部，那么問題也來了：，無法從一臺效勞器上同時下載頁面中全部圖片信息；文字和圖片以提高掃瞄速度。因此，頁面中圖片越多Web就越大。同時由于受到掃瞄器本身的并發(fā)連接數(shù)限制(2個～6個并發(fā))，意味著示。I/O：因此當(dāng)并發(fā)用戶數(shù)越來越多時，I/O性能瓶頸；由于受操作系統(tǒng)的限制,一個名目中能存放的圖片文件數(shù)量也是有限的：隨著圖片資源不斷增加，如何有效治理和維護圖片也是一個難題；如何解決問題？對于少數(shù)大型網(wǎng)站系統(tǒng)，由于自身具有雄厚的資金和人力資源，可承受NFS、CDN、Ligd、反向代理、負(fù)載均衡等技術(shù)提高用戶訪問速度；但是，這些技術(shù)需要浩大的資金來支持。對于多數(shù)中小型網(wǎng)站系統(tǒng)，有沒有一種方案適用于中等規(guī)模商務(wù)網(wǎng)站的海量圖片數(shù)據(jù)分布式動態(tài)存儲及負(fù)載均衡的解決方案？該方案可否只需增加器的數(shù)量及圖片的存儲名目，確保系統(tǒng)具有可擴展性和伸縮性。二、架構(gòu)設(shè)計：構(gòu)建圖片效勞器集群有海量級的圖片文件，所承受的技術(shù)更是涉及廣泛，從硬件到軟件、編程語言、數(shù)據(jù)庫、Web效勞器、防火墻等各個領(lǐng)域都有較高要求。因此，有必要設(shè)立單獨的圖片效勞器來特地存放圖片，把圖片數(shù)據(jù)的流量從Web效勞器上分別開，這樣的架構(gòu)可以有效緩解WebI/O系統(tǒng)設(shè)計目標(biāo)基于以上的考慮，我們期望的設(shè)計目標(biāo)是：圖片能進展分布式存儲；圖片效勞器能實現(xiàn)負(fù)載均衡；點；系統(tǒng)的正常運行；〔1〕和2〕是針對系統(tǒng)的高可用和伸縮性，而3〕和4〕對系統(tǒng)的高可用和可擴展而言的。系統(tǒng)架構(gòu)設(shè)計系統(tǒng)整體架構(gòu)如上圖所示：包括客戶端、Web效勞器、數(shù)據(jù)庫效勞器、圖4用戶掃瞄網(wǎng)頁時，Web效勞器響應(yīng)懇求并訪問數(shù)據(jù)庫效勞器，獲得網(wǎng)頁中全部URLURL效勞器下載并顯示相應(yīng)圖片。同時需要記錄全部圖片效勞器的配置及當(dāng)前狀態(tài)信息。可以依據(jù)需要動態(tài)增加或刪減。三、系統(tǒng)實現(xiàn)：一種簡潔且價廉可用的方案數(shù)據(jù)庫設(shè)計與實現(xiàn)：兩張簡潔的表Web效勞器需要準(zhǔn)時把握全部圖片效勞器的狀態(tài)和信息才能動態(tài)打算把圖地看出，圖片效勞器信息表中記錄了圖片效勞器的ID、名稱、URL、最大存儲數(shù)量、當(dāng)前已存數(shù)量以及效勞器的狀態(tài)：不行用，每個圖片效勞器下會有多個圖片信息記錄，因此它們是一對多的關(guān)系。圖片效勞器狀態(tài)信息表建表語句：圖片記錄信息表建表語句：是：保存；由客戶端掃瞄器對圖片路徑向圖片效勞器集群進展懇求；Controller圖片上傳的過程比較簡單，首先Web效勞器接收客戶端的訪問懇求WebGetAllUseableServersFlgUsabletrueCurPicAmountMaxPicAmount最大存儲量這兩個條件。假設(shè)有宕機或不行用的狀況，需要治理員將那一行的FlgUsablefalse。publicList<ImageServerInfo>GetAllUseableServers{List<ImageServerInfo>serverList=db.ImageServerInfo.Where<ImageServerInfo>(s=>s.FlgUsable==true&&s.CurPicAmount<s.MaxPicAmount).ToList;returnserverList;}這里用到了一個GetServerIndex的方法，它的實現(xiàn)如下：從圖片效勞N。然后用隨機函數(shù)產(chǎn)生一個隨機數(shù)R1，用R1與N進展取余運算記作I=R1%N。則C[I〔固然，我們可以設(shè)計一個更加高效的，類似于一致性哈希算法的哈希函數(shù)〕#region01.獵取效勞器索引號///<summary>///01.獵取效勞器索引號///</summary>///<paramname=“serverCount“>效勞器數(shù)量</param>///<returns>索引號</returns>publicstaticintGetServerIndex(intserverCount){Randomrand=newRandom;intrandomNumber=rand.Next;intserverIndex=randomNumber%serverCount;returnserverIndex;}#endregion圖片的字節(jié)流轉(zhuǎn)交給了具體的圖片效勞器處理程序：Web端程序的工作就到此完畢，但是這里木有承受異步，因此需要等待圖片效勞器的工作完畢。WebClientclientnewWebClient;client.UploadData(serverFullUrl,類向具體的圖片效勞器發(fā)送懇求，或者是通過在圖片效勞器上部署WebServiceWebView上傳頁面：formenctype=“multipart/form-data“掃瞄頁面：這里主要通過對不同的圖片效勞器發(fā)送懇求獵取圖片，從而降低WebI/O這是一個簡潔的一般處理程序，它首先接收要保存的圖片擴展名以及效勞器ID，依據(jù)規(guī)章生成具體的保存路徑，然后通過I/O流將圖片保存到該效勞器的磁盤上；最終將更改數(shù)據(jù)庫信息記錄，由于要同時對兩張表進展修改，這里我AddpublicImageStatusEnumAdd(ImageInfoimageEntity){//首先是圖片信息表db.ImageInfo.Add(imageEntity);//其次是圖片效勞器信息表ImageServerInfo

serverEntity =s=>s.ServerId==imageEntity.ImageServerId);if(serverEntity!=null){//當(dāng)前效勞器存儲數(shù)量+1serverEntity.CurPicAmount+=1;}//一起提交到SQLServerintresult=db.SaveChanges;if(result>0){}{}}

returnImageStatusEnum.Failure;簡潔測試圖片文件的上傳與掃瞄測試前的預(yù)備工作64VMwareR2Web〔沒用端口號區(qū)分不同的效勞程序來模擬效果。②將WebIIS中，80108020測試圖片文件上傳與存儲gif的過程作為展現(xiàn)。在我連續(xù)上傳操作了N次之后，現(xiàn)在我們來看看兩個文件效勞〔這里主要是看部署的程序所在Upload〕AB總結(jié)：從圖中可以看出，我們一共上傳了13張圖片，其中圖片效勞器A6張，圖片效勞器B7張，兩個效勞器的負(fù)載并沒有消滅一頭小一頭大，而是一個相比照較均衡的數(shù)量，這得益于我們的隨機函數(shù)。測試圖片文件掃瞄懇求①是否顯示了圖片列表：②是