本文是F君在阅读了大量网站架构类文章后的所见所感。虽然文中所讨论的情况已经大大的超过F君在实践中所碰到的计算规模,但F君相信也许有一天,亿万人民能用上自己加过的应用服务。^_^
世界上牛逼的大型网站应用还真不少,有JAVA阵营的Ebay,LAMP阵营的Digg,杂烩式的Amazon,自己独成体系的Google。我要讲的是.NET世界中的MySpace,MySpace从03年底上线,但注册用户数量早在06年就已经达到了1亿。它仅用了3年就达到了这个级别,这点连facebook都自叹不如。其实MySpace也是从大家所构建的小型网站开始一步步壮大起来的。
阶段一:物理分离
也许某一天我们上厕所时,会突然冒出一个很好的想法,我们认为也许我们的会成为下一个互联网上的杀手级应用,于是我们无比兴奋的将想法付诸于实践,这是一个实验性的产品,我们找到一台托管主机,把网站应用和数据库部署上去。Ok,正式对外提供访问。在chaos阶段大多数应用吸引的用户寥寥无几。然而少部分幸运儿总是能脱颖而出。用户开始渐渐的多了起来,你会发现在高峰时期服务器渐渐的不堪重负,频繁的宕机使得我们不得不重启机器和应用。原因很简单,WEB服务器和数据库都是急需硬件资源的主儿,因此最简单的方法就是将应用和数据库分开部署,以此来减少互相的竞争,具体用几台服务器作为WEB服务器,几台作为数据库,这个问题是具体情况具体讨论的。
MySpace在用户数增长到50万之前,还只有两台Web服务器和一个数据库服务器。在用户增长到50万后时,后台数据库已经不堪重负。于是MySpace采用类似MySQL的master-slave replication架构(关于与DB相关的master-slave,反范式,Sharding,垂直分表,水平分库会在F君以后的文章进行讨论),让两台slave数据库服务器来负责read的负载,master数据库服务器来负责write。slave服务器同时同步master机器最新的更新。(也可以slave服务器每隔一段固定时间与master机器作同步),这样来均衡负载,降低数据库的压力。master-slave replication架构,是以冗余的代价来换取更高效率的数据库读写,而且这种架构在负载分配算法合理的情况下有着很好的读性能,也具有一定的可靠性(slave机器down了有替身,master机器down了就玩完了),同时也比较方便的进行scale-out。具体在架构中slave和master机器的数量比例是通过性能调研网站应用的数据库读写比例得出的。
下次是缓存。