写给WEB2.0的站长 不仅仅是泼冷水_建站经验教程

推荐：站长的朴实 站长的共鸣
不说话的站长 租一间房子，拉一条网线，借钱买一台电脑，很多个人站长就这样开始了自己的站长生涯。 站长是没有早晨的，当早市上人潮汹涌的时候，他们才刚刚入睡，在梦中他们拥着QQ上那个远方的女孩，假如这时候有人在他们旁边，定会看到他们脸上灿烂的笑脸。 中午醒来

当互联网吵吵嚷嚷的进入2.0时代，当互联网的技术不再是那么高不可攀，当复制变成家常便饭，互联网热闹起来了

Myspace火了，中国冒出更多的myspace

Youtube刚刚起来，中国的视频网站就遍地开花

51拔地而起，中国出了无数的SNS

facebook则改变了中国站长的抄袭方式，不再学chianren了，校内火了

..........

当抄袭变成习惯，我想说的是，模拟，站长，你预备好了吗？

假如你打算做垃圾站，或者赚点广告费的网站，请不要点击这篇文章，我从技术角度方面谈谈WEB2.0网站的模拟问题。

当投资和流量都不是问题的时候，我想说的是，您真的一帆风顺吗？

拿SNS网站来说，当匆匆上线的2.0，当一笔笔投资砸进去的时候，当流量上去的时候，您的困惑在什么地方？

我做过多个2.0公司的技术顾问，简单的谈谈2.0公司碰到的问题(涉及隐私，我用A B C D代替)，这里就不再赘述大家众所周知的页面静态化，缓存和代码安全等问题了，有点技术的2.0公司的CTO都知道这些东西，我们谈点发展之后的问题

A公司

A公司做的是SNS网站，程序是两个毛头小伙子做的，目标直指51，程序开发是一帆风顺，功能也比51牛多了，推广也是一帆风顺（A公司有自己独到的推广方式。但是当ALEXA到2W的时候问题出来了，天天下午4点左右，网站速度慢的惊人，基本上打不开，公司三台服务器CPU100%，让人郁闷的是公司的网络配置方式，居然是双WEB的集群，而单独一台DB数据库。整个瓶颈在数据库，于是我建议做DB的集群，分析了一下数据结构，MD，典型的WEB程序员的作品，没有一点数据库设计规范，功能实现是可以，假如要扩展，不可能，集群基本上是不可能的，怎么办？不能办，于是，一个月的时间修改程序，数据结构基本上换了一遍 前期砸进去的几十万打了水飘，用户走光了。

结论：WEB2.0前期设计的时候不应该只考虑功能，应该认真考虑一下底层和数据结构了。

B公司

B公司也是做的SNS网站，程序是3个人开发的，CEO是某名牌大学的经济学硕士，有点知己网的味道，又有一些特色出来，说实话，公司的潜力不错，CEO有很强的运作能力，感觉前景不错。系统架构还行，但是---但是系统崩溃了，why?系统没有考虑到用户有个海量的说法，文件也有个海量的说法，用户的相册，图片全部存贮在WEB服务器的一个分区上，每个用户一个目录，而打开性能监视器，磁盘的IO高的惊人，基本上无暇响应。众所周知，文件系统也是一个数据库，单独大文件无所谓，要害是整个是300多个G的零碎文件，大量的读写操作，系统崩溃，数据丢失，文件系统的一个链断了，用户数据全部丢失！！！这是一个非常沉重的问题，系统整整停了一个月来做数据恢复（单独文件很轻易，但是海量文件目前还没有一个软件能组织起来软件架构）。解决方案：修改程序架构，做分布式文件存贮（程序修改用了8天，但是文件转移却又用去了将近一个月），20万用户损失殆尽。

结论：WEB2.0前期的设计应该有应付海量存贮的考虑，整个涉及了程序架构的修改，前期规划不好的话基本上思路一条。

C公司

C公司是一个值得尊敬的公司，CEO技术出身，和比尔盖茨一样，大学未毕业出来做网络，01到03年做短信狠赚了一笔，后来做的小项目也小有所成，说实话，我很佩服。公司做的是校友方面，但是更偏重myspace风格，注重个人主页，推广方面也下了大手笔。系统崩溃的原因其实很简单，由于采用的是微软的SqlServer，而微软直接就告诉了我们，SQLSERVER不支持集群，他们的数据库超负载，100%就没有下去过，只能横向增加配置，采用了4路4核CPU系统，但是系统还是崩溃了... 高互动注定了高负载。解决方案： 现从基本入手，解决掉几个程序耗能大户，对数据库采用横向切割，将用户每10万进行分组，同时对数据库系统进行散列，将多个表垂直分割，同时进行文件分组 ，解决问题. 因为修改了数据结构，程序也基本上大动了一下。 好在系统没有出大错，损失不算很大，不过对用户体验造成了很坏的影响。

分享：什么是垂直搜索？
垂直搜索是针对某一个行业的专业搜索引擎，是搜索引擎的细分和延伸，是对网页库中的某类专门的信息进行一次整合，定向分字段抽取出需要的数据进行处理后再以某种形式返回给用户。 垂直搜索引擎和普通的网页搜索引擎的最大区别是对网页信息进行了结构化信息抽取，也就是