高性能Web后端(转)

真正有资格谈Web高性能的，一定是具有丰富实战经验、经过很多次高并发压力考验的架构师。到目前为止我没有这种经验，个人作品访问量几近于零，接外包做的网站访问压力也不大。虽然没有机会披甲上阵，但纸上谈兵总是可以的吧！国内有2本非常不错的Web架构技术书籍，一本是来自阿里巴巴技术专家李智慧的《 大型网站技术架构 》，另一本则是监控宝CTO郭欣写的《 构建高性能Web站点 》。

《大型网站技术架构》所涉及的范围非常广，从5个方面（高性能、高可用、伸缩性、可扩展、安全）谈到了大型网站的架构。高屋建瓴，一目了然，唯一的缺点就是细节不够。而《构建高性能Web站点》则集中精力谈高性能，给出了很多实战操作示例。总的来说，这2本书非常适合搭配着看。

高性能可以分别对Web前端和Web后端来谈，本文是在我草草翻了翻这2本书后，针对如何提高Web后端性能做的一点读书笔记。

性能评价

要知道Web系统的性能怎么样，首先必须要有评价指标和测试方法。

（1）评价指标

一般有下面几个：

• 吞吐率：单位时间内服务器处理的请求次数（requests per second）
• 用户平均请求等待时间：每个用户发起一次请求->得到回应的耗时
• 服务器平均请求处理时间：服务器处理一条请求的耗时
• 系统负载：一般包括CPU使用率、CPU Load、内存使用情况、磁盘I/O、网络I/O等

这里稍微提一下CPU Load，它是指一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息。如果服务器是8核，若Load=1，表示只有1个任务正在被处理，此时负载很小；Load=8，表示每个核都在处理一个任务，满负载；Load>8，表示需要处理的任务太多，CPU已经超负荷工作啦！可以用top命令查看CPU Load。

（2）测试方法

如何得到上面的指标呢？可以用Apache2附带的工具ab发起测试请求，用法很简单：

ab -n10000 -c10 http://localhost:5000

-n10000 表示总共发起10000次请求， -c10 表示并发用户数为10，也就是说同一时刻有10个用户访问了网站 http://localhost:5000 ，一共访问了10000次（假设每个用户访问网站时仅发起1次请求）。执行完毕后就有blabla一大堆数据出来。

引起评价指标波动的关键因素在于 并发数 ，所以一般会在不同并发数下发起测试，得到指标数据。然后以每个评价指标作为y轴，并发数作为x轴进行描点绘图。一般y=f(x)有一个最大值，这个最大值就是系统能够承受的最大并发数了，高于此并发，系统性能会急剧下降，直至崩溃。下面是吞吐量随并发数的变化曲线示例：

Web系统模型

Web系统一般是由不同组件构成的，必须着眼不同的组件来考虑性能优化。以最简单的Web架构来说吧，如图：

从左往右看：用户发出request，服务器收到后派发给App（就是指网站程序，一般基于某Web开发框架），App解析request，然后根据业务逻辑可能会访问数据库、读写文件等等，把信息整合为response交给Server，Server再传回用户。

用一个隐喻说明上面的关系：Server就像Boss，负责接活/将产品交付用户；App是干活的码农，但他在干活中可能还需要测试部门、安全部门等的支持。很简单吧！下面针对不同组件来分析性能优化方法。

Server性能优化

关键：如何提升网络I/O吞吐率。

（1）并发策略

要想同一时间处理更多请求，自然要考虑并发了。就我的理解来看，并发策略中主要有2个自由度：I/O模型、执行模型。

在这里，I/O模型主要指服务器如何处理网络I/O。《UNIX网络编程》6.2节对此有非常精彩的描述，一般有5种：阻塞、非阻塞、I/O多路复用、信号驱动、异步。前四种都属于同步I/O，就是说用户进程在I/O处理中存在阻塞，而异步I/O则是在底层完成I/O处理后再通过信号机制通知用户进程。

执行模型的话，一般有这些：单进程/线程、多进程/线程（不考虑协程的话）。多进程/线程一般比单进程/线程性能要好，这样可以充分利用多核的优势。

与I/O模型组合起来说就是：到底是用哪一种执行模型，来运行哪一种I/O模型。举一些例子：NodeJS是单线程+异步I/O、Gunicorn是多进程+同步I/O等等。

完全追求I/O性能的话，多线程/进程+异步I/O应该是最牛的吧，比如用 pm2 开启cluster 模式，使用多进程在多核机器上跑NodeJS，性能有多强悍，还没有做过测试...

（2）集群与负载均衡

