谈并发的大部分是装逼的。这是我这段时间的体会。如果真要人。你不懂他都可以招去慢慢培养。
不想要人。你就是再牛也没用。
这么多人顶我呀。受宠若惊的感觉。不过并发没办法帮你解决了。我还没有处理过上万的并发了！
但通常都是要找出瓶颈。才能去解决问题。
http://berb.github.io
这是一个基本的介绍。楼主可以去读读。
写了非常多的想法。基本是硬件+软件的解决办法。
硬件方面主要是负载均衡。CDN加速。auto scale（vertical scale && horizontal scale）。但我觉得3个服务器来scale 好像用处不大。
软件方面就是做各种缓存。还有PHP运行机制的改变。比如fastcgi通常比cgi更好等。facebook的那个hiphop应该就是从这个方面去优化的吧？
当然其他的优化还有i/o阻塞。同步。异步等等。排队等处理方式。最近流行的node.js就是在这个方面做得吧。
至于更加高级的mapreduce等等。我觉得那些已经不再普通程序员的讨论范围内了。

PS::在我看来瓶颈很少是由语言造成的。那些个拿语言来说事的。我都懒的回复了。

如果比较懒的话。直接Amazon Lambda解决所有问题。Lambda可以在你负载上来的时候自动伸缩。上传代码就行。其他的交给Lambda去解决吧。只要出服务器费用多大的事都不是事。
就怕这那种一台1G内存的虚拟机谈什么无限并发。那不是难为人魔。。

感觉你没有和他沟通就开始作答：
首先，他说只有三台服务器，只指三台web服务器吗？那么db主备各有几台，提到了吗？
其次，他说的并发量几乎接近无穷大？这么大的流量，他来源何处，有效的流量到底有多少？你问了嘛？无效的流量需要你做优化吗？直接干掉
最后，cdn做缓存，我有点不大理解，cdn顶多也就是存储一些静态图片资源，js，css等等，像论团这种类型的，很多可能都是UGC内容，你用cdn如何缓存啊？

三台机器，三台什么样的机器，三台机器并发接近无穷大这问题本身就是相悖的。我认为在面试中太宽泛的问题其实就是耍流氓，不过也可以说明一点，面试官没有什么处理高并发的经验，只是想听听你的看法
三台这样的：
CPU：Intel(R) Xeon(R) CPU E7-4870 v2 @ 2.30GHz×4 总计60核
内存：512G
硬盘：fio卡，文件系统采用ext4文件系统

还是三台IBM的小型机、还是三台阿里云512M的vps，这里如何保证高可用，高性能，只能说尽最大优化，达到并发的极限

社区型平台的瓶颈在哪里，活跃用户有多少，数据量有多大，什么都没有怎么做？
只好回单业内通用的架构了

1.拆表：大表拆小表（垂直拆，水平拆；分表，分区partition，分片sharding），可以在应用层实现，也可以在数据库层面实现一部分；提高系统性能。
2.分库：把表放到不同的数据库，这也是分布式数据库的基础；提高系统性能。
3.分布式：不同的数据库放到不同的服务器；提高系统性能。
4.集群：使用数据库复制等技术组建集群，实现读写分离、备份等；提高系统性能、可用性。
5.缓存：对常用的数据进行缓存。提高系统性能。
6.备份：主从库，快照，热备，异地备份等；提高系统可用性
架构：LVS+keepalived+Java/PHP/Python+mysql/mongodb+memcached/redis+centos+nginx/apache+sphinx/solr+Gearman+Munin+TFS

你的回答的确很普通,你应该说三台机器根本就扛不住高并发,3台服务器会直接宕机的,无论怎么优化都无法做到抗住高并发,这个面试官是个SB.

三台服务器肯定是满足不了无限的并发，只能是尽量的优化。优化的顺序是：业务、程序、部署。

从业务上要处理好应用超出负荷时的处理，比如：目前在线人过多请稍候访问之类的提示；减少图片、附件等上传的大小限制，甚至临时取消附件功能，减少带宽和存储空间的压力；分页只支持固定的分页。

