浅谈常规网站是如何从小变大的

到上面一个阶段，我们初步接触到了逻辑、存储等的多机模式。这样的结构，对于逻辑不是特别复杂的网站，足以撑起千万级的压力。所以大多数网站，只要能够用好上面的结构就可以很好的应对服务压力了。只不过还有很多细节的工作需要精细化，比如：多机的运维、稳定性的监控、日志的管理、请求的分析与挖掘等。

如果流量持续增长，或者是业务持续的扩展，上述的架构可能又将面临挑战。比如，多人开发常常出现版本冲突；对于数据库的更新量变大；一个表里面的记录数已经超过千万甚至过亿等等。

怎么解决呢？还记得我们之前介绍过一个CAP理论嘛？三要素里面有一个东东叫：分区容忍性（Partition tolerance）。其实，这个就是我们接下来解决问题的基础：切分！

一、从数据流向来看，切分包括：请求的切分、逻辑的切分、数据的切分。

数据的切分：将不同的数据放到不同的库中，将原来的单一的一个库，切分成多个库。

逻辑的切分：将不同的业务逻辑拆分成多份代码，用不同的代码管理路径来管理（如svn目录）。

请求的切分：将不同的逻辑请求分流到不同的机器上。比如：图片请求、视频请求、注册请求等。

二、从数据组织来看，切分包括：水平切分、垂直切分。

数据库的变大通常是朝着两个方向来进行的，一个是功能增加，导致表结构横向扩展；一个是提交数据持续增多，导致数据库表里的数据量持续纵向增加。

数据量变大以后，单机性能会下降很明显，因此我们需要在合适的时候对数据进行切分（这个我没有太深入的研究过相关数据库的最合适的切分点，只是从经验上来讲，单表的字段数控制在20个以内，记录数控制在5千万以内会比较好些）。

垂直切分和水平切分，其实是挺纠结的两个词。我之前对这两个词经常搞混。后来自己画了个图，就很直接明了了。

水平切分：

水平切分就是因为记录数太多了，需要横着来一刀，将原来一张表里面的数据存入到多张表中，用于减少单张表里的数据量。

垂直切分：

垂直切分就是因为业务逻辑需要的字段太多，需要竖着来一刀，将原来放在一张表里的所有字段，拆分成多张表，通过某一个Key来做关联（如关系数据库中的外键），从而避免大表的产生。