面對峯值響應衝擊，解決高併發的三大策略

當前在互聯網+的大潮下，衆所周知淘寶、京東這些交易系統天天產生的數據量都是海量的，天天的交易併發也是驚人的，尤爲是「雙11」、「6.18」這些活動，對系統的峯值響應提出了很是高的要求，因此對系統架構也就有了很要的要求。

在寫這篇博客的前2天，據說某系統在25人的用戶量下就宕機了，實在讓人震驚，因此捋了下互聯網交易系統咱們能夠採起哪些技術來解決互聯網平臺下大數據量高併發的問題。

首先根據架構分層把不一樣技術進行了一些分類，以下圖：

 

互聯網技術架構分層策略圖

接下來我會逐一解釋各個技術的大概原理和思路，供你們參考和學習：

1、互聯網層

一、負載均衡

負載均衡英文名稱爲Load Balance，意思就是分攤到多個操做單元上進行執行，例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等，從而共同完成工做任務。

好比Nginx是一款能夠經過反向代理實現負載均衡的服務器，把流量導向不一樣的服務器；如今的雲平臺都提供了負載均衡服務，不過須要單獨付費，好比阿里的SLB。

二、內容分發網絡(CDN)

內容分發網絡基本思路是儘量避開互聯網上有可能影響數據傳輸速度和穩定性的瓶頸和環節，使內容傳輸的更快、更穩定。

經過在網絡各處放置節點服務器所構成的在現有的互聯網基礎之上的一層智能虛擬網絡，CDN系統可以實時地根據網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上。

其目的，是使用戶可就近取得所需內容，解決Internet網絡擁擠的情況，提升用戶訪問網站的響應速度。這個不須要單獨去實現，能夠用現成的產品去作，好比: Akamai(好些，比較貴)，Verizon EdgeCast(便宜些)，ChinaCach；若是是雲平臺基本上都提供了這個服務，不過也須要付費的，好比阿里雲基於本身的CDN加速提供了不一樣形式的加速；好比基於P2P技術的PCDN，加強防禦DDoS、CC、Web應用攻擊的SCDN以及全站加速。

2、Web服務器層

一、Session→Cookie

傳統的B/S架構都是把用戶會話放到Session裏面，在在線用戶量不高的狀況下沒啥問題，可是對於如今互聯網採起了分佈式或者微服務架構，就很難單獨去維護Session了，由於Session會分佈在不一樣的服務器上，會話的同步會面臨着很大的問題。因此一種方式是把Session的維護拿到Cookie裏去作，不依賴於某臺或多臺服務器，同時也減小了服務器的開銷。固然，也能夠利用內存緩存服務器來統一存儲Session信息，有的內存緩存服務器還能把內存數據持久化到磁盤來提升可用性和可恢復性，就不會有同步問題了。

二、Static page

動態頁面靜態化，爲何又要把動態網頁以靜態網頁的形式發佈呢？一個很重要的緣由就是搜索引擎；另外一個重要緣由就是提升程序性能。

不少大型網站，進去的時候看它頁面很複雜，可是加載也沒有耗費多長時間，緣由在於先於用戶獲取資源或數據庫數據，進而經過靜態化處理，生成靜態頁面。全部人都訪問這一個靜態頁面，而靜態化處理的頁面自己的訪問速度要較動態頁面快不少倍，所以程序性能會有大大的提高。使用場景是那些常常須要訪問可是數據不常常更新的時候。這種狀況就是時候將動態頁面靜態化了，好比淘寶的寶貝信息頁面，頁面動態部分能夠用AJAX加載進來，好比月銷多少筆。

三、Cache

緩存，Web服務層的緩存依賴於下面三個方面：

• 瀏覽器端的緩存，好比CSS/JS等；
• 在CDN這類技術當中作大量頁面緩存來提升就近訪問速度；
• 本身搭建內存緩存服務器對頻率訪問比較高的頁面進行緩存，好比首頁等。

四、Gzip

利用瀏覽器能自動進行Gzip解壓縮的原理對訪問頁面和資源（含圖片、JavaScript、CSS等）進行Gzip壓縮，減小文件大小，以此來提升網絡加載速度。

