本文主要介绍了HttpDns业务Cache调优的相关问题及解决办法。 上篇文章回顾：
这是最近做的一次业务优化，以一个小方案的形式分享一下优化过程。
业务简介
公司内部叫Resolver服务，其本质是一个httpdns系统，以http形式提供域名解析的服务，用户在连接业务时，先通过Resolver服务获取ip地址列表，然后通过拿到的ip列表连接到对应服务器上，解决了域名劫持和连接降级的问题。
Resolver服务采用nginx+后端的系统结构，后端是开发同学用c++自写，前后端通过fastcgi协议进行通信，平时单机的QPS在7k左右，高峰期达到1万以上。
遇到问题
分析问题
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会返回最近一次缓存的结果吐给用户，用户依然可以拿到解析列表，截图如下。
文章首发于共公众号“小米运维”，。