前言：
最近負責的一個小型以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授權，使用諸如騰訊，新浪，人人等社交帳號，實在不行限制區域，綁定物理地址也可以考慮。