高併發業務線上效能、儲存二三事

最近兩天促銷開始，零點流量大幅增加，通過還是比較平穩的，到是到了白天一個節點流量有大幅增加，但是量遠沒有達到系統極限，但是系統多個業務效能有一段時間下降。

首先分析問題原因，流量本身不正常因為白天突然增加七倍訪問量，這個基本是不可能的，再有就是就算流量真的漲七倍，如果是正常流量本身系統也是沒有問題的，那麼可以說流量本身異常的，不然系統本身沒有問題。

經下游同學定位，流量本身是刷子流量，並且來自於M站點，移動網頁站點應該是各大網站刷流量抓取重地。刷子一般沒有帶使用者資訊這種情況是沒有登陸，再有就是登陸了但是訪問頁面異常的快以及異常的多。導致系統流量突然加大，其實突然增大流量也不會導致請求異常，是什麼導致服務效能異常呢？

服務效能異常就要從服務本身特點出發，我們業務本身應用redis儲存，redis儲存能處理高併發請求，但對於頻繁單個key請求很容易造成效能熱點從而導致服務效能異常。對於避免這種問題可以從三個方面處理這個問題。

一是從外部避免這個問題，就是從M站本身加強對於刷子流量過濾，增加防刷策略從而避免此類問題，保護內部系統，也是對刷子的一種一種防止，一種對抗。這樣是比較根本方式，來避免業務異常。

二是我們個性化服務增加過濾機制，對於空使用者直接返回通過資料，不要去讀取redis資料從而避免單key過熱導致效能下降。再有就是對於單個使用者增加限制機制一是過於頻繁訪問通過策略限制訪問次數，從而避免單key過熱導致效能下降。

三是，我們的下游服務直接將訪問我們的刷子流量降調，從而避免個性化服務本身受影響。二和三應該是不得已而為之方式，因為從架構合理性角度，一個防刷不可能每一層都去做，而是應該最外層去做，但是從寬進嚴出角度我們也應該做相應檢查，避免因為一些場景導致效能受影響。

最近線上還有一個事就是儲存量一直增長，導致儲存有一個快被寫滿的情況，其實這個事本來很簡單，分散式儲存直接擴容就可以了，但是有個問題就是儲存本身很大，以及儲存客戶端非常多導致連線非常多，擴容後連線會更大幅增加從而導致連線有可能取不到，這是儲存本身面臨問題。

解決方案一是減少客戶端，從而減少連線，這就要對儲存進行拆分，召回儲存以及特徵要拆成小叢集，並且叢集從一主一叢方式拆解到一主多從方式，從而進一步減少叢集連線壓力並且可以將讀取壓力拆解到多個從上，達到叢集擴充套件性增強。能夠支援更多訪問量，並且叢集小擴容和管理本身也能降低難度，拆解之後一定都是好處很明顯不是，因為能夠處理qps會降低的很明顯。

你在儲存和線上業務遇到過什麼問題呢，可以在評論中分享下。