五、One file

原理是把多個須要加載的內容合成一個文件，減小加載次數和網絡鏈接時間，提升訪問效率，好比把小圖標集合合成一個大圖片，把CSS/JavaScript 合成到一個文件裏面。

六、Cluster

集羣和傳統的高性能計算機技術相比，計算機集羣經過一組鬆散集成的計算機軟件和/或硬件鏈接起來高度緊密地協做完成計算工做。在某種意義上，它們能夠被看做是一臺計算機。

集羣系統中的單個計算機一般稱爲節點，一般經過局域網鏈接，但也有其它的可能鏈接方式。集羣計算機一般用來改進單個計算機的計算速度和/或可靠性。通常狀況下，集羣計算機比單個計算機（好比工做站或超級計算機）性能價格比要高得多，大多數集羣採用主從式來管理集羣節點，好比Websphere Cluster。

和常見的分佈式的不一樣點在於：集羣是同一個業務部署在多個服務器上；分佈式是一個業務分拆成多個子業務，或者自己就是不一樣的業務，部署在不一樣的服務器上。

簡單地說，分佈式是以縮短單個任務的執行時間來提高效率，而集羣則是經過提升單位時間內執行的任務數來提高效率。

3、應用服務器或者業務服務器層

一、Distributed/分佈式|SC/服務中心|微服務|Decouple/解耦

分佈式系統是支持分佈式處理的軟件系統，是由通訊網絡互聯的多處理機體系結構上執行任務的系統。簡單來講，分佈式處理就是多臺相連的計算機各自承擔同一工做任務的不一樣部分，在人的控制下同時運行，共同完成同一件工做任務。包括分佈式操做系統、分佈式程序設計語言及其編譯系統、分佈式文件系統、分佈式數據庫系統、分佈式調度系統等。這經常伴隨須要作負載均衡、熔斷和限流等；還得考慮是全量計算仍是增量計算等。

因此隨着分佈式的發展，微服務架構就變得愈來愈流行，它的主要做用是將功能分解到離散的各個服務當中，從而下降系統的耦合性，並提供更加靈活的服務支持，圍繞業務領域組件來建立應用，這些應用可獨立地進行開發、管理和迭代。在分散的組件中使用雲架構和平臺式部署、管理和服務功能，使產品交付變得更加簡單，因此業務的解耦和拆分的就變得愈來愈重要。

如今隨着容器(Docker)的發展讓分佈式、微服務變得更加靈活和容易，也讓如今支持大數據量高併發提供了很好的基礎設施。

二、Cache

這一層的緩存主要是對高頻數據進行緩存，好比對中間計算結果進行緩存，並且是基於內存緩存居多，好比Memcached和Redis，有的還提供緩存持久化，好比Redis。在分佈式計算中常常要對批量數據進行緩存預讀取以提升計算速度。

三、同步轉異步/MQ

同步轉異步的思路一方面不讓進程或者線程阻塞在順序執行裏，從而加快程序的執行，就像Node.js用異步和Java用同步作相同計算測試，好多時候速度Node.js比Java還快，不信你們能夠試試，像雙11的搶購都是採用了異步機制。

另外一方面不讓用戶一直等在那裏，用戶能夠繼續作別的事情，等異步執行完畢通知用戶。這裏面大量用到了消息隊列(MQ)，流行的產品不少，最先的WebsphereMQ，到如今的Kafka、RabbitMQ，有些甚至和流行的開源框架緊密集成，好比RabbitMQ和SpringBoot。

4、數據訪問、文件訪問、內部網絡訪問層

一、讀寫分離

由於在大數據量併發狀況下，讀的操做頻率遠遠超過寫操做，因此經過讀寫分離來提升讀的速度，其思路是讓主數據庫（master）處理事務性增、改、刪操做（INSERT、UPDATE、DELETE），而從數據庫（slave）處理SELECT查詢操做，下面是淘寶最先的時候採用的讀寫分離策略：

 

讀寫分離示意圖

二、DB Cluster

