最近负责的一个小型以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这项,就上面那个数据,转移的计算压力那是很是巨大的。cookie
服务器条件不是很好,没有基础的DDOS预防设施,硬盘都能被服务器日志写满,我就不说什么了。至于当初给我分配资源的时候,链接池最大设定是多大,因为对方不肯透露的缘由,也无从得知。这也是影响网站最终性能的一个因素。并发
投票性质的网站,特别是以开放式的投票,如采用IP计票等要作好高并发量的准备,预防最坏状况(广告联盟方式的刷票)。对于投票这一性质,我的以为采用IP计票自己就是个错误,还不如绑定账号这样安全省事,为了提升登陆速度,能够采起OAuth受权,使用诸如腾讯,新浪,人人等社交账号,实在不行限制区域,绑定物理地址也能够考虑。高并发