nginx http fastcgi_记一次HttpDns业务调优——fastcgi-cache容量提升5倍

这是最近的一次优化，我想以一个小计划的形式来分享一下优化过程。

一、业务介绍

公司内部调用该服务，本质上是一个以http形式提供域名解析服务的系统。用户连接业务时，首先通过服务获取IP地址列表，然后通过获取的IP列表连接到对应的服务器，解决了域名劫持和连接降级的问题。

服务采用nginx+后端的体系结构。后端是开发同学用C++写的。前端和后端通过协议进行通信。单机QPS通常在7k左右，高峰期达到10000以上。

2、遇到问题

业务高峰期QPS达到万以上，服务中出现大量502，尤其是鹿谷机房，拒绝服务。生意一时基本没法做。我尝试通过nginx limit来限制，但是效果不是很好。大量用户被封锁。如果砍掉的话，现有用户还是会有很多502的，所以只有两个办法，扩大容量，想办法优化。

3.分析问题

Nginx 本身是一个非阻塞模型。万级QPS对nginx本身压力不大。经过分析，发现很大的原因是me大了，也就是说后端C++慢了，所以怀疑后端已经到了。和开发同学一起分析日志后确定了业务瓶颈。开发同学立即提出了加机器的要求。

作为运维，继续分析是否可以通过运维手段做一些优化。该服务的本质是客户端发起http请求，然后服务返回一个IP地址列表。这个列表会根据不同的URL参数而变化，但同时一个参数在1分钟内发生变化的可能性基本不存在。然后跟开发确认业务逻辑，不依赖ua、等额外参数进行业务处理。开发同学表示这个缓存方案1分钟绝对没有问题。

4.解决问题

好了，现在我有了一个方向性的模糊想法，那就是是否可以使用nginx缓存。这是一个非常熟悉的领域。结合内存的使用，根据之前的业务经验，根据命中率，能够起到非常好的优化效果，性能可能会暴涨。即使命中率很低，每次命中你仍然可以获得一分。立即采取行动进行测试。

看nginx的配置文件，遇到的第一个问题就是前后端没有用来互相通信，也就是说最常用的直接使用是不可行的，之前用的最多且成熟的就是这个，然后我想添加一个，引入多个端口也是之前常用的解决方案。这样做的缺点是增加了nginx的复杂度。这是唯一的方法，并且可以用作基本解决方案。继续分析，通信其实是有-cache的。虽然很少使用，但是可以测试一下。

研究机器的内存使用情况。拿出5G内存来做缓存是绝对没问题的，一分钟的内容5G可能都无法存储。至少资源够用。然后百度一下找到各个参数的配置含义。反复配置、测试，最终形成可用的配置。将缓存的数据放到/dev/shm中，然后进行灰度化。效果非常明显。根据后端计算，基础单机容量可提升5倍。这是几张照片。图片：

对应服务器内存的消耗，一个小想法也得到了证实，如下：

5、优化效果

通过消耗小于200M内存的服务器资源，达到75%~80%的命中率，机器性能可提升5倍以上。本次优化主要实现了以下效果

1、节省服务器资源，后端渗透率降低至1/5，容量提升5倍，节省大量服务器；

2.减轻了后端C++的压力，后端对每台服务器的请求基本减少到原来的1/5；

3、起到消峰作用，高峰期后端请求量不会波动，不会有压力；

4、对于错误5xx的降级，一旦后端发生错误，nginx会返回最新的缓存结果给用户，用户仍然可以获得解析列表，如下图所示。