程序上包括应用的优化和数据库的优化。有可能的话尽量使用第三方的服务减少服务器自身的压力。首页等访问量大的页面静态化，减少数据库的压力，批量的实务代替时时的处理。数据库要对业务表的锁进行细化处理，读写分离。

部署上要数据库一台，另外两台负载均衡。使用cdn尽量把流量分离出去。增加防ddos攻击，跳高防护的等级，减少网络攻击对普通用户的影响。

其实三台服务器能做很多事情 ：）

应对并发的体会，暂时想到下面2点：

并发中的性能问题
1，有钱就堆设备
2，充分利用缓存(配合php的黑魔法fastcgi_finish_request非常好用)

并发中数据一致性问题
1，使用队列
2，必要的自动复查
3，数据库锁的合理利用

话说有一次我去蓝汛面试，“面试官”问了我两道题，我都答上来了，但是他非说我错了，还说自己写了5年shell，《shell编程》那本书从头到尾都看过，从没见过这种写法，云云。 当时他带着电脑来面试的。我说在电脑上试一下就可以知道对不对。但是他说没必要。然后就说我不合适。我回去之后，在自己的电脑上试一下，完全正确。
这个故事告诉我们，有些所谓“面试官”其实水平很烂，而且有些人怕地位不保，还不想招水平比自己高的人。
所以也没必要为了一次面试没过或者答案被否定就否定自己。

:) 楼上的很多人对面试官有意见啊。其实，面试的时候被问一些模糊的问题很正常，我面试的时候也会问几个这种问题。站在面试官的角度来说，抛出一个边界不确定的问题，让被面试者自己界定和分析问题，既能有效观察到被面者的应对技巧和分析思路，又能避免把问题限定到被面者不熟悉的地方从而让被面者无法发挥。而且，在实际项目中，项目经理或者产品经理甚至同事给你建任务的时候，提的需求或者问题，很可能是模糊的。所以从面试官来讲，问些模糊甚至不着边的问题其实还是蛮需要的。

就这个问题来讲，楼主过早的给出了答案，而没有把问题条件分析清楚。面试官的意思是，在给定的三台服务器情况下优化现有社区型平台的并发能力，越高越好。1.先分析清楚社区型平台的特性，计算密集还是IO密集？2.现有社区型平台的技术架构是什么？3.三台服务器里服务和DB的部署情况是什么样的，利用率有没有达到最优？4.确定前三个问题，找到性能节点，如果是数据库，换数据库/分表/分库/热存balabala，如果是前端，那用的是前端模板还是后端模板，cdn/静态化/API合并/缓存balabala，如果是后端，根据平台框架，可能的优化方案更多了。。。5.结合问题的界定和分析，给出答案以后，可以抛开面试官给的限定谈一下对高并发看法，比如硬件堆砌，集群等等。

负载均衡
读写分离
缓存，分布式缓存

才三台服务器，还谈什么并发，单台机器的并发是有瓶颈的，社区型平台并发瓶颈不应该是写入，而是读取，可以用一台物理服务器做为缓存服务器，还需要在高并发时，缓存的网卡会不会被打满，社区型发贴也可以有延时，写入时可以使用消息队列写入，同时处理与队列处理，用户可能是无感知的，消费一个队列的时间很快，在写入数据库中，可以同时刷新缓存，也可以使用nosql数据库来做，就是控制好内存使用，cache与storage合理使用。
如果硬要说构架：
分层，分割，分布式，集群，缓存，异步等，就三台机器，说构架，我也是醉了

其实面试官是个技术垃圾的一逼，他害怕招人比他优秀，然后把它顶掉！你想啊，三台机器，就想着并发无限大，有这想法的人会是啥水平？单机瓶颈在那放着呢，说不定就是三台512的阿里云，哈哈。
或者他根本不是招人，而是让人免费提供解决方案的！然后你说了，他觉得查点资料他自己就能搞了。
再者吧，他可能就是渣，用的还是Windows图形界面的服务器呢，你上来说lnmp环境，他根本不会玩啊，不pass你，pass谁啊！以上是玩笑话！

不过呢，对于面试优化的，你说的什么生成静态啊，cdn啊，这些都是太宽泛，你要具体到事例上。

其实考官只是看你怎么在有限的资源内处理问题的能力。
现在很多程序员根本只知道程序内的事，不考虑资源的合理利用。

