结合MySpace，论大型网站的架构设计(一)

结合MySpace，论大型网站的架构设计(一)

     本文是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机器的数量比例是通过性能调研网站应用的数据库读写比例得出的。

 

下次是缓存。