集羣就再也不作過多說明，數據庫集羣是利用至少兩臺或者多臺數據庫服務器，構成一個虛擬單一數據庫邏輯映像，像單數據庫系統那樣，向客戶端提供透明的數據服務。其目的仍是爲了增長數據吞吐量，提升數據庫性能，知足大數據量下對數據的讀寫速度要求。

阿里雲的RDS雲數據庫就繼承了上述2大特徵，外面看來是一個MySQL集羣，提供統一的透明訪問，而在內部就自動實現了讀寫分離，爲高性能數據庫存儲提供了很大便利。

三、分佈式存儲(DAS/NAS/SAN)

三種分佈式存儲方案，你們可自行百度，各類介紹比較比較多，這裏再也不贅述，好比阿里的OSS存儲也是一種分佈式存儲。

四、Cache

緩存無處不在，連CPU都有二級緩存，在數據訪問這一層，能夠根據你的數據須要充分利用緩存技術來提供讀寫速度，好比對要求不是特別實時的大數據進行預統計分析，而後緩存下來作報表等，這個時候直接從緩存裏讀取便可，提升統計速度。

五、NoSQL，Key/Value

NoSQL，泛指非關係型的數據庫。隨着互聯網Web2.0網站的興起，傳統的關係數據庫在應付Web2.0網站已經顯得力不從心，暴露了不少難以克服的問題，而非關係型的數據庫則因爲其自身的特色（高可擴展性、分佈式計算、低成本、架構的靈活性、半結構化數據，沒有複雜的關係）獲得了很是迅速的發展。NoSQL數據庫的產生就是爲了解決大規模數據集合多重數據種類帶來的挑戰，尤爲是大數據應用難題。其數據庫類型有列存儲、文檔存儲、Key/Value存儲、對象存儲和圖存儲等。

六、Split/分割，Partition/分區

表分區是DB對於很是大的表進行優化的一種有效方法，是根據數據庫定義不一樣的分區策略決定的，好比取模、時間和哈希等，是很是有效的一種手段，在不少狀況下比表分割更有效。

好比，有一個代碼表使用分區表把100萬紀錄分在10個分區中（ID每從1到10萬爲一個分區），那樣寫查詢語句的時候，只要給出查詢條件中所須要的代碼，DB自動會定位到對應的分區進行查詢，大大下降的查詢時間。

而採用表分割那必須先根據查詢的代碼指定所要查詢的表，才能找到相應的記錄，是由DBA或架構師根據業務須要來定義如何分割的。表分割分爲水平分割和垂直分割：

• 水平分割：根據一列或多列數據的值把數據行放到兩個獨立的表中；
• 垂直分割：把主碼和一些列放到一個表，而後把主碼和另外的列放到另外一個表中。

七、BGP

邊界網關協議，主要用於互聯網AS（自治系統）之間的互聯，BGP的最主要功能在於控制路由的傳播和選擇最好的路由。中國網通與中國電信都具備AS號（自治系統號），全國各大網絡運營商多數都是經過BGP協議與自身的AS號來互聯的。

使用此方案來實現雙線路須要在CNNIC（中國互聯網信息中心）申請IDC本身的IP地址段和AS號，而後經過BGP協議將此段IP地址廣播到移動，網通、電信等其它的網絡運營商，使用BGP協議互聯後移動。網通與電信的全部骨幹路由設備將會判斷到IDC機房IP段的最佳路由，以保證移動、網通和電信用戶的高速訪問。如今很多的雲平臺都支持BGP。

5、總結

「緩存」、「異步」和「分」是互聯網大數據量高併發下架構策略中用的最多的3種策略，從上面各個技術層面，「分」也是佔據了大多數技術的核心思想，因此考慮的時候要多想一想分哪裏、如何分，另外不少業務場景還得想一想怎麼合。

順便在此給你們推薦一個Java架構方面的交流學習羣：698581634，裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化這些成爲架構師必備的知識體系，主要針對Java開發人員提高本身，突破瓶頸，相信你來學習，會有提高和收穫。在這個羣裏會有你須要的內容  朋友們請抓緊時間加入進來吧。