算了，35岁程序员也要懂高并发

互联网发展到今天，已经造就了多少科技巨头，比如某广，哈哈还有某厂。咱们是不是有这样的感觉，如果公司有人离职了，那个人的技术非常厉害，咱们是不是都会那样想，他是不是大概率要去某厂了，也就是说现在跳个槽，都要卷到和某厂关联，好像你不是去某厂了，你都不好意思发个朋友圈的工作动态。这些咱们都不聊了，咱们聊聊35岁程序员那些事，程序员也是很娱乐的哇。

本系列将会带着大家一起聊聊“35岁程序员”要懂的高并发。

咱们是35岁程序员

哇，程序员都35岁了，这么大的年纪了，还在和年轻人抢写代码的活，好low啊，是的笔者也觉得很low，好像到了年纪了，如果你还是一个工程师，你自己都觉得你太low了。

但是事实真的是这样子的吗？笔者碰到过很多大咖，人家对外的名片总是灌输自己是一名普通的工程师，尤其国外的程序员，都可以干工程师干一辈子，为什么咱们国内就不行了。

很多人都在说，中国互联网几十年的发展史是从抄袭国外而发展起来的，所以只有在国外才会出现真正的科技型公司上市，而中国不行。中国的公司只会重视业务和应用，因为它们赚钱快啊，技术这个东西没啥鸟用，不就是一堆写代码的人么？

所以在公司就会存在很多这样的场景：一个很牛的人到一个新公司，因为不熟悉业务，被莫名其妙的潜规则，但是呢，那些能力一般的人，却能够牢牢的抓住自己手头上的业务项目，不肯分一点给新人。我想上述现象是我们在职场中工作的一个常态，可是就是因为这些常态滋生了“35岁程序员”这个敏感的话题。

好吧，既然技术在大部分公司都不是那么的香，老板总是说我们是一个业务型的公司，那为什么在招聘那些大牛的时候，有拼命的问高并发、高可用、高性能的硬核知识呢，有为什么要是从某某大厂出来的呢？其实这个真是一个矛盾体，导致了大部分程序员的焦虑。

做一个凡人，好好认识高并发吧

好吧，咱们是一个凡人，还是好好认识和理解高并发吧，毕竟这个是进大厂的标配，也是入卷坑的门票。

为什么要认识和理解高并发呢，其实当我看到头条新闻，我都会思考这样问题，又有多少程序员在默默的加班啊。比如，在微博中，明星动辄拥有几千万甚至上亿的粉丝，你要怎么保证明星发布的内容让粉丝实时地看到呢？淘宝双十一，当你和上万人一起抢购一件性价比超高的衣服时，怎么保证衣服不会超卖？春运时我们都会去 12306 订购火车票，以前在抢票时经常遇到页面打不开的情况，那么如果你来设计 12306 系统，要如何保证在千万人访问的同时也能支持正常抢票呢？天猫双十一，你又要怎么确保自己的系统不挂，但是又能抗住几十倍流量剧增的技术挑战呢？

其实呢，这些问题是我们在设计和实现高并发系统时经常会遇到的痛点问题，都需要涉及如何在高并发场景下做到高性能和高可用的架构设计以及代码落地。

不可否认的是，目前的经济形势不好，某厂和某厂一方面在减少招聘的人员数量（现在都在裁员了），另一方面也期望花费了人力成本之后可以给公司带来更大的价值。

那么对于某厂来说，仅仅懂得 CRUD 的程序员就不如有高并发系统设计经验的程序员有吸引力了。所以当咱们去面试时，面试官会要求你有高并发设计经验，有的面试官会询问你的系统在遭遇百万并发时可能有哪些瓶颈点，以及有什么优化思路等问题，为的就是检验你是否真的了解这方面的内容。那么进不了某厂，没有高并发的场景，这些设计的经验又要从何处来呢？这就是鸡生蛋蛋生鸡的问题了。

很多程序员可能会说：“我在小公司工作，小公司的系统并发不高，流量也不大，学习高并发系统设计似乎有些多此一举。”但我想说的是，公司业务流量平稳，并不表示不会遇到一些高并发的需求场景，就算没有咱们程序员也要自己创造场景，去替你老板思考这些问题，这样才能保证自己技能远高于你自己级别的技能，哈哈，你才能跳槽啊，去某厂和某厂。

聚焦套路，毕竟咱们是35岁程序员了

咱们是35岁程序员了，时间和精力远不如年轻的小伙子了，当然这个是那些某厂的招聘人员定的，咱们才不信了。

