ReactPHP:PHP版的Node.js

从名字说起 

ReactPHP:PHP版的Node.js
ReactPHP:PHP版的Node.js

虽然ReactPHP项目已经发展了有4年之久,但是对于其称呼显得有点混乱。在开源中国为其建立的项目主页上,其被命名为React,或者node.PHP。国外的一些的博客谈及这个项目时,多数使用的是ReactPHP。到底哪种说法比较标准呢?我们不妨来看看官方的态度。此项目的官方主页是 http://www.reactphp.org 。打开官网,你会发现网站的title是React,其logo上的文字为reactphp。可以看出,官方更倾向于被命名为React或者ReactPHP。我建议使用ReactPHP作为其名称。原因大概有两个。

  1. React单词的意思太泛,并且已经有一些项目的名称与React相关,容易引起误解。
  2. 目前国内使用ReactPHP的人比较少,相关资料文档也比较少。在国外它一般被称为ReactPHP,使用ReactPHP在国外检索资料更容易。

ReactPHP与Node.js有着相同的特点

许多人认为ReactPHP是Node.js的php版本,这是有一定道理的。他们的确有很多相似的特点。

事件驱动,异步执行,非阻塞IO

什么是事件驱动?所谓事件驱动,简单的说就是,你告诉我你关注什么事情,等事情发生的时候我会主动通知你,然后你再作相应的处理。这样可以就可以把你解放出来,你只关注于处理好相应事件即可。采用事件驱动有什么优势呢?相对于常见的多进程编程,能更好的利用CPU资源。多进程编程会使进程数量变多,进程上下文切换频繁会增加系统压力,浪费宝贵的CPU资源。相对于多线程编程而言,可以降低编程复杂度。开发者不必再考虑线程间资源共享导致资源竞争等问题。

ReactPHP和Node.js都采用了事件驱动和非阻塞IO。从官方主页的宣传语上就可以得到印证。在Node.js的官网上有一段话:

Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient。

上面的意思是,Node.js使用事件驱动和非阻塞IO模型,以保证轻量级和高效。

在ReactPHP官网也有一段话:

Event-driven, non-blocking I/O with PHP.

上面的意思是,ReactPHP使用PHP语言实现了事件驱动和非阻塞。

ReactPHP和Node.js在实现事件驱动机制时也有相似之处。在事件的监听上,ReactPHP和Node.js都使用了libev库,但是也都是不只使用libev库。由于libev对windows支持不够好。因此,Node.js中封装了一层libuv。libuv是基于windows的IOCP和*nix的libev进行封装。而ReactPHP除了使用libev库外,还是用了其他的库。如,libevent。

ReactPHP和Node.js都各自有自己的生态圈。在各自生态圈中的一些模块一般都采用了事件驱动,异步编程的风格。如,ReactPHP的Stream模块,提供了以下几个事件:drain、error、close、pipe、end、data。相应的,在Node.js中也有一些类似的事件。Node.js的Net模,其中的net.Socket对象就有以下事件:connect、data、end、timeout、drain、error、close等。这样,开发人员只需要知道自己关注那些事件,并在这些事件上注册回调函数。等事件发生的时候,会主动执行这些注册的回调函数。这些回调函数都是异步执行的,这些函数虽然在注册的时候有先后顺序,但是在执行的时候是无序的,随机的,执行顺序和事件发生顺序相关。事件驱动再加上非阻塞IO,就可以极大的利用系统资源,代码无需阻塞等待资源可用。

单进程单线程

ReactPHP和Node.js一样都是采用了单进程和单线程的运行方式。单进程,单线程方式,没有多线程的资源抢占和上下文切换,高效率的运行,维护着一个事件队列。这种运行方式,通常情况下瓶颈一般在CPU而不是内存。由于单进程,单线程只能在一个CPU上运行,本身不能充分利用多个CPU资源。为了解决这个问题,我们可以启动多个进程,监听不同的端口,前端使用nginx等做代理,把请求分发到不同的进程上。对于多进程的管理上,现在已经有不少开源项目可以实现。如,php-pm

ReactPHP性能压测

相对于传统的nginx+php-fpm方式,ReactPHP的性能表现如何呢?现在我们来做下性能压测。服务器环境如下:

  • 8核CPU
  • PHP版本为5.5.15,使用opcache扩展
  • 操作系统为Centos5
  • Nginx版本为nginx/1.2.9
  • ReactPHP版本为0.4

为了公平起见,我们php-fpm和ReactPHP都只启动一个进程。压测工具我们使用ab,Apache开源的http服务压测工具。我们压测分两种情况来进行:第一种情况是只输出简单的Hello World。第二种情况只进行一次简单的sql语句查询,select 1 as num。

第一种情况:Hello World的压测结果如下,QPS:

ReactPHP:PHP版的Node.js
ReactPHP:PHP版的Node.js

第二种情况:SQL查询的压测结果如下,QPS:

ReactPHP:PHP版的Node.js
ReactPHP:PHP版的Node.js

可见,对于cpu密集型的应用,nginx+php-fpm的方式要比ReactPHP有更好的表现。但是对于数据库查询这样涉及网络IO的场景,ReactPHP的性能要远远好于nginx+php-fpm的方式。 

ReactPHP的应用场景

根据上面的测试,ReactPHP更适合IO密集型的应用。以下是ReactpHP比较适合的应用场景。

  1. 从RESTful API获取数据,并进行拼装输出只是请求api获取数据,然后进行简单的拼装,最后输出到客户端。本身业务逻辑不复杂。在请求的时候,可以同时对多个api进行请求,相对于顺序调用api的方式,会节省很多的时间,大大提高了响应的效率。
  2. 实时推送,在线聊天实时推送和在线聊天都需要维护大量的链接。这个正是ReactpHP擅长的。他可以很轻松的维护上万的链接。
  3. 分布式IO系统如一个数据库中间件层,它需要解析SQL为多条子SQL,然后把子SQL分发到不同的服务器查询数据,然后合并数据返回给客户端。这种情况下可以使用ReactPHP同时对多个数据库服务器进行查询。

如何使用ReactPHP 

ReactPHP可以使用composer安装,这个也是官方推荐的安装方式。首先安装composer。

curl -s https://getcomposer.org/installer| php

安装完成后,会在当前目录下生成一个composer.phar文件。然后我们使用composer.phar安装react。

php ./composer.phar require react/react

安装成功后,会在当前目录下生成一个vendor目录。下载的程序就在这个目录下。现在你就可以使用ReactPHP写程序了。例如,我们想提供一个http服务,我们将把客户端通过data参数提交的数据加上www.后进行返回。代码如下: 

writeHead(200, array('Content-Type' => 'text/plain'));
        $query = $request->getQuery();
        $data = isset($query["data"]) ? $query["data"] : "";
        $response->end("www.{$data}n");
};

$loop = ReactEventLoopFactory::create();
$socket = new ReactSocketServer($loop);
$http = new ReactHttpServer($socket, $loop);

$http->on('request', $app);

$socket->listen($port, '0.0.0.0');
$loop->run();
?> 

把上面的代码保持为文件reactphp.php。然后启动服务:

php ./reactphp.php 5501

最后,我们验证下效果,可以通过下面的方式访问。 

$curl  http://10.101.80.141:5501/?data=bo56.com

www.bo56.com 

ReactPHP也有自己的生态圈。如进行异步mysql查询的react-php。

小结

ReactPHP作为Node.js的PHP版本。在实现思路,使用方法,应用场景上的确有很多相似之处。但是ReactPHP毕竟比Node.js年轻,目前生态圈还是不如Node.js完善。目前文档也不是很完善,在国内应用也比较少。但是相信,它会越来越完善,应用越来越广。

如何收集 NGINX 指标(第二篇)

如何收集 NGINX 指标(第二篇)
如何收集 NGINX 指标(第二篇)

如何获取你所需要的 NGINX 指标

如何获取需要的指标取决于你正在使用的 NGINX 版本以及你希望看到哪些指标。(参见 如何监控 NGINX(第一篇) 来深入了解NGINX指标。)自由开源的 NGINX 和商业版的 NGINX Plus 都有可以报告指标度量的状态模块,NGINX 也可以在其日志中配置输出特定指标:

指标可用性

指标 NGINX (开源) NGINX Plus NGINX 日志
accepts(接受) / accepted(已接受) x x  
handled(已处理) x x  
dropped(已丢弃) x x  
active(活跃) x x  
requests (请求数)/ total(全部请求数) x x  
4xx 代码   x x
5xx 代码   x x
request time(请求处理时间)     x

指标收集:NGINX(开源版)

开源版的 NGINX 会在一个简单的状态页面上显示几个与服务器状态有关的基本指标,它们由你启用的 HTTP stub status module 所提供。要检查该模块是否已启用,运行以下命令:

nginx -V 2>&1 | grep -o with-http_stub_status_module

如果你看到终端输出了 httpstubstatus_module,说明该状态模块已启用。

如果该命令没有输出,你需要启用该状态模块。你可以在从源代码构建 NGINX 时使用 –with-http_stub_status_module 配置参数:

./configure
…
--with-http_stub_status_module
make
sudo make install

在验证该模块已经启用或你自己启用它后,你还需要修改 NGINX 配置文件,来给状态页面设置一个本地可访问的 URL(例如: /nginx_status):

server {
    location /nginx_status {
        stub_status on;

        access_log off;
        allow 127.0.0.1;
        deny all;
    }
}

注:nginx 配置中的 server 块通常并不放在主配置文件中(例如:/etc/nginx/nginx.conf),而是放在主配置会加载的辅助配置文件中。要找到主配置文件,首先运行以下命令:

nginx -t

打开列出的主配置文件,在以 http 块结尾的附近查找以 include 开头的行,如:

