互联网架构“高并发”到底怎么玩?-技术圈

从公众号的发展到现在，自己基本上在公众号上都没有写过“技术文章”（悄咪咪的说：博客之前写的有“技术文章”），如果经常看和尚交流群或者朋友圈的小伙伴知道上个月，和尚因为赶项目加了一个月的班，目前项目已经上线了，
现在也有时间来写写文章了，最近实践和学习都用到了一些“高并发”的知识，所以今天就准备来写一篇关于《互联网架构“高并发”到底怎么玩》的文章。

首先抛出一个点，我们为什么学高并发设计？

很实在的就是你找工作面试必问点
天天被叫做 CRUD boy，但是我们在高并发的情况下写好 CRUD 并不容易

高并发是什么？

**高并发（**High Concurrency）是互联网分布式系统架构设计中必须考虑的因素之一，它通常是指，通过设计保证系统能够同时并行处理很多请求。

高并发相关常用的一些指标有响应时间（Response Time），吞吐量（Throughput），每秒查询率QPS（Query Per Second），每秒事务处理量TPS(Transaction Per Second)，并发用户数等。

这里不细提这些指标的含义，不了解的可以 Google。

现在问题来了，多少 QPS 才算高并发？

看下面这段话之前，欢迎大家先去 Google 上搜一下这个答案，看看是否有具体的数据？

其实这个问题怎么没有具体的数据来衡量什么才是高并发？

比如：

就一个服务部署在单机上，一次请求就访问一个服务，抗住的 QPS 肯定很高
但是如果是多个分布式服务，一次请求需要访问多个全链路服务，这时候 QPS 又跟业务服务数量等强相关

所以具体多少 QPS 才算高并发其实跟业务是强相关的。

高并发设计真的就只是 synchronized、lock 这些吗？

经常也看见很多内容标题是《高并发 xxx》，然后点进去一看，就是讲 synchronized、volatile 等等，其实个人觉得这些点只能算并发编程设计等，不能算到高并发设计里。

明确几点，高并发系统比较关注的点

可用性，系统在高并发情况下不能被流量打挂，
稳定性，系统肯定不能出现一会好用，一会不好用的情况
高性能，比如

淘宝的双 11 活动，如果你 0.00 下单一直卡在哪里，等了 1 分钟，然后才告诉你要买的东西没货了。
每个月的花呗还款日，还款处理中，等了 1 分钟告诉你还款成功/失败

正题来了，高并发系统的通用设计方法是什么？

其实到了这里，很多人肯定就会说，分布式一致性怎么做、缓存一致性怎么做、Nginx 负载均衡怎么做、熔断限流怎么做，叭叭叭。

但是这里不讲具体高并发系统下的细节，这里只分享通用设计方法，这些设计方法可以让你对于高并发系统的设计有一个大的骨架，就像修房子一样，先有一个大体的房子架构图，再去考虑到房子里怎么装修，这些方法同理如此。

我们可以把高并发设计比喻为：大家去火车站坐火车，火车站进站开多个进站窗口验身份证和票，安检传送带东西太多需要等待，那可以把安检传送带设计宽一点放更多的东西，安检人数过多，让后面的人在卡点等一下，等前面的人安检完毕再慢慢放人。

横向扩展

只要学过算法的我们，肯定知道分而治之这个点，分而治之这个点同理在高并发系统设计里通用，

当大流量打到系统所在机器上的时候，我们可以把机器的配置升高，比如4 核 8g 的电脑带不上吃鸡，那我们就可以升级到 8 核 16g，这里就堆硬件配置来解决问题，但是如果当我们的流量超过了一台机器配置的极限的时候，我们又该怎么做？

我们可以拿多个机器来处理这些流量，我们可以把多个机器组成一个分布式集群来进行处理这些流量，这样的话流量就分摊到每个机器上去了，当然可能很多人就会问：机器挂了怎么办？分布式一致性怎么做？怎么让流量到服务器上？这里不谈这些，因为这些点约谈越深，根本出不来。

这里谈的横向扩展包含了很多点，比如系统主服务扛不住可以加机器，数据库扛不住也可以加机器做分库分表等，接下来要说的缓存如果扛不住也可以机器。

使用缓存来提升性能

其实说到缓存，可能第一印象就是 Redis，但是缓存这个概念在计算机里到处都是，比如我们了解到的CPU 缓存、Web 缓存、磁盘缓存等等，这些地方都用到了缓存。缓存的种类和实践是非常多的，但是我们可以发现这些缓存的点，最终目的就是降低响应时间。再回过来想我们学习 Redis 的第一点就学到，Redis 是基于内存的，它很快。

同步转异步处理

又说到同步、异步这些词，这些词真的是太太太大众化了。

那什么是同步，什么是异步呢？

以调用一个方法举例，

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

做个比喻：以等外卖为例，你在门口一直等到外卖送过来，这个就是同步外卖。你先去干自己的事情，外卖到了给你打电话叫你取餐，你才来取餐，这个就是异步外卖。

比如前面图片我说到的花呗还款，还款一直显示的是还款处理中，其实这个提示就代表着系统在异步处理我们的还款请求了。因为一个还款请求需要涉及到很多内部服务之间的互相调用。

我们做同步转异步的方式就是：采用消息队列，还款处理时我们会把这个请求丢到消息队列中，然后同时快速告诉我们：还款处理中，然后就释放出资源去处理更多的还款请求。当我们的还款请求在消息队列最终被处理完毕之后，再告诉我们还款成功/失败。

当我们采用消息队列同步转异步，比如可以从以前的同步还款 10s 响应时间，提高到 4s 响应时间告诉他处理中。系统的资源占用也少了很多，可以去处理更多的花呗还款请求了，系统承受高并发的能力也就提升了。这里其实也是消息队列的作用之一。