記一次容量提高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倍，曬一下幾張圖：

對應服務器內存的消耗，也確認了很小的想法，以下：

優化效果

經過不到200M內存的服務器資源消耗，達到了命中率75%到80%的效果，機器的性能能夠提高到5倍以上，此次優化主要達到了以下效果

一、節約了服務器資源，後端穿透量降爲1/5，容量提高5倍，節約了大量服務器；

二、減緩了後端c++的壓力，每臺服務器後端的請求書基本降爲原來的1/5；

三、起到了消峯做用，高峯期後端的請求量基本不會抖動，壓力下降；

四、對於錯誤5xx的降級，一旦後端出錯後，nginx會返回最近一次緩存的結果吐給用戶，用戶依然能夠拿到解析列表，截圖以下。

文章首發於共公衆號「小米運維」，點擊查看原文。