上篇介紹的基于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構成批量發包的話(假如是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,….存貯為數字索引，然后進行分區存貯，數字類型的數據在數據庫中可以更有效的被查詢和被更新和共享，結合方案一和 方案二這個就是方案三。

　　對于Q級別。數據量已經是足夠海量了，這個時候無論用哪種方案都是一個讓人頭大的數據，不能簡單的用查詢的方案來處理了，可以參考S級別的進行 處理。但這個時候我們采用的方案是根據用戶活躍度的權值結合數據量進行臨時數據表的存放。如果一個非意外的數據情況下，每天登錄的用戶量不會上千萬。這個 時候我們需要做的是一個簡單的數據代理程序。一個臨時的用戶驗證數據庫，每天執行一次批處理，將活躍度高的用戶賬戶提取到臨時數據庫中，查詢的時候先查詢 臨時庫，如果沒有在進行全庫查詢。這個根據系統的負載情況來估計閾值，不同的系統估算方案也不盡相同。

　　上面對于，M,S,Q三種界別進行了簡單的概述，下面介紹一個在其之上更高級的一個查詢方案，數據緩存服務器，我們也可以把它理解為緩沖服務器，數據做為只讀來使用。

　　具體實現方案如下：以為涉及了海量，DBMS常規的緩存方案已經不符合我們的要求了，那么我們需要一個有效的緩存方案，這個時候處理的流程其實 就是講最常用最直接的數據直接存放在緩存服務器中，而這個緩存服務器定時從主服務器獲取并更新信息。這個是一個簡單的查詢，我們還可以更深入的講緩存服務 器做二次緩存，也就是一次性處理輸入并存放到LIST數據中，作為全局變量放到內存中進行查詢，同時用HASHTABLE或者數組進行數據組索引(可以是 多級)，根據查詢分布到各個變量中。直接從內存中讀取數據。

　　以筆者的經驗來說的話，對于ITEM數據不超過10K的來說，每個列表最佳的存放范圍是0到6萬之間。

　　這里簡單的介紹了一下DBMS基本架構，里面具體細節處理的還有很多，這里只介紹個大概的綱要。有問題請給我發郵件(Heroqst # Gmail.com)，請講#替換為@

　　這里只是簡單的介紹了一下DBMS的基本布局，下章講具體對我們常見的多對多關系數據庫進行具體配置說明。

　　首先介紹一下問題的大概，比如對于文章和標簽，每個文章可以有多個標簽，而每個標簽下又會有多個文章，那么數據量將是文章數乘以標簽數，這個時候如何進行處理并有效的索引，將是下章要介紹的內容。

轉載：http://blog.csdn.net/heiyeshuwu/archive/2008/10/01/3006964.aspx