作为一个看过几千份简历，面试过几百人的面试官，常常会看到简历中有如下文字：
对业务逻辑解耦，高并发等有比较深入的研究和丰富的开发实战经验
对解决高并发问题有深入理解
熟悉大并发技术，如：反向代理、负载均衡、Keepalived
而当我在面试中，问及对方的职业规划的时候，也有一大半人会回答
希望将来可以处理高并发业务
希望学习高并发相关技术
希望开发数千万/数亿级别并发的应用
但是当我问及以下问题的时候，绝大多数人都会麻爪：
负载均衡有几种分配方式？（大概不到1/10的简历提及高并发的人能答出来）
有没有用任何方式（比如虚拟机）模拟过各种集群（API服务器，数据库，CDN等等）？
有没有用任何方式测试过采用了高并发应对策略后对项目的改进和提升？数据有什么变化？
如果业务规模再次扩大，下一阶段应该用什么技术和策略？
问题就在这里了，
为什么我会把简历里提及“高并发”的绝大多数人KO掉，或者在面试中，对职业规划只有“高并发”的人发拒信？
很爱“高并发”的面试者，应当如何在简历中体现自己的能力和期待？
首先，绝大多数人没有考虑过如何把技术应用于高并发场景
以PHP码农圈子而言，绝大多数用PHP的企业都是初创或者早期公司或者技术储备并不丰富的中小企业，这些企业做正常业务的很难有做高并发的使用场景。（例外：涉黄，涉赌，超大企业【腾讯华为之类】外包团队）
因此，大多数的初中级PHP码农是没有机会在生产环境应用高并发相关技术的，自然也就不会有什么积累和心得。
我经常会问沉迷于高并发的面试者：当你有了一个数千万乃至数亿级别的高并发解决方案的时候，你准备用在哪里？让谁买单？
显而易见，买单的是企业，企业为用户服务，但是这样规模的企业本身已经不是很多，而且它们使用的方案或者是已有的成熟方案，或者是企业内部长期迭代得来，不太会有人冒业务中断的风险去应用一套外部的没来头的方案。
另外，解决高并发的方案不是单纯的三五项技术，而是许多套完整的技术栈，把它运行起来需要一个完整的研发、运维团队来进行支持，没有几个单独的个人可以百分百解决，那么这个人的技能短板会立刻导致方案不可靠。
因此，脱离使用场景的技术价值是要大打折扣的。
第二，高并发背后的高成本是大多数人没有考虑过的
硬件成本的问题：一般在企业中做开发，都至少要有开发环境，集成测试环境，生产环境，有的时候还需要有镜像的灾备环境。如果用了服务器集群，那么高并发方案的服务器的数量就要比堆硬件硬抗的方案翻好几倍。而且运维的成本也会增加很多。
人力因素也很重要，人肉运维自然是成本贵，能写程序搞自动运维的工程师显然更贵。
成本需要企业来买单，程序员学了用了新技术开心了，企业成本提高做挂了显然不是企业想看到的。
因此，如何用各种方式降低你的方案的成本【比如在虚拟环境做各种测试】并且说服企业应用，是面试者要思考的问题。
第三，高并发只是业务规模巨大导致的众多严重问题中的一个，还不一定是最重要的那个
高并发只是表象，业务规模用户规模巨大会导致一系列严峻问题，不仅仅是高并发。
举例来说，团购秒杀拍卖之类的场景是常见的高并发应用场景。总而言之都是卖货，但是在卖货的大前提下，商品库存数字的变化（要不要实时，要不要各端同步），订单状态变化对业务流程的影响（下单减库存还是付款减库存还是发货减库存，预售和返现等营销行为导致的钱款卡券变化）都有可能导致整个方案变化。【想想12306，处理商品库存数据的实时性要比处理高并发请求复杂的多】
因此，结合具体业务场景，展示出面试者在整个业务场景中，包含但不限于高并发技术而体现出来的价值，才能为面试加分。
第四，你说你擅长高并发，你得要证明给我看
从面试的角度来说，我除了预设的面试题之外，还会很细致的询问对方的简历细节。
知乎用户：为什么有面试官喜欢让面试者用纸笔写代码？
面试者在简历上写了擅长高并发，那我就要三段论问一下：是什么问题，怎么解决的，效果如何？
即使去掉伪造简历和过度美化简历的人，仍然有大多数人无法回答第三个“效果如何”的问题。
大量的声称研究过负载均衡的面试者都是用两三台电脑搭一个环境测试能够实现平均分配的负载均衡策略，但是如果问“如果我想测试三五台或七八台服务器的场景应该如何实现？”就又答不出来了。
（答案：现在有docker，古时候有各种虚拟机【vmware，virtual box】和云端部署【gae，sae之类】，实在不行还可以用各种云服务器的按量付费按小时启动服务就好）
因此，用丰富的细节和深刻理解的心得体会来证明面试者的技能水平，是面试要解决的一个最核心的问题
总结：
掌握高并发技术不是坏事，技术好不仅仅体现在能处理高并发
有水平需要证明，证明需要实践（企业没有责任挖掘面试者的价值，面试者需要自己证明）
能解决实际业务问题的技能才是企业需要的，企业里没有龙，面试者的屠龙之技就没有卖点
不要过度美化简历（我的建议：至少要能够抗住3-5个刨根究底的问题才能写到简历上）