闲话中小型网络平台如何解决负载问题入门

前言扯淡篇
标题，暂时定这个，入门级文章，专业人士勿扰，最近很多客户（年收入千万级别）都会问这个负载问题，一般问这个问题的客户稍微懂点，也有很多人自以为是内行，其实屁都不懂，这里我说的负载问题是如果你那个破网站没有几百万条数据，访问量没个几十万IP，没有几个机柜，都不能称之为中小型网络平台，中国好几亿网民，有个几百万用户并没有什么了不起的，所以如果你达不到这个起码的标准，就不用杞人忧天担心自己的东西会有什么负载问题，我曾经遇到一个沈阳的做垃圾网站的朋友，他有40多台服务器，文件存储是4个T，独立IP是30多万，关键的问题是解决如何分布式存储的问题，因为数据备份的问题，还需要压缩备份，一般压缩率能达到2/3。

开始步入正题吧

影响一个网站访问速度最大瓶颈是什么？那些自以为内行的人（非专业人士），请回答，答中有奖，有人回答是服务器内存，有人回答是服务器CPU？
正确答案是：带宽和存储
带宽不用说，这是基本条件，马路寛跑得开，解决这个问题也不难，最省事的做法就是花钱！
说说存储，一般一个网站俗的讲就两个主要方面，一是数据库，一个是文件存储；对于一个server来说（服务器），CPU和内存其实都很快，关键的瓶颈磁盘IO的速度（一般SAS硬盘15000转），备注：这里是入门篇，不深度解析磁盘的工作原理。也许有些客户会问了，你说这些有啥用？我只care我的网站的问题，我可以买更多的服务器啊，稍安勿躁，世界上最头疼的问题是花钱不能解决的问题，你买更多的server也解决不了的问题才是最头疼的问题。
上面我们提到了存储，一个网站应用程序最主要的两个部分一个是数据库，一个是文件存储；现在对于一个网站来说这两个东西可以说是至关重要的玩意儿！首先让我来介绍一下随着网站的发展，用户越来越多，几千IP到几万IP，到几十万IP，（当然这是一个过程），比如说你做一个这样的论坛，比如几百万用户，平均日访问量三四十万IP，单日平均帖子数一两万的样子，附件上传单日几万个（假设2万个），每个附件大小限制是2M，平均附件大小500K；那这时候你会发现，数据库层面：一天平均的数据库写入量是一二十万，读取一般一个网站来说60%-80%是读取，大概在几百万读取的量级别（为了通俗一些，这里的量用SQL的条数来衡量了，就是一天几十万条插入查询、几百万的读取查询）；文件存储层面：一天大概有三五万M文件的存储，也就是三五万M文件的存储（1024M=1G），大概每天10G吧，当然以上都是假设，一般情况下，这种论坛每天几十万用户访问，每天上传附件肯定没有这么多，我朋友30万IP，总共也就4T的附件，做了都七八年了，也就是说每年大概有500～600G的数据吧，一天也就是几个G的数据量，这个时候你可能遇到的问题：
1、应用层面，单台服务器不足以支持日访问量几十万IP的访问量，需要做应用层的负载，比如采用LVS等等处理方案，这里存在的问题不大，一般情况下LVS或者dns轮询支持十万级别的还是凑凑有余的，只是存在一个session存储、文件等存储的问题，也很容易处理，多台服务器之间的session同步和文件存储同步问题等等，session可以由原来的文件存储改成存储到数据库中或者memcache中，文件存储可以采用散列的方式存储，基本原因下面在讲存储层面的时候再详细讲述。
2、数据库层面
数据库越来越大，每天至少十万级别的新的数据记录，数据库表记录百万级别的，数据库查询读取问题很大，传统的架构根本解决不了问题，这时候我们通常的做法是将数据库的读写分离，把写操作分配到一组高性能的server，把查操作放分配到另外一组从服务器上面；另外就是将单个服务分离，不过那个貌似没个千八百万用户没有什么必要性，比如注册登陆做一组单独的服务，后面跟着数据库、缓存等服务器，这样做最大的弊端就是各个应用之间的交互就只能通过接口调用的机制了，但也是他最大的优点，服务独立，扩展性也比较不错。
3、存储层面
这个问题，我们原来采用的解决方案比较傻，弄好几台服务器做存储，然后挂载n多的本地盘，nfs这个玩意儿读没有啥大问题，但是写的时候就打哈哈了，4T数据，用七八台服务器，每台服务器存点，前台的时候也麻烦，比如s1.xxx.com,s2.xxx.com,s3.xxx.com麻烦死人，有钱的上存储阵列，不过我身边的人貌似都是穷人，都是追求廉价的方案。4T数据原来的存储方式是在论坛的附件里面加一个字段，标识该附件存储的服务器，比如server字段存储值是s1,然后挂载本地磁盘目录，s1,s2...sn这种做法当然比较傻，但是也是最简单的解决方法。现在我们基本上不会再这么玩了，我们用openFiler和FreeNAS做网络存储，为此我还专门写过一篇安装的入门篇（http://user.qzone.qq.com/153987948/blog/1323157044），我们也用hadoop，坦白的HDFS是一个不错的分布式文件系统，但是并不是那么完美，不适合低延迟数据访问、无法高效存储大量小文件、不支持多用户写入及任意修改文件。但是基本上论坛的附件之类的都不会反复任意的修改，所以基本上也是可以尝试用用的，另外就是分布式存储的最大的好处就是备份和负载同时都考虑到了，所以也是一个很好的选择。
 
那您为什么要选择我们的服务呢？
首先，任何架构都不可能一步到位，当你只有1000IP的时候，你的应用必须能满足5万IP的用户的访问量，如果你的访问量达到一两万的时候，你就应该着手去进行第二步的架构的升级了，系统应该能满足十万级别的访问量，一步一步升级架构，来满足你的网站业务发展的规律

这里我就要说说coolphp的架构优势，因为我们所有的项目开发都是基于这个玩意儿，我们针对负载这个话题也做了一些工作，可以无缝支持您的应用的扩展，主要体现在：

数据库层面，支持分布式主从数据库，COOLPHP支持分布式主从数据库读写，配置一下轻松搞定；其次，面对大表，我们支持表的散列存储；数据库驱动支持Mongodb扩展，可以让您使用基于分布式文档存储的数据库架构；
缓存机制，在数据库层面，我们每个应用支持memcache、EA等缓存加速机制，类似Ruby ON Rails，COOLPHP也支持页面缓存，片段缓存机制；

session存储机制，支持数据库，memcache存储机制，可以顺利解决多台服务直接session同步的问题；
自主研发的基于Master/Worker的Kworker处理队列机制，可以将各个任务分解到不同的服务器进行处理；

COOLPHP的应用开发架构案例说明
下面是我们给某客户提供的网络部署解决方案，客户日均大概有10万IP左右，用户每天上传文件附件（包括视频）大约3000～5000个左右，每个文件的大小大约是1M左右，文件上传之后必须压缩存储



主要应用架构说明：

Nginx+PHP-fpm服务+Mysql主服务

MemCache服务+Mysql从服务+sphinx索引服务

存储服务

最后，我要说的是，也许以上这些并不足以解决你的问题，但是它会为你迅速解决负载问题留下一些时间，让你来得及升级你的系统，任何架构都不可能一步到位，没有架构师可以很完美的预见未来；我们能做的只有尽力做得更好！写篇文章真费时间，就到这里了，有问题随时与我们联系kokko<kokko
at itbeing.com> 一天创想北京科技有限公司 http://www.itbeing.com
版权所有一天创想北京科技有限公司 http://www.itbeing.com