应对负载和数据压力,分几个层面
第一是硬件性能挖掘
要理解硬件的瓶颈,内核的特性,压力构成,对硬件适当提升;典型的如淘宝和新浪微博,使用fusion-io做固态存储,i/o支撑能力提升了几十倍,很多优化就简单多了,当然,人家对整个mysql的多线程写入机制,cpu寻址方式,顺序写和随即写的存储分布也做了非常多的工作,不仅仅是购买硬件而已,但是核心是,理解硬件,理解系统级的处理机制,来做优化。
第二是DBA级别和系统运维级别
理解数据库的结构,索引方式,善于使用各种数据库工具分析数据负载并掌握瓶颈点,优化数据索引和查询,插入语句,优化数据库配置参数,通常很多小公司,小网站,这一步都不到位,一些简单查询就把数据库搞死了。
对于nginx或apache,要知道针对你的业务类型,如何调整参数和优化,如何选择日志记录方式,等等。
第三是应用架构和程序层级
如何设置缓存,设置存储队列,将频繁重复的查询缓存化,将频繁的更新操作通过队列合并化,通过减少数据请求减少数据压力。
此外,通过数据中间件(自己写或第三方),通过负载均衡工具(lvs,haproxy等公开方案即可),将系统结构扩展,尽量做到充分冗余,无单点隐患,同时支持服务器自由扩展,可以参考haproxy和lvs的百度百科文档和网上资料,非常多。但是我希望提醒一点,如果单服务器的优化没有做到位,就开始做负载均衡和服务器规模化的事情,其实是给自己找麻烦,不但成本居高不下,而且运维复杂度也高了很多,做架构升级前,请确保基本服务器的性能达到一定水准(不要求如淘宝一样极端,但是至少能保证都可以做到每秒几千个请求处理)。
第四是需求控制
用户主要和基本功能满足的前提下,对用户极少关注和使用的特性,以及功能细节,予以适当的裁撤和放弃,保证系统整体的可靠性,比如最简单的一个话题,无论百度,谷歌,淘宝,微博,都不允许用户无限制大翻页,这就是最基本的需求控制方法。我实例发现不少工程师花费70%的时间和精力在用户根本不需要的功能特性上,这是很浪费的。
细节很多,想个人做到,如果没有一定技术基础,很难,非常难,相当相当难。
nginx可以做到一秒上万请求,mysql读请求可以做到一秒数千到上网(一定数据量和索引合理的情况下),写操作500/s以上合格,淘宝能做到十万,这个不好比,我们能做到几千。(有一定数据规模,真实业务场景)。mysql 5000w条记录以下个人认为基本不需要分表。
文件有类似mogifile等分布式文件系统,不过个人感觉不好用。
-- 完 --
下载知乎 iPhone 客户端:
http://zhi.hu/ios