記一次容量提升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、節約了伺服器資源，後端穿透量降為1/5，容量提升5倍，節約了大量伺服器；

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

3、起到了消峰作用，高峰期後端的請求量基本不會抖動，壓力降低；

4、對於錯誤5xx的降級，一旦後端出錯後，nginx會返回最近一次快取的結果吐給使用者，使用者依然可以拿到解析列表，截圖如下。