小小投票網站的大智慧(技術報告)

前言：

    最近負責的一個小型以IP方式投票網站的項目,在臨近比賽截止的時候,因爲惡意刷票,致使服務器癱瘓,最後經調查，最後3小時有52312IP涌入，PV量可想而知，這樣直接致使了IIS超過最大線程數，鏈接池一直假死未釋放，更奇葩的是最終服務器日誌文件寫滿磁盤，形成service unavailable，再加上服務器管理那邊並無基礎的DDOS預防設施,也沒流量監控設備，最後只能從零星的數據中去推測服務器service unavailable的緣由，如遇這方面的大神，望指點一二....

網站緣由：

    以IP方式投票，每一個IP天天10票，後臺投票邏輯作了相應的優化，數據讀取採用按需分離的方式,使用AJAX技術更新局部數據,避免數據更新須要刷新整個頁面，屢次所有從數據庫中讀取。

    就以這樣的條件，整個系統扛過了累計前5天近20萬個IP的訪問（107872個不重複IP），特別是前三天的訪問量，那麼龐大都沒有出問題，但是後面這個數據，短短三個小時52312個IP,確實讓我嚇一跳。

    惟一缺陷是，沒有在設計之初使用cookie來攔截流量，由於當初考慮到是爲了防止經過修改cookie來刷票，因此就只採用服務器驗證方式,當時可能腦殼短路，當時大概想一想也不可能有上述這樣大的流量（最後沒想到人類的力量如此巨大），認爲cookie的做用就沒有了，實際上cookie把計算壓力轉移到了客戶端，無能否認我在這點腦殘了。想一想若是單增長cookie這項，就上面那個數據，轉移的計算壓力那是很是巨大的。

服務器緣由：

   服務器條件不是很好，沒有基礎的DDOS預防設施，硬盤都能被服務器日誌寫滿，我就不說什麼了。至於當初給我分配資源的時候，鏈接池最大設定是多大，因爲對方不肯透露的緣由，也無從得知。這也是影響網站最終性能的一個因素。

最後：

　 投票性質的網站，特別是以開放式的投票，如採用IP計票等要作好高併發量的準備，預防最壞狀況（廣告聯盟方式的刷票）。對於投票這一性質，我的以爲採用IP計票自己就是個錯誤，還不如綁定賬號這樣安全省事，爲了提升登陸速度，能夠採起OAuth受權，使用諸如騰訊，新浪，人人等社交賬號，實在不行限制區域，綁定物理地址也能夠考慮。