程序员修神之路--高并发下如何缩短响应时间

网站响应时间是指系统对请求作出响应的时间。通俗来讲就是我们把网址输入进浏览器然后敲回车键开始一直到浏览器把网站的内容呈现给用户的这段时间。网站响应时间是越短越好，因为网站页面打开速度越快，就意味着我们的用户可以更快的访问站点或者我们的服务器。一般我们网站的响应时间保持在100~1000ms即可。1m=1000ms，打开速度越快对用户体验度越好。据说响应时间还会影响到网站SEO效果（请行业专家留言告诉我）。

响应时间并不能直接反映网站性能的高低，但是在一定程度上反应了网站系统的处理能力，也是给用户最直观上的感受。如果网站的响应时间过长，比如10秒以上，用户的流失率会大大增加，所以把响应时间控制在一定范围内是提高用户体验度的第一要素。

当用户请求一个网站数据的时候，实际上是发送了一个http请求，在宏观上可以分为两个部分：

1. http请求到达目标网站服务器之前

2. http请求到达目标网站服务器之后

如果忽略其中硬件部分和部分细节，请求一个网站数据的大体过程如下图所示（其中CDN和缓存部分可以省略）：

一般网站的访问方式都采用域名的方式（很少见IP方式），既然是域名就涉及到DNS解析速度的问题，如果DNS服务解析的速度比较慢，整体过程的响应时间也会加长，不过这个过程其实很少出现慢的问题（不是说没有）。

当一个请求到达网站服务器，服务器便开始处理请求，一般会有专门处理业务请求的一个业务层，有的体现为rpc协议的微服务，有的体现为简单的一个代码分层。最终请求的数据会通过查询数据库来返回。其实这个过程和车站购票流程一样，每个窗口的处理能力是有限的，对应到服务器处理能力。由于这个原因，所以诞生了负载均衡的策略，核心思想就是：分。一台服务器不够，那就两台，三台，四台..... 直到并发的所有请求的响应时间都在可控范围之内。

数据库的情况类似，一个数据库扛不住压力，就加到N个数据库分散压力。一个表扛不住压力，就把这个表拆分开，拆分成多个表，甚至拆分到多个不同服务器数据库，这就是我们常用的拆表策略。有的时候在同一个数据库中进行表拆分，性能的提升并非最大化，因为一台服务器的磁盘IO是有上限的，就算拆成100个表，还是在同一个物理磁盘上，当然这样可缓解锁单表的情况。

现在有很多的场景采用NOsql代替关系型数据库来缩短响应时间，在正常情况下，由于关系型数据库的本身因素在特定场景下的读写速度比Nosql要慢很多，所以系统设计初期，可以考虑采用关系型数据库和Nosql混用的方案。

一些小厂可能用不到cdn，但是cdn带来的加速还是很客观的。cdn依靠部署在各地的边缘服务器，通过中心平台的负载均衡、内容分发、调度等功能模块，使用户就近获取所需内容，降低网络拥塞，提高用户访问响应速度和命中率。CDN就是把离用户最近的数据返回给用户。