大型網站架構 底層架構概論

上篇介紹的基於AJAX的攻擊很多人提出疑問，比如不能跨域，減輕負擔之類。 Ajax是通過簡單的GET和POST進行資料傳遞的，採用HTTPDEBUGGER，抓取資料，然後採用如下方案， 順便寫個示例的攻擊代碼.比傳統的webform，我們更容易構造一些，其實對於webform和ajax的處理和發包過程是一樣的，ajax資料量相對小，速度也快一些。

結合SharpPcap和HttpWebRequest我們構造一個合理的正常的IP資料包過去,代碼很長，我們用偽代碼簡單的表達一下。

request. CreateUrl(Ajax處理頁面);

request. Method=」GetORPost」;

request.refere=」網頁來源」;

SharpPcap.SetLinkConnection(偽造IP位址);

String content = request. GetResponseStream() 如果作為一個多執行緒的應用程式對對方的WEB構成批量發包的話(假如是HTTP://www.aliyun.com/zixun/aggregation/16485.html"> DEDECMS)，足可以把Dedecms的資料庫搞垮

文入正題：

對於上回書提到要解決問題A，我們先講解一下電信公司ADSL的佈局方案。 機器上沒有裝VISIO，我簡單的用文字描述一下流程。

Adsl使用者Aè輸入使用者名密碼è遠端連線到帳戶資料庫(在天津)è帳戶資料庫連接計費資料庫並返回狀è如果成功，連接PPPOE伺服器，並進一步連接計費資料庫è認證服務並連接。 這裡沒有什麼特別的地方，但是和qq通訊服務是一樣的，就是採用了統一的使用者驗證服務器，同時對於使用者驗證的資訊資料庫是唯讀的，我們從其中可以想到什麼嗎?

以上是個簡單的例子，下面開始談具體的架構策略，首先對於上篇提到的問題A，我們首先以使用者資料庫為例來做解釋和要求。

首先做使用者量估算需求，假如我們做的是學術社區，那麼這個使用者量不會很大，可能我們不需要考慮這個，對於使用者量的級別，我們暫時把使用者量級別定為三種，百萬級別(M)和千萬界別(S)，以及億萬級別(Q)， 並考慮使用者登錄驗證以及查詢常用的操作，對M和S進行擴充以及瞭解。

眾所周知，在這個情況下，對於使用者資料的負載其實並非可行而不可行的問題，而是如何最大化的保證查詢和更新以及各個伺服器之間的資料同步。 這裡我們不再講解如何優化如何索引，只介紹架構初期的方案，下面介紹的方案如果涉及全表查詢，可以採用分區視圖的方案，大家可以具體搜索相關資料。

對於M級別來說，現有的DBMS經過合理的佈局完全可以滿足需求。 我們需要解決的問題的關鍵其實是處理IO方面的問題，處理方案相對簡單一些，對資料庫的FILE檔分磁片存貯(不是分區，是不同的硬碟)，根據負載量大小，我們可以適當的控制硬碟的數量和檔分區的數量。

對於S級別，上個處理方案已經不能完全滿足需求了，這個時候我們需要對註冊和入庫的流程進行簡單的修改了，解決方案是資料散列和分區視圖的概念，具體概念大家去google一下，我不詳細說明了。

　　我們常用的方案有三種。 第一種是等容擴充法，在使用者註冊控制的基礎上，保證每個庫的使用者容量不超過500萬，超過之後入第二個庫，以此類推，這個方案可以保證系統有效的擴充性，但不能保證資料被有效的索引。 第二種就是共區索引方案，其實和第一種方案有異曲同工的之說但是講第一種方案進行了合理的優化，按照使用者名進行分庫存貯。 比如我們可以建立26的資料庫，按照使用者名的索引來控制使用者資料入哪個庫。 假如使用者名是CrazyCoder，那麼就講該使用者名的資料存放在使用者表C中，在資料存貯的時候可以很方便的根據使用者名進行相應的資料查詢，方案二可以有效的解決資料索引問題。 方案三是一個更具模型化的方案，結合方案一和方案二，進行使用者ID的編碼，不是INDENTIFY Cloumn，我們用一種序列化的方案將使用者名以編碼的形式存貯，比如使用者名是CrazyCoder, 我們的編碼方案就是通過演算法進行數位化，將CrazyCoder按照C，R,A,....存貯為數字索引，然後進行分區存貯，數位類型的資料在資料庫中可以更有效的被查詢和被更新和共用，結合方案一和方案二這個就是方案三。