高併發的常見策略--大型web項目

一個運營的系統在正式上線後將會遇到各類層級的高併發請求，所以咱們必須對此作出相應的策略和技術解決方案，首先咱們須要認清系統的高併發由3個層面致使：

1. 傳輸層
大量用戶對系統請求後，將會形成網絡帶寬和Web服務器的I/O瓶頸。

2. 計算層
接收大量用戶請求進行計算，將會形成業務服務器和業務支撐服務器的瓶頸。

3. 存儲層
傳輸層和計算層將會產生大量的數據，數據量暴增，將會致使數據庫和儲存上的瓶頸。

針對以上將會形成的系統高併發瓶頸，咱們須要採用不一樣的技術手段解決。

從整體上來看
1.首先須要解決網絡帶寬和Web請求的高併發，須要合理的加大服務器和帶寬的投入，而且須要充分的利用系統中軟件、硬件的緩存機制，將能緩存的內容都進行緩存存儲，減小計算層和存儲層的壓力。

2.其次須要對業務服務器和業務支撐服務器進行合理的分層，而且採用並行計算和分佈式算法對大量計算進行處理，而且在開發的過程當中須要採用Java SDK中併發包(Concurrency)進行編碼實現。

3.存儲層須要採用分佈式文件服務器和列式的存儲服務器進行構建，支撐海量數據的存放和讀取，而且還要對關係型數據進行深層次的配置參數優化。

4.咱們還須要清楚的認識到，未來根據系統運行的狀態以及平臺中不一樣的業務場景按部就班的進行調整和優化。

   對於大型系統來講，採用的技術是涉及面很是廣，從硬件到軟件、編程語言、數據庫、WebServer、防火牆等各個領域都有了很高的要求。在面對大量用戶訪問、高併發請求方面，基本的解決方案集中在這樣幾個環節：將會使用 高性能的服務器、高性能的數據庫、高效率的編程語言、還有高性能的Web容器。

   可是除了這幾個方面，還無法根本解決面臨的高負載和高併發問題，因此須要將計算和負載的壓力分載到每一個計算機上，使用不一樣的服務器集羣機組進行分佈式和並行計算，面對所產生的壓力，下面這張圖清晰的描述了，咱們對系統中不一樣的計算瓶頸採用的不一樣解決手段，如圖所示：

查看大圖請點擊這裏

 

如下描述是針對不一樣層面產生的計算壓力所採用的計算策略，清單以下：

傳輸層

1.CDN Content Delivery Network，即內容分發網絡

    網絡鏈路出口進行壓力分載，經過CDN讓用戶訪問最近的數據緩存。

2.智能雙路

    針對電信、網通 不一樣的訪問用戶訪問請求，對應用戶訪問請求進行服務器帶寬的智能切換。

3. LVS 負載均衡

    對用戶的請求進行壓力分載，而且實現多種負載均衡的策略，也能夠選擇使用HA-Proxy實現。

4. HA-Proxy

   針對Web服務器進行方向代理，經過HA-Proxy將用戶的請求分發到不一樣的Web服務器上。

5. Long-Polling

    在Web服務器上採用的一種策略，專門針對某個用戶須要不斷頻繁的輪詢訪問。

6. Session2Cache

    將用戶的會話進行集中處理，存放在中央式的緩存服務器當中，減小服務器之間的會話通訊

 

計算層

1. MapReduce

   採用最經典的分佈式算法對海量數據進行處理，將計算進行分載。

2. BSP

    BSP(Bulk Synchronous Parallel-大型同步模型)算法是基於MPI算法的基礎進行演化，運用在系統中並行計算的部分。

3. Result Cache

    將計算的一部分結果進行緩存，緩解對存儲層讀取的請求。

4. Scatter/Gather

    中間經過一個服務器進行中轉，將大量的請求分發給內部的服務器進行計算，相似前端的web反向代理。

 

存儲層

1. 讀寫分離

    因爲系統的讀大於寫的頻率，數據庫架構採用了1主/多從，雙主多從的策略，因此咱們將會將讀和寫進行分離，而且將大量的讀請求分散給多臺不一樣的(Slave)服務器。

2. 分區策略

    系統採用不一樣的時間段做爲分區的主要策略，提升對數據的讀寫性能。

3. Sharding

    一臺數據庫將很快沒法知足大量併發，須要使用庫表散列，將數據庫中的數據進行分散存儲。

4. Column-Based

   使用在海量數據中的查詢功能，採用列模式的存儲方式將能夠有效的提升系統查詢效率。