看了一些人的所谓大型项目的方法，我感觉都是没有说到点子上，有点难受。
我也说说自己的看法.我个人认为，很难衡量所谓项目是否大型，即便很简单的应用在高负载和高增长情况下都是一个挑战.因此，按照我的想法，姑且说是高负载高并发或者高增长情况下，需要考虑的问题.这些问题，很多是和程序开发无关，而是和整个系统的架构密切相关的.
一、数据库
没错，首先是数据库，这是大多数应用所面临的首个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等也是考虑的，不过都属于比较简单的了。抛砖引玉而已。
