为什么Stack Overflow只需要11台IIS 服务器和4台负载均衡就可以支撑这么大的流量？ 第1页

因为他们把买硬件的钱花在找程序员身上了

2013年还是2014年，stackoverflow第一次公布了部分数据和架构，引发了我很大的兴趣。

当时stackoverflow日UV 300W+，PV 2Y+，正好和我司当时的数据完全一样。他们使用了8台物理服务器，而我们呢，使用了400+近500台物理服务器。

我们是lamp架构，和stackoverflow的windows体系架构有区别，但是性能差异不至于到大数量级。而且一般来说lamp架构的性能更好，而我们正相反。我们采购的是戴尔低端机型，换算到stackoverflow的性能，大概是2:1，那么硬件资源的对比是250:8，性能差异是反比，8:250。

我们的架构上应该没有大问题，db分布了，缓存分布了，solr做的search，图片资源多但走的是外部的cdn，该做的调优也做了，打了google的malloc，开了大页内存，nginx mysql redis的各项参数，也做了性能测试和ab test经过n轮调整，那为什么性能差异还是这么大?

一个原因应该是业务逻辑，我们带有社交元素，交叉的各种点赞，关注，收藏等关系和查询，有更多性能开销，但是这个我觉得不是主要原因。主要的性能差异在我看来，是应用层面开发的程序员造成的。

我们处理过许多许多典型的性能坑：

db查询没用到索引

联表查询太复杂性能奇差

循环里写查询一次连接变几十次

打开文件句柄 socket连接没有释放

300k文本直接存到redis里

curl请求没有加超时

不同的进程争抢同一个文件资源写日志

get_image_size()获取图片尺寸(会把图片文件整个读取到内存里，每个连接都会！)

写的扩展内存溢出

直接读取整个巨大文本文件(应该逐行方式读取)

在代码逻辑循环里直接发短信发邮件(应该扔到队列异步处理)

ip黑名单和关键词过滤直接用文本查找比对(应该做成hash表)

每次看面试题都是算法，调优，架构(我们自己也是)，其实我想说90%的情况下我们需要的是能合格编写增删改查的业务需求的程序员就够了。

至于stackoverflow，我想他们也没有发明什么太多银子弹黑魔法，指数级的提高性能。他们做到的只是：找到了合格的程序员。

这就够了。