這是最近做的一次優化，以一個小方案的形式分享一下優化過程。
一、業務簡介
公司內部叫Resolver服務，其本質是一個httpdns系統，以http形式提供域名解析的服務，用戶在連接業務時，先通過resolver服務獲取ip地址列表，然後通過拿到的ip列表連接到對應服務器上，解決了域名劫持和連接降級的問題。
Resolver服務採用nginx+後端的系統結構，後端是開發同學用c++自寫，前後端通過fastcgi協議進行通信，平時單機的QPS在7k左右，高峰期達到1萬以上。
二、遇到問題
業務到高峰期QPS達到1萬以上，服務出現大量502特別是魯谷機房，進而拒絕服務，業務瞬間基本屬於不可用的狀態，嘗試通過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與upstream通信的，這就意味著最常使用的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會返回最近一次緩存的結果吐給用戶，用戶依然可以拿到解析列表，截圖如下。
閱讀更多 矢量bit 的文章
