在绕了N个圈之后我终于找到了会场,看看时间12点48分,按照规定牛人要13点30开始演讲,到了这个时间,我发现只有51.com 的finalbsd同志到场了,主持会议的草上飞(唐川)说嘉宾正在路上,牛人的时间自然贵点,晚点到场也是应该的,于是我安慰了一下自己,牛人于14点左右差不多陆续来了。 FinalBSD同志的“群服务器负载均衡的开源解决方案”讲的很好,个人理解如下: 1、目前最好的负载均衡的硬件设备是F5和Netscaler,两者基本上属于同质品,所以两者是直接竞争者,不过后者可以将TCP的三次握手全部自己搞定,F5是转发到后端,因此Netscaler具有更高的抗DDOS特性。两者拥有太多的相似点,其中之一就是价格,中小互联网企业根本舍不得买,比如BlogBus。 2、F5、Netscaler都能工作在OSI模型的4~7层中。 3、开源软件解决负载均衡中,HaProxy和LVS相对比较优秀,LVS只能工作在4层中,HaProxy能工作在4~7层,并且提供web的状态查询,LVS可以基于命令行进行管理,HaProxy只能通过配置文件实现,HaProxy配置信息子节点可以继承,也可以重新定义,HaProxy能够实现高层应用,也意味着损失一些性能,当然加入实现同样的功能,和LVS差别不大,HaProxy可以很容易实现备份均衡器配置,加入一组负载均衡的机器倒掉之后,HaProxy会自动切换到备份的一组机器上,并且session等信息可以平滑过渡,好处是用户不需要重新登录、购物车不会因切换而被清空等 4、HaProxy实现了负载均衡的ALC控制,减轻后端的集群压力,但是我怀疑这台负载均衡机器的性能是否足够的好,不然会造成单点故障,当然,可以配置多台负载均衡机器 5、HaProxy比LVS更容易实现CDN加速,具体原因没听明白。 接着淘宝来的同志介绍了XEN实现的虚拟化技术,演讲者的名字我也忘了,改日补上。 1、虚拟化主要是指一分多或者多合一,之所以记住这句话,是我的概念中总是以为虚拟化是一分多,可能日常基础的例子都是这样。虚拟主机,VPS等等。 2、虚拟化能够实现快速拷贝环境,配置好一个环境可以复制任意多份运行,前提是物理机器足够的多和强大。 3、虚拟化软件中,Vmware和XEN效率最高,前者是商业软件,后者是免费开源产品。 4、虚拟化并没有在生产环境中得到大规模的应用,目前都是试验性质的,淘宝几乎所有的测试环境都构建于虚拟环境,但生产环境没有例子。 5、虚拟化可以共享存储,真实系统可以读取到虚拟主机中的任意文件,只要设置正确。 第三个是来自这次活动赞助商梭子鱼的经理的演讲,主要是推销梭子鱼的负载均衡设备,号称只有F5三分之一的价格,通过他滔滔不绝的演讲,让我了解(或者叫猜测)到梭子鱼网络均衡设备便宜的原因,实际上梭子鱼就是一个软件集成的厂商,将几个开源软件修改修改,然后丢进一台开起来很山寨的server中,就可以买到F5三分之一的价格,假如这个也叫便宜的话,我觉得F5应该再提价5倍。 第四位依然是51.com的工程师,讲Mysql的灾备体系。 1、灾备体系就是灾难备份体系,也就是在特别紧急情况下的数据恢复问题,比如911事件后,美国摩根斯坦利第二天就能正常运作,这就得意于他们的灾难备份和恢复体系。 2、灾难备份不仅要同地区备份,还要异地备份,最好能定期存入永久存储介质中。 3、备份中需要注意的几个问题是:备份一致性,备份存储,备份对正在运行的业务影响,备份策略等 4、假如11:00发出备份指令,12:00备份完成,如何保证备份时间中的数据一致性问题,主要解决方案如下 a、 使用从库(slave)进行备份,11:00时对从库加锁,然后进行备份,这样做的缺点是,需要增加架设从库的硬件成本,假如有300台主库(master),那么就需要300个从库,当然,可以通过一台机器启动多个从库来减少一部分成本,假如从库压力不大的话。切记要在从库备份前先flush table,不然很多数据还在内存中,无法被备份。 b、直接使用Mysqldump来备份,优点是不会增加太多成本,缺点是一旦启用dump那么数据库将加锁,业务就会被停止,尽管可能停止很短时间 c、使用snapshot(快照)进行备份,此种备份只适合使用InnoDB的存储引擎,因为在备份开始和结束这短时间中,数据库的所有改动操作全部保存在undo log中,备份完成后通过undo log的前滚来保证备份的一致性。 5、在99.9%的情况下Mysql的安全性是可以得到保证的,还有0.1%情况下是不可靠的,比如你正在执行一个删除操作,然后立刻按住CTRL + C中断删除,你会发现一个神奇的事情,你的数据被删了,bin log中却没有任何记录,也就是说,没法恢复了。 6、淘宝现在的所有后台操作只用十几个oracle就搞定了,可见oracle的性能。 7、oracle和Mysql的搭配能显出更高的效率,比如oracle只写,而用Mysql做同步的只读数据。 我感兴趣的内容总结如上,还有其他的演讲者内容就忽略了,抱歉~~ 演讲的PPT估计过几天ChinaUnix会挂出来,隔几日再奉上。
Monthly Archives: 四月 2009
利用CodeIgniter缓存进行攻击
CI自带的缓存系统确实很方便,但她存在一个很大的弊端,看缓存系统的源码: CI把md5(index.php+uri_string)作为缓存文件名(没完全copy,详见libraries/output.php) 这个uri_string允许URI串夹杂垃圾信息,比如: http://ci-site.com/index.php/index/index/1 http://ci-site.com/index.php/index/index/1/2 http://ci-site.com/index.php/index/index/1/2/3 上面三个请求,CI将生成3个不同的缓存文件 问题来了,假如攻击者写一个并发访问脚本: 每秒并发访问100次(任何adsl用户都有足够带宽发起攻击) 循环访问 index.php/index/index/1 至 index.php/index/index/10000000 那么服务器将生成一千万个首页垃圾缓存,在同一个目录里面! 假如你的网站首页html有10kb(一般来讲,10kb作为首页不算大) 这个缓存目录的尺寸将达到:10kb x 10,000,000 = 100GB 完成攻击所需时间:大约27小时 更重要的是CodeIgniter本身并没有提供更详细的缓存检测机制和缓存容量限制机制,加入你没有对cache目录进行磁盘配额限制的话,那么一轮并发高的缓存攻击将有可能将硬盘塞满,之后网站就会变得异常缓慢。而且更要命的是CodeIgniter本身没有缓存清除机制,只能干等着缓存过期或者手动清除,CodeIgniter最大的优势在于它的性能和学习曲线。 总觉得CodeIgniter本身就是一个半成品,没有缓存清除机制也就算了,还没有模块化缓存(即只缓存页面某个或者某几个部分)的的机制,CodeIgniter这么优秀的Framework在缓存方面算是做得很失败了,不过得益于它优秀的扩展性能,仍然有很多解决方法,况且任何Framework都不是完美的。 解决CodeIgniter大体上有四种方法 1)关闭缓存,我觉得这基本上算不得一种解决方法,因为这牺牲了网站的性能 2)架设缓存服务器,对于一般的中小型网站来说这也比较奢侈,且不说squid或者vanish的学习曲线有点长,也没与服务器设备。 3)增加严格的检测机制,这是一个非常可行的方案,比如对URI每个传入参数的类型进行严格的验证,在一个页面显示前进行详细的处理,比如ID为10000的记录数据库中根本不存在,那么使用show_404()方法输出404页面,这个页面并不会被缓存,假如没有增加这个验证,程序输出的页面将会被缓存,只是页面的某个区域的内容为空而已。比如显示文章的区域是空,侧边栏和头部都是从模板中继承过来了,仍然被缓存了。 4)使用其他cache类替代CodeIgniter的缓存类,比如APC