看了一些人的所谓大型项目的方法,我感觉都是没有说到点子上，有点难受。
我也说说自己的看法.我个人认为,很难衡量所谓项目是否大型,
即便很简单的应用在高负载和高增长情况下都是一个挑战.因此,按照我的想法,姑且说是高负载
高并发或者高增长情况下,需要考虑的问题.这些问题,很多是和程序开发无关,而是和整个系统的
架构密切相关的.
数据库
没错,首先是数据库,这是大多数应用所面临的首个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工作都使用了这样的架构，整体感觉来说还是值得信赖的，单表毕竟存在面对极限数据量的风险。