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

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

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

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

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

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

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

it知識庫：大型Web架構思想系列專題之-未雨綢繆，轉載需保留來源！

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