开发大型高负载类网站应用的几个要点(转)

看了一些人的所谓大型项目的方法,我感觉都是没有说到点子上,有点难受。
我也说说自己的看法.我个人认为,很难衡量所谓项目是否大型,
即便很简单的应用在高负载和高增长情况下都是一个挑战.因此,按照我的想法,姑且说是高负载
高并发或者高增长情况下,需要考虑的问题.这些问题,很多是和程序开发无关,而是和整个系统的
架构密切相关的.

数据库
没错,首先是数据库,这是大多数应用所面临的首个SPOF。尤其是Web2.0的应用,数据库的响应是首先要解决的。
一般来说MySQL是最常用的,可能最初是一个mysql主机,当数据增加到100万以上,
那么,MySQL的效能急剧下降。常用的优化措施是M-S(主-从)方式进行同步复制,将查询和操作和分别在不同的
服务器上进行操作。我推荐的是M-M-Slaves方式,2个主Mysql,多个Slaves,需要注意的是,虽然有2个Master,
但是同时只有1个是Active,我们可以在一定时候切换。之所以用2个M,是保证M不会又成为系统的SPOF。
Slaves可以进一步负载均衡,可以结合LVS,从而将select操作适当的平衡到不同的slaves上。

以上架构可以抗衡到一定量的负载,但是随着用户进一步增加,你的用户表数据超过1千万,这时那个M变成了
SPOF。你不能任意扩充Slaves,否则复制同步的开销将直线上升,怎么办?我的方法是表分区,
从业务层面上进行分区。最简单的,以用户数据为例。根据一定的切分方式,比如id,切分到不同的数据库集群去。
全局数据库用于meta数据的查询。缺点是每次查询,会增加一次,比如你要查一个用户nightsailer,你首先要到
全局数据库群找到nightsailer对应的cluster id,然后再到指定的cluster找到nightsailer的实际数据。
每个cluster可以用m-m方式,或者m-m-slaves方式。
这是一个可以扩展的结构,随着负载的增加,你可以简单的增加新的mysql cluster进去。

需要注意的是:
1、禁用全部auto_increment的字段
2、id需要采用通用的算法集中分配
3、要具有比较好的方法来监控mysql主机的负载和服务的运行状态。如果你有30台以上的mysql数据库在跑就明白我的意思了。
4、不要使用持久性链接(不要用pconnect),相反,使用sqlrelay这种第三方的数据库链接池,或者干脆自己做,因为php4中mysql的
链接池经常出问题。

缓存
缓存是另一个大问题,我一般用memcached来做缓存集群,一般来说部署10台左右就差不多(10g内存池)。需要注意一点,千万不能用使用
swap,最好关闭linux的swap。

负载均衡/加速
可能上面说缓存的时候,有人第一想的是页面静态化,所谓的静态html,我认为这是常识,不属于要点了。页面的静态化随之带来的是静态服务的
负载均衡和加速。我认为Lighttped+Squid是最好的方式了。
LVS <------->lighttped====>squid(s) ====lighttpd

上面是我经常用的。注意,我没有用apache,除非特定的需求,否则我不部署apache,因为我一般用php-fastcgi配合lighttpd,
性能比apache+mod_php要强很多。

squid的使用可以解决文件的同步等等问题,但是需要注意,你要很好的监控缓存的命中率,尽可能的提高的90%以上。
squid和lighttped也有很多的话题要讨论,这里不赘述。

存储
存储也是一个大问题,一种是小文件的存储,比如图片这类。另一种是大文件的存储,比如搜索引擎的索引,一般单文件都超过2g以上。
小文件的存储最简单的方法是结合lighttpd来进行分布。或者干脆使用Redhat的GFS,优点是应用透明,缺点是费用较高。我是指
你购买盘阵的问题。我的项目中,存储量是2-10Tb,我采用了分布式存储。这里要解决文件的复制和冗余。
这样每个文件有不同的冗余,这方面可以参考google的gfs的论文。
大文件的存储,可以参考nutch的方案,现在已经独立为hadoop子项目。(你可以google it)

其他:
此外,passport等也是考虑的,不过都属于比较简单的了。

说了关键的几个部分,还有一些比如squid群、LVS或者VIP(四层交换)之类的必须考虑,数据库逻辑分表不需要master里面查id,可以定期缓存或者程序逻辑上进行控制。
跟大家分享一下我的经验: http://www.toplee.com/blog/archives/337.html (欢迎讨论)

