上篇介紹的基于AJAX的攻擊很多人提出疑問，比如不能跨域，減輕負(fù)擔(dān)之類。Ajax是通過簡單的GET和POST進(jìn)行數(shù)據(jù)傳遞的，采用 HTTPDEBUGGER，抓取數(shù)據(jù)，然后采用如下方案，順便寫個(gè)示例的攻擊代碼.比傳統(tǒng)的webform，我們更容易構(gòu)造一些，其實(shí)對于webform 和ajax的處理和發(fā)包過程是一樣的，ajax數(shù)據(jù)量相對小，速度也快一些。

   結(jié)合SharpPcap和HttpWebRequest我們構(gòu)造一個(gè)合理的正常的IP數(shù)據(jù)包過去,代碼很長，我們用偽代碼簡單的表達(dá)一下。

　　request.CreateUrl(Ajax處理頁面);

　　request.Method=”GetORPost”;

　　request.refere=”網(wǎng)頁來源”;

　　SharpPcap.SetLinkConnection(偽造IP地址);

　　String content = request.GetResponseStream() 如果作為一個(gè)多線程的應(yīng)用程序?qū)Ψ降腤EB構(gòu)成批量發(fā)包的話(假如是DEDECMS)，足可以把Dedecms的數(shù)據(jù)庫搞垮

　　文入正題：

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

　　Adsl用戶Aè輸入用戶名密碼è遠(yuǎn)程連接到賬戶數(shù)據(jù)庫(在天津)è賬戶數(shù)據(jù)庫連接計(jì)費(fèi)數(shù)據(jù)庫并返回狀è如果成功，連接PPPOE服務(wù)器，并進(jìn)一步連接計(jì)費(fèi)數(shù)據(jù)庫è認(rèn)證服務(wù)并連接。

　　這里沒有什么特別的地方，但是和qq通訊服務(wù)是一樣的，就是采用了統(tǒng)一的用戶驗(yàn)證服務(wù)器，同時(shí)對于用戶驗(yàn)證的信息數(shù)據(jù)庫是只讀的，我們從其中可以想到什么嗎?

　　以上是個(gè)簡單的例子，下面開始談具體的架構(gòu)策略，首先對于上篇提到的問題A，我們首先以用戶數(shù)據(jù)庫為例來做解釋和要求。

　　首先做用戶量估算需求，假如我們做的是學(xué)術(shù)社區(qū)，那么這個(gè)用戶量不會(huì)很大，可能我們不需要考慮這個(gè)，對于用戶量的級(jí)別，我們暫時(shí)把用戶量級(jí)別定 為三種，百萬級(jí)別(M)和千萬界別(S)，以及億萬級(jí)別(Q)，并考慮用戶登錄驗(yàn)證以及查詢常用的操作，對M和S進(jìn)行擴(kuò)充以及了解。

　　眾所周知，在這個(gè)情況下，對于用戶數(shù)據(jù)的負(fù)載其實(shí)并非可行而不可行的問題，而是如何最大化的保證查詢和更新以及各個(gè)服務(wù)器之間的數(shù)據(jù)同步。這里 我們不再講解如何優(yōu)化如何索引，只介紹架構(gòu)初期的方案，下面介紹的方案如果涉及全表查詢，可以采用分區(qū)視圖的方案，大家可以具體搜索相關(guān)資料。

　　對于M級(jí)別來說，現(xiàn)有的DBMS經(jīng)過合理的布局完全可以滿足需求。我們需要解決的問題的關(guān)鍵其實(shí)是處理IO方面的問題，處理方案相對簡單一些， 對數(shù)據(jù)庫的FILE文件分磁盤存貯(不是分區(qū)，是不同的硬盤)，根據(jù)負(fù)載量大小，我們可以適當(dāng)?shù)目刂朴脖P的數(shù)量和文件分區(qū)的數(shù)量。

　　對于S級(jí)別，上個(gè)處理方案已經(jīng)不能完全滿足需求了，這個(gè)時(shí)候我們需要對注冊和入庫的流程進(jìn)行簡單的修改了，解決方案是數(shù)據(jù)散列和分區(qū)視圖的概念，具體概念大家去google一下，我不詳細(xì)說明了。

　　我們常用的方案有三種。第一種是等容擴(kuò)充法，在用戶注冊控制的基礎(chǔ)上，保證每個(gè)庫的用戶容量不超過500萬，超過之后入第二個(gè)庫，以此類推，這 個(gè)方案可以保證系統(tǒng)有效的擴(kuò)充性，但不能保證數(shù)據(jù)被有效的索引。第二種就是共區(qū)索引方案，其實(shí)和第一種方案有異曲同工的之說但是講第一種方案進(jìn)行了合理的 優(yōu)化，按照用戶名進(jìn)行分庫存貯。比如我們可以建立26的數(shù)據(jù)庫，按照用戶名的索引來控制用戶數(shù)據(jù)入哪個(gè)庫。假如用戶名是CrazyCoder，那么就講該 用戶名的數(shù)據(jù)存放在用戶表C中，在數(shù)據(jù)存貯的時(shí)候可以很方便的根據(jù)用戶名進(jìn)行相應(yīng)的數(shù)據(jù)查詢，方案二可以有效的解決數(shù)據(jù)索引問題。方案三是一個(gè)更具模型化 的方案，結(jié)合方案一和方案二，進(jìn)行用戶ID的編碼，不是INDENTIFY Cloumn，我們用一種序列化的方案將用戶名以編碼的形式存貯，比如用戶名是CrazyCoder,我們的編碼方案就是通過算法進(jìn)行數(shù)字化，將 CrazyCoder按照C，R,A,….存貯為數(shù)字索引，然后進(jìn)行分區(qū)存貯，數(shù)字類型的數(shù)據(jù)在數(shù)據(jù)庫中可以更有效的被查詢和被更新和共享，結(jié)合方案一和 方案二這個(gè)就是方案三。

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

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

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

　　以筆者的經(jīng)驗(yàn)來說的話，對于ITEM數(shù)據(jù)不超過10K的來說，每個(gè)列表最佳的存放范圍是0到6萬之間。

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

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

　　首先介紹一下問題的大概，比如對于文章和標(biāo)簽，每個(gè)文章可以有多個(gè)標(biāo)簽，而每個(gè)標(biāo)簽下又會(huì)有多個(gè)文章，那么數(shù)據(jù)量將是文章數(shù)乘以標(biāo)簽數(shù)，這個(gè)時(shí)候如何進(jìn)行處理并有效的索引，將是下章要介紹的內(nèi)容。

轉(zhuǎn)載：http://blog.csdn.net/heiyeshuwu/archive/2008/10/01/3006964.aspx