最近對架構設計系統的學習下，站在一定高度對系統的整體運營是有很好幫助的
A. 硬件法
1. 多個機器併發服務
2. 數據複製多份, 空間換時間
3. 帶寬複用和疊加網路設備
B. 軟件法
1. 採用高緩存. 將訪問量高的信息放在內存中, 直接使用內存輸出
2. 精確定位. 減少定位搜索時間, 包括索引等
3. 分歷史和新聞信息存儲. 歷史訪問量低, 放在歷史庫. 新聞訪問量高, 放緩存
web網站架構思想
大型的web站點很容易出現瓶頸的問題，都些問題都需要在需求分析階段（架構設計階段）或之前就要弄明白的，
至少要知道將來可能存在哪些缺 陷，可能你會說，我現在沒那麼大的訪問量，在線用戶很少，還不需要考慮那麼
多，有這樣的想法是很可怕的，如果訪問量上來（突增），就無法應對了， 可能會推翻系統重建，類似中國的
”破窗效應“，對把系統做大做強是不利的，對用戶更是不利的。不過這也爲擴大內需做貢獻了，呵呵；雖然現
在 業務很少，但我們要考慮業務的突增來設計系統，起初考慮成本，可以只滿足當前業務配置系統。使架構具有
可擴展性出現瓶頸大概有四個方面：數據庫、網絡架構、網絡帶寬、讀寫。但這四個方面都是應用程序服務，所以前期的應用架構設計很重要，就拿北京的交通來說，一旦北京公路竣工完畢，投入到運營中，交通是否方便，是否擁塞交管部門只能在現有的環境下通過相關的法規或者是一些其他的方法來改善交通的擁塞情況，它只是其輔助作用。
1.數據庫
數據庫服務器操作系統的選擇：一般爲linux，unix（aix，hpunix,solaires等）
數據庫的選擇 ：目前一般爲oracle，mysql，db2，sqlserver
硬件的選擇：根據自己的業務需求
例如：
數據庫服務器操作系統爲linux，數據庫選擇oracle10g ，CPU採用至強3G x 2或x4，內存8G或16G或以上，目前的cpu發展很快，很少成爲瓶頸，我們就拿內存來衡量系統的最大併發連接，拿16G的內存來說按照Oracle推薦的，分配給Oracle實例的內存爲物理內存的80%。那麼對於OLTP應來，pga_aggregate_target(20%的空間用來進行PGA的存儲)的值大約就是 2621MB[(16*1024MB×80%)×20%]。這些內存將被分配與PGA區域，並且這個是和併發連接有直接關係的，每個併發的連接都需要一定量的PGA內存以執行SQL語句，假設每個用戶session平均需要1M（按照通常的經驗值）的空間來計算，那麼從併發連接數上來講，共可以支持近2600左右個併發連接數。
如果一臺數據庫承載不了當前的業務，就要擴展；我們現在很幸運，因爲已經很有多案例我們可以參考，因爲這些案例都是經過實踐長時間驗證的，像擁有億級用戶的myspace社區，可以參考它的按用戶橫向擴展，用數據庫緩存最終才解決myspace的數據庫瓶頸問題
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大樓的建造，有的三兩層，有的幾十層甚至上百層。高度說明不了問題，關鍵在於你的心是否容的下這所建築！
還有一點，當我們的圖片服務器裏的圖片很多的話，這也會成爲瓶頸，有能力的話可以從新改寫管理圖片的文件系統，因爲一般的文件系統是通過目錄結構來查找到圖片資源的，這是很耗時的，如果通過類似索引的結構查找到圖片，那速度將會提高很大
參考文檔：
http://kb.cnblogs.com/page/43977/
http://www.dbanotes.net/arch/imobile_web_arch_ppt.html
http://blog.csdn.net/wangjiafeng2008/archive/2008/12/02/3431718.aspx
http://www.dbanotes.net/arch/heroku_architecture.html
