X系統高可用與高併發解決方案

PPT下載:https://download.csdn.net/download/love254443233/12334991

 

 

 

 

2.1 數據存儲主備

主機工作,備機處於監控準備狀況;當主機宕機時,備機接管主機的一切工作

2.2 雙機房部署

多臺主機一起工作,各自運行一個或幾個服務,各爲服務定義一個或多個備用主機,當某個主機故障時,運行在其上的服務就可以被其它主機接管。

 

2.3 集羣部署

多臺主機一起工作,各自運行一個或幾個服務,各爲服務定義一個或多個備用主機,當某個主機故障時,運行在其上的服務就可以被其它主機接管。

 

三、服務穩定性

這裏的穩定性是指系統能夠正常提供服務隨時間不變化或不出問題的能力。

3.1  流量削峯(現象1)

推送促銷活動導致流量突然增加2倍甚至更多

3.1  流量削峯(現象2)

qpm2500上升到5000甚至10000

 

3.1  流量削峯(影響)

參考文章:基於LRU-K算法設計本地緩存實現流量削峯

3.1.1)接口響應時長增加了5(qps增加了2)

3.1.2)機房局域網交換機帶寬報警(1kM帶寬使用了900M)

3.1.3)從redis獲取數據接口響應時長增加等

3.1  流量削峯(方案)

1、服務各實例自動識別熱點數據

2、存儲有限的熱點數據

3、熱點數據先從本地緩存取,不再走redis與數據庫 可大大減少請求響應時間,提高併發

 

3.1  流量削峯(LRU-K)

1)數據第一次被訪問,加入到訪問歷史記錄表(簡稱記錄表);在記錄表中對應的K單元中設置最後訪問時間=new(),且設置訪問次數爲1

2)如果數據訪問次數沒有達到K次,則訪問次數+1最後訪問時間與當前時間間隔超過預設的值(30)訪問次數0並加1

3)當數據訪問計數超過(>=)K次後,則訪問次數+1。將數據保存到LRU緩存隊列中,緩存隊列重新按照時間排序;

4LRU緩存隊列中數據被再次訪問後,重新排序;

5LRU緩存隊列需要淘汰數據時,淘汰緩存隊列中排在末尾的數據,即:淘汰“倒數第K次訪問離現在最久”的數據。

3.1  流量削峯(效果1)

1、優化參數前QPS增長時,響應時間未見明顯變短。如左右第1

2、參數調優上線後。QPS明顯增加後,redis請求響應時間增加的情況下,整體響應時間未見變化。見左右最後1

3.1  流量削峯(效果2)

QPS增加4倍,響應時間未見變化,跟平時一樣

 

1、接入系統使用多線程推送

2、極限狀態下像網絡超時會出現重新推送(出現過1秒鐘推了6次情況)

3、過快會影響C系統與X服務的穩定性

1、接入系統使用多線程推送

2、推參狀態持久化,性能好,對系統幾乎無副作用

3、定時任務單線程處理,控制併發。下游系統無壓力

從大數據同步數據的幾種模式:

1http推送:實時,併發高會影響服務

2、消息推送:半限流,併發高會影響服務

3、主動去拉數據:單線程,不影響服務

1、把部分流量從整體併發高的服務引入或分流到其它整體流量小的服務

2Y校驗房東與門店正確關係由查詢X調整成查詢權限平臺

 

 

併發平均降了9w,最高降了15w,當時分銷所有服務併發共計8w5

 

traceIdip統計

 

 

結果或影響

1)核心單個查詢接口(房東+門店+房屋)響應時間對比:原來的2ms-7ms降至0.04ms-0.8ms,大約降低了

2redis整體併發對比:原來729K,現在266.469K(峯值),大約減少了64%

3redis整體流量對比:原來25K,現在17K,大約減少了降低了約32%

平均響應時間:2.25ms
最大值響應時間:13ms
 
平均響應時間:1.712ms/18=0.09ms
最大值響應時間:1.2ms
平均響應時間:0.585ms/18=0.032ms
最大值響應時間:1.0ms
25k->17k=8K
8K/25=32%
 
 
 
 
 
 
 
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章