首先要感謝諸多朋友對鄙人的一些拙見表示關(guān)注，不少朋友反應(yīng)上一篇的分享有點意猶未盡，我的理解可能是大家覺得我寫的不夠快。呵呵...由于系統(tǒng)整理相關(guān)資料需要一段時間，另外要盡量保持原創(chuàng)的風(fēng)格。所以周期會稍微長一點點，但我盡量會一周寫1-2篇相關(guān)專題。

      上篇看到不少反饋，主要是在“瓶頸”這個問題上有些疑問。的確大型站點很容易造成瓶頸問題，但是這些問題都需要在需求分析階段或者之前就要弄明白這些問題，至少要知道將來可能會存在哪些缺陷。不知道用-未雨綢繆這個詞合不合適。如果想建一座摩天大廈，我想在暴風(fēng)雨來臨之前就應(yīng)該把大樓都建踏實了，至少建造大樓的方案都已經(jīng)研究過了。同樣一個大型Web站點也需要考慮這些，如果還沒有開始，那我們不妨就開始做一些數(shù)據(jù)分析研究，四個方面：數(shù)據(jù)庫、網(wǎng)絡(luò)架構(gòu)、網(wǎng)絡(luò)帶寬、讀寫。

1、數(shù)據(jù)庫
      假設(shè)我們前提是：數(shù)據(jù)庫服務(wù)器操作系統(tǒng)采用Linux，數(shù)據(jù)庫采用Oracle 11g，CPU采用至強3G x 2或x4，內(nèi)存8G或16G或以上。如果從內(nèi)存角度來衡量系統(tǒng)的最大并發(fā)連接和處理數(shù)量。抑或oracle數(shù)據(jù)庫安裝在一臺擁有16G內(nèi)存的服務(wù)器上，按照Oracle推薦的，分配給Oracle實例的內(nèi)存為物理內(nèi)存的80%。那么對于OLTP應(yīng)用來，pga_aggregate_target(20%的空間用來進行PGA的存儲)的值大約就是2621MB[(16*1024MB×80%)×20%]。這些內(nèi)存將被分配與PGA區(qū)域，并且這個是和并發(fā)連接有直接關(guān)系的，每個并發(fā)的連接都需要一定量的PGA內(nèi)存以執(zhí)行SQL語句，假設(shè)每個用戶session平均需要1M（按照通常的經(jīng)驗值）的空間來計算，那么從并發(fā)連接數(shù)上來講，共可以支持近2600左右個并發(fā)連接數(shù)。另外從TPC-C基準角度方面估算數(shù)據(jù)庫所能支持的并發(fā)用戶數(shù)。根據(jù)TPC-C官方網(wǎng)站對Oracle Database 11g Standard Edition One測試結(jié)果http://www.tpc.org/tpcc/results/tpcc_result_detail.ASP?id=107091301，在硬件配置為1 CPU、4 Cores的情況下的tpmC值約為10萬左右，假設(shè)被評估系統(tǒng)采購的數(shù)據(jù)庫服務(wù)器為4 CPU，在不考慮任何其他資源消耗的情況下，那么tpmC值能夠達到40萬。而業(yè)界認可的一般性應(yīng)用系統(tǒng)與TPC-C基準程序的復(fù)雜性比例為10-20：1，此處我們采用較低的10：1，另外假設(shè)系統(tǒng)數(shù)據(jù)庫交換每60秒處理5筆業(yè)務(wù)，根據(jù)以上基礎(chǔ)上推算出該系統(tǒng)所應(yīng)達到的并發(fā)數(shù)為：40萬tpmC/(10*60/5)=3333.3，從以上分析可以看出如果要達到Web并發(fā)5K已經(jīng)成功了一小半。

2、網(wǎng)絡(luò)架構(gòu)
      常用網(wǎng)絡(luò)架構(gòu)大都在硬件防火墻存在TCP并發(fā)連接瓶頸。通常平臺使用Web界面訪問，訪問方式采用TCP短連接方式傳輸數(shù)據(jù)，我們使用clearsight對與該平臺業(yè)務(wù)類似的淘寶以及阿里巴巴頁面的TCP連接數(shù)進行了測試，結(jié)果沒個頁面平均短連接數(shù)保持在30個左右。目前主流的高端企業(yè)防火墻（電信級防火墻除外）在理想情況下（防火墻不受到外界任何攻擊，防火墻不開啟任何附加的保護策略，只使用默認的防火墻策略）每秒TCP連接數(shù)可達30000并發(fā)，如果TCP連接在1秒內(nèi)建立完成，則一個分布式處理中心大約可以承受30000/30=1000個TCP并發(fā)。這一點不是非常滿意，這樣一來在分布式處理中心還要做些文章。

3、網(wǎng)絡(luò)帶寬
      對于網(wǎng)絡(luò)帶寬，假設(shè)系統(tǒng)有1000個并發(fā)用戶數(shù)，網(wǎng)絡(luò)是100Mbps，則有效帶寬為12.5MBytes，每頁面的平均大小按照100KB計算，那么不管服務(wù)器本身速度多快，最好的響應(yīng)時間為：2000User*200KB/(12.5MBytes*1024) = 31.25秒，即：如果網(wǎng)絡(luò)是100Mbps的話，最好的頁面訪問執(zhí)行時間也就是31.25秒。這樣無論服務(wù)器的響應(yīng)有多快，總是要在網(wǎng)絡(luò)上傳輸這么大的數(shù)據(jù)量。因此，網(wǎng)絡(luò)將是一個很大的瓶頸。如果網(wǎng)絡(luò)是125MBytes即約1Gbps，則響應(yīng)時間是3.125秒，所以并發(fā)飆升，帶寬費用將是一筆巨大的開支。

4、讀寫
      假設(shè)最大的讀寫在圖片服務(wù)器，且配置如下：1、CPU：至強3G x 2，或同級別的其他CPU；2、內(nèi)存：2G或以上；3、硬盤：300G x 2做RAID 0或146G x 4做RAID 1+0。就普通的服務(wù)器而言，其使用的SCSI硬盤的理論最大傳輸速度是320M/S，實際可能只有一半。按照系統(tǒng)需求中一般的頁面的響應(yīng)時間應(yīng)在5秒內(nèi)（局域網(wǎng)內(nèi)為3秒內(nèi)，互聯(lián)網(wǎng)上一般應(yīng)該在5秒內(nèi)）的要求計算圖片總流量為800M（按照實際值計算）。如果按照每個頁面上的圖片的平均大小為100K來計算，普通配置圖片服務(wù)器可以承受8000用戶的流量。

      有了這些數(shù)據(jù)我們在做系統(tǒng)架構(gòu)的時候就知道如果規(guī)避種種問題，當(dāng)然在架構(gòu)階段盡可能的為升級留有余地。我喜歡在建樓之前畫盡可能多的圖紙，做盡可能多的實驗。不管怎樣我們都熱愛這份Web大樓的建造，有的三兩層，有的幾十層甚至上百層。高度說明不了問題，關(guān)鍵在于你的心是否容的下這所建筑！

it知識庫：大型Web架構(gòu)思想系列專題之-未雨綢繆，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。