并发量大->接近无穷大 的时候,最简单,最有效的解决问题的方法就是: 增加服务器,强哥当年说的都是真理啊

只要不是代码、架构问题（该索引索引，该缓存缓存），3台**普通**服务器的情况下，优先考虑的确是应该是加机器或者提高机器性能：
现在普通web服务器一台3~5万，能支持PHP或Java Web页面并发500~1000（大概经验，不喜勿喷），招技术做高级架构优化就不止这点钱了。

PHP也有高并发框架，楼主可以试试，接触过swoole，一般机器单机能上万。

p.s.单机百万并发听说过，但是并发量接近无穷大这种要求还真没听说过，不知道考官怎么想的，无穷大并发首先考虑带宽的钱给不给的起吧。。。（要是楼主没听清楚问题建议再沟通，要是真要求无穷大并发，这个考官可能不是工程师而是老板）

谈一点简单的想法。高并发引起的性能瓶颈一般出现在3个地方。1.web服务器：访问量过大，引起web服务器处理性能直线下降；2.应用程序：由于高并发下，对程序的调用比率增加，程序是否具有原子性，执行效率高低都可能是应用程序的瓶颈，进而影响整个系统；3数据库：这个不必多说，100万次查询比10次查询给数据库的压力肯定大；

下面说一下方案。其实我也没啥好方案，简单的说说供大家吐槽。
既然只有三台服务，那么一台做数据库，一台做缓存服务器，一台做web服务器。web服务器用nginx。缓存用redis，数据库还是mysql。整个网站页面采用静态化处理。静态资源可以借助cdn加速。用户session保存在redis中。redis可以作为mysq的前置缓存对外提供服务。程序语言选什么，仁者见仁，智者见智吧。

三台服务器，无限并发，你问问他，吃三个馒头，从此不用再吃饭了，行不行？

技术主管装逼的情况的太普遍了，面试时总会刁难你

这种公司还是不用去了~相当于问你一个没有范围的问题，然后要你一个没有范围的答案。这种非确定性结果跟程序员的思维是相悖的

你是面试高级工程师还是架构师？

他招你进去一般不会想你改他的架构的，我觉得问这个问题只是想了解你是否对网站架构有所了解。

如果你没有参与过高并发的项目，只是根据网上的资料，然后回答，我觉得被pass掉很正常。

这样回答可能效果更好点：

我以前在XXX公司做过XXX项目，也遇到了高并发的问题，我们采取的解决方案有....

其实高并发的问题要码农和运维人员一起解决，关键在于实战。。。

这个问题可是很宽泛的,分为好几个方面.

最基本的各种配置文件的优化是有必要的.

程序方面:数据文件缓存,内存缓存,静态缓存,opcode缓存等等

数据库方面:设计合适的表结构,表缓存优化,主从动静分离,集群,冷热数据分离等....

系统架构方面:redis,高可用啦等等.....我就不说了,太多了

在补充个一点，能提到高并发的都是爱装逼，这个问题本身就是世界难题，尤其这个面试官还说是接近无穷大！

这种问题，回答大致的思路就好了。另外，考官的问题描述也不够准确。

只能说你回答的思路 对不上面试官的。

其实你就应该反问他 给他问萌了为止， 机器的配置。 别说什么无限大，每秒峰值多少
然后你就告诉他 保证多少吞吐的情况下 支持并发，要考虑高负载情况下的一些极端情况。 而且你得假设 所谓并发高、但业务支撑少的原则，按此说，3台机子理论上 就是2台web机 1台db，2台机子LVS＋keepalived这种东东根本用不上，就直接在nginx上面写策略。然后你再问他 瓶颈可能还出现在哪里？ 支持高并发的原则就是，哪里有瓶颈就解决哪里，拒绝空谈 大谈 特谈 扯淡 ！

最后 最主要 你要告诉他一个答案，按着你的配置和计算，最大可以支撑多少并发的业务 ，如果清晰完整的说完这些他还不满意，我建议你对他呵呵后再见。 我就有一次面试 跟面试官抬杠，最后大哥跟我聊上硬件了 估计也是急眼了