本文主要介紹了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會返回最近一次快取的結果吐給使用者，使用者依然可以拿到解析列表，截圖如下。
文章首發於共公眾號“小米運維”，點選檢視原文。