到处都是什么大规模啊，高流量啊，高性能之类的网站架构设计，这类文章一是满足人们好奇心，但看过之后也就看过了，实际收益可能并不大；另外一个副作用是容易让人心潮澎湃，没学走先学跑，在很多条件仍不具备的情况下，过度设计、过度扩展(高德纳大爷也说过，"过早优化是万恶之源")，所以，这里反弹琵琶，讨论一下小规模、低性能、低流量的网站该如何搞法。
如果站点起步阶段可能就是一台机器(或是一台虚拟机，比如 JobsDigg.com )，这个时候，去关注什么数据拆分啊，负载均衡啊，都是没影子的事情。很多大站点的经验绝不能照搬，辩证的参考才是硬道理。
拥抱熟知的技术
动手构建站点的时候，不要到处去问别人该用什么，什么熟悉用什么，如果用自己不擅长的技术手段来写网站，等你写完，黄花菜可能都凉了。所以，有现成的软件组件可用，就不要自己重新发明轮子。人家说 Python 牛，但自己只懂 PHP ，那就 PHP 好了，如果熟悉 .net ?，那也不错。用烂技术不是丢人的事情，把好技术用烂才丢人。
架构层次清晰化
起步的阶段应该清楚的确定下来架构的层次。如果都搅和在一起，业务一旦扩增开来，如果原有的一堆东西拆不开就是非常痛苦的事情。
Web Server <--> (AppServer)<-->Cache(eg. Memcached)<-->DB
层次清晰化的一个体现是(以 LAMP 架构为例)：即使只有一台机器，也应该起个 Memcached 的实例，效果的确非常好(除非内存小)--一般人儿我不告诉他...不要把什么都压到 DB 上，DB 一旦 I/O 压力走到磁盘上，问题要暴露出来是很快的。没错，DB 本身也会利用自己的 Cache，但 DB 的Cache 和 Memcached 设计出发点毕竟不一样。
数据冗余? 有必要
很多人并不是数据库设计专家，如果应用要自己设计表结构什么的，基本都是临时抱佛脚，但三个范式很多人倒是记得牢，这是大多数小型 Web 站点遇到的一个头疼事儿，一个小小的应用搞了几十个表... 忘掉范式这个玩意儿! 记住，尽可能的冗余数据，你在数据层陷入的时间越多，你在产品上投入的就会越少。用户更关心的是产品的设计。
前端优化很重要
因为流量低，访客可能也不多，这时候值得注意的是页面不要太大，多数流量低的站点吃亏就在于一个页面动辄几兆(我前两天看到一个Startup的首页有4M之大,可谓惊人)，用户看个页面半分钟都打不开，你说咋发展? 先把基本的条件满足，再去研究前端优化。
功能增加要谨慎
不是有个 80/20 原则么? 把最重要的精力放在最能给你带来商业价值的地方。有些花里胡哨的功能带来很大的开销，反而收效甚微。记住，小站点，最有价值的是业务模式，而不是你的技术有多牛。技术是为业务服务的，不要炫技。
有些网站不停的添加功能，恰恰是把这些新功能变成了压死自己的稻草。
从开始考虑性能
这一点是可选的，但也重要。设计应用的时候在开始就应考虑 Profile 这件事情。一套应用能否在后期进行有效优化和扩展，很大的程度限制在是否有比较合适的 Profile 机制上。需要补充的是，对性能的考虑必然要把有关的历史数据考虑进来。另请参见网站运维之道的容量规划以及其它小帖子。
好架构不是设计出来的
这是最后要补充的一点。好的架构和最初的设计有关系，但最重要的是发展中的演化：
发展-->发现问题-->反馈-->解决问题(执行力)--> 改进->进化到下一阶段--新问题出现(循环)
有些站点到了某个阶段停足不前，可能卡在执行力这个地方，来自用户的反馈意见上来了之后，没有驱动力去做改进。最后也是死猪不怕开水烫了。最怕听到的就是"业务不允许"的托词，试想如果不改进业务都没了，那业务还允许么? 其实就是一层心理障碍。
这篇文章有浓重的山寨风格，所以，你不要太认真。如果在用短、平、快的方式构建某些山寨网站的话，可参考其中对你有益的点，不赞同的地方可以直接忽视掉，就没必要费力留言进行争论了。
--EOF--
- 好的业务模式(产品) + 很好的技术 = 大赚钱
- 好的业务模式(产品) + 能用的技术 = 也赚钱
- 差的业务模式(产品) + 好的技术 = 赚吆喝(现在的SNS就差不多这样了)
- 差的业务模式(产品) + 差的技术 = 自己浪费资源
猪破或WP改改主题就上了
山寨一般都这么搞的吧,嘿嘿
至理名言，有时真的很容易就陷入到过度设计的尴尬境地，洋洋洒洒的准备了很多东西，却不能在有限的时间中实现出来，商机就这样浪费了。
看来冯大哥很看不起.net技术阿。
我觉得数据冗余上还是不要了，数据冗余的话在维护数据完整性上需要下额外功夫，而数据冗余往往是为了提高性能而冗余的，小站点这方面压力不大，就不要冗余了，现在的ORM框架都能很方便的把关系表现为对象，操作起来很方便，不会带来太多代价。
霍炬大叔最喜欢说啥来着：“提前优化是万恶之源！”
小站点的话，.net 是不咋地。关键是用.net 就要用 Windows，只有一台服务器，几乎一小半的硬件资源被操作系统吃掉，你说还怎么省钱?
数据冗余更是必须的。小站点压力不大更要冗余，冗余不会吧站点搞死，但是遵守范式写两个烂SQL才会让站点奇慢如牛
除了数据冗余，我觉得这篇文章还是很实用的。毕竟技术是用来解决问题的，如果没有那么多需求，那么当然不需要用很复杂的技术。
@西乔
这句话嘎好，俺用了
比较赞同jeffz的关于数据冗余的观点。
那是没有调配好系统才会让操作系统占用很多资源的吧，不该用的服务不用，不该跑得东西不跑，现在Windows Server都可以连GUI都不装了，会占多少额外资源？Windows士别三日改刮目相看了，Windows都别了n久了。
至于冗余问题，看来还是个取舍
1、冗余的优点，查询快捷。缺点：需要更多维护，业务一变，可能还要加不同冗余数据。
2、不冗余的优点，不用维护。缺点：查询需要级联，性能降低。
我的观点是基于：小站点的话，我不知道会不会有复杂查询，级联会不会多。而且小站点的数据甚至都可能完全在内存中，速度很快，数据库自身的优化也很厉害了，再加上你也提到了缓存。真不觉得冗余有什么额外好处——“尽可能的冗余数据”，更是走过了……
我很喜欢这篇文章！太喜欢了！我就喜欢干这种山寨的事情。
每一个人心中的小站都不一样。 看博主的文章都是介绍一个大型网站，至少也是手机之家这种百万流量每日的。
那么什么算小网站呢？一个博客，一个地方信息发布平台。
博主明示！
@杆儿
小型有明确商务目的站点，有赢利点。
不是简单的CMS。
骗子，居然说有美女。
呃呃，正如你所说，python看着好，还在学。只能拿PHP了，好在有诸如wordpress这样的开源系统，架一个网站需要的优化不会太多。
在je看到冯的文章，后来一直关注，只是关注，
今天，这篇不得不给点好评，说得太好了，（之前的文章就应该给评论）
小辈很欣赏这篇文章。想一口吃撑胖子，遗害无穷啊。
Twitter 留言，测试
Twitter 留言居然不用OAuth 还要输入密码？
哈哈，从头开始当然是实用性最重要啦。
我没看错吧？twitter登录竟然是post到dbanotes的服务器的。。。。。
前端优化很重要,十分赞同。学习了
“即使只有一台机器，也应该起个 Memcached 的实例”
网站现在只用了一台机子，之前一直在想要不要给加memcache，现在看来是有必要的
现在一台机子上装了不少东西来支撑一个网站，什么eAccelerator，optimizer，sphinx...装的越多越担心维护的难度，维护成本在不断地增加呀
Memcached、eAccelerator，optimizer，sphinx全用上了，就是为了每天不超过100个IP的网站，而且专用了一台2G内存的服务器，感觉实在浪费，不过不用上这些感觉说不过去，cache层考虑了多memcahced分布，DB层考虑mysql读写分离，天天在这里看，都将那些用上去了
@dyh1919
关于要不要起memcached实例，我也持保留意见。
要做的其实只是“缓存”，但是对于php这种无全局缓存的技术来说，memcached很有必要，因为缓存方案是必须的。但是对于.net/java这种有进程内缓存存储的话，在只有一台机器的时候，就不用memcached这种进程外的缓存了，就算本地回环的性能很高，序列化和反序列化的开销还是省不了的。
@jeffz
看得很透彻啊~
我用memcached来存储db缓存、session和smarty模板缓存，感觉不错，对于小规模站点来说用java是浪费，用。net还说的过去，最好php
请教下FENG大侠，我现做企业网站，每天IP几百，打算增加在线OA和订单处理这些，数据库是MySQL5.1.33，用MyISAM还是InnoDB？有资料说配置优化好两者性能差不多，但那个比较稳定，以及备份方便性，要有免费备份工具，我打算用InnoDB，主要考虑它有事务和存储过程？以你的经验给我建议下？
@jeffz
还是做过几个非 Java/.net 的项目再说吧
@ronin
用 InnoDB 好了.
抱歉，应该是请教Fenng大侠
@Fenng
我接触的东西很广泛的，这方面应该不是井底之蛙。
再说，我是肯定缓存的重要性。然后，如果有进程内缓存，那么自然就用进程的，如果没有进程的，那么就起memcached——这么说难道有什么问题吗？我又没有否定memcached。
@jeffz
你没发现我说的是以数据为核心麽? Memcached 缓存的是数据, 而不是其他
@Fenng
这个和进程内缓存不冲突啊，进程内缓存的也是数据。
@Fenng
这个和进程内缓存不冲突啊，进程内缓存的也是数据。
打个比方：本来可能是
1、检查memcached中是否有数据，有则取出，没有则去下一步。
2、从db中获取数据，并放入memcached
如果是进程内缓存，只是把“memcached”换成“进程内的缓存容器”罢了。
memcached是跨进程的，因此也可以被多个进程（服务器）读写，所谓“分布式缓存”。
同进程内的缓存容器不能被其他进程（服务器）读写，不过节省了网络传输的开销（变成内存共享了），以及数据的序列化和反序列化开销——记得douban的某个阶段不就是因为这个开销导致cpu成为瓶颈了吗？
呵呵，jeffz的观点也没啥问题，冗余不冗余，哪些信息需要冗余都不是绝对的。缓存用开源的还是自己实现也都无所谓，总的来说对于小流量网站，技术上是怎么简单怎么做，具有一定的扩展性，能满足产品需求和较好的用户体验才是最重要的。
哈哈，如果数据量不多的话，哪直接整进程内的内存里面，哪速度...
要知道冗余的方式，这个在业务复杂的时候也适用吗？
这可不是山寨，句句说的是理
"好架构不是设计出来的"
这段的方法论 用PDCA描述更好些 呵呵~~
memcached还没有用到，不过数据尽可能的冗余做的很好，哈哈
fenng老大您好，目前在大数据缓存的环节是否可以考虑使用压缩算法，使得内存空间更加充分利用，以“CPU换内存”的做法适合吗？
是否已经有成熟的解决方案？
@laja
压缩要看什么样的数据了吧，一般来说，没必要的压缩的。”充分利用“不是目的，你的目的是要优化网站，而不是把所有的硬件都跑起来。
构建支持多种缓存模式的类。。这个刚学.net都知道工厂模式。
一台服务器的时候用默认用进程缓存。量大了改配置支持memcached就ok了。
两位大侠为这问题争得。。。
支持文章中的观点！
也许是这样的。
看了这片文章之后，有点后怕。我最近的工作貌似都是“过度优化”
不错，刚好适合。。
自己制作了一个小的数据管理型站点。每个功能，每次，执行前都会进行一次权限验证。当数据库被直接改动时，站点能及时反映出来。
但现在权限验证是访问速度瓶颈，大约占一次[请求-响应]中60%的时间。
验证规则为：
1.当前帐号存在且可用；
2.当前帐号所属组存在且可用；
3.当前功能存在且可用；
4.当前功能所述的各上级类别存在且可用；
5.存在可以匹配当前功能与当前帐号所属组的访问规则且该访问规则已启用。
当所有条件均满足时，当前帐号可以使用所选中的功能。
其中1、2、3、5可以用一个带子SQL的单次查询验证，但4需要递归查询，很吃时间。
权限验证为什么要查询那么多次？有没有可能查询一次搞定？ 这么简单的系统 Schema 设计那么复杂干嘛?
重复的查询考虑Cache了没有？
第一次来，踩一脚，看了很多文章，拓展了不少思路
的确很多时候太纠结一开始就想把什么东西都想好，结果发觉想出来的东西并不是用户想要的东西，所以很多时候应该要先快速的把东西给整出来。再做修改，尤其是人手不够的情况下，快更是要注意~
我认为小站点还要注意一点，不要用Java，太费资源
php／python／ruby都挺好
自己差的太多了。