一个扛不住？那就加更多的服务器一起上吧！还需要使用某种负载均衡技术将网络请求均衡地分配到各个机器上，一般有：HTTP重定向、DNS轮询、反向代理、IP负载均衡、数据链路层负载均衡。均衡算法一般有：轮询、加权轮询、随机、最少连接、源地址散列等。以上这些在《大型网站技术架构》中都有精彩的阐述，就不展开说明了。

值得一提的是，集群和负载均衡是一种非常通用的技术，可以用于很多Web组件中。

（3）持久链接

HTTP是建立在TCP基础之上的，浏览器是一种HTTP软件，它在与服务器通信时首先需要建立TCP连接，这个过程有一定的开销。如果每次请求后都断掉的话，那是不是太浪费资源了？好在现代浏览器和服务器一般都支持长连接（Keep-Alive）技术。服务器在开启Keep-Alive后，会在HTTP应答中加上Connection: Keep-Alive 这个header，然后浏览器就知道需要长时间保持连接不关掉啦！

App性能优化

关键：在接收到request后，如何更快地做出response。

（1）执行速度

不同语言的运行速度会相当不一样，但是运行速度和开发效率是需要相互权衡的。让我用汇编去写Web，打死都不愿意！一般根据业务需求、团队喜好来选择，Java/Python/NodeJS/Go/PHP/Ruby都不错。选定后，可以采用某些措施加速代码的运行，比如使用更好的编译器/解释器、使用C/C++编译的第三方库等等。

（2）算法与数据结构

如果业务逻辑中涉及到一定复杂度的运算，那就可以考虑从算法和数据结构层面进行优化。这个可能对单次request效果不明显，但如果访问量特别大的话，微小的性能提升也会被放大很多倍哦！

（3）I/O模型

你可能比较好奇，不是在Server中已经提了I/O模型了嘛，怎么这里又来一个？请注意，Server中的I/O一般指网络I/O，具体来说是对TCP Socket的读写。而在App代码中也会和各种I/O设备打交道，举例：

• 磁盘I/O：读写文件
• 网络I/O：发起OAuth请求
• 数据库I/O：读写MySQL
• 内存I/O：读写Redis

内存I/O等待一般是可以忽略的（除非是分布式缓存，或者某块内存忽然坏掉-_-），其他I/O则不容忽视。那么从I/O请求到读写完毕之间，到底该怎么处理？一般的Web开发框架都是同步I/O模型，但是也有采用异步模型的，比如NodeJS、Tornado。在App中采用异步模型，必须采用支持异步调用的库。NodeJS中的File、HTTP、Net、Stream等module都是为Node量身打造的，完全异步。Tornado也可以使用到很多第三方库的 异步版 。值得一提的是，在App层面采用的异步I/O库，一般都是在Server的异步I/O机制的基础上打造的：Node自然不用说了，都是基于Node的事件机制；Tornado的异步库也都是基于 tornado.ioloop 的。

天下没有免费的午餐，由于执行模式是异步的，会给编程和调试带来巨大挑战。我们需要采取额外的措施来提升开发体验，事件机制、Promise等都是NodeJS中比较流行的应对方法。

BTW，在App层面采用异步I/O模型，只能解决I/O性能问题。如果业务逻辑是偏CPU运算密集型，提升效果就不明显啦！

（4）缓存

缓存真的是万金油。哪里卡哪里抹一点，从前端到后端，能抹的地方太多啦。对于App来说，下面是几种典型的应用场景：

• 缓存Session
• 缓存HTML页面：比如访问压力较大的首页
• 数据库读缓存/写缓存：读缓存很常见，这里提一下写缓存，有时候我们没有必要太频繁地写数据库，可以将写操作直接在缓存上做，然后累积到一定次数再一起写入数据库中
• 缓存复杂运算结果：比如把计算得出的当前热门话题缓存起来

一般使用Redis/Memcached来做缓存。

（5）计算外包

为了保证较高的请求吞吐率，业务逻辑代码中不适合出现特别耗时的操作（比如图像处理、群发邮件等），这个时候就可以把这些耗时的计算过程从App中外包出去，交给独立的计算模块完成。计算外包（也就是分布式计算啦）可以有2种策略：异步计算、并行计算。

异步计算 是将计算任务转移出去的一种方法，这种架构中一般会有3种角色：生产者、任务队列、消费者。App在这里充当了生产者的角色，不断地将新的计算任务插入队列中；可以用Redis、MySQL、第三方消息队列（比如RabbitMQ）等存储计算任务；消费者就是真正执行计算的了，一般会开启多个后台worker，不断地从队列中取出任务来执行。

举个例子，GitHub仓库的语言构成的计算是比较耗时的，每一次commit都执行计算是非常划不来的，所以GitHub采用了异步计算，每周以一定频率计算并更新各仓库的语言构成。

