針對海量承載商品圖片的解決方案學習
來源：程序員人生 發布時間：2015-01-07 08:25:15 閱讀次數：3271次
前言：
隨著計算機網絡技術的發展和普及,出現了愈來愈多像,“淘寶”,”京東”等大型電子商務網站。這類網站都保存有大量圖片資源。用戶在訪問這些站點網頁時,網頁中圖片信息占到頁面數據流量的大部份。由于受客戶端閱讀器限制,沒法從1臺服務器上同時下載頁面中所有圖片信息,因此即便服務器有很高帶寬,用戶的訪問速度還是會遭到很大影響。由于圖片保存在物理硬盤上,訪問圖片需要頻繁進行I/O操作,因此當并發用戶數愈來愈多時,I/O操作就會成為全部系統的性能瓶頸。
對大型的網站系統來講，由于具有雄厚的資金，可使用 NFS、CDN、Lighttpd等技術提高用戶的訪問速速。但這些技術需要龐大的資金支持,對處于創業早期中等范圍的商務網站,由于缺少必要的資金支持,因此沒法采取這些技術提升網站的訪問速度 。今天我們講1個適用于中等范圍商務網站的海量圖片數據散布式動態存儲及負載均衡的解決方案。該方案只需增加很少的硬件本錢,便可提升網站的訪問速度,并且可以根據需要動態調劑圖片服務器的數量及圖片的存儲目錄,確保系統具有可擴大性和伸縮性。
系統架構設計：
對Web服務器而言，用戶對圖片信息的訪問是很消耗服務器資源的。當1個網頁被閱讀時,Web服務器與閱讀器建立連接,每一個連接表示1個并發。當頁面包括多個圖片時,Web服務器與閱讀器會產生多個連接,同時發送文字和圖片以提高閱讀速度。因此,頁面中圖片越多Web服務器遭到的壓力也就越大。對小型網站,由于數據范圍小,可以把網站所有頁面和圖片統1寄存在1個主目錄下,這樣的網站對系統架構、性能要求都很簡單 。但大中型網站都保存有海量級的圖片文件,所采取的技術更是觸及廣泛 ，因此,有必要設立單獨的圖片服務器來專門寄存圖片,把圖片數據的流量從Web服務器上分離開,這樣的架構可以有效減緩Web服務器的I/O性能瓶頸
，提高用戶的訪問速度.
系統架構設計需要滿足4點要求：
(1)圖片能進行散布式存儲;
(2)能實現負載均衡;
(3)能根據用戶訪問量及網站圖片數據量的增加能動態添加圖片服務器節點;
(4)圖片服務器節點的動態調劑對網站用戶而言是透明的,并且不會中斷系統的正常運行。
架構說明：
客戶端是指IE、Firefox等經常使用的客戶端閱讀器,用戶可以通過客戶端來閱讀網站的圖片信息,也能夠通過客戶端上傳圖片信息。Web服務器部署網站的Web頁面,用于響應客戶端用戶的要求。當用戶閱讀網頁時,Web服務器響應要求并訪問數據庫服務器,取得網頁中所有圖片的URL路徑,然后生成頁面并返回給客戶端,客戶端接收該頁面并根據頁面中的圖片URL路徑自動從不同的圖片服務器下載并顯示相應圖片。當用戶上傳圖片時,Web服務器首先從數據庫服務器中獲得所有圖片服務器確當前狀態,并根據相干算法選擇1個圖片服務器及保存的目錄,再調用該圖片服務器的Web
Service方法把圖片保存到該服務器,最后在數據庫服務器中紀錄該圖片的編號及URL路徑等信息。
數據庫服務器用于記錄所有圖片的編號和圖片的寄存位置等信息,同時需要記錄所有圖片服務器的配置及當前狀態信息（這里學習下心跳機制，負責監聽圖片服務器的狀態，下面百科了心跳機制的方法）。
圖片服務器集群用于寄存網站的所有圖片信息,該集群的服務器數量可以根據需要動態增加。
系統實現及關鍵技術：
增加了圖片服務器后,對客戶端而言,全部網站系統履行進程應當依然是透明的,不會給用戶帶來任何影響。但后臺系統需要解決以下4個問題:
(1)如何實現圖片的散布式部署,圖片上傳時如何動態肯定保存到哪臺圖片服務器;
(2)如何做到圖片服務器的負載均衡,既要保證所有圖片服務器都有均等的機會來保存圖片.
(3)如何把1臺圖片服務器上圖片均衡保存到多個子目錄中以便突破操作系統在同1個目錄中保存文件數的限制,對圖片進行更好的管理和保護;
(4)如何能根據性能需要和圖片數量的增加實現圖片服務器的動態擴充。
Web服務器需要及時掌握所有圖片服務器的狀態和信息才能動態決定把圖片保存到哪1臺圖片服務器,因此,需要把所有的圖片服務器的狀態信息全部紀錄到數據庫服務器中, 狀態信息表中的ServerId字段為主鍵自增列,唯1代表1條圖片服務器紀錄。
ServerName字段記錄服務器的名稱,方便管理員辨認該記錄代表哪臺服務器。
ServerUrl字段標識了圖片服務器上圖片主目錄的URL根路徑。
PicRootPath字段標識了保存圖片的物理主目錄。
MaxPicAmount字段表示圖片服務器能保存的最大圖片數,該數可以根據圖片服務器的硬件配置和性能和用戶實際需要而進行動態調劑。
CurPicAmount字段表示當前已保存的圖片數,當CurPicAmount≥MaxPicAmount時系統將不再把圖片上傳到該服務器。
FlgUsable字段表示圖片服務器是不是可用。
圖片文件上傳：
由于B/S架構本身技術限制,圖片沒法通過Web服務器直接上傳到不同的圖片服務器,因此需要在所有圖片服務器上部署1個Web Service以便Web服務器可通過調用不同圖片服務器上的Web Service履行保存。從狀態表挑選出可用的圖片服務器集合記作C,并獲得集合的總記錄數N。然后用隨機函數產生1個隨機數R1并用R1與N進行取余運算記作I=R1%N。則C[I]即為要保存圖片的圖片服務器。
圖片閱讀：
客戶端用戶通過閱讀器向Web服務器發出閱讀某頁面的要求,Web服務器從數據庫服務器中獲得該頁面的所有圖片URL信息,并根據URL信息去搜索圖片服務器的狀態信息表,判斷該URL所指向的圖片服務器的狀態字段FlgUsable,若FlgUsable == false表示該圖片服務器當前因某種緣由處于不可用狀態,則把該圖片的URL替換成Web服務器上保存的1個默許圖片的URL,否則把該URL直接返回給客戶端。客戶端再根據圖片的URL路徑自動從不同的圖片服務器上下載并顯示相應的圖片。由于圖片URL路徑直接指向具體的圖片服務器,因此需要在每一個圖片服務器的保存圖片的主目錄上建立1個Web站點。由于客戶端閱讀器所需要的圖片是從多個圖片服務器上直接下載,因此閱讀器可以并發地從多臺服務器上同時下載圖片,這樣就縮短了圖片下載時間,同時也減輕了Web服務器的I/O要求及性能壓力,因此,提高了網站的訪問速度
.
附-心跳機制：
網絡中的接收和發送數據都是使用操作系統中的SOCKET進行實現。但是如果此套接字已斷開，那發送數據和接收數據的時候就1定會有問題。可是如何判斷這個套接字是不是還可使用呢？這個就需要在系統中創建心跳機制。其實TCP中已為我們實現了1個叫做心跳的機制。如果你設置了心跳，那TCP就會在1定的時間（比如你設置的是3秒鐘）內發送你設置的次數的心跳（比如說2次），并且此信息不會影響你自己定義的協議。所謂“心跳”就是定時發送1個自定義的結構體（心跳包或心跳幀），讓對方知道自己“在線”。
以確保鏈接的有效性。所謂的心跳包就是客戶端定時發送簡單的信息給服務器端告知它我還在而已。代碼就是每隔幾分鐘發送1個固定信息給服務端，
服務端收到后回復1個固定信息如果服務端幾分鐘內沒有收到客戶端信息則視客戶端斷開。比如有些通訊軟件長時間不使用，要想知道它的狀態是在線還是離線就需要心跳包，定時發包收包。發包方：可以是客戶也能夠是服務端，看哪邊實現方便公道。1般是客戶端。服務器也能夠定時輪詢發心跳下去。心跳包之所以叫心跳包是由于：它像心跳1樣每隔固定時間發1次，以此來告知服務器，這個客戶端還活著。事實上這是為了保持長連接，至于這個包的內容，是沒有甚么特別規定的，不過1般都是很小的包，或只包括包頭的1個空包。在TCP的機制里面，本身是存在有心跳包的機制的，也就是TCP的選項。系統默許是設置的是2小時的心跳頻率。但是它檢查不到機器斷電、網線拔出、防火墻這些斷線。而且邏輯層處理斷線可能也不是那末好處理。1般，如果只是用于保活還是可以的。心跳包1般來講都是在邏輯層發送空的包來實現的。下1個定時器，在1定時間間隔下發送1個空包給客戶端，然后客戶端反饋1個一樣的空包回來，服務器如果在1定時間內收不到客戶端發送過來的反饋包，那就只有認定說掉線了。只需要send或recv1下，如果結果為零，則為掉線。但是，在長連接下，有可能很長1段時間都沒有數據來往。理論上說，這個連接是1直保持連接的，但是實際情況中，如果中間節點出現甚么故障是難以知道的。更要命的是，有的節點（防火墻）會自動把1定時間以內沒有數據交互的連接給斷掉。在這個時候，就需要我們的心跳包了，用于保持長連接，保活。在獲知了斷線以后，服務器邏輯可能需要做1些事情，比如斷線后的數據清算呀，重新連接呀固然，這個自然是要由邏輯層根據需求去做了。總的來講，心跳包主要也就是用于長連接的保活和斷線處理。1般的利用下，判定時間在30⑷0秒比較不錯。如果實在要求高，那就在6⑼秒。
生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈
