记一次容量提升5倍的HttpDns业务Cache调优

本文主要介绍了HttpDns业务Cache调优的相关问题及解决办法。

 

这是最近做的一次业务优化，以一个小方案的形式分享一下优化过程。

 

业务简介

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

 

Resolver服务采用nginx+后端的系统结构，后端是开发同学用c++自写，前后端通过fastcgi协议进行通信，平时单机的QPS在7k左右，高峰期达到1万以上。

 

遇到问题

业务到高峰期QPS达到1万以上，服务出现大量502特别是鲁谷机房，进而拒绝服务，业务瞬间基本属于不可用的状态，不可用瞬间用户自动降级走DNS解析，尝试通过nginx的limit来限制解决，效果不好，大量用户被切掉，存量用户还是有很多的502，所以只有扩容和想办法优化两条路可走。

 

分析问题

Nginx本身是一种非堵塞的模型，1万级别的QPS对于nginx本身的压力很小，分析后发现request_time大的原因在于upstream_response_time大，那就是说后端c++的慢了，所以怀疑是后端到达了业务瓶颈，与开发同学分析日志后确定了这个结论，开发同学第一时间提出了加机器的要求。

 

作为运维，是需要继续分析是否可以通过运维手段做一些优化，此服务的本质是用户端发起一个http请求，然后服务返回一个ip地址列表，这个列表会根据不同的url参数有所变化，但同一个参数在1分钟内变化的可能性基本没有，进而与开发确认业务逻辑，在业务处理上没有依赖ua、reffer、cookie等额外参数判断，开发的同学表示这个解决缓存1分钟时绝对没有问题的。

 

解决问题

分析到现在有个方向性的模糊思路了，那就是是否可以用nginx cache呢？这个是非常熟悉的领域，再结合内存的使用，按照之前的业务经验看，依照命中率的不同可以起到非常好的优化效果，性能可能会飞起来，哪怕命中率小，命中一个同样赚了一个，那么马上行动起来做测试。

 

查看nginx配置文件，首先遇到的问题是前后端不是用proxy_pass与upsteam通信的，这就意味着最常使用的proxy_cache直接用是行不通的，而之前用的最多最成熟的就是这个，继而想通过加一个多端口的server来引入proxy_pass，这个也是之前常用的方案，这么做的坏处是增加nginx的复杂程度，不得已只能这么做，可以作为一个打底方案。继续分析，fastcgi通信其实是有一个fastcgi-cache的，虽然很少用，但是可以测一下。

 

调研机器的内存使用情况，拿出5G的内存做缓存用是绝对没问题的，而且1分钟的内容可能也跑不到5G，起码资源是够的，然后翻google和百度，查找各参数的配置含义，进行配置，反复测试最后形成一份可用的配置，将缓存数据放到了/dev/shm，然后进行灰度，效果非常明显，基本单机的容量按照后端算可以提升5倍，晒一下几张图：

 

bb

 

bb

 

bb

 

对应服务器内存的消耗，也验证了很小的想法，如下：

 

bb

 

优化效果

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

 

1、节约了服务器资源，后端穿透量降为1/5，容量提升5倍，节约了大量服务器；

 

2、减缓了后端c++的压力，每台服务器后端的请求书基本降为原来的1/5；

 

3、起到了消峰作用，高峰期后端的请求量基本不会抖动，压力降低；

 

4、对于错误5xx的降级，一旦后端出错后，nginx会返回最近一次缓存的结果吐给用户，用户依然可以拿到解析列表，截图如下。

 

bb

 

bb