之前的异步计算只是把计算任务转移，但并没有减少总体的处理时间。怎么办？能不能把计算任务先分割为小块儿，然后一起算，算好了再汇总呢？这就是 并行计算 的原理啦！这里不得不提一下Google的Map/Reduce分布式并行计算框架。

简单地说，App这边负责拆分计算任务，然后会有多个worker对每一个计算任务都并发调用Map函数来运算，运算结果根据某参照（比如城市编号、班级号）存放在不同的结果集中。所有的Map都运算完毕后，再由worker针对每一个Map结果集都并发调用Reduce函数进行汇总计算，得出最终结果。这篇 文章 还不错，可以说明Map/Reduce的大概原理。

（6）资源复用

之前说过，既然Server可以复用与客户端的TCP连接，那么App能不能复用与各种I/O设备的连接呢？当然可以！比如MySQL、Redis等都可以用线程池的形式存放连接，减少开销。

数据库性能优化

关键：如何更快地读/写数据。

这里的数据库特指MySQL，在介绍数据库性能优化方法之前，提几个用于性能分析的MySQL命令行工具：

• mysqlreport ：第三方MySQL状态报告工具，分析结果一目了然
• explain ：用于分析SQL语句的执行细节（比如是否用到了索引）
• mysqlsla ：用于查询哪些SQL操作的耗时超过了预设的阈值，使用此工具之前需要在 my.cnf 开启慢查询日志，即增加 long_query_time=1 和log-slow-queries = /data/var/mysql_slow.log 这2行配置项

（1）索引

索引就像是一本书的目录，好的索引可以极大地提升select操作的效率，但会增加delete/update/insert的开销。如果你的数据库的读远多于写，那么索引是非常奏效的。

• 在哪个字段设置索引：经常出现在select语句的where/order by/group by后的字段，都可以考虑设置索引
• 使用组合索引：如果一条select语句的条件过滤中涉及到了多个field，那可以考虑设置组合索引，组合索引有一个最重要的原则就是 最左前缀 ，比如where A=1 and C=2 是无法使用到 A, B, C 组合索引的
• 判断一个SQL操作是否用到索引，可以使用explain工具

（2）冗余设计

数据库的表设计一般遵循所谓的第三范式（3NF），即要求非主键字段之间不能存在依赖关系。但是如果完全按照这样来做的话，SQL语句中会包含大量的join操作。在设计时我们可以保留适量的冗余，比如一个user的blogs数目，可以直接在user表中增加一个blogs_count字段，每次增加/删除blog时就相应地+/-此字段。以后查询起来就快了。

（3）读写分离

单个数据库读写扛不住？那就把读写分离开吧，使用MySQL的主从复制功能，多个从数据库保持与主数据库的同步，然后update/delete/insert全部走主数据库，select则使用负载均衡技术分摊到多个从数据库上。

（4）垂直分区 & 水平分区

读写分离了还是不行，怎么办？可以考虑把相对独立的数据表存放在不同的服务器上，然后每一个都采用读写分离技术，这就是垂直分表，可以进一步将读写压力分摊到更多的服务器上。

如果垂直分表了还不行，那就考虑将单表进一步拆分（分表），然后每n（n>=1）个表部署到独立的服务器上（水平分区）。分表和水平分区的方法大概有：哈希算法、范围分区、映射关系，具体见《构建高性能Web站点》P370页。

（5）NoSQL

如果以上的方法还不奏效，或者虽然奏效但维护成本太高，那就可以考虑抛弃关系数据库，转投NoSQL阵营了。需要注意的是，关系数据库和NoSQL都有各自的适用场景，谁也无法完全取代谁。但NoSQL实在是太多啦，如何选择呢？这里推荐一些比较不错的博文：Robbin的 文章 对NoSQL有一个概览式的分类，草屋主人的NoSQL系列文章 涉及到了各类应用场景，值得一读。

文件存储性能优化

关键：如何更快地写入和读取。

（1）存储介质

换过SSD的同学一般都会体会到操作体验的巨大提升，我所用过的Digital Ocean的主打亮点就是SSD。不过SSD的性价比和稳定性尚待考验，但未来应该是SSD的！

（2）分布式存储

了解了很多眼花缭乱的名词：RAID、HDFS、MongoDB GridFS...但完全不知道它们的关系和脉络到底如何，至于适用场景的话也没怎么看懂TAT，所以就不说了...以后如果有了这方面的实战经验，我想可以单独讨论一下。留几个链接以后再看吧： [1] 、 [2] 、 [3] 、 [4] 。

Web后端性能优化方面的知识就记录到这里，前端篇待续。

· EOF ·