前言：
最近负责的一个小型以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授权，使用诸如腾讯，新浪，人人等社交帐号，实在不行限制区域，绑定物理地址也可以考虑。