高并发代表着大流量，高并发系统设计的魅力就在于我们能够凭借自己的聪明才智设计巧妙的方案，从而抵抗巨大流量的冲击，带给用户更好的使用体验。这些方案好似能操纵流量，让流量更加平稳地被系统中的服务和组件处理。

从古至今，长江和黄河流域水患不断，远古时期大禹曾拓宽河道，清除淤沙让流水更加顺畅；都江堰作为史上最成功的治水案例之一，用引流将岷江之水分流到多个支流中，以分担水流压力；三门峡和葛洲坝通过建造水库将水引入水库先存储起来，然后再想办法把水库中的水缓缓地排出去，以此提高下游的抗洪能力。

通常我们面对高并发的流量，必须要有自己的几板斧，不然咱们真的是“35岁册程序员”了。

Scale-out（横向扩展）：分而治之是一种常见的高并发系统设计方法，采用分布式部署的方式把流量分流开，让每个服务器都承担一部分并发和流量。

缓存：使用缓存来提高系统的性能，就好比用“拓宽河道”的方式抵抗高并发大流量的冲击。

异步：在某些场景下，未处理完成之前我们可以让请求先返回，在数据准备好之后再通知请求方，这样可以在单位时间内处理更多的请求。

以上估计是咱们在大部分技术分享和大咖演讲时，听到的应对高并发流量的三板斧了，哈哈，是不是感觉很简单，把这些思想落地不就好了。

在处理高并流量时，通常将类似追逐摩尔定律不断提升 CPU 性能的方案叫做 Scale-up（纵向扩展），把类似 CPU 多核心的方案叫做 Scale-out，这两种思路在实现方式上是完全不同的。

聊聊Scale-out（横向扩展）

Scale-up 通过购买性能更好的硬件来提升系统的并发处理能力，比方说目前系统 4 核 4G 每秒可以处理 200 次请求，那么如果要处理 400 次请求呢？很简单，我们把机器的硬件提升到 8 核 8G（硬件资源的提升可能不是线性的，这里仅为参考）。

Scale-out 则是另外一个思路，它通过将多个低性能的机器组成一个分布式集群来共同抵御高并发流量的冲击。沿用刚才的例子，我们可以使用两台 4 核 4G 的机器来处理那 400 次请求。

一般来讲，在系统设计初期会考虑使用 Scale-up 的方式，因为这种方案足够简单，所谓能用堆砌硬件解决的问题就用硬件来解决，但是当系统并发超过了单机的极限时，咱们程序员就要使用 Scale-out 的方式。

Scale-out 虽然能够突破单机的限制，但也会引入一些复杂问题。比如，如果某个节点出现故障如何保证整体可用性？当多个节点有状态需要同步时如何保证状态信息在不同节点的一致性？如何做到使用方无感知的增加和删除节点？哈哈，全是问题，这些都是需要解决的啊，不然怎么落地呢？

聊聊缓存

缓存能够提升系统的性能，这一点毋庸置疑。提到缓存，问题就更多了，我们是使用本地缓存，还是使用分布式缓存呢，操作系统需不需要缓存、Web服务器需不需要缓存，中间件需不需要缓存、数据库需不需要缓存等等。另外加了缓存之后，我们怎么解决数据一致性和性能之间的关系，缓存挂了之后怎么办？数据丢了之后，还能恢复吗？等等，头都疼了，我想这些都是人家面试官，面试的时候经常会问的话题。

聊聊异步

异步也是一种常见的高并发设计方法，与之共同出现的还有它的反义词：同步。比如分布式服务框架 Dubbo 中有同步方法调用和异步方法调用，IO 模型中有同步 IO 和异步 IO。

那么什么是同步，什么是异步呢？以方法调用为例，同步调用代表调用方要阻塞等待被调用方法中的逻辑执行完成。这种方式下，当被调用方法响应时间较长时，会造成调用方长久的阻塞，在高并发下会造成整体系统性能下降甚至发生雪崩。异步调用恰恰相反，调用方不需要等待方法逻辑执行完成就可以返回执行其他的逻辑，在被调用方法执行完毕后再通过回调、事件通知等方式将结果反馈给调用方。

好吧我们都知道消息中间件是解决异步调用问题的，它是来给系统解耦的，那为什么大部分的消息中间件都说自己，是支持海量消息处理能力，支持高吞吐量，有能保证高性能的呢，其实人家底层也是应用很很多经典的高并发设计的方法论。

总结

人生海海是笔者最喜欢的一本书，35岁的程序员也要懂高并发的。

下一期：开启35岁程序员高并发认知系列