在即时通讯网社区里，多是做IM、消息推送、客服系统、音视频聊天这类实时通信方面的开发者，在涉及到即时通讯技术时聊的最多的话题就是高并发、高吞吐、海量用户。
代码还没开始写，就考虑万一哪天这IM用户量破百万、千万该怎么办的问题，是多数程序员的基本修养。
在面视即时通讯相关工作的时候，高并发也是必谈问题，那到底什么是高并发？嗯，真要说出个所以然来，还真有点懵。
什么是高并发?
高并发是互联网系统架构的性能指标之一，它通常是指单位时间内系统能够同时处理的请求数。
简单点说，就是QPS（Queries per second）。
那么我们在谈论高并发的时候，究竟在谈什么东西呢？归根结底，到底什么是高并发？
高并发究竟是什么?
这里先给出结论:
1）高并发的基本表现为单位时间内系统能够同时处理的请求数；
2）高并发的核心是对CPU资源的有效压榨。
举个例子：如果我们开发了一个叫做MD5穷举的应用，每个请求都会携带一个md5加密字符串，最终系统穷举出所有的结果，并返回原始字符串。这个时候我们的应用场景或者说应用业务是属于CPU密集型而不是IO密集型。
这个时候CPU一直在做有效计算，甚至可以把CPU利用率跑满，这时我们谈论高并发并没有任何意义。(当然，我们可以通过加机器也就是加CPU来提高并发能力,这个是一个正常猿都知道废话方案，谈论加机器没有什么意义，没有任何高并发是加机器解决不了，如果有,那说明你加的机器还不够多！)
对于大多数互联网应用来说，CPU不是也不应该是系统的瓶颈，系统的大部分时间的状况都是CPU在等I/O(硬盘/内存/网络) 的读/写操作完成。
这个时候就可能有人会说，我看系统监控的时候，内存和网络都很正常，但是CPU利用率却跑满了这是为什么？
这是一个好问题，后文我会给出实际的例子，再次强调上文说的“有效压榨”这4个字，这4个字会围绕本文的全部内容！
控制变量法
万事万物都是互相联系的，当我们在谈论高并发的时候，系统的每个环节应该都是需要与之相匹配的。
1）我们会经过DNS服务器的解析，请求到达负载均衡集群；
2）负载均衡服务器会根据配置的规则，想请求分摊到服务层。服务层也是我们的业务核心层，这里可能也会有一些RPC、MQ的一些调用等等；
3）再经过缓存层；
4）最后持久化数据；
5）返回数据给客户端。
要达到高并发，我们需要负载均衡、服务层、缓存层、持久层都是高可用、高性能的。
甚至在第5步，我们也可以通过压缩静态文件、HTTP2推送静态文件、CDN来做优化，这里的每一层我们都可以写几本书来谈优化。
本文主要讨论服务层这一块，即图红线圈出来的那部分。不再考虑讲述数据库、缓存相关的影响。
高中的知识告诉我们，这个叫控制变量法。
那我们再谈谈上下文切换：
在谈论上下文切换之前，我们再明确两个名词的概念：
1）并行：两个事件同一时刻完成；
2）并发：两个事件在同一时间段内交替发生，从宏观上看，两个事件都发生了。
线程是操作系统调度的最小单位，进程是资源分配的最小单位。由于CPU是串行的，因此对于单核CPU来说，同一时刻一定是只有一个线程在占用CPU资源的。因此，Linux作为一个多任务(进程)系统，会频繁的发生进程/线程切换。
在每个任务运行前，CPU都需要知道从哪里加载，从哪里运行，这些信息保存在CPU寄存器和操作系统的程序计数器里面，这两样东西就叫做CPU上下文。
进程是由内核来管理和调度的，进程的切换只能发生在内核态，因此虚拟内存、栈、全局变量等用户空间的资源，以及内核堆栈、寄存器等内核空间的状态，就叫做进程上下文。
前面说过，线程是操作系统调度的最小单位。同时线程会共享父进程的虚拟内存和全局变量等资源，因此父进程的资源加上线上自己的私有数据就叫做线程的上下文。
对于线程的上下文切换来说，如果是同一进程的线程，因为有资源共享，所以会比多进程间的切换消耗更少的资源。
现在就更容易解释了，进程和线程的切换，会产生CPU上下文切换和进程/线程上下文的切换。而这些上下文切换，都是会消耗额外的CPU的资源的。
进一步谈谈协程的上下文切换：
那么协程就不需要上下文切换了吗？需要，但是不会产生 CPU上下文切换和进程/线程上下文的切换，因为这些切换都是在同一个线程中，即用户态中的切换，你甚至可以简单的理解为，协程上下文之间的切换，就是移动了一下你程序里面的指针，CPU资源依旧属于当前线程。
需要深刻理解的，可以再深入看看Go的GMP模型。
最终的效果就是协程进一步压榨了CPU的有效利用率。
回到开始的那个问题
这个时候就可能有人会说，我看系统监控的时候，内存和网络都很正常，但是CPU利用率却跑满了这是为什么？即时通讯软件开发咨询蔚可云开发。
注意本篇文章在谈到CPU利用率的时候，一定会加上有效两字作为定语，CPU利用率跑满，很多时候其实是做了很多低效的计算。
以"世界上最好的语言"为例。
典型PHP-FPM的CGI模式，每一个HTTP请求:
1）都会读取框架的数百个php文件；
2）都会重新建立/释放一遍MYSQL/REIDS/MQ连接；
3）都会重新动态解释编译执行PHP文件；
4）都会在不同的php-fpm进程直接不停的切换切换再切换。
php的这种CGI运行模式，根本上就决定了它在高并发上的灾难性表现。
找到问题，往往比解决问题更难。当我们理解了高并发之后，我们会发现高并发和高性能并不是编程语言限制了你，限制你的只是你的思想。
找到问题，解决问题！当我们能有效压榨CPU性能之后，能达到什么样的效果?
下面我们看看 php+Swoole的HTTP服务与Java高性能的异步框架Netty的HTTP服务之间的性能差异对比。