include /etc/nginx/conf.d/*.conf;

在其中一个包含的配置文件中,你应该会找到主 server 块,你可以如上所示配置 NGINX 的指标输出。更改任何配置后,通过执行以下命令重新加载配置文件:

nginx -s reload

现在,你可以浏览状态页看到你的指标:

Active connections: 24
server accepts handled requests
1156958 1156958 4491319
Reading: 0 Writing: 18 Waiting : 6

请注意,如果你希望从远程计算机访问该状态页面,则需要将远程计算机的 IP 地址添加到你的状态配置文件的白名单中,在上面的配置文件中的白名单仅有 127.0.0.1。

NGINX 的状态页面是一种快速查看指标状况的简单方法,但当连续监测时,你需要按照标准间隔自动记录该数据。监控工具箱 Nagios 或者 Datadog,以及收集统计信息的服务 collectD 已经可以解析 NGINX 的状态信息了。

指标收集: NGINX Plus

商业版的 NGINX Plus 通过它的 ngxhttpstatus_module 提供了比开源版 NGINX 更多的指标。NGINX Plus 以字节流的方式提供这些额外的指标,提供了关于上游系统和高速缓存的信息。NGINX Plus 也会报告所有的 HTTP 状态码类型(1XX,2XX,3XX,4XX,5XX)的计数。一个 NGINX Plus 状态报告例子可在此查看

如何收集 NGINX 指标(第二篇)
如何收集 NGINX 指标(第二篇)

注:NGINX Plus 在状态仪表盘中的“Active”连接的定义和开源 NGINX 通过 stubstatusmodule 收集的“Active”连接指标略有不同。在 NGINX Plus 指标中,“Active”连接不包括Waiting状态的连接(即“Idle”连接)。

NGINX Plus 也可以输出 JSON 格式的指标,可以用于集成到其他监控系统。在 NGINX Plus 中,你可以看到 给定的上游服务器组的指标和健康状况,或者简单地从上游服务器的单个服务器得到响应代码的计数:

{"1xx":0,"2xx":3483032,"3xx":0,"4xx":23,"5xx":0,"total":3483055}

要启动 NGINX Plus 指标仪表盘,你可以在 NGINX 配置文件的 http 块内添加状态 server 块。 (参见上一节,为收集开源版 NGINX 指标而如何查找相关的配置文件的说明。)例如,要设置一个状态仪表盘 (http://your.ip.address:8080/status.html)和一个 JSON 接口(http://your.ip.address:8080/status),可以添加以下 server 块来设定:

server {
    listen 8080;
    root /usr/share/nginx/html;

    location /status {
        status;
    }

    location = /status.html {
    }
}

当你重新加载 NGINX 配置后,状态页就可以用了:

nginx -s reload

关于如何配置扩展状态模块,官方 NGINX Plus 文档有 详细介绍

指标收集:NGINX 日志

NGINX 的 日志模块 会把可自定义的访问日志写到你配置的指定位置。你可以通过添加或移除变量来自定义日志的格式和包含的数据。要存储详细的日志,最简单的方法是添加下面一行在你配置文件的 server 块中(参见上上节,为收集开源版 NGINX 指标而如何查找相关的配置文件的说明。):

access_log logs/host.access.log combined;

更改 NGINX 配置文件后,执行如下命令重新加载配置文件:

nginx -s reload

默认包含的 “combined” 的日志格式,会包括一系列关键的数据,如实际的 HTTP 请求和相应的响应代码。在下面的示例日志中,NGINX 记录了请求 /index.html 时的 200(成功)状态码和访问不存在的请求文件 /fail 的 404(未找到)错误。

127.0.0.1 - - [19/Feb/2015:12:10:46 -0500] "GET /index.html HTTP/1.1" 200 612 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari 537.36"

127.0.0.1 - - [19/Feb/2015:12:11:05 -0500] "GET /fail HTTP/1.1" 404 570 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36"

你可以通过在 NGINX 配置文件中的 http 块添加一个新的日志格式来记录请求处理时间:

log_format nginx '$remote_addr - $remote_user [$time_local] '
                 '"$request" $status $body_bytes_sent $request_time '
                 '"$http_referer" "$http_user_agent"';

并修改配置文件中 server 块的 access_log 行:

access_log logs/host.access.log nginx;

重新加载配置文件后(运行 nginx -s reload),你的访问日志将包括响应时间,如下所示。单位为秒,精度到毫秒。在这个例子中,服务器接收到一个对 /big.pdf 的请求时,发送 33973115 字节后返回 206(成功)状态码。处理请求用时 0.202 秒(202毫秒):

127.0.0.1 - - [19/Feb/2015:15:50:36 -0500] "GET /big.pdf HTTP/1.1" 206 33973115 0.202 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/40.0.2214.111 Safari/537.36"

你可以使用各种工具和服务来解析和分析 NGINX 日志。例如,rsyslog 可以监视你的日志,并将其传递给多个日志分析服务;你也可以使用自由开源工具,比如 logstash 来收集和分析日志;或者你可以使用一个统一日志记录层,如 Fluentd 来收集和解析你的 NGINX 日志。

结论

监视 NGINX 的哪一项指标将取决于你可用的工具,以及监控指标所提供的信息是否满足你们的需要。举例来说,错误率的收集是否足够重要到需要你们购买 NGINX Plus ,还是架设一个可以捕获和分析日志的系统就够了?

在 Datadog 中,我们已经集成了 NGINX 和 NGINX Plus,这样你就可以以最小的设置来收集和监控所有 Web 服务器的指标。在本文中了解如何用 NGINX Datadog 来监控 ,并开始 Datadog 的免费试用吧。


via: https://www.datadoghq.com/blog/how-to-collect-nginx-metrics/

作者:K Young 译者:strugglingyouth 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

来源:https://linux.cn/article-5985-1.html

如何运维网站能让其稳定高效——稳定篇

作为一名运维工程师,工作中最大的希望就是自己运维的网站能够稳定高效运行,但理想很丰满现实很骨感,实际情况是总会有各种各样状况导致网络、服务器或者应用环境发生故障。面对这种情况,我觉得还是要能从故障中总结出经验规律,让发生的几率不断的降低。要完成稳定和高效两者中的任何一个都是一个极具挑战的事情,这里我以维护自己的blog为例来阐述一下我对稳定这个词的诠释和理解。

       我的Blog架设在wordpress环境上的,记录了工作中的一些经验总结和随笔文章,虽然是个人网站,但麻雀虽小,五脏俱全,有一定的代表性。

如何运维网站能让其稳定高效——稳定篇
如何运维网站能让其稳定高效——稳定篇

一. 稳定之硬件稳定

       硬件是基础设施,必须打好硬件稳定的基础。传统的硬件选型一般都是购买HP,DELL的机架式服务器,根据自己的需求选择CPU,内存,硬盘等,这种方式有一个弊端就是不能很方便的对硬件进行后期扩容,买了后一般情况下就定型了,而且还要托管,购买带宽,后期的硬件维护也是需要自己来做。面对这些问题,我觉得选择当下比较炙手可热的云服务器是个不错的选择。它解决了:

1)硬件型号不再重要,自然也就不会成为网站发展的瓶颈,CPU,内存,硬盘等硬件的大小都是弹性的,根据自己使用的情况随时可以增大和减小

2)云服务器提供商提供托管场地和网络带宽设施

3)因为云服务器提供商一般都有大量的服务器,所以会专门有一个机房工程师每天做硬件,网络的巡检工作,及时发现问题并将基础问题处理在萌芽阶段

4)对磁盘IO要求比较高的,可以选择购买本地磁盘和SSD磁盘来解决问题

总的来说,选择云服务器比较省心,而且国内的云服务器也逐渐的成熟起来,我个人使用云服务器这种方式7个月了,截止目前,硬件,网络都没有出现过问题,还是比较稳定的。当然大型云服务器提供商是比较好的选择,阿里云、腾讯云、Ucloud都不错。具体选择哪家,可以根据自己的实际情况来酌情选择。

如何运维网站能让其稳定高效——稳定篇
如何运维网站能让其稳定高效——稳定篇

二. 稳定之软件稳定

       软件是具体提供服务的应用组件,要做好这个稳定我觉得比硬件难一些了,方方面面都要考虑清楚,这里从下往上来逐个分析吧:

1)Wordpress是一个PHP环境的程序,那么Linux作为系统环境就是一个很好的选择,其实稳定的另一个特征就是当出现了故障时能够很快的排除故障,在成百上千的Linux发布系统中很多人最终选择Redhat,CentOS肯定是有其原因的,CentOS是基于企业级linux系统发布Redhat编译而来,兼容性好而且免费使用,网络中有大量的技术文章可以借阅参考,64位也会逐渐的取代32位系统,我最后选择的是CentOS6 64位系统环境。这里不是说让大家全部选择此发行版,而是一个建议,在实际选择过程中最好根据自己的业务类型,选择一个能用上3到5年的系统,不折腾。

2)nginx、mysql、php的搭档组合有逐步取代AMP组合的趋势,V1.0以上的nginx,V5.1以上的mysql,V5.4以上的PHP,这个版本选择是目前比较实用的组合,能够支撑一段时间不需要在更新了。

3)组件选择好后,比较关键的就是配置好这些组件了,配置这个过程没有一个统一的标准,需要不同参数也就不同,但不管环境怎样,还是有几个比较通用的法则:

A. 一个PHP和nginx进程大约占用内存20M,最大允许的进程数是要根据自己的实际内存大小来动态调整,否则可能导致内存耗尽而系统崩溃

B.调整参数的原则就是让自己的硬件资源能够充分利用,最大使用率根据28原则

C.配置的过程是一个循序渐进的过程,很多时候也是在处理问题时逐步总结出来最优配置

三. 稳定之实时监控

       网站对外发布后,剩下的任务就是要保证网站不出故障,持久稳定运行了。要做到这一点,就要对网站和硬件的运行情况有一个全面的了解才可以。掌握的数据越多,就对自己的网站运行情况越有利。

可用性监控:

网站当下是否能够正常访问,这是一个最基本的要求。但我们不可能实时去盯着,这里需要有个实时监控的服务去不断的探测,提供这样服务的工具有很多,例如nagios,zabbix等开源产品就是专门做这个事情的,周期性的探测网站的可用性,不过这种产品有一个很大的局限性,就是nagios和zabbix是部署在和自己网站同样的网络环境中,常常会出现nagios探测是好的,但外部访问却不行的状况。

这里我选择了一个第三方公司的产品——云智慧的监控宝,来做我的blog的可用性监控,其实现原理是使用它在全世界托管的监测服务器来周期性的访问我的blog,这种监控比较接近于实际用户访问,比较有说服力,如果发现了问题,会有一个告警信息发送到手机、邮件上。

如何运维网站能让其稳定高效——稳定篇
如何运维网站能让其稳定高效——稳定篇
如何运维网站能让其稳定高效——稳定篇
如何运维网站能让其稳定高效——稳定篇

四. 稳定之压力测试

       压力测试的目的是为了能够对自己网站的最大负载能力有一个预估值,原则是测试一个有复杂业务逻辑的动态页面为好,通过压力测试得出自己网站的最大并发值和承载能力。得出这个值之后,剩下的在配置参数的时候就有依据了。压力测试的方法有很多种,比较常见的有ab,loadrunnner等工具。

五.稳定之硬件资源使用监控和并发数监控

       压力测试的目的就是为了能够在这一环节有的放矢,网站上线后通过可用性监控得知网站是否能正常访问。在通过硬件资源使用情况和web服务的并发数监控,在监控中将告警阀值设置为压力测试过程中的80%为准。通过这样的实时监控,就对自己的服务器的运行情况有一个立体式的掌控,让其能够运行在正常的区间中。

如何运维网站能让其稳定高效——稳定篇
如何运维网站能让其稳定高效——稳定篇
如何运维网站能让其稳定高效——稳定篇
如何运维网站能让其稳定高效——稳定篇

总结:

保证服务的稳定是一个持续的过程,通过时间的积累对自己维护的业务运行情况越来越熟悉,对架构的掌握也越来越透彻,将网站架构中的薄弱环节加固,再通过后期的实时监控,对网站的整体运行情况有一个清晰的认识,由此来让自己运维的网站稳定运行。以上五点算是抛砖引玉吧,如果你有好的方法,随时沟通交流:wxd5981@163.com

Linux:NGINX缓存使用官方指南

我们都知道,应用程序和网站一样,其性能关乎生存。但如何使你的应用程序或者网站性能更好,并没有一个明确的答案。代码质量和架构是其中的一个原因,但是在很多例子中我们看到,你可以通过关注一些十分基础的应用内容分发技术,来提高终端用户的体验。其中一个例子就是实现和调整应用栈(application stack)的缓存。这篇文章,通过几个例子来讲述如何使用NGINX缓存,此外,结尾处还列举了一些常见问题及解答。

Linux:NGINX缓存使用官方指南
Linux:NGINX缓存使用官方指南

基础

一个web缓存坐落于客户端和“原始服务器(origin server)”中间,它保留了所有可见内容的拷贝。如果一个客户端请求的内容在缓存中存储,则可以直接在缓存中获得该内容而不需要与服务器通信。这样一来,由于web缓存距离客户端“更近”,就可以提高响应性能,并更有效率的使用应用服务器,因为服务器不用每次请求都进行页面生成工作。

在浏览器和应用服务器之间,存在多种“潜在”缓存,如:客户端浏览器缓存、中间缓存、内容分发网络(CDN)和服务器上的负载平衡和反向代理。缓存,仅在反向代理和负载均衡的层面,就对性能提高有很大的帮助。

举个例子说明,去年,我接手了一项任务,这项任务的内容是对一个加载缓慢的网站进行性能优化。首先引起我注意的事情是,这个网站差不多花费了超过1秒钟才生成了主页。经过一系列调试,我发现加载缓慢的原因在于页面被标记为不可缓存,即为了响应每一个请求,页面都是动态生成的。由于页面本身并不需要经常性的变更,并且不涉及个性化,那么这样做其实并没有必要。为了验证一下我的结论,我将页面标记为每5秒缓存一次,仅仅做了这一个调整,就能明显的感受到性能的提升。第一个字节到达的时间降低到几毫秒,同时页面的加载明显要更快。

并不是只有大规模的内容分发网络(CDN)可以在使用缓存中受益——缓存还可以提高负载平衡器、反向代理和应用服务器前端web服务的性能。通过上面的例子,我们看到,缓存内容结果,可以更高效的使用应用服务器,因为不需要每次都去做重复的页面生成工作。此外,Web缓存还可以用来提高网站可靠性。当服务器宕机或者繁忙时,比起返回错误信息给用户,不如通过配置NGINX将已经缓存下来的内容发送给用户。这意味着,网站在应用服务器或者数据库故障的情况下,可以保持部分甚至全部的功能运转。

下一部分讨论如何安装和配置NGINX的基础缓存(Basic Caching)。

如何安装和配置基础缓存

我们只需要两个命令就可以启用基础缓存: proxy_cache_pathproxy_cache。proxy_cache_path用来设置缓存的路径和配置,proxy_cache用来启用缓存。

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m
                 use_temp_path=off;

server {
...
    location / {
        proxy_cache my_cache;
        proxy_pass http://my_upstream;
    }
}

proxy_cache_path命令中的参数及对应配置说明如下:

1.用于缓存的本地磁盘目录是/path/to/cache/

2.levels/path/to/cache/设置了一个两级层次结构的目录。将大量的文件放置在单个目录中会导致文件访问缓慢,所以针对大多数部署,我们推荐使用两级目录层次结构。如果levels参数没有配置,则NGINX会将所有的文件放到同一个目录中。

3.keys_zone设置一个共享内存区,该内存区用于存储缓存键和元数据,有些类似计时器的用途。将键的拷贝放入内存可以使NGINX在不检索磁盘的情况下快速决定一个请求是`HIT`还是`MISS`,这样大大提高了检索速度。一个1MB的内存空间可以存储大约8000个key,那么上面配置的10MB内存空间可以存储差不多80000个key。

4.max_size设置了缓存的上限(在上面的例子中是10G)。这是一个可选项;如果不指定具体值,那就是允许缓存不断增长,占用所有可用的磁盘空间。当缓存达到这个上线,处理器便调用cache manager来移除最近最少被使用的文件,这样把缓存的空间降低至这个限制之下。

5.inactive指定了项目在不被访问的情况下能够在内存中保持的时间。在上面的例子中,如果一个文件在60分钟之内没有被请求,则缓存管理将会自动将其在内存中删除,不管该文件是否过期。该参数默认值为10分钟(10m)。注意,非活动内容有别于过期内容。NGINX不会自动删除由缓存控制头部指定的过期内容(本例中Cache-Control:max-age=120)。过期内容只有在inactive指定时间内没有被访问的情况下才会被删除。如果过期内容被访问了,那么NGINX就会将其从原服务器上刷新,并更新对应的inactive计时器。

6.NGINX最初会将注定写入缓存的文件先放入一个临时存储区域, use_temp_path=off命令指示NGINX将在缓存这些文件时将它们写入同一个目录下。我们强烈建议你将参数设置为off来避免在文件系统中不必要的数据拷贝。use_temp_path在NGINX1.7版本和NGINX Plus R6中有所介绍。

最终, proxy_cache命令启动缓存那些URL与location部分匹配的内容(本例中,为`/`)。你同样可以将proxy_cache命令添加到server部分,这将会将缓存应用到所有的那些location中未指定自己的proxy_cache命令的服务中。

陈旧总比没有强

NGINX内容缓存的一个非常强大的特性是:当无法从原始服务器获取最新的内容时,NGINX可以分发缓存中的陈旧(stale,编者注:即过期内容)内容。这种情况一般发生在关联缓存内容的原始服务器宕机或者繁忙时。比起对客户端传达错误信息,NGINX可发送在其内存中的陈旧的文件。NGINX的这种代理方式,为服务器提供额外级别的容错能力,并确保了在服务器故障或流量峰值的情况下的正常运行。为了开启该功能,只需要添加proxy_cache_use_stale命令即可:

location / {
    ...
    proxy_cache_use_stale error timeout http_500 http_502 http_503 http_504;
}

按照上面例子中的配置,当NGINX收到服务器返回的error,timeout或者其他指定的5xx错误,并且在其缓存中有请求文件的陈旧版本,则会将这些陈旧版本的文件而不是错误信息发送给客户端。

缓存微调

NGINX提供了丰富的可选项配置用于缓存性能的微调。下面是使用了几个配置的例子:

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m
                 use_temp_path=off;

server {
    ...
    location / {
        proxy_cache my_cache;
        proxy_cache_revalidate on;
        proxy_cache_min_uses 3;
        proxy_cache_use_stale error timeout updating http_500 http_502 http_503 http_504;
        proxy_cache_lock on;

        proxy_pass http://my_upstream;
    }
}

这些命令配置了下列的行为:

1.proxy_cache_revalidate指示NGINX在刷新来自服务器的内容时使用GET请求。如果客户端的请求项已经被缓存过了,但是在缓存控制头部中定义为过期,那么NGINX就会在GET请求中包含If-Modified-Since字段,发送至服务器端。这项配置可以节约带宽,因为对于NGINX已经缓存过的文件,服务器只会在该文件请求头中Last-Modified记录的时间内被修改时才将全部文件一起发送。

2.proxy_cache_min_uses设置了在NGINX缓存前,客户端请求一个条目的最短时间。当缓存不断被填满时,这项设置便十分有用,因为这确保了只有那些被经常访问的内容才会被添加到缓存中。该项默认值为1。

3.proxy_cache_use_stale中的updating参数告知NGINX在客户端请求的项目的更新正在原服务器中下载时发送旧内容,而不是向服务器转发重复的请求。第一个请求陈旧文件的用户不得不等待文件在原服务器中更新完毕。陈旧的文件会返回给随后的请求直到更新后的文件被全部下载。

4.当proxy_cache_lock被启用时,当多个客户端请求一个缓存中不存在的文件(或称之为一个MISS),只有这些请求中的第一个被允许发送至服务器。其他请求在第一个请求得到满意结果之后在缓存中得到文件。如果不启用proxy_cache_lock,则所有在缓存中找不到文件的请求都会直接与服务器通信。

跨多硬盘分割缓存

使用NGINX,不需要建立一个RAID(磁盘阵列)。如果有多个硬盘,NGINX可以用来在多个硬盘之间分割缓存。下面是一个基于请求URI跨越两个硬盘之间均分缓存的例子:

proxy_cache_path /path/to/hdd1 levels=1:2 keys_zone=my_cache_hdd1:10m max_size=10g
                 inactive=60m use_temp_path=off;
proxy_cache_path /path/to/hdd2 levels=1:2 keys_zone=my_cache_hdd2:10m max_size=10g
                 inactive=60m use_temp_path=off;

split_clients $request_uri $my_cache {
              50%          “my_cache_hdd1”;
              50%          “my_cache_hdd2”;
}

server {
    ...
    location / {
        proxy_cache $my_cache;
        proxy_pass http://my_upstream;
    }
}

上例中的两个proxy_cache_path定义了两个缓存(my_cache_hdd1my_cache_hd22)分属两个不同的硬盘。split_clients配置部分指定了请求结果的一半在my_cache_hdd1中缓存,另一半在my_cache_hdd2中缓存。基于$request_uri(请求URI)变量的哈希值决定了每一个请求使用哪一个缓存,对于指定URI的请求结果通常会被缓存在同一个缓存中。

常见问题解答

这部分内容回答了一些关于NGINX内容缓存的常见问题。

可以检测NGINX缓存状态吗?

可以,使用add_header指令:

add_header X-Cache-Status $upstream_cache_status;

上面的例子中,在对客户端的响应中添加了一个`X-Cache-Status`HTTP响应头,下面是$upstream_cache_status的可能值:

  1. MISS——响应在缓存中找不到,所以需要在服务器中取得。这个响应之后可能会被缓存起来。
  2. BYPASS——响应来自原始服务器而不是缓存,因为请求匹配了一个proxy_cache_bypass(见下面我可以在缓存中打个洞吗?)。这个响应之后可能会被缓存起来。
  3. EXPIRED——缓存中的某一项过期了,来自原始服务器的响应包含最新的内容。
  4. STALE——内容陈旧是因为原始服务器不能正确响应。需要配置proxy_cache_use_stale
  5. UPDATING——内容过期了,因为相对于之前的请求,响应的入口(entry)已经更新,并且proxy_cache_use_staleupdating已被设置
  6. REVALIDATED——proxy_cache_revalidate命令被启用,NGINX检测得知当前的缓存内容依然有效(If-Modified-Since或者If-None-Match)。
  7. HIT——响应包含来自缓存的最新有效的内容。

NGINX 如何决定是否缓存?

默认情况下,NGINX需要考虑从原始服务器得到的Cache-Control标头。当在响应头部中Cache-Control被配置为PrivateNo-CacheNo-Store或者Set-Cookie,NGINX不进行缓存。NGINX仅仅缓存GET和HEAD客户端请求。你也可以参照下面的解答覆盖这些默认值。

Cache-Control头部可否被忽略?

可以,使用proxy_ignore_headers命令。如下列配置:

location /images/ {
    proxy_cache my_cache;
    proxy_ignore_headers Cache-Control;
    proxy_cache_valid any 30m;
    ...
}

NGINX会忽略所有/images/下的Cache-Control头。proxy_cache_valid命令强制规定缓存数据的过期时间,如果忽略Cache-Control头,则该命令是十分必要的。NGINX不会缓存没有过期时间的文件。

当在头部设置了Set-Cookie之后NGINX还能缓存内容吗?

可以,使用proxy_ignore_headers命令,参见之前的解答。

NGINX能否缓存POST 请求?

可以,使用proxy_cache_methods命令:

proxy_cache_methods GET HEAD POST;

这个例子中可以缓存POST请求。其他附加的方法可以依次列出来的,如PUT。

NGINX 可以缓存动态内容吗?

可以,提供的Cache-Control头部可以做到。缓存动态内容,甚至短时间内的内容可以减少在原始数据库和服务器中加载,可以提高第一个字节的到达时间,因为页面不需要对每个请求都生成一次。

我可以再缓存中打个洞(Punch a Hole)吗?

可以,使用proxy_cache_bypass命令:

location / {
    proxy_cache_bypass $cookie_nocache $arg_nocache;
    ...
}

这个命令定义了哪种类型的请求需要向服务器请求而不是尝试首先在缓存中查找。有些时候又被称作在内存中“打个洞”。在上面的例子中,NGINX会针对nocache cookie或者参数进行直接请求服务器,如: http://www.example.com/?nocache=true。NGINX依然可以为将那些没有避开缓存的请求缓存响应结果。

NGINX 使用哪些缓存键?

NGINX生成的键的默认格式是类似于下面的NGINX变量的MD5哈希值: $scheme$proxy_host$request_uri,实际的算法有些复杂。

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m
                 use_temp_path=off;

server {
    ...
    location / {
        proxy_cache $my_cache;
        proxy_pass http://my_upstream;
    }
}

按照上面的配置, http://www.example.org/my_image.jpg的缓存键被计算为md5(“http://my_upstream:80/my_image.jpg”)。

注意,$proxy_host变量用于哈希之后的值而不是实际的主机名(www.example.com)。$proxy_host被定义为proxy_pass中指定的代理服务器的主机名和端口号。

为了改变变量(或其他项)作为基础键,可以使用proxy_cache_key命令(下面的问题会讲到)。

可以使用Cookie作为缓存键的一部分吗?

可以,缓存键可以配置为任意值,如:

proxy_cache_key $proxy_host$request_uri$cookie_jessionid;

NGINX使用Etag头部吗?

在NGINX 1.7.3和NGINX Plus R5及之后的版本,配合使用If-None-Match, Etag是完全支持的。

NGINX 如何处理字节范围请求?

如果缓存中的文件是最新的,NGINX会对客户端提出的字节范围请求传递指定的字节。如果文件并没有被提前缓存,或者是陈旧的,那么NGINX会从服务器上下载完整文件。如果请求了单字节范围,NGINX会尽快的将该字节发送给客户端,如果在下载的数据流中刚好有这个字节。如果请求指定了同一个文件中的多个字节范围,NGINX则会在文件下载完毕时将整个文件发送给客户端。

一旦文件下载完毕,NGINX将整个数据移动到缓存中,这样一来,无论将来的字节范围请求是单字节还是多字节范围,NGINX都可以在缓存中找到指定的内容立即响应。

NGINX 支持缓存清洗吗?

NGINX Plus支持有选择性的清洗缓存。当原始服务器上文件已经被更新,但是NGINX Plus缓存中文件依然有效(Cache-Control:max-age依然有效,proxy_cache_path命令中inactive参数设置的超时时间没有过期),这个功能便十分有用。使用NGINX Plus的缓存清洗特性,这个文件可以被轻易的删除。详细信息,参见Purging Content from the Cache

NGINX如何处理Pragma 头部?

当客户端添加了Pragma:no-cache头部,则请求会绕过缓存直接访问服务器请求内容。NGINX默认不考虑Pragma头部,不过你可以使用下面的proxy_cache_bypass的命令来配置该特性:

location /images/ {
    proxy_cache my_cache;
    proxy_cache_bypass $http_pragma;
    ...
}

NGINX支持Vary 头部吗?

是的,在NGINX Plus R5、NGINX1.7.7和之后的版本中是支持的。看看这篇不错的文章: good overview of the Vary header

延伸阅读

有非常多的方式对NGINX进行个性化定制和调优。要了解更多关于NGINX缓存,请看下面的资源:

  • NGINX文档中的ngx_http_proxy_module部分包含所有内容缓存的可选项。
  • NGINX内容缓存研讨会全程可以根据自己的需要查看。这篇博客包含了研讨会的部分内容。
  • NGINX Plus管理员指南中的Content Caching部分有更多关于调优NGINX缓存的配置案例和信息内容。
  • Content Caching with NGINX Plus产品页包含如何配置NGINX Plus进行缓存清洗的概述,并提供了其他缓存个性化配置的例子。

来源:http://www.jointforce.com/jfperiodical/article/949

如何让你的 Docker 镜像更小

Docker是个好东西毋庸置疑,甚至可以称其为万金油,什么场合都看到他的身影。自14年底开始,小到防污染的DNS、CoreOS的socks5代理,大点到开发团队的CI系统,一些Web项目等等,都有在用,并且稳定性非常好,使用起来也方便,但是最近经常发现各大论坛、网站、文档在使用Docker镜像的时候常常发现的一个误区,谨以此文抛砖引玉。

让我们从一个dockerfile说起,缘起我5月写的一个2048的Docker镜像,当时是在csphere的群里,以游戏的形式,教人快速的集成Web服务,提供服务。我们首先来看一个传统的镜像写法:

FROM ubuntu:12.04
RUN apt-get update
RUN apt-get install -y nginx zip curl
RUN echo "daemon off;" >> /etc/nginx/nginx.conf
RUN curl -o /usr/share/nginx/www/master.zip -L https://codeload.github.com/gabrielecirulli/2048/zip/master
RUN cd /usr/share/nginx/www/ && unzip master.zip && mv 2048-master/* . && rm -rf 2048-master master.zip
EXPOSE 80
CMD ["/usr/sbin/nginx", "-c", "/etc/nginx/nginx.conf"]

解读一下:

基于ubuntu12.04,先来一个更新,然后安装nginx、zip、curl,配置nginx,下载2048代码,解压再放到指定位置,删除原始文件,抛出80端口,最后是执行命令。

这样的dockerfile再熟悉不过了吧,随便docker hub或者其他教学文档都是这样,接下来,我们来谈谈中间的毛病。

  1. pull一个ubuntu需要多少时间,占多大的空间?(初学者好多在这一步就头痛)
  2. ubuntu在没有添加中国镜像源的情况,更新是个多么痛苦的事?(灯,等等等等)
  3. 配置啰嗦(麻烦,麻烦)
  4. 整个生成的镜像硕大无比,玩个2048不需要这么复杂。

光提问题,不给解决方案就是耍流氓,还是看dockerfile:

FROM alpine:latest
MAINTAINER alex alexwhen@gmail.com
RUN apk --update add nginx
COPY . /usr/share/nginx/html
EXPOSE 80
CMD [“nginx”, “-g”, “daemon off;”]

极简化的利用dockerfile和base镜像和github的特性,能少一句就少一句,动动手试一下,这样build出来,整个镜像不超过10M,回过头来看看前面的镜像,光一个ubuntu得多大啊,实在是居家必备。

 

Docker是个好东西,应用的时候充分考虑自己的使用环境,不要动不动就FROM ubuntu、debian、centos。alpine是一个非常好的base,包管理系统比较完善,神器啊。

本人的docker-2048,可以从以下方式获得:

  1. github:https://github.com/alexwhen/docker-2048注:你可以在此基础上玩出更多你想要的东西
  2. 直接运行: docker run -d -p 80:80 alexwhen/docker-2048 (本机80端口有占用的请换端口),然后打开浏览器输入127.0.0.1,你就可以愉快的玩了。
  3. 本镜像同样存在于alauda和daocloud。

写在最后,写这个本来是教一个新人学写Dockerfile和快速的利用Docker云服务快速的构建出自己的应用。

来源:http://dockone.io/article/504

Linux:如何让你的 Docker 镜像更小

Docker是个好东西毋庸置疑,甚至可以称其为万金油,什么场合都看到他的身影。自14年底开始,小到防污染的DNS、CoreOS的socks5代理,大点到开发团队的CI系统,一些Web项目等等,都有在用,并且稳定性非常好,使用起来也方便,但是最近经常发现各大论坛、网站、文档在使用Docker镜像的时候常常发现的一个误区,谨以此文抛砖引玉。

让我们从一个dockerfile说起,缘起我5月写的一个2048的Docker镜像,当时是在csphere的群里,以游戏的形式,教人快速的集成Web服务,提供服务。我们首先来看一个传统的镜像写法:

FROM ubuntu:12.04
RUN apt-get update
RUN apt-get install -y nginx zip curl
RUN echo "daemon off;" >> /etc/nginx/nginx.conf
RUN curl -o /usr/share/nginx/www/master.zip -L https://codeload.github.com/gabrielecirulli/2048/zip/master
RUN cd /usr/share/nginx/www/ && unzip master.zip && mv 2048-master/* . && rm -rf 2048-master master.zip
EXPOSE 80
CMD ["/usr/sbin/nginx", "-c", "/etc/nginx/nginx.conf"]

解读一下:

基于ubuntu12.04,先来一个更新,然后安装nginx、zip、curl,配置nginx,下载2048代码,解压再放到指定位置,删除原始文件,抛出80端口,最后是执行命令。

这样的dockerfile再熟悉不过了吧,随便docker hub或者其他教学文档都是这样,接下来,我们来谈谈中间的毛病。

  1. pull一个ubuntu需要多少时间,占多大的空间?(初学者好多在这一步就头痛)
  2. ubuntu在没有添加中国镜像源的情况,更新是个多么痛苦的事?(灯,等等等等)
  3. 配置啰嗦(麻烦,麻烦)
  4. 整个生成的镜像硕大无比,玩个2048不需要这么复杂。

光提问题,不给解决方案就是耍流氓,还是看dockerfile:

FROM alpine:latest
MAINTAINER alex alexwhen@gmail.com
RUN apk --update add nginx
COPY . /usr/share/nginx/html
EXPOSE 80
CMD [“nginx”, “-g”, “daemon off;”]

极简化的利用dockerfile和base镜像和github的特性,能少一句就少一句,动动手试一下,这样build出来,整个镜像不超过10M,回过头来看看前面的镜像,光一个ubuntu得多大啊,实在是居家必备。

 

Docker是个好东西,应用的时候充分考虑自己的使用环境,不要动不动就FROM ubuntu、debian、centos。alpine是一个非常好的base,包管理系统比较完善,神器啊。

本人的docker-2048,可以从以下方式获得:

  1. github:https://github.com/alexwhen/docker-2048注:你可以在此基础上玩出更多你想要的东西
  2. 直接运行: docker run -d -p 80:80 alexwhen/docker-2048 (本机80端口有占用的请换端口),然后打开浏览器输入127.0.0.1,你就可以愉快的玩了。
  3. 本镜像同样存在于alauda和daocloud。

写在最后,写这个本来是教一个新人学写Dockerfile和快速的利用Docker云服务快速的构建出自己的应用。

来源:http://dockone.io/article/504

Linux:一个社交App是如何构建高伸缩性的交互式系统

一个社交App需实现的功能

用户关注的常规社交功能、活动、地理位置、探索功能、新鲜事、视频照片分享等等,需要提供的功能不胜枚举,所以从技术角度来说,开发者需要解决的问题也是异常复杂的。

当一款社交App发布之初,用户访问量比较小,使用一台服务器就能够支撑全部的访问压力和数据存储需求,但是互联网应用具有病毒式的传播特点。一款App很可能会面临一夜爆红的现象,访问量和数据量在短时间内呈现爆发式增长,这时候会面临的局面是每天上亿PV、数百万新增用户和活跃用户、流量飙升至每秒数百兆。这些对于一个只部署了简单后端架构的应用来讲是无法支撑的,会直接导致服务器响应缓慢甚至超时,以及在高峰期时服务呈现瘫痪状态,使得后端的服务完全无法使用,用户体验急剧下降。本文将会通过一个真实的案例来分享一个社交应用如何构建一个具备高伸缩性的后端系统。

社交App最初部署的后端架构解析

社交App在最初的时候,后端架构相对比较简单,最初是部署在基础网络之上。最前面放置一台绑定了公网IP的nginx服务器作负载均衡,后面放置3台应用服务器来负责处理所有业务上的请求,最后面搭建一台MySQL Database数据库。

Linux:一个社交App是如何构建高伸缩性的交互式系统
Linux:一个社交App是如何构建高伸缩性的交互式系统

构建私有网络

随着产品的不断迭代、用户数的持续增长、数据量的积累,App就需要改进自己的后端架构,即开始构建私有网络。用户可以使用私有网络构建自己的网络拓扑——创建路由器和私有网络,将后续加入的用于运行内部服务的主机放置在私用网络中,可以有效地和云平台其他用户主机,在网络上实现100%二层隔离。主机对外开放的仅仅只有80端口,这样系统安全性上多了一层保障。

Linux:一个社交App是如何构建高伸缩性的交互式系统
Linux:一个社交App是如何构建高伸缩性的交互式系统

在上面的架构图中,最前面的是防火墙,后面接负载均衡器,然后接路由器和私有网络,很多互联网应用都存在读多写少的情况,这个比例有时可以达到8:2,所以我们首先通过引入缓存分摊数据库读压力。其次,引入负载均衡器,替换最初架构中的nginx proxy,负责均衡器在这里其主要用于分发请求到后端多台应用服务器,,当其中一台应用服务器挂掉,负载均衡器可以进行自动隔离。

业务分区与扩展

App随着并发访问量和数据量不断增大,首先想到横向扩容Web服务。水平扩容业务服务器的前提是要保证每台服务器都是无状态的,将session信息下放到缓存或数据库中存储,保证请求被负载到任何一台服务器可以正常处理。

Linux:一个社交App是如何构建高伸缩性的交互式系统
Linux:一个社交App是如何构建高伸缩性的交互式系统

从上图中看到,在前一步「构建私有网络」之后,增加了一个新的私有网络来扩展网络层,这里可以利用自有映像功能,将原有的应用服务器制作成模板,后续就可以基于这个模板快速启动新的主机。另外可以利用Auto-scaling(自动横向扩展)功能,根据后端服务器的负载请求,动态调整服务器的数量。

一个社交应用的后端会提供很多服务请求接口,比如添加好友、刷新新鲜事、浏览页面等,可以通过日志分析每一个接口的耗时,将耗时长但非重要业务的请求分到单独的Web服务器上进行处理,从而给主Web服务器留出更多资源去处理关键业务的请求。

面向服务的架构

随着产品功能的不断迭代,业务代码会越来越复杂,出现故障的可能性也在加大,当一个局部功能出现问题时,都会影响整个服务的可用性。此时可以构建面向服务的架构,将一个完整且庞大的服务拆分为一个个的子服务,服务之间通过接口交互。如下图所示:

Linux:一个社交App是如何构建高伸缩性的交互式系统
Linux:一个社交App是如何构建高伸缩性的交互式系统

社交App的服务被拆分成了四个子服务——新鲜事(News Feed)、用户资料(Profile)、广告(Ads)和探索(Explore),不同的服务之间通过消息通信框架(例如ZeroMQ)来进行交互。把一个大服务拆分为几个小的子服务的好处不言而喻,主要是:

  • 故障隔离:子服务出现故障不会影响全局,比如广告业务出现问题并不会让整个App不能使用,依然可以查看新鲜事等;
  • 独立扩展:每一个被拆分出的子服务有着不同的访问压力,比如新鲜事的调用相比一些二级页面的用户资料要高很多,所以前者会被分配更多的Web 服务器;
  • 独立部署:一个大服务的配置因功能过多会异常复杂,一旦被拆分就可根据不同的特性需求定制配置项,从而提高可管理性;
  • 团队协作开发:开发者都有着自己精通的方向,从而提高开发效率;
  • 抽象出数据访问:在后续进行数据层面(数据库、缓存)扩展时,可通过修改子服务的Data Service,实现对下层数据的透明。 

数据库Replication

业务增长也会给数据库带来诸多问题,当最初架构中单台数据库(数据库同时提供读和写)不足已支撑起App访问压力时,首先需要做数据副本Replication。市面上常见的MySQL、MongoDB等数据库都提供Replication功能,以MySQL为例,从高层来看,Replication可分成三步:

  1. Master将改变记录到二进制日志(binary log)中(这些记录叫做二进制日志事件,binary log events);
  2. Slave将Master的binary log events拷贝到它的中继日志(relay log);
  3. Slave重做中继日志中的事件,将改变反映它自己的数据。

具体实现该过程的第一部分就是Master记录二进制日志。在每个事务更新数据完成之前,Master在二进制日志记录这些改变。MySQL将事务串行的写入二进制日志,即使事务中的语句都是交叉执行的。在事件写入二进制日志完成后,Master通知存储引擎提交事务。

下一步就是Slave将Master的binary log拷贝到它自己的中继日志。首先,Slave开始一个工作线程——I/O线程。I/O线程在Master上打开一个普通的连接,然后开始binlog dump process。Binlog dump process从Master的二进制日志中读取事件,如果已经跟上Master,它会睡眠并等待Master产生新的事件。I/O线程将这些事件写入中继日志。

SQL slave thread处理该过程的最后一步。SQL线程从中继日志读取事件,更新Slave的数据,使其与Master中的数据一致。只要该线程与I/O线程保持一致,中继日志通常会位于OS的缓存中,所以中继日志的开销很小。

此外,在Master中也有一个工作线程:和其它MySQL的连接一样,Slave在Master中打开一个连接也会使得Master开始一个线程。复制过程有一个很重要的限制——复制在Slave上是串行化的,也就是说Master上的并行更新操作不能在Slave上并行操作。

对于云计算使用者来说,只需要知道数据库的IP和端口即可进行使用。具体实现见下图:

Linux:一个社交App是如何构建高伸缩性的交互式系统
Linux:一个社交App是如何构建高伸缩性的交互式系统

第一步要做的是扩充Slave,将单机Master变成Master+3台Slave的架构,而在其中的Slave上搭建一个内网的负载均衡器(Load Balancer),对于最上层的Data Service来说,只要配置一个MySQL Master节点和一个LB节点即可,今后因业务变化进行增减Slave对上层来说完全是透明的。

此做法可以带来两个好处,第一是提高可用性,若是一台Master出现错误,则可以提升某一台的Slave作为Master继续提供服务,从而保证数据可用性;第二个是分摊读压力,对于一个社交App来说,读写分离是在数据层优化第一步要做的事情,利用上面的架构可以很轻易地做到将读的请求分担到MySQL Slave上进行查询,而写留给Master。但是读写分离时会有数据库一致性的问题,即在数据写至Master之后同步到Slave有一个延迟的时间,对于社交应用来说,这是可以接受的,只要保证数据的最终一致性即可。

在上图的最下面有一个Snapshot,即定期对数据进行冷备份,这不同于单纯对MySQL Master进行复制的Slave,因为线上bug或误操作会删除Master上的数据,这时会立即同步到slave上造成数据丢失这时冷备份Snapshot就会起到数据保护作用。

运行过程中肯定需要监控,用户可以利用Linux上的工具进行统计分析top / iotop / df / free / netstat等工具去监控系统里的各个服务和组件是否正常运行,以及通过日志的信息(http access log / application log / database slow log )分析各个服务的性能瓶颈。

数据分区与扩容

下一步业务的调整要进行数据库的分区和扩容。第一,构建缓存集群,在开始的架构中引用了Memcached缓存,是单机数据库缓存。当数据量增长,,需要把数据分散到多台缓存服务器上,常用的是HashRing算法,好处在于不管是添加结点还是删除结点时,只会使得少部分数据失效。还可以引用NoSQL数据库,这里用到了Redis把社交数据里对于关系要求不强但对查询效率要求很高的数据从MySQL里拿到Redis里存。Redis尤其适合存储列表类数据,比如好友关系列表、排行榜数据等。

Linux:一个社交App是如何构建高伸缩性的交互式系统
Linux:一个社交App是如何构建高伸缩性的交互式系统

除此以外可以考虑做数据分区对于MySQL第一步是垂直拆分,把原来单独的数据库按照功能模块分别拆分成:好友新鲜事、用户资料、广告数据以及探索数据。对于Redis也同样,将原来的单台Redis按照功能模块拆成四个,分别为:排行榜数据、好友、广告数据、探索数据。

接下来会遇到的瓶颈是单表过大的问题,这时候我们需要做水平拆分——把一个表拆分成多个表,需要选取一个分区Key,比如对用户表做拆分时,通常选取User ID。分区key的选择主要是看所有的查询语句频繁使用哪个查询字段,就选择那个字段作为分区key这样能保证大部分的查询可以落在单个数据表上,少量没有带分区Key的查询语句,可能要遍历一遍所有切分后的数据表。

构建完整的测试环境

构建完整测试服务器时需要创建新的路由器和私有网络、独立的网络环境和带宽资源、内网GRE隧道打通路由器、VPN拨入网络和SSH密钥管理。

Linux:一个社交App是如何构建高伸缩性的交互式系统
Linux:一个社交App是如何构建高伸缩性的交互式系统

这个过程你可以创建一个包含所有系统服务的all-in-one的环境,将其制作成自有映像。如果后续你的团队来新的人,需要独立的完整开发环境,只需基于自有镜像快速创建主机即可;还可以利用User Data定制化功能,在主机启动执行一段你上传的脚本,来初始化环境。你可以将这两个功能结合起来用,把所有你所需要用的服务全部安装部署完毕后做成映像,并用User Data脚本从代码库里更新代码。因为代码的变动相对于环境的更新更加频繁,不可能每次代码的更新都要构建一个新的自有镜像。通过这种方式构建起一个完整的测试服务器,让每个工程师都可以有自己独立的测试服务器。

在App发布上线时需要连到线上环境怎么办?这两个网络本身完全100%隔离,可利用GRE隧道的功能,把两个路由器打通,实现测试环境网络和线上生产环境网络的完全连通。

多机房部署与混合组网

为了让后端架构更可靠和业务更稳定,就需要实施多机房部署和混合组网。具体原因有以下三点:

  • 异地容灾:在复杂的网络环境下,机房可能会出现网络状况,导致一些比较关键性的业务的可用性降低,备份机房后可保证服务不会出现明显的长时间中断;
  • 负载分摊:单独一个机房可能不足以支撑全部的请求,这时可以把一部分的请求压力分担到另一个机房;
  • 加速区域访问:在国内网络环境下,南方和北方相互之间网络访问时有较高的延迟。通过做多机房部署实现加速区域用户的访问。 
Linux:一个社交App是如何构建高伸缩性的交互式系统
Linux:一个社交App是如何构建高伸缩性的交互式系统

如上所示,有三个机房,中间是QingCloud北京1区机房,负责主营业务。左边是亚太1区机房,主要服务亚太和海外的客户。这两个机房都使用了QingCloud私有网络部署,利用路由器,通过GRE隧道或者IPsec加密隧道的方式进行互通。如果对数据传输过程的安全性要求较高,可以用IPsec的方式把两个机房相互打通,这时的访问只能通过内网IP进行访问。右边是办公室机房,工程师在这个环境下进行开发。

在实现混合组网时,只要机房路由器或者网宽设备支持标准的GRE隧道协议、IP隧道协议,就可以将传统物理世界的机房与路由器连通,并最终打通公有云环境。多机房部署通常见的方案有这些:

异地冷备份

把主机房全套业务在异地重新构建一遍,且不需要提供线上服务,只有在主机房出现故障的时候才切换到备用机房,部署相对要简单一些。但有两方面缺点,一是成本比较高,需要双倍的费用且只是用来做冷备份,平时完全用不上;另外,当主机房突然挂掉时,备用机房再起动起来提供服务,数据需要预热,这是非常缓慢的过程,可能会出现服务响应慢,甚至不能正常提供服务。

异地多活

从易到难有三阶段:第一,反向代理,用户请求到第二个机房,但不做任何处理被转向第一个机房这样会对两地的延时有一定的要求。第二,在第二个机房部署应用服务器和缓存,大部分的数据请求可以从缓存中读取,不用进行跨机房请求,但当缓存失效时,依然落到第一个机房的数据库去查询。所以,这个方式不太彻底;第三,全套服务的部署,包括HTTP服务器、业务服务器、缓存和数据库的 slave。此方式使得进入第二个机房的请求,只需要在机房内就可以完成请求处理,速度更快,但会遇到数据一致性和缓存一致性的问题,针对这点也会有一些解决方法。除了数据同步过程中的不一致问题,还需要面对缓存。

好的系统架构不是设计出来的,而是进化而来的

构建稳定可靠的业务系统需要注意以下这些: 

  • 分析用户行为,理解你的业务,如社交、电商、视频;

不同的业务有不同的行业属性和特点,对于社交来讲,比较典型的特点是数据量庞大、数据查询维度多,比如查询6月11日-7月15日在xx咖啡厅我所有好友里拍过照片的人,查询条件包括好友维度、照片维度、地点维度、隐私状态维度等,这时就需要合理的做数据层面的扩展。

电商的特点是定期举办大促销活动,届时会需要大量的计算资源、应用服务器来扛流量峰值,此时可利用云计算平台的弹性实现快速扩展业务,而在自己业务压力、促销来临时调用API接口,及AutoScaling扩展后端计算资源。视频业务有非常明显的流量高峰期和低峰期,流量高峰期通常是白天或者大家晚上下班回家那段时间,晚上2点到早上6点是流量非常低的时候,可利用云计算弹性优势,来调用API方式调整业务带宽资源,从而达到节省成本目的。

  • 合理规划系统,预估系统容量,如 10w / 100w / 1000w PV(DAU):不同的系统容量有可能对应不同架构的部署方式,找到最适合自己的那一个;
  • 系统是可横向扩展的 scalable;
  • 不遗余力地解决单点问题;
  • 为出错而设计design for failure:App的后端架构在开发支出就要为可能出现的各种问题进行准备,比如异地备份等;
  • 设计面向服务的架构,拆分子系统,API交互,异步处理;
  • 构建无处不在的缓存:页面缓存、接口缓存、对象缓存、数据库缓存;
  • 避免过度设计,好的系统架构不是设计出来的,而是进化而来的。

来源:http://www.csdn.net/article/2015-07-12/2825185

Linux:Linux 运维工程师的十个基本技能点

本人是linux运维工程师,对这方面有点心得,现在我说说要掌握哪方面的工具吧。

说到工具,在行外可以说是技能,在行内我们一般称为工具,就是运维必须要掌握的工具。我就大概列出这几方面,这样入门就基本没问题了。

Linux系统如果是学习可以选用RedHat或CentOS,特别是CentOS在企业中用得最多。当然还会有其它版本的,但学习者还是以这2个版本学习就行,因为这两个版本都是兄弟,没区别的,有空可以再研究一下SUSE,有些公司也喜欢用,例如我公司 。

工具如下:

Linux:Linux 运维工程师的十个基本技能点
Linux:Linux 运维工程师的十个基本技能点

1、linux系统基础

这个不用说了,是基础中的基础,连这个都不会就别干了,参考书籍,可以看鸟哥linux基础篇,至少要掌握这书60%内容,没必须全部掌握,但基本命令总得会吧。

2、网络服务

服务有很多种,每间公司都会用到不同的,但基础的服务肯定要掌握,如FTP, DNS,SAMBA, 邮件, 这几个大概学一下就行。

LAMP和LNMP是必须要熟练,我所指的不是光会搭建,而是要很熟悉里面的相当配置才行,因为公司最关键的绝对是WEB服务器,所以nginx和apache要熟悉,特别是nginx一定要很熟悉才行。有些公司还会用tomcat,这个也最好学一下。

其实网络服务方面不用太担心,一般公司的环境都已经搭建好,就算有新服务器或让你整改,公司会有相应的文档让你参照来弄,不会让你乱来的,但至少相关的配置一定要学熟,而且肯定是编译安装多,那些模块要熟悉一下他的作用,特别是PHP那些模块。

这面2点只是基础,也是必要条件,不能说是工具,下以才是真正的要掌握的工具。

3、shell脚本和另一个脚本语言

shell是运维人员必须具备的,不懂这个连入职都不行,至少也要写出一些系统管理脚本,最简单也得写个监控CPU,内存比率的脚本吧,这是最最最基本了。别以为会写那些猜数字和计算什么数的,这些没什么作用,只作学习意义,写系统脚本才是最有意义。

而另一个脚本语言是可选的,一般是3P,即Python,Perl和PHP,PHP就不需要考虑了,除非你要做开发,我个人建议学Python会比较好,不难实现自动化运维,Perl是文本处理很强大,反正这两个学一个就行了。

4、sed和awk工具

必须要掌握,在掌握这两个工具同时,还要掌握正则表达式,这个就痛苦了,正则是最难学的表达式,但结合到sed和awk中会很强大,在处理文本内容和过滤WEB内容时十分有用,不过在学shell的同时一般会经常结合用到的,所以学第3点就会顺便学第4点。

5、文本处理命令

sort , tr , cut, paste, uniq, tee等,必学,也是结合第3点时一并学习的。

6、数据库

首选MySQL,别问我为什么不学SQL Server和Oracle,因为Linux用得最多绝对是MySQL。增删改查必学,特别要学熟查,其它方面可能不太需要,因为运维人员使用最多还是查,哪些优化和开发语句不会让你弄的。

7、防火墙

不学不行,防火墙也算是个难点,说难不难,说易不易,最重要弄懂规则。如果学过CCNA的朋友可能会比较好学,因为iptables也有NAT表,原理是一样的,而Filter表用得最多,反正不学就肯定不合格。

8、监控工具

十分十分重要,我个人建议,最好学这3个,cacti,nagios,zabbix。企业用得最多应该是nagios和 zabbix,反正都学吧,但nagios会有点难,因为会涉及到用脚本写自动监控,那个地方很难。

9、集群和热备

这个很重要,肯定要懂的,但到了公司就不会让你去弄,因为新手基本不让你碰。集群工具有很多,最好学是LVS,这是必学,最好也学学nginx集群,反向代理。还有热备,这个就更多工具能实现了,像我公司是自己开发热备工具的,MySQL热备也要学,就是主从复制,这个别告诉我容易,其实不容易的,要学懂整个流程一点也不容易,只照着做根本没意思。

10、数据备份

不学不行,工具有很多,但至少要把RAID的原理弄懂,特别是企业最常用的1+0或0+1,自己做实验也要弄出来,备份工具有很多,如tar, dump, rsync等,最好多了解一下。

算了,说到这10点已经够你受了,应该可以入门了,因为有些技术会比较难学。例如apache和nginx中还有些很重要的技术,如系统调优和服务优化,还有程序优化,这些在没接触工作前很难学习到的,所以先把这10点学了吧。估计要学熟至少3个月不止,就脚本那部分已经让你很吃力了。我建议是先学熟shell,等工作后再学另一门脚本语言,这样会比较好。以上就是踏入linux运维工程师需要掌握的工具,其实还有很多工具要掌握的,但你在学习环境中是很难学到,最后我再提醒一下,这里所指的工具相当于技能,而不是像windows或ubuntu那些图形化工具,那些工具没用的,还有,学linux就别装图形界面,这样虚拟机就不用吃太多内存,而且绝对不建议在真机上装linux,根本达不到学习效果。

来源:http://bbs.51cto.com/thread-1087414-1.html

Linux:深入 NGINX: 我们如何设计性能和扩展

NGINX 能在 web 性能中取得领先地位,这是由于其软件设计所决定的。许多 web 服务器和应用程序服务器使用一个简单的基于线程或进程的架构,NGINX 立足于一个复杂的事件驱动的体系结构,使它能够在现代硬件上扩展到成千上万的并发连接。

下面这张深入 NGINX 的信息图从高层次的进程架构上深度挖掘说明了 NGINX 如何在单一进程里保持多个连接。这篇博客进一步详细地解释了这一切是如何工作的。

Linux:深入 NGINX: 我们如何设计性能和扩展
Linux:深入 NGINX: 我们如何设计性能和扩展

知识 – NGINX 进程模型

Linux:深入 NGINX: 我们如何设计性能和扩展
Linux:深入 NGINX: 我们如何设计性能和扩展

为了更好的理解这个设计,你需要理解 NGINX 如何运行的。NGINX 有一个主进程(它执行特权操作,如读取配置和绑定端口)和一些工作进程与辅助进程。

# service nginx restart
* Restarting nginx
# ps -ef --forest | grep nginx
root     32475     1  0 13:36 ?        00:00:00 nginx: master process /usr/sbin/nginx
                                                -c /etc/nginx/nginx.conf
nginx    32476 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32477 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32479 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32480 32475  0 13:36 ?        00:00:00  _ nginx: worker process
nginx    32481 32475  0 13:36 ?        00:00:00  _ nginx: cache manager process
nginx    32482 32475  0 13:36 ?        00:00:00  _ nginx: cache loader process

在四核服务器,NGINX 主进程创建了4个工作进程和两个管理磁盘内容缓存的缓存辅助进程。

为什么架构很重要?

任何 Unix 应用程序的根本基础是线程或进程。(从 Linux 操作系统的角度来看,线程和进程大多是相同的,主要的区别是他们共享内存的程度。)一个线程或进程是一个自包含的指令集,操作系统可以在一个 CPU 核心上调度运行它们。大多数复杂的应用程序并行运行多个线程或进程有两个原因:

  • 它们可以同时使用更多的计算核心。
  • 线程或进程可以轻松实现并行操作。(例如,在同一时刻保持多连接)。

进程和线程消耗资源。他们每个都使用内存和其他系统资源,他们会在 CPU 核心中换入和换出(这个操作叫做上下文切换)。大多数现代服务器可以并行保持上百个小型的、活动的线程或进程,但是一旦内存耗尽或高 I/O 压力引起大量的上下文切换会导致性能严重下降。

网络应用程序设计的常用方法是为每个连接分配一个线程或进程。此体系结构简单、容易实现,但是当应用程序需要处理成千上万的并发连接时这种结构就不具备扩展性。

NGINX 如何工作?

NGINX 使用一种可预测的进程模式来分配可使用的硬件资源:

  • 主进程(master)执行特权操作,如读取配置和绑定端口,然后创建少量的子进程(如下的三种类型)。
  • 缓存加载器进程(cache loader)在加载磁盘缓存到内存中时开始运行,然后退出。适当的调度,所以其资源需求很低。
  • 缓存管理器进程(cache manager)定期裁剪磁盘缓存中的记录来保持他们在配置的大小之内。
  • 工作进程(worker)做所有的工作!他们保持网络连接、读写内容到磁盘,与上游服务器通信。

在大多数情况下 NGINX 的配置建议:每个 CPU 核心运行一个工作进程,这样最有效地利用硬件资源。你可以在配置中包含 worker_processes auto指令配置:


1
worker_processes auto;

当一个 NGINX 服务处于活动状态,只有工作进程在忙碌。每个工作进程以非阻塞方式保持多连接,以减少上下文交换。

每个工作进程是一个单一线程并且独立运行,它们会获取新连接并处理之。这些进程可以使用共享内存通信来共享缓存数据、会话持久性数据及其它共享资源。(在 NGINX 1.7.11 及其以后版本,还有一个可选的线程池,工作进程可以转让阻塞的操作给它。更多的细节,参见“NGINX 线程池可以爆增9倍性能!”。对于 NGINX Plus 用户,该功能计划在今年晚些时候加入到 R7 版本中。)

NGINX 工作进程内部

Linux:深入 NGINX: 我们如何设计性能和扩展
Linux:深入 NGINX: 我们如何设计性能和扩展

每个 NGINX 工作进程按照 NGINX 配置初始化,并由主进程提供一组监听端口。

NGINX 工作进程首先在监听套接字上等待事件(accept_mutex内核套接字分片)。事件被新进来的连接初始化。这些连接被分配到一个状态机 – HTTP 状态机是最常用的,但 NGINX 也实现了流式(原始 TCP )状态机和几种邮件协议(SMTP、IMAP和POP3)的状态机。

Linux:深入 NGINX: 我们如何设计性能和扩展
Linux:深入 NGINX: 我们如何设计性能和扩展

状态机本质上是一组指令,告诉 NGINX 如何处理一个请求。大多数 web 服务器像 NGINX 一样使用类似的状态机来实现相同的功能 – 区别在于实现。

调度状态机

把状态机想象成国际象棋的规则。每个 HTTP 事务是一个象棋游戏。一方面棋盘是 web 服务器 —— 一位大师可以非常迅速地做出决定。另一方面是远程客户端 —— 在一个相对较慢的网络下 web 浏览器访问网站或应用程序。

不管怎样,这个游戏规则很复杂。例如,web 服务器可能需要与各方沟通(代理一个上游的应用程序)或与身份验证服务器对话。web 服务器的第三方模块甚至可以扩展游戏规则。

一个阻塞状态机

回忆我们之前的描述,一个进程或线程就像一套独立的指令集,操作系统可以在一个 CPU 核心上调度运行它。大多数 web 服务器和 web 应用使用每个连接一个进程或者每个连接一个线程的模式来玩这个“象棋游戏”。每个进程或线程都包含玩完“一个游戏”的指令。在服务器运行该进程的期间,其大部分的时间都是“阻塞的” —— 等待客户端完成它的下一步行动。

Linux:深入 NGINX: 我们如何设计性能和扩展
Linux:深入 NGINX: 我们如何设计性能和扩展
  1. web 服务器进程在监听套接字上监听新连接(客户端发起新“游戏”)
  2. 当它获得一个新游戏,就玩这个游戏,每走一步去等待客户端响应时就阻塞了。
  3. 游戏完成后,web 服务器进程可能会等待是否有客户机想要开始一个新游戏(这里指的是一个“保持的”连接)。如果这个连接关闭了(客户端断开或者发生超时),web 服务器进程会返回并监听一个新“游戏”。

要记住最重要的一点是每个活动的 HTTP 连接(每局棋)需要一个专用的进程或线程(象棋高手)。这个结构简单容并且易扩展第三方模块(“新规则”)。然而,还是有巨大的不平衡:尤其是轻量级 HTTP 连接其实就是一个文件描述符和小块内存,映射到一个单独的线程或进程,这是一个非常重量级的系统对象。这种方式易于编程,但太过浪费。

NGINX是一个真正的象棋大师

也许你听过车轮表演赛游戏,有一个象棋大师同时对战许多对手?

Linux:深入 NGINX: 我们如何设计性能和扩展
Linux:深入 NGINX: 我们如何设计性能和扩展

列夫·吉奥吉夫在保加利亚的索非亚同时对阵360人。他的最终成绩是284胜70平6负。

这就是 NGINX 工作进程如何“下棋”的。每个工作进程(记住 – 通常每个CPU核心上有一个工作进程)是一个可同时对战上百人(事实是,成百上千)的象棋大师。

Linux:深入 NGINX: 我们如何设计性能和扩展
Linux:深入 NGINX: 我们如何设计性能和扩展
  1. 工作进程在监听和连接套接字上等待事件。
  2. 事件发生在套接字上,并且由工作进程处理它们:
    • 在监听套接字的事件意味着一个客户端已经开始了一局新棋局。工作进程创建了一个新连接套接字。
    • 在连接套接字的事件意味着客户端已经下了一步棋。工作进程及时响应。

一个工作进程在网络流量上从不阻塞,等待它的“对手”(客户端)做出反应。当它下了一步,工作进程立即继续其他的游戏,在那里工作进程正在处理下一步,或者在门口欢迎一个新玩家。

为什么这个比阻塞式多进程架构更快?

NGINX 每个工作进程很好的扩展支撑了成百上千的连接。每个连接在工作进程中创建另外一个文件描述符和消耗一小部分额外内存。每个连接有很少的额外开销。NGINX 进程可以固定在某个 CPU 上。上下文交换非常罕见,一般只发生在没有工作要做时。

在阻塞方式,每个进程一个连接的方法中,每个连接需要大量额外的资源和开销,并且上下文切换(从一个进程切换到另一个)非常频繁。

更详细的解释,看看这篇关于 NGINX 架构的文章,它由NGINX公司开发副总裁及共同创始人 Andrew Alexeev 写的。

通过适当的系统优化,NGINX 的每个工作进程可以扩展来处理成千上万的并发 HTTP 连接,并能脸不红心不跳的承受峰值流量(大量涌入的新“游戏”)。

更新配置和升级 NGINX

NGINX 的进程体系架构使用少量的工作进程,有助于有效的更新配置文件甚至 NGINX 程序本身。

Linux:深入 NGINX: 我们如何设计性能和扩展
Linux:深入 NGINX: 我们如何设计性能和扩展

更新 NGINX 配置文件是非常简单、轻量、可靠的操作。典型的就是运行命令

1
nginx –s reload

,所做的就是检查磁盘上的配置并发送 SIGHUP 信号给主进程。

当主进程接收到一个 SIGHUP 信号,它会做两件事:

  • 重载配置文件和分支出一组新的工作进程。这些新的工作进程立即开始接受连接和处理流量(使用新的配置设置)
  • 通知旧的工作进程优雅的退出。工作进程停止接受新的连接。当前的 http 请求一旦完成,工作进程就彻底关闭这个连接(那就是,没有残存的“保持”连接)。一旦所有连接关闭,这个工作进程就退出。

这个重载过程能引发一个 CPU 和内存使用的小峰值,但是跟活动连接加载的资源相比它一般不易察觉。每秒钟你可以多次重载配置(很多 NGINX 用户都这么做)。非常罕见的情况下,有很多世代的工作进程等待关闭连接时会发生问题,但即使是那样也很快被解决了。

NGINX 的程序升级过程中拿到了高可用性圣杯 —— 你可以随时更新这个软件,不会丢失连接,停机,或者中断服务。

Linux:深入 NGINX: 我们如何设计性能和扩展
Linux:深入 NGINX: 我们如何设计性能和扩展

程序升级过程类似于平滑重载配置的方法。一个新的 NGINX 主进程与原主进程并行运行,然后他们共享监听套接字。两个进程都是活动的,并且各自的工作进程处理流量。然后你可以通知旧的主进程和它的工作进程优雅的退出。

整个过程的详细描述在 NGINX 管理

结论

深入 NGINX 信息图提供一个 NGINX 功能实现的高层面概览,但在这简单的解释的背后是超过十年的创新和优化,使得 NGINX 在广泛的硬件上提供尽可能最好的性能同时保持了现代 Web 应用程序所需要的安全性和可靠性。

如果你想阅读更多关于NGINX的优化,查看这些优秀的资源:


via: http://nginx.com/blog/inside-nginx-how-we-designed-for-performance-scale/

作者:Owen Garrett 译者:wyangsun 校对:wxy

本文由 LCTT 原创翻译,Linux中国 荣誉推出

来源:https://linux.cn/article-5681-1.html

Linux:NGINX引入线程池 性能提升9倍

1. 引言

正如我们所知,NGINX采用了异步、事件驱动的方法来处理连接。这种处理方式无需(像使用传统架构的服务器一样)为每个请求创建额外的专用进程或者线程,而是在一个工作进程中处理多个连接和请求。为此,NGINX工作在非阻塞的socket模式下,并使用了epoll 和 kqueue这样有效的方法。

因为满负载进程的数量很少(通常每核CPU只有一个)而且恒定,所以任务切换只消耗很少的内存,而且不会浪费CPU周期。通过NGINX本身的实例,这种方法的优点已经为众人所知。NGINX可以非常好地处理百万级规模的并发请求。

Linux:NGINX引入线程池 性能提升9倍
Linux:NGINX引入线程池 性能提升9倍

每个进程都消耗额外的内存,而且每次进程间的切换都会消耗CPU周期并丢弃CPU高速缓存中的数据。

但是,异步、事件驱动方法仍然存在问题。或者,我喜欢将这一问题称为“敌兵”,这个敌兵的名字叫阻塞(blocking)。不幸的是,很多第三方模块使用了阻塞调用,然而用户(有时甚至是模块的开发者)并不知道阻塞的缺点。阻塞操作可以毁掉NGINX的性能,我们必须不惜一切代价避免使用阻塞。

即使在当前官方的NGINX代码中,依然无法在全部场景中避免使用阻塞,NGINX1.7.11中实现的线程池机制解决了这个问题。我们将在后面讲述这个线程池是什么以及该如何使用。现在,让我们先和我们的“敌兵”进行一次面对面的碰撞。

2. 问题

首先,为了更好地理解这一问题,我们用几句话说明下NGINX是如何工作的。

通常情况下,NGINX是一个事件处理器,即一个接收来自内核的所有连接事件的信息,然后向操作系统发出做什么指令的控制器。实际上,NGINX干了编排操作系统的全部脏活累活,而操作系统做的是读取和发送字节这样的日常工作。所以,对于NGINX来说,快速和及时的响应是非常重要的。

Linux:NGINX引入线程池 性能提升9倍
Linux:NGINX引入线程池 性能提升9倍

工作进程监听并处理来自内核的事件

事件可以是超时、socket读写就绪的通知,或者发生错误的通知。NGINX接收大量的事件,然后一个接一个地处理它们,并执行必要的操作。因此,所有的处理过程是通过一个线程中的队列,在一个简单循环中完成的。NGINX从队列中取出一个事件并对其做出响应,比如读写socket。在多数情况下,这种方式是非常快的(也许只需要几个CPU周期,将一些数据复制到内存中),NGINX可以在一瞬间处理掉队列中的所有事件。

Linux:NGINX引入线程池 性能提升9倍
Linux:NGINX引入线程池 性能提升9倍

所有处理过程是在一个简单的循环中,由一个线程完成

但是,如果NGINX要处理的操作是一些又长又重的操作,又会发生什么呢?整个事件处理循环将会卡住,等待这个操作执行完毕。

因此,所谓“阻塞操作”是指任何导致事件处理循环显著停止一段时间的操作。操作可以由于各种原因成为阻塞操作。例如,NGINX可能因长时间、CPU密集型处理,或者可能等待访问某个资源(比如硬盘,或者一个互斥体,亦或要从处于同步方式的数据库获得相应的库函数调用等)而繁忙。关键是在处理这样的操作期间,工作进程无法做其他事情或者处理其他事件,即使有更多的可用系统资源可以被队列中的一些事件所利用。

我们来打个比方,一个商店的营业员要接待他面前排起的一长队顾客。队伍中的第一位顾客想要的某件商品不在店里而在仓库中。这位营业员跑去仓库把东西拿来。现在整个队伍必须为这样的配货方式等待数个小时,队伍中的每个人都很不爽。你可以想见人们的反应吧?队伍中每个人的等待时间都要增加这些时间,除非他们要买的东西就在店里。

Linux:NGINX引入线程池 性能提升9倍
Linux:NGINX引入线程池 性能提升9倍

队伍中的每个人不得不等待第一个人的购买

在NGINX中会发生几乎同样的情况,比如当读取一个文件的时候,如果该文件没有缓存在内存中,就要从磁盘上读取。从磁盘(特别是旋转式的磁盘)读取是很慢的,而当队列中等待的其他请求可能不需要访问磁盘时,它们也得被迫等待。导致的结果是,延迟增加并且系统资源没有得到充分利用。

Linux:NGINX引入线程池 性能提升9倍
Linux:NGINX引入线程池 性能提升9倍

一个阻塞操作足以显著地延缓所有接下来的操作

一些操作系统为读写文件提供了异步接口,NGINX可以使用这样的接口(见AIO指令)。FreeBSD就是个很好的例子。不幸的是,我们不能在Linux上得到相同的福利。虽然Linux为读取文件提供了一种异步接口,但是存在明显的缺点。其中之一是要求文件访问和缓冲要对齐,但NGINX很好地处理了这个问题。但是,另一个缺点更糟糕。异步接口要求文件描述符中要设置O_DIRECT标记,就是说任何对文件的访问都将绕过内存中的缓存,这增加了磁盘的负载。在很多场景中,这都绝对不是最佳选择。

为了有针对性地解决这一问题,在NGINX 1.7.11中引入了线程池。默认情况下,NGINX+还没有包含线程池,但是如果你想试试的话,可以联系销售人员,NGINX+ R6是一个已经启用了线程池的构建版本。

现在,让我们走进线程池,看看它是什么以及如何工作的。

3. 线程池

让我们回到那个可怜的,要从大老远的仓库去配货的售货员那儿。这回,他已经变聪明了(或者也许是在一群愤怒的顾客教训了一番之后,他才变得聪明的?),雇用了一个配货服务团队。现在,当任何人要买的东西在大老远的仓库时,他不再亲自去仓库了,只需要将订单丢给配货服务,他们将处理订单,同时,我们的售货员依然可以继续为其他顾客服务。因此,只有那些要买仓库里东西的顾客需要等待配货,其他顾客可以得到即时服务。

Linux:NGINX引入线程池 性能提升9倍
Linux:NGINX引入线程池 性能提升9倍

传递订单给配货服务不会阻塞队伍

对NGINX而言,线程池执行的就是配货服务的功能。它由一个任务队列和一组处理这个队列的线程组成。当工作进程需要执行一个潜在的长操作时,工作进程不再自己执行这个操作,而是将任务放到线程池队列中,任何空闲的线程都可以从队列中获取并执行这个任务。

Linux:NGINX引入线程池 性能提升9倍
Linux:NGINX引入线程池 性能提升9倍

工作进程将阻塞操作卸给线程池

那么,这就像我们有了另外一个队列。是这样的,但是在这个场景中,队列受限于特殊的资源。磁盘的读取速度不能比磁盘产生数据的速度快。不管怎么说,至少现在磁盘不再延误其他事件,只有访问文件的请求需要等待。

“从磁盘读取”这个操作通常是阻塞操作最常见的示例,但是实际上,NGINX中实现的线程池可用于处理任何不适合在主循环中执行的任务。

目前,卸载到线程池中执行的两个基本操作是大多数操作系统中的read()系统调用和Linux中的sendfile()。接下来,我们将对线程池进行测试(test)和基准测试(benchmark),在未来的版本中,如果有明显的优势,我们可能会卸载其他操作到线程池中。

4. 基准测试

现在让我们从理论过度到实践。我们将进行一次模拟基准测试(synthetic benchmark),模拟在阻塞操作和非阻塞操作的最差混合条件下,使用线程池的效果。

另外,我们需要一个内存肯定放不下的数据集。在一台48GB内存的机器上,我们已经产生了每文件大小为4MB的随机数据,总共256GB,然后配置NGINX,版本为1.9.0。

配置很简单:

worker_processes 16;

events {
    accept_mutex off;
}

http {
    include mime.types;
    default_type application/octet-stream;

    access_log off;
    sendfile on;
    sendfile_max_chunk 512k;

    server {
        listen 8000;

        location / {
            root /storage;
        }
    }
}

如上所示,为了达到更好的性能,我们调整了几个参数:禁用了loggingaccept_mutex,同时,启用了sendfile并设置了sendfile_max_chunk的大小。最后一个指令可以减少阻塞调用sendfile()所花费的最长时间,因为NGINX不会尝试一次将整个文件发送出去,而是每次发送大小为512KB的块数据。

这台测试服务器有2个Intel Xeon E5645处理器(共计:12核、24超线程)和10-Gbps的网络接口。磁盘子系统是由4块西部数据WD1003FBYX 磁盘组成的RAID10阵列。所有这些硬件由Ubuntu服务器14.04.1 LTS供电。

Linux:NGINX引入线程池 性能提升9倍
Linux:NGINX引入线程池 性能提升9倍

为基准测试配置负载生成器和NGINX

客户端有2台服务器,它们的规格相同。在其中一台上,在wrk中使用Lua脚本创建了负载程序。脚本使用200个并行连接向服务器请求文件,每个请求都可能未命中缓存而从磁盘阻塞读取。我们将这种负载称作随机负载。

在另一台客户端机器上,我们将运行wrk的另一个副本,使用50个并行连接多次请求同一个文件。因为这个文件将被频繁地访问,所以它会一直驻留在内存中。在正常情况下,NGINX能够非常快速地服务这些请求,但是如果工作进程被其他请求阻塞的话,性能将会下降。我们将这种负载称作恒定负载。

性能将由服务器上ifstat监测的吞吐率(throughput)和从第二台客户端获取的wrk结果来度量。

现在,没有使用线程池的第一次运行将不会带给我们非常振奋的结果:

% ifstat -bi eth2
eth2
Kbps in  Kbps out
5531.24  1.03e+06
4855.23  812922.7
5994.66  1.07e+06
5476.27  981529.3
6353.62  1.12e+06
5166.17  892770.3
5522.81  978540.8
6208.10  985466.7
6370.79  1.12e+06
6123.33  1.07e+06

如上所示,使用这种配置,服务器产生的总流量约为1Gbps。从下面所示的top输出,我们可以看到,工作进程的大部分时间花在阻塞I/O上(它们处于top的D状态):

top - 10:40:47 up 11 days,  1:32,  1 user,  load average: 49.61, 45.77 62.89
Tasks: 375 total,  2 running, 373 sleeping,  0 stopped,  0 zombie
%Cpu(s):  0.0 us,  0.3 sy,  0.0 ni, 67.7 id, 31.9 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem:  49453440 total, 49149308 used,   304132 free,    98780 buffers
KiB Swap: 10474236 total,    20124 used, 10454112 free, 46903412 cached Mem

  PID USER     PR  NI    VIRT    RES     SHR S  %CPU %MEM    TIME+ COMMAND
 4639 vbart    20   0   47180  28152     496 D   0.7  0.1  0:00.17 nginx
 4632 vbart    20   0   47180  28196     536 D   0.3  0.1  0:00.11 nginx
 4633 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.11 nginx
 4635 vbart    20   0   47180  28136     480 D   0.3  0.1  0:00.12 nginx
 4636 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.14 nginx
 4637 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.10 nginx
 4638 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.12 nginx
 4640 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.13 nginx
 4641 vbart    20   0   47180  28324     540 D   0.3  0.1  0:00.13 nginx
 4642 vbart    20   0   47180  28208     536 D   0.3  0.1  0:00.11 nginx
 4643 vbart    20   0   47180  28276     536 D   0.3  0.1  0:00.29 nginx
 4644 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.11 nginx
 4645 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.17 nginx
 4646 vbart    20   0   47180  28204     536 D   0.3  0.1  0:00.12 nginx
 4647 vbart    20   0   47180  28208     532 D   0.3  0.1  0:00.17 nginx
 4631 vbart    20   0   47180    756     252 S   0.0  0.1  0:00.00 nginx
 4634 vbart    20   0   47180  28208     536 D   0.0  0.1  0:00.11 nginx
 4648 vbart    20   0   25232   1956    1160 R   0.0  0.0  0:00.08 top
25921 vbart    20   0  121956   2232    1056 S   0.0  0.0  0:01.97 sshd
25923 vbart    20   0   40304   4160    2208 S   0.0  0.0  0:00.53 zsh

在这种情况下,吞吐率受限于磁盘子系统,而CPU在大部分时间里是空闲的。从wrk获得的结果也非常低:

Running 1m test @ http://192.0.2.1:8000/1/1/1
  12 threads and 50 connections
  Thread Stats   Avg    Stdev     Max  +/- Stdev
    Latency     7.42s  5.31s   24.41s   74.73%
    Req/Sec     0.15    0.36     1.00    84.62%
  488 requests in 1.01m, 2.01GB read
Requests/sec:      8.08
Transfer/sec:     34.07MB

请记住,文件是从内存送达的!第一个客户端的200个连接创建的随机负载,使服务器端的全部的工作进程忙于从磁盘读取文件,因此产生了过大的延迟,并且无法在合理的时间内处理我们的请求。

现在,我们的线程池要登场了。为此,我们只需在

1
location

块中添加aio threads指令:

location / {
    root /storage;
    aio threads;
}

接着,执行NGINX reload重新加载配置。

然后,我们重复上述的测试:

% ifstat -bi eth2
eth2
Kbps in  Kbps out
60915.19  9.51e+06
59978.89  9.51e+06
60122.38  9.51e+06
61179.06  9.51e+06
61798.40  9.51e+06
57072.97  9.50e+06
56072.61  9.51e+06
61279.63  9.51e+06
61243.54  9.51e+06
59632.50  9.50e+06

现在,我们的服务器产生的流量是9.5Gbps,相比之下,没有使用线程池时只有约1Gbps!

理论上还可以产生更多的流量,但是这已经达到了机器的最大网络吞吐能力,所以在这次NGINX的测试中,NGINX受限于网络接口。工作进程的大部分时间只是休眠和等待新的时间(它们处于top的S状态):

top - 10:43:17 up 11 days,  1:35,  1 user,  load average: 172.71, 93.84, 77.90
Tasks: 376 total,  1 running, 375 sleeping,  0 stopped,  0 zombie
%Cpu(s):  0.2 us,  1.2 sy,  0.0 ni, 34.8 id, 61.5 wa,  0.0 hi,  2.3 si,  0.0 st
KiB Mem:  49453440 total, 49096836 used,   356604 free,    97236 buffers
KiB Swap: 10474236 total,    22860 used, 10451376 free, 46836580 cached Mem

  PID USER     PR  NI    VIRT    RES     SHR S  %CPU %MEM    TIME+ COMMAND
 4654 vbart    20   0  309708  28844     596 S   9.0  0.1  0:08.65 nginx
 4660 vbart    20   0  309748  28920     596 S   6.6  0.1  0:14.82 nginx
 4658 vbart    20   0  309452  28424     520 S   4.3  0.1  0:01.40 nginx
 4663 vbart    20   0  309452  28476     572 S   4.3  0.1  0:01.32 nginx
 4667 vbart    20   0  309584  28712     588 S   3.7  0.1  0:05.19 nginx
 4656 vbart    20   0  309452  28476     572 S   3.3  0.1  0:01.84 nginx
 4664 vbart    20   0  309452  28428     524 S   3.3  0.1  0:01.29 nginx
 4652 vbart    20   0  309452  28476     572 S   3.0  0.1  0:01.46 nginx
 4662 vbart    20   0  309552  28700     596 S   2.7  0.1  0:05.92 nginx
 4661 vbart    20   0  309464  28636     596 S   2.3  0.1  0:01.59 nginx
 4653 vbart    20   0  309452  28476     572 S   1.7  0.1  0:01.70 nginx
 4666 vbart    20   0  309452  28428     524 S   1.3  0.1  0:01.63 nginx
 4657 vbart    20   0  309584  28696     592 S   1.0  0.1  0:00.64 nginx
 4655 vbart    20   0  30958   28476     572 S   0.7  0.1  0:02.81 nginx
 4659 vbart    20   0  309452  28468     564 S   0.3  0.1  0:01.20 nginx
 4665 vbart    20   0  309452  28476     572 S   0.3  0.1  0:00.71 nginx
 5180 vbart    20   0   25232   1952    1156 R   0.0  0.0  0:00.45 top
 4651 vbart    20   0   20032    752     252 S   0.0  0.0  0:00.00 nginx
25921 vbart    20   0  121956   2176    1000 S   0.0  0.0  0:01.98 sshd
25923 vbart    20   0   40304   3840    2208 S   0.0  0.0  0:00.54 zsh

如上所示,基准测试中还有大量的CPU资源剩余。

wrk的结果如下:

Running 1m test @ http://192.0.2.1:8000/1/1/1
  12 threads and 50 connections
  Thread Stats   Avg      Stdev     Max  +/- Stdev
    Latency   226.32ms  392.76ms   1.72s   93.48%
    Req/Sec    20.02     10.84    59.00    65.91%
  15045 requests in 1.00m, 58.86GB read
Requests/sec:    250.57
Transfer/sec:      0.98GB

服务器处理4MB文件的平均时间从7.42秒降到226.32毫秒(减少了33倍),每秒请求处理数提升了31倍(250 vs 8)!

对此,我们的解释是请求不再因为工作进程被阻塞在读文件,而滞留在事件队列中,等待处理,它们可以被空闲的进程处理掉。只要磁盘子系统能做到最好,就能服务好第一个客户端上的随机负载,NGINX可以使用剩余的CPU资源和网络容量,从内存中读取,以服务于上述的第二个客户端的请求。

5. 依然没有银弹

在抛出我们对阻塞操作的担忧并给出一些令人振奋的结果后,可能大部分人已经打算在你的服务器上配置线程池了。先别着急。

实际上,最幸运的情况是,读取和发送文件操作不去处理缓慢的硬盘驱动器。如果我们有足够多的内存来存储数据集,那么操作系统将会足够聪明地在被称作“页面缓存”的地方,缓存频繁使用的文件。

“页面缓存”的效果很好,可以让NGINX在几乎所有常见的用例中展示优异的性能。从页面缓存中读取比较快,没有人会说这种操作是“阻塞”。而另一方面,卸载任务到一个线程池是有一定开销的。

因此,如果内存有合理的大小并且待处理的数据集不是很大的话,那么无需使用线程池,NGINX已经工作在最优化的方式下。

卸载读操作到线程池是一种适用于非常特殊任务的技术。只有当经常请求的内容的大小,不适合操作系统的虚拟机缓存时,这种技术才是最有用的。至于可能适用的场景,比如,基于NGINX的高负载流媒体服务器。这正是我们已经模拟的基准测试的场景。

我们如果可以改进卸载读操作到线程池,将会非常有意义。我们只需要知道所需的文件数据是否在内存中,只有不在内存中时,读操作才应该卸载到一个单独的线程中。

再回到售货员那个比喻的场景中,这回,售货员不知道要买的商品是否在店里,他必须要么总是将所有的订单提交给配货服务,要么总是亲自处理它们。

人艰不拆,操作系统缺少这样的功能。第一次尝试是在2010年,人们试图将这一功能添加到Linux作为fincore()系统调用,但是没有成功。后来还有一些尝试,是使用RWF_NONBLOCK标记作为preadv2()系统调用来实现这一功能(详情见LWN.net上的非阻塞缓冲文件读取操作异步缓冲读操作)。但所有这些补丁的命运目前还不明朗。悲催的是,这些补丁尚没有被内核接受的主要原因,貌似是因为旷日持久的撕逼大战(bikeshedding)。

另一方面,FreeBSD的用户完全不必担心。FreeBSD已经具备足够好的读文件取异步接口,我们应该用这个接口而不是线程池。

6. 配置线程池

所以,如果你确信在你的场景中使用线程池可以带来好处,那么现在是时候深入了解线程池的配置了。

线程池的配置非常简单、灵活。首先,获取NGINX 1.7.11或更高版本的源代码,使用

1
--with-threads

配置参数编译。在最简单的场景中,配置看起来很朴实。我们只需要在

1
http

、 

1
server

,或者

1
location

上下文中包含aio threads指令即可:

aio threads;

这是线程池的最简配置。实际上的精简版本示例如下:

thread_pool default threads=32 max_queue=65536;
aio threads=default;

这里定义了一个名为“default”,包含32个线程,任务队列最多支持65536个请求的线程池。如果任务队列过载,NGINX将输出如下错误日志并拒绝请求:

thread pool "NAME" queue overflow: N tasks waiting

错误输出意味着线程处理作业的速度有可能低于任务入队的速度了。你可以尝试增加队列的最大值,但是如果这无济于事,那么这说明你的系统没有能力处理如此多的请求了。

正如你已经注意到的,你可以使用thread_pool指令,配置线程的数量、队列的最大值,以及线程池的名称。最后要说明的是,可以配置多个独立的线程池,将它们置于不同的配置文件中,用做不同的目的:

http {
    thread_pool one threads=128 max_queue=0;
    thread_pool two threads=32;

    server {
        location /one {
            aio threads=one;
        }

        location /two {
            aio threads=two;
        }
    }
…
}

如果没有指定

1
max_queue

参数的值,默认使用的值是65536。如上所示,可以设置

1
max_queue

为0。在这种情况下,线程池将使用配置中全部数量的线程,尽可能地同时处理多个任务;队列中不会有等待的任务。

现在,假设我们有一台服务器,挂了3块硬盘,我们希望把该服务器用作“缓存代理”,缓存后端服务器的全部响应信息。预期的缓存数据量远大于可用的内存。它实际上是我们个人CDN的一个缓存节点。毫无疑问,在这种情况下,最重要的事情是发挥硬盘的最大性能。

我们的选择之一是配置一个RAID阵列。这种方法毁誉参半,现在,有了NGINX,我们可以有其他的选择:

# 我们假设每块硬盘挂载在相应的目录中:/mnt/disk1、/mnt/disk2、/mnt/disk3

proxy_cache_path /mnt/disk1 levels=1:2 keys_zone=cache_1:256m max_size=1024G
                 use_temp_path=off;
proxy_cache_path /mnt/disk2 levels=1:2 keys_zone=cache_2:256m max_size=1024G
                 use_temp_path=off;
proxy_cache_path /mnt/disk3 levels=1:2 keys_zone=cache_3:256m max_size=1024G
                 use_temp_path=off;

thread_pool pool_1 threads=16;
thread_pool pool_2 threads=16;
thread_pool pool_3 threads=16;

split_clients $request_uri $disk {
    33.3%     1;
    33.3%     2;
    *         3;
}

location / {
    proxy_pass http://backend;
    proxy_cache_key $request_uri;
    proxy_cache cache_$disk;
    aio threads=pool_$disk;
    sendfile on;
}

在这份配置中,使用了3个独立的缓存,每个缓存专用一块硬盘,另外,3个独立的线程池也各自专用一块硬盘。

缓存之间(其结果就是磁盘之间)的负载均衡使用split_clients模块,

1
split_clients

非常适用于这个任务。

在 proxy_cache_path指令中设置

1
use_temp_path=off

,表示NGINX会将临时文件保存在缓存数据的同一目录中。这是为了避免在更新缓存时,磁盘之间互相复制响应数据。

这些调优将带给我们磁盘子系统的最大性能,因为NGINX通过单独的线程池并行且独立地与每块磁盘交互。每块磁盘由16个独立线程和读取和发送文件专用任务队列提供服务。

我敢打赌,你的客户喜欢这种量身定制的方法。请确保你的磁盘也持有同样的观点。

这个示例很好地证明了NGINX可以为硬件专门调优的灵活性。这就像你给NGINX下了一道命令,让机器和数据用最佳姿势来搞基。而且,通过NGINX在用户空间中细粒度的调优,我们可以确保软件、操作系统和硬件工作在最优模式下,尽可能有效地利用系统资源。

7. 总结

综上所述,线程池是一个伟大的功能,将NGINX推向了新的性能水平,除掉了一个众所周知的长期危害——阻塞——尤其是当我们真正面对大量内容的时候。

甚至,还有更多的惊喜。正如前面提到的,这个全新的接口,有可能没有任何性能损失地卸载任何长期阻塞操作。NGINX在拥有大量的新模块和新功能方面,开辟了一方新天地。许多流行的库仍然没有提供异步非阻塞接口,此前,这使得它们无法与NGINX兼容。我们可以花大量的时间和资源,去开发我们自己的无阻塞原型库,但这么做始终都是值得的吗?现在,有了线程池,我们可以相对容易地使用这些库,而不会影响这些模块的性能。

来源:http://www.infoq.com/cn/articles/thread-pools-boost-performance-9x