接口性能調優方案探索

以前咱們的電影詳情一直採用從redis中讀取數據，但QPS一直不高，用了30組redis服務器，採用一致性哈希算法去命中機器去連redis讀取結果返回。由於redis取的次數問題及結果過大，一是同一次請求可能多個redisKey，由於key名不一樣，所以形成要屢次一致性hash而且鏈接屢次才能取得結果，經過如下想法跟試驗優化了下：

一、將屢次Redis查詢的數據緩存到一臺機器上，只一次讀取，提升了一點QPS，但只是從之前的單臺八百多到一千出頭。

二、優化redis集羣的分組，每一個主庫下掛多個從庫，提升了一點

三、redis緩存服務器專門用來讀取，只設置一臺，不走一致性哈希，走一主N從架構，提升了些

四、緩存一致性哈希結果，每次都要去根據配置文件去計算一致性哈希生成哈希環，而後經過key去查找命中，經過文件將一致性哈希的結果緩存起來，其中遇到了很多坑，包括unserialize的文件大於200K以後解不出來。生成哈希環的過程當中剛好一臺服務器碰到併發比較高形成文件屢次寫入沒法json_decode狀況。最後經過Yac跟一次寫入的方式解決了這個問題

五、將緩存結果直接存文件，經過文件的建立時間判斷是否過時。

最後發現存文件比讀redis緩存的qps高上不少不少，8核16G的標配服務器經過AB壓測獲得的結果從以前的六百多到了如今的兩千五百多，提升了不少。