呦西，YY妹子，最近天这么热了，你怎么还穿这么多？
这是你技术提高的大好机会呀
来，凑近一点，哥给你解释一番
我们以高速收费站为例子也许更直观一些，吞吐量就是一天之内通过的车辆数，响应时间就是车速，并发数就是高速上同时奔跑的汽车数。由此可见其实以上几个指标是有内在联系的。比如：响应时间缩短，在一定程度上可以提高吞吐量。
其实以上几个指标主要反映了两个概念：
1. 系统在单位时间之内能做多少事情
2. 系统做一件事情需要的时间
通过增加服务器来解决你的网站瓶颈，意味着你的网站需要做负载均衡，如果没有运维相关人员，你可能还得需要研究负载均衡的方案，比如LVS，Nginx，F5等。我曾经面试过很多入道不久的同学，就提高吞吐量问题，如果没有回答上用负载均衡方案的基本都pass了，不要说别的，这个方案就是一个基础，就好比学习一个语言，你连最基本的语法都不会，我凭什么让你通过。有喷的同学可以留言哦
当一个请求到达服务器并且正确的被服务器接收之后，最终执行这个请求的载体是一个线程。当一个线程被cpu载入执行其指令的时候，在同步的状态下，当前线程会阻塞在那里等待cpu结果，如果cpu执行的是比较慢的IO操作，线程会一直被阻塞闲置很长时间，这里的很长是对比cpu的速度而言，如果你想有一个直观的速度对比，可以去查看菜菜以前的文章：
当一个新的请求到来的时候，如果没有新的线程去领取这个任务并执行，要么会发生异常，要么创建新的线程。线程是一种很稀缺的资源，不可能无限制的创建。这种情况下我们就要把线程这种资源充分利用起来，不要让线程停下来。这也是程序推荐采用异步的原因，试想，一个线程不停的在工作，遇到比较慢的IO不会去等待结果，而是接着处理下一个请求，当IO的结果返回来得到通知的时候，线程再去取IO结果，岂不是能在相同时间内处理更多的请求。
还有一点，尽量减少线程上下文在cpu的切换，因为线程上线文切换的成本也是比较大的，在线程切换的时候，cpu需要把当前线程的上下文信息记录下来用以下次调用的时候使用，然后把新线程的上下文信息载入然后执行。这个过程相对于cpu的执行速度而言，要慢很多。
不要拿Golang反驳以上观点，golang的协程虽然是用户级别比线程更小的载体，但是最终和Cpu进行交互的还是线程。
通过上图大体可以看出，内核会为每个I/O设备维护一个buffer（同一个文件描述符读和写的buffer不同），应用程序发出一个IO操作的指令其实通过了内核空间和用户空间两个部分，并且发生了数据的复制操作。这个过程其实主要包含两个步骤：
1. 用户进程发出操作指令并等待数据
2. 内核把数据返回给用户进程（buffer的复制操作）
根据这两个操作的不同表现，所以IO模型有了同步阻塞，同步非阻塞，异步阻塞，异步非阻塞的概念，但是这里并非此文的重点，所以不在展开详细介绍。
利用cpu提高系统吞吐量主要目标是提高单位时间内cpu运行的指令数，避免cpu做一些无用功：
恭喜 安浅 QI 两位喜提上周抽奖Golang书籍。