前言 隨著網際網路的快速發展，很多傳統行業都開始將原有的產品網際網路化移動化，這其中就涉及到對原有系統的改造，因為之前大部分時間都是在傳統銀行工作所以對於原先的系統設計我們也有一個套路，類似傳統的SSH、LAMP這種，但是隨著技術的不斷快速發展，網際網路高併發的架構設計也有了新的模式，本文就介紹下基本的高併發設計模式。網際網路大部分系統的設計採用本文的設計模式都是可以的，但是對於一些超高併發的特殊場景的系統還是需要根據具體業務場景單獨去設計的，下面我們就對高併發設計模式進行講解。
分層 分層設計是企業應用系統中常見的設計模式，為了保證後續系統的可拆分和可複用，一般會將系統拆分為應用層、服務層、資料層，這也是傳統的系統分層拆分模式。通過分層，可以更好的將一個龐大的軟體系統切分為不同的部分，便於分工合作並行開發和維護。每層都是獨立的，互相通過介面進行呼叫，各層可以根據業務情況的變化獨立作出調整，只需要保證介面一致性即可。
分層比較大的挑戰就是合理規劃和劃分每一層的邊界和介面，在實施過程中禁止躍層呼叫。對於分層架構不是一成不變的，一般來說在實際過程中，會根據具體的情況再細化分層，應用層可以分為檢視層、業務邏輯層等，服務層也可以細分為資料介面適配層、邏輯處理層等。
分層架構對網站支援高併發分散式的發展方向至關重要，所以在系統剛開始建的時候最好就要採取分層架構，這樣後續分層會比較容易。
分割 分層是對系統的橫向的切分，分割則是對系統縱向的切分。系統越大，分割的就會越細，例如銀行系統我們會切分為核心系統、賬戶系統、支付系統、現金管理系統、營銷系統等等，基本上你在網銀或者手機銀行上看到的每個功能背後基本都是一個系統去支撐，例如我們常見的手機銀行裡的賬戶交易查詢，就這麼一個簡單的交易查詢功能，對於有一定規模的銀行來說，都會單建一個交易查詢系統提供全渠道的查詢服務。
按照這樣將功能從業務層面分割以後，各個系統承載的壓力自然也就下降下來，而且擴充套件性也會比較好。不過功能分割對於大型網站的分割粒度一般會比較小，對於小規模的公司來說一般沒必要上來就分割成很多子系統，隨著業務的發展再進行分割就可以。
分散式 分散式由來已久，分散式意味著可以通過增加機器完成同樣的功能，機器越多，cpu資源、記憶體、磁碟都是隨著機器的增加而線性增加，機器越多能夠處理的併發訪問和資料量就越大，從而能為更多的使用者提供服務。
分散式架構需要考慮很多問題，並不是簡單的加機器就可以了。實施分散式以後需要考慮使用者會話如何管理，資料在分散式環境中如何保持資料一致性，分散式事務如何保證一致性，分散式的日誌維護等都是需要考慮的問題，所以分散式設計要根據具體情況而來，不要為了分散式而分散式。
分散式方案有以下幾種：
1）分散式應用和服務：將分層和分割後的應用分散式部署，這樣可以提高網站效能和併發，加快開發和釋出速度，還可以讓不同應用交叉複用共同的應用，便於功能擴充套件。
2）分散式靜態資源：網站的靜態資源獨立分散式部署，並採用獨立的域名，這就是動靜分離。靜態資源的分散式部署可以減少應用伺服器的壓力，使用獨立域名可以加快載入速度，也可以降低靜態資源伺服器的壓力。
3）分散式資料和儲存：大型網站處理的資料都是P級的，單臺伺服器無法提供這麼大的儲存空間，這麼大的資料需要分散式儲存。除了分散式檔案儲存，還有關係型資料庫和Nosql都有分散式的部署方案。通過分散式能夠提供海量的資料儲存空間。
4）分散式計算：對於很多後臺批量處理的任務都是採用分散式計算方案，常用的有Hadoop和MapReduce分散式計算框架。分散式計算框架內容比較多。
叢集 分散式部署的應用和服務部署了很多機器後還需要將其叢集化才能對外提供服務，多臺伺服器部署相同應用構成一個叢集，通過負載均衡裝置共同對外提供服務。
當業務量不斷增大以後，可以在叢集中不斷增加伺服器就可以滿足業務增長了，當一臺伺服器壞了也不會影響對外的服務提供，只是效能有所下降。
快取 快取是高併發系統的殺手鐗，在真正有高併發需求的系統一般會設計多級快取來減少真正的服務計算，而是直接通過快取提供服務。像微博、朋友圈這些高QPS的系統都是採用了多級快取的架構方案。
1）CDN：CDN供應商一般都部署在距離使用者最近的網路服務商，使用者的請求總是先到網路服務商，在這裡快取網站的靜態資源，可以就近將靜態資料返回給使用者。一般來說對於電商、社交應用、新聞門戶或者視訊網站這些高QPS網站，都建議使用CDN來環節源系統的壓力。
2）反向代理：反向代理屬於網站前端架構的一部分，部署在網站的前端，當使用者請求到達網站的資料中心時，最先訪問到的就是反向代理伺服器，這裡將網站的靜態資源快取起來，這樣不需要繼續轉發應用伺服器，直接從反向代理快取中返回就可以了。
3）本地快取：對於應用伺服器被訪問的高熱點資料，應用程式可以在伺服器記憶體中快取這些熱點資料，這樣就不需要訪問伺服器磁碟或者資料庫了，能夠將記憶體中的熱點資料直接返回。
4）分散式快取：很多系統資料量非常大，光靠本地快取可能記憶體空間不夠，這時候就可以考慮使用分散式快取了，常用的分散式快取有redis、memcache這些key-value分散式快取，這些分散式快取一般也都提供了叢集版本，能夠做到很好的高可用和高效能。
非同步 非同步也是處理高併發的一把利器，也是處理解耦的手段之一，業務系統之間的訊息傳遞不是同步呼叫，而是將一個業務操作分為多個階段，每個階段之間通過共享資料的方式非同步執行。
在單一伺服器內部可通過多執行緒共享佇列的方式實現非同步，處在業務操作前面的執行緒將輸出的內容寫入佇列，後面的處理執行緒從佇列中取出資料進行處理；在分散式系統中，多個伺服器叢集通過分散式訊息佇列實現非同步。
對於簡單的非同步實現可以通過記憶體佇列來實現，對於需要高可用和高併發的系統一般來說都依靠商用的訊息佇列中介軟體產品，Websphere MQ、Rabbit MQ、Rocket MQ等都是比較好的訊息中介軟體產品。
冗餘 為了保證系統的高可用，我們一般會對伺服器和資料都進行冗餘備份，這樣可以保證在伺服器當機的情況下系統依然可以保證提供服務。
訪問和負載很小的應用服務也必須部署至少兩臺伺服器組成一個叢集，就是為了通過冗餘來實現高可用。資料庫要定期進行全量備份，每天還要進行增量備份，防止資料庫伺服器出現異常導致資料丟失，對於實時的資料備份可以通過資料庫自帶的日誌來進行恢復。
總結 上面介紹的這些就是常用的一些高併發的設計模式，其中每一條都值得深入的研究，本文只是介紹了高併發設計時需要考慮的設計方案簡介，可以通過這些方案緩解壓力提高併發效能和高可用。、
感興趣可以加Java架構師群獲取Java工程化、高效能及分散式、高效能、深入淺出。高架構。效能調優、Spring，MyBatis，Netty原始碼分析和大資料等多個知識點高階進階乾貨的直播免費學習許可權 都是大牛帶飛 讓你少走很多的彎路的 群..號是：855801563 對了 小白勿進 最好是有開發經驗
注：加群要求
1、具有工作經驗的，面對目前流行的技術不知從何下手，需要突破技術瓶頸的可以加。
2、在公司待久了，過得很安逸，但跳槽時面試碰壁。需要在短時間內進修、跳槽拿高薪的可以加。
3、如果沒有工作經驗，但基礎非常紮實，對java工作機制，常用設計思想，常用java開發框架掌握熟練的，可以加。
4、覺得自己很牛B，一般需求都能搞定。但是所學的知識點沒有系統化，很難在技術領域繼續突破的可以加。
5.阿里Java高階大牛直播講解知識點，分享知識，多年工作經驗的梳理和總結，帶著大家全面、科學地建立自己的技術體系和技術認知！