所谓高并发，就是同一时间有很多流量(通常指用户)访问程序的接口、页面及其他资源，解决高并发就是当流量峰值到来时保证程序的稳定性。如何做到高并发优化

我们一般用QPS(每秒查询数，又叫每秒请求数)来衡量程序的综合性能，数值越高越好，一般需要压测(ab工具)得到数据。

假设我们的一个进程(也可以是线程或者协程)处理一次请求花费了50毫秒(业内达标范围一般是20毫秒至60毫秒)，那么1秒钟就可以处理20个请求，一台服务器是可以开很多这样的进程并行去处理请求的，比如开了128个，那么这台机器理论上的QPS=2560。

千万不要小瞧这个数字，当你的QPS真有这么高的时候意味着你的DAU(用户日活)有2560*200=51.2万，业内一般是放大200倍计算，有这样的日活说明做得很不错了。

一台服务器能够达到的最大QPS受很多因素的影响，比如机器参数配置、机房地理位置、CPU性能、内存大小、磁盘性能、带宽大小、程序语言、数据库性能、程序架构等，我们一一细说。

1.机器参数配置

这个很好理解，比如服务器最大可以开启128个进程，你设置了最大只开启100个，这属于服务器调优。

2.机房地理位置

如果你做海外用户，服务器机房应该选择国外的，反之应该选择国内的，因为机房距离用户越近，在传输上的时间损耗就越低。

3.CPU性能

CPU性能越好，处理速度就越快，核心数越多，能够并行开启的进程就越多。

4.内存大小

内存越大，程序就能把更多的数据直接放到内存，从内存读取数据比从磁盘读取数据的速度快很多。

5.磁盘性能

这个不用多说吧，一般固态硬盘的性能比机械硬盘的性能好很多，性能越好读写数据的速度就越快。

6.带宽大小

服务器的带宽一般指流出带宽，单位为Mb/S，比如带宽为8Mb/S即1MB/S，如果提供文件下载服务，可能一个用户的下载行为就把服务器带宽用完了。

一般把图片、视频、css文件、JavaScript脚本等资源放到第三方的CDN去，按流量计费，这样就不占用服务器带宽了。

如果用户规模小，基本上一台服务器就好了，这个时候一般会选按固定带宽大小计费。

如果用户规模很大了，基本上会用到负载均衡器来分流，即把流量按照一定的规则分配到不同的服务器上，负载均衡器一般会按流量来计费。

如果平均一次请求返回的数据大小为50KB，为了达到1000QPS这个指标，需要的带宽峰值=1000*50*8/1024=390.625Mb/S。

我们在设计接口的时候应该尽量减少返回的数据大小，比如user_id就可以简化为uid，像图片、视频、css等文件压缩的目的就是减少数据的大小。

7.程序语言

编译型语言的性能一般好于解释型语言的性能，比如go语言性能就好于php语言性能，当语言短期不会替换时，可以通过堆机器解决高并发问题。

8.数据库性能

一台服务器上部署的数据库总是有一个瓶颈的，比如每秒查询数、每秒写入数。

我们可以通过增加很多从库解决查询(select语句)的瓶颈，称之为多从库模型，需要注意的是主从同步数据可能有延迟，当修改数据后马上需要查询时需要设置强制从主库读取。

我们可以将业务拆分，让某些表存储在一个数据库实例上，另一些表存储在其他数据库实例上，虽然一个数据库实例有自己的瓶颈，但是很多的数据库实例堆积起来性能就会大大改善，多个数据库实例的方案称之为多主库模型，主要是为了解决写入瓶颈(insert语句、update语句、delete语句)。

如果你有多个主库又有多个从库，你就实现了多主多从模型。

如果一个表存储的数据量很大，这个时候就要考虑分表了(一般用中间件实现)，比如按时间分表或者按用户分表，当把一个表的所有分表都放在一个数据库实例上都满足不了要求的时候，你应该把某些分表存储在新的数据库实例上，这个时候一个表的数据分布到了不同的数据库实例上，这就是所谓的分布式数据库方案了，你需要处理的事情就很复杂了，比如处理分布式事务。

数据库的并发连接数也是有限制的，我们可以用连接池技术来应对，就是保持一定数量的和数据库的连接不断开的长连接，需要连接数据库的时候就从池子里选择一个连接，用完放回去就好了，这个一般也是用中间件来实现。

好的索引也能提高数据库的性能，有时候比堆多个从库的方案还要好。

如果能够减少数据库的读写，也算间接提高了数据库的性能，比如我们用redis来做缓存，用消息队列异步落库等。

有时候某些数据用数据库来计算需要很长时间，可以取到元数据(最小粒度的数据)用程序来计算，这称之为用内存换时间。

9.程序架构

比如实现同样的功能，初级程序员写的程序需要循环100次，而高级程序员写的程序只需要循环10次，效果肯定不一样。

总结

一般大型项目基本是前后端分离的，从性能方面说就是为了将页面渲染的处理在客户端运行，降低服务器的压力。

从带宽层面考虑，css、图片、视频、JavaScript等文件资源能用CDN的就用CDN，能压缩的就尽量压缩，接口能减小返回数据的大小就尽量减小。

为了解决编程语言的不足或者单台服务器的瓶颈，可以先堆机器应对。

索引、多主多从、分布式数据库、缓存、连接池、消息队列等是从数据库方便考虑如何优化性能。

有时候程序的低耦合性比程序的高性能更重要，不要一味地追求高性能。

TODO

持续更新

原文地址：https://segmentfault.com/a/1190000016902003