楼上说的很好.
我再说一下关于为何要在主表查询,最主要的因素是考虑到复制和维护的问题。假设按照程序逻辑,用户nightsailer应该在s1集群,但是由于种种原因,我须要将nightsailer的数据从s1集群转移到s5集群或者某些时候,我需要将某几个集群的数据合并,此时,我维护的时候只需要更新一下主数据库中nightsailer的cluster id从1变成5,,维护的工作可以独立进行,无需考虑更新应用程序的逻辑。也许程序的id分配逻辑可以考虑到这种情况,但是这样一来,你的这个逻辑会发散到各个应用中,产生的代码的耦合是很高的。相反,采用查表这种方式,只需要在最初的时候进行初始分配,那么其他的应用是无需考虑这些算法和逻辑的。
当然,我最初提到的增加这次查询并不是说每次查询都需要找主数据库,缓存策略是必定要考虑的。

至于说为什么要禁用auto_increment,我想也清楚了,数据的合并和分隔,肯定是不能用auto_increment的。

在闲扯一下,PHP的优化可以有很多,主要的措施:
1、使用FCGI方式,配合lighttpd,Zeus.
我个人比较喜欢Zeus,简单可靠。不过,需要¥¥¥。
lighty也不错,配置文件也很简单,比较清爽。最新的1.5,虽然不稳定,但是配合linux的aio,性能的提升
非常明显。即便现在的稳定版,使用2.6的epoll可以得到的性能是非常高。当然,lighty比zeus缺点是对于smp
的支持很有限,所以可以采用多服务器负载,或者干脆起不同的进程服务监听不同的端口。
2、专门的PHP FCGI服务器。
好处多多,在这个服务器上,就跑php的fcgi服务,你可以把一些缓存加上,比如xcache,我个人喜欢这个。
还有别的,套用大腕的话,把能装的都装上,呵呵。
另外,最主要的是,你可以只维护一个php的环境,这个环境能够被apache,zeus,lighttpd同时share,
前提是这些都使用php的fcgi模式,而且,xcache可以充分发挥!
3、apache+mod_fastcgi
apache并非无用,有时候也需要。比如我用php做了一个web_dav的服务器,在其他有问题,只能跑apache.
那么,apache安装一下mod_fastcgi,通过使用externl server,使用2配置的php fastcgi。
4、优化编译
ICC是我的首选,就是intel的编译器啦,用icc重新编译php,mysql,lighty,能编的都编,会有不小的收获的。尤其是你用
intel的cpu的话。
5、php4的64位需要patch
好像没有人在linux x86_64上编译过php4吧,我曾经googleit
,别说国内了,连老外都很少用。
这里就做个提醒把,如果用php官方下载的(包括最新的php-4.4.4),统统无法编译通过。问题是出在autoconf上,需要
手工修改config.m4,一般是在mysql,gd,ldap等一些关键的extension上,还有phpize的脚本。把/usr/lib64加入到
config.m4中相关搜索的path中。
不过我估计很少人像我这样死用php4不防,呵呵。php5就没有问题。
我也考虑正在迁移到php5.2,写代码太方便了,一直忍着呢。

==

过我们可能讨论的不完全一样,呵呵。
我所说的分表要依据不同的业务情况来划分的,

1、可以是垂直划分,
比如依据业务实体切分,比如用户a的blog贴子,用户的tag,用户的评论都在a数据库u,甚者是完整的一套数据结构(这种情况下应该说是分数据库)

2、也可以水平划分,
一个表的数据分在不同的数据库上。
比如message表,你可能分为daily_message,history_message,
dialy_meesage可能是hot对象,week_message是warm,2个月以前的帖子
可能属于cold对象了。这些对象依据访问频度不同会划分到不同的数据库群上。

3、二者结合

不过,不论如何,更改、删除并不复杂,和未分区的表没有区别。

至于查询和排序,不可能仅仅是通过select,order吧?
而是应该产生类似摘要表,索引表,参考表。。。
另外,要根据业务具体分析减少垃圾数据,有些时候,只需要最初的1万条记录,那么所有表
数据的排序就不需要了。很多传统的业务,比如零售,流水表很大,但是报表的数据
并非实时生成的,扎报表应该不陌生。

也可以参考很多网站的做法,比如technorati啊,flickr之类的。

所谓的麻烦是你设计系统的结构的时候要考虑到,在设计数据库的时候更要注意,
因此只要项目的framework最初设计比较完备,那么可以说大部分对开发人员是透明的。
前提是,你一定要设计好,而不是让程序员边写代码边设计,那会是噩梦。

我写这么多废话,并非仅仅是对程序员来说,也许对设计者更有用。

==

程序逻辑上控制表拆分只需要维护一个数据库访问的配置文件即可,对于开发来说,完全透明,可以不用关心访问的是哪里,而只需要调用通用的接口即可,曾经做过的系统里面,这样的应用经常遇到,尤其在全网passport、社区帖子等方面的处理上应用最多。

原来在yahoo工作和后来mop工作都使用了这样的架构,整体感觉来说还是值得信赖的,单表毕竟存在面对极限数据量的风险。

留下评论

您的电子邮箱地址不会被公开。 必填项已用 * 标注

36 + = 44