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

1,142 阅读4分钟
本文主要介绍了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倍,晒一下几张图:

对应服务器内存的消耗,也确认了很小的想法,如下:

优化效果

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

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

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

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

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


文章首发于共公众号“小米运维”,点击查看原文