为什么国内的程序员都痴迷 “海量高并发”？

题图： from Zoommy

身体恢复后的第一个工作周，所有的时间几乎被面试所占满。

一般每年的春节过后的三月与四月都是招聘旺季，那些对当下存在不满的，或者想得到更好发展的小伙伴都开始蠢蠢欲动。

对面试官来说，这绝对不是一个快乐的季节，每当回忆起面试过程中的种种细节，我的内心总会掀起一阵阵的疲惫感。

面对堆得像小山一样的简历，你必须用最短的时间，在其中找到有用的信息，并决定是否要邀约求职者进行进一步面谈……这个流程，相信每位面试官都不陌生。而对求职者来说，要想给面试官留下深刻印象，并赢得面试机会，也必须学会在简历中的巧用一些关键词汇。

在近二十年的职业生涯里，我看过不下上千份的简历。在形形色色的关键词中，打着 “有海量高并发经验” 与 “精通技术原理” 这两杆大旗的不在少数。

先说有经验的，不是说自己对某某开源软件的原理非常精通，或者对某项通讯协议有独到的见解，就是说自己对高并发有比较深入的研究和丰富的开发实战经验，或者熟悉大并发技术。

再说没经验的，干脆用恳求的口吻写明，希望将来可以处理高并发业务与技术，开发数千万/数亿级别并发的应用。

看这架势，似乎在绝大多数的程序员心中，只要拥有这两项技能，职业生涯就能完美收官，从此走上人生巅峰。

但在这股痴迷之风的背后，当国内的许多程序员面向海量高并发场景时，是否真的有进行充分的思考？

思考1：高并发场景背后的高成本

去年在某微信群中，和一些朋友争论 “技术基础化服务到底是选择商业采购，还是开源自研？” 的话题。

有的人说，商业采购不仅贵，自主性差，而且体现不了技术价值。

有人则说，开源自研不仅投入成本高，技术风险大，而且费力不讨好。

这种话题本来就是爹说爹有理，娘说娘有理的事，不同的企业或行业，不同的技术负责人都会得出不同的结论。

不过，有一个观点大家都比较赞同，所谓技术方案，无论选择哪一边，都是基于最优成本的落地实践。

这句话怎么理解呢？

比如，一般在企业中做开发，都至少要有开发、集成测试、生产等多套环境，外加一些灾备环境。如果用了服务器集群，那么高并发方案的服务器的数量就要比堆硬件硬抗的方案翻好几倍，而且运维的成本也会增加很多。

另外，为了能够支撑这么多的环境，同时降低众多人肉运维的成本，自然需要招聘价格更昂贵的自动化运维工程师。

这一来一去，不管你的方案有多牛逼，在老板眼里似乎只看到了快速飙升的技术成本。而在许多程序员眼中，始终觉得只要方案好，成本不是问题，如果企业不愿意承担成本，那就是老板抠门。

这些年里，无论是我自己，还是身边朋友，因为成本过高而夭折的项目不在少数，很多矛盾都由此而形成。

在我看来，如何用各种方式降低你方案的成本，并且说服企业应用，才是在实现高并发场景之前迫切需要思考的问题。

思考2：你擅长高并发？证明给我看

在部分高端技术岗位的面试中，我喜欢让求职者在黑板上写或画出一些核心内容的实现过程。

原因很简单，为了考察其简历中部分内容的真实性。

比如，简历上写了 “有关高并发“ 的相关内容，我就一定会问上一句：最终解决的效果怎么样？

可惜的是，我感觉大多数的人都回答的不太理想。

有人说，你这是故意找茬吧。是吗？那我来举几个例子看下。

比如，我会问在高并发场景中，你通常会用到负载均衡中的哪几种分配方式？

或者问，当你采用了高并发策略后，与之前相比，对项目的改进和提升能达到多少？请用数据化的结果说明一下。

还会问，假设现有规模再扩大一倍，在现有的高并发策略上，你还会做出哪些调整？

在我的经历中，绝大多数的人都会把Docker与虚拟化的理论跟我背诵一通，或者干脆画一张用2-3台电脑实现的平均分配的负载均衡策略示意图，只有少数几位，能够有条理的写出负载均衡的原理与在各业务场景的落地实践过程。

如果光看简历，可能你会觉得这些人都差不太多。

因此，在我看来，用原理和经验深度的验证方式，是发现是否擅长高并发场景的最佳套路。

什么？你问那少数几位最后都成功入职了吗？很遗憾，大部分都因薪酬谈不拢而告吹。

不知道从什么时候开始，但凡每次在面试中谈到海量高并发的话题，我总会苦口婆心的唠叨几句。

比如说，痴迷高并发技术不是坏事，但良好的技术功底不仅仅体现在能处理高并发。

比如说，能解决实际业务问题的技能才是企业需要的，为要为了技术而技术。

比如说……

可能我真的年纪大了，感觉自己越来越唠叨，看不惯的事务越来越多，啥事都要叨几句。

这番话在对方听来，也无非保持一个尴尬而不失礼貌的微笑，内心千万只草泥马奔腾而过，很想说干你屁事。

但我始终觉得，作为国内的程序员，与其痴迷某些技术的尖端，不如解决某些行业的业务落地。

也许只有这样，才能获得更好的职业发展。