高併發的解決方案[轉載]

版權聲明：本文爲博主原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接和本聲明。
本文連接：https://blog.csdn.net/sanyaoxu_2/article/details/78992113

1.應用和靜態資源分離
剛開始的時候應用和靜態資源是保存在一塊兒的，當併發量達到必定程度的時候就須要將靜態資源保存到專門的服務器中，靜態資源主要包括圖片、視頻、js、css和一些資源文件等，這些文件由於沒有狀態因此分離比較簡單，直接存放到響應的服務器就能夠了，通常會使用專門的域名去訪問。
經過不一樣的域名可讓瀏覽器直接訪問資源服務器而不須要再訪問應用服務器了。架構圖以下：

 

2.頁面緩存
頁面緩存是將應用生成的頁面緩存起來，這樣就不須要每次都生成頁面了，從而能夠節省大量的CPU資源，若是將緩存的頁面放到內存中速度就更快了。若是使用Nginx服務器就可使用它自帶的緩存功能，固然也可使用專門的Squid 服務器。頁面緩存的默認失效機制一班都是按緩存時間處理的，固然也能夠在修改數據以後手動讓相應的緩存失效。
頁面緩存主要是使用在數據不多發生變化的頁面，可是不少頁面是大部分數據都不多發生變化，而其中不多一部分數據變化頻率卻很是高，好比說一個顯示文章的頁面，正常來講徹底能夠靜態化，可是若是文章後面有「頂」和「踩」的功能並且顯示的有響應的數量，這個數據的變化頻率就比較高了，這就會影響靜態化。這個問題能夠用先生成靜態頁面而後使用Ajax來讀取並修改響應的數據，這樣就能夠一箭雙鵰來，既可使用頁面緩存也能夠實時顯示一些變化頻率高的數據來。

其實你們都知道，效率最高、消耗最小的就是純靜態化的html頁面，因此咱們儘量使咱們的網站上的頁面採用靜態頁面來實現，這個最簡單的方法其實也是最有效的方法。可是對於大量內容而且頻繁更新的網站，咱們沒法所有手動去挨個實現，因而出現了咱們常見的信息發佈系統CMS，像咱們常訪問的各個門戶站點的新聞頻道，甚至他們的其餘頻道，都是經過信息發佈系統來管理和實現的，信息發佈系統能夠實現最簡單的信息錄入自動生成靜態頁面，還能具有頻道管理、權限管理、自動抓取等功能，對於一個大型網站來講，擁有一套高效、可管理的CMS是必不可少的。

除了門戶和信息發佈類型的網站，對於交互性要求很高的社區類型網站來講，儘量的靜態化也是提升性能的必要手段，將社區內的帖子、文章進行實時的靜態化，有更新的時候再從新靜態化也是大量使用的策略，像Mop的大雜燴就是使用了這樣的策略，網易社區等也是如此。

同時，html靜態化也是某些緩存策略使用的手段，對於系統中頻繁使用數據庫查詢可是內容更新很小的應用，能夠考慮使用html靜態化來實現，好比論壇中論壇的公用設置信息，這些信息目前的主流論壇均可以進行後臺管理而且存儲再數據庫中，這些信息其實大量被前臺程序調用，可是更新頻率很小，能夠考慮將這部份內容進行後臺更新的時候進行靜態化，這樣避免了大量的數據庫訪問請求。

3.集羣與分佈式
集羣是每臺服務器都具備相同的功能，處理請求時調用那臺服務器均可以，主要起分流做用。

分佈式是將不一樣的業務放到不一樣的服務器中，處理一個請求可能須要用到多臺服務器，這樣就能夠提升一個請求的處理速度，並且集羣和分佈式也能夠同時使用。

集羣有兩個方式：一種是在靜態資源集羣。另外一種是應用程序集羣。靜態資源集羣比較簡單。應用程序集羣在處理過程當中最核心的問題就是Session 同步問題。

Session 同步有兩種處理方式：一種是在Session 發生變化後自動同步到其餘服務器，另外一種就是用個程序統一管理Session。全部集羣的服務器都使用同一個Session，Tomcat 默認使用就是第一種方式，經過簡單的配置就能夠實現，第二種方式可使用專門的服務器安裝Mencached等高效的緩存程序統一來管理session，而後再應用程序中經過重寫Request並覆蓋getSession 方法來獲取制定服務器中的Session。

對於集羣來講還有一個核心的問題就是負載均衡，也就是接收到一個請求後具體分配到那個服務器去處理的問題，這個問題能夠經過軟件處理也可使用專門的硬件（如：F5）解決。

 

4. 反向代理
反向代理指的是客戶端直接訪問的服務器並不真正提供服務，它從別的服務器獲取資源而後將結果返回給用戶。

圖：

 

4.1 反向代理服務器和代理服務器的區別
代理服務器的做用是代我門獲取想要的資源而後將結果返回給咱們，所要獲取的資源是我門主動告訴代理服務器的，好比，我門想訪問Facebook，可是直接訪問不了，這時就可讓代理服務器訪問，而後將結果返回給咱們。

反向代理服務器是我門正常訪問一臺服務器的時候，服務器本身去調用了別的服務器資源並將結果返回給咱們，我門本身並不知道。

代理服務器是咱們主動使用的，是爲咱們服務的，他不須要有本身的域名；反向代理服務器是服務器本身試用的，我門並不知道，它有本身的域名，我門訪問它和訪問正常的網址沒有任何區別。

反向代理服務器主要有三個做用：
1. 能夠做爲前端服務器跟實際處理請求的服務器集成；
2. 能夠作負載均衡
3. 轉發請求，好比說能夠將不一樣類型的資源請求轉發到不一樣的服務器去處理。

5. CDN
cdn實際上是一種特殊的集羣頁面緩存服務器，他和普通集羣的多臺頁面緩存服務器相比，主要是它存放的位置和分配請求的方式有點特殊。CDN 服務器是分佈在全國各地的，當接收到用戶請求後會將請求分配到最合適的CDN服務器節點獲取數據。好比聯通的用戶分配到聯通的節點，上海的用戶分配到上海的節點。

CDN的每一個節點其實就是一個頁面緩存服務器，若是沒有請求資源的緩存就會從主服務器獲取，不然直接返回緩存的頁面。

CDN分配請求（負載均衡）的方式是用專門的CDN域名解析服務器在解析域名的時候就分配好的。通常的作法是在ISP哪裏試用CNAME將域名解析到一個特定的域名，而後再將解析到的那個域名用專門的CDN服務器解析道相應的CDN節點。如圖。

 

第二步訪問CDN的DNS服務器是應爲CNAME記錄的目標域名使用NS記錄指向了CDN的DNS服務器。CDN的每一個節點可能也是集羣了多臺服務器。

6. 底層的優化
前面說的全部都是架構都是創建在最前面介紹的基礎結構之上的。不少地方都須要經過網絡傳輸數據，若是能夠加快網絡傳輸的速度，那將會讓整個系統獲得改善。

 

7.數據庫集羣和庫表散列

大型網站都有複雜的應用，這些應用必須使用數據庫，那麼在面對大量訪問的時候，數據庫的瓶頸很快就能顯現出來，這時一臺數據庫將很快沒法知足應用，因而咱們須要使用數據庫集羣或者庫表散列。

在數據庫集羣方面，不少數據庫都有本身的解決方案，Oracle、Sybase等都有很好的方案，經常使用的MySQL提供的Master/Slave也是相似的方案，您使用了什麼樣的DB，就參考相應的解決方案來實施便可。

上面提到的數據庫集羣因爲在架構、成本、擴張性方面都會受到所採用DB類型的限制，因而咱們須要從應用程序的角度來考慮改善系統架構，庫表散列是經常使用而且最有效的解決方案。咱們在應用程序中安裝業務和應用或者功能模塊將數據庫進行分離，不一樣的模塊對應不一樣的數據庫或者表，再按照必定的策略對某個頁面或者功能進行更小的數據庫散列，好比用戶表，按照用戶ID進行表散列，這樣就可以低成本的提高系統的性能而且有很好的擴展性。sohu的論壇就是採用了這樣的架構，將論壇的用戶、設置、帖子等信息進行數據庫分離，而後對帖子、用戶按照板塊和ID進行散列數據庫和表，最終能夠在配置文件中進行簡單的配置便能讓系統隨時增長一臺低成本的數據庫進來補充系統性能。

8. 小結
網站架構的整個演變過程主要是圍繞大數據和高併發這兩個問題展開的，解決方案主要分爲使用緩存和多資源兩種類型。多資源主要指多存儲（包括多內存）、多CPU和多網絡，對於多資源來講又能夠分爲單個資源處理一個完整的請求和多個資源合做處理一個請求兩種類型，如多存儲和多CPU中的集羣和分佈式，多網絡中的CDN和靜態資源分離。理解了整個思路以後就抓住了架構演變的本質，並且本身可能還能夠設計出更好的架構。

 

其它簡單總結：

首先，我認爲解決問題以前首先要有清晰的思路，若是隻是用來別人的解決方案那也只能是拿來主義，沒有真正理解，沒有作到觸類旁通。

海量數據和高併發常常被連在一塊說事兒，雖然他們徹底是兩回事兒。海量數據純指的是數據庫的海量數據，而併發指的卻包括數據庫和服務器的高訪問量。

那麼問題來了，既然是數據庫的數據量大，那怎麼辦呢？要想解決問題，首先要知道問題是什麼！！！那麼海量數據會給我帶來什麼樣的問題呢？

海量數據帶來的問題無非就是增刪改查的問題，除了以外還能有啥問題呢？總不能是帶來安全問題吧（打臉一，還真有多是安全問題）

1 數據庫訪問緩慢

2 插入更新緩慢，這個問題只能經過分庫分表解決

要解決數據庫訪問緩慢的問題還有幾種方法，既然訪問數據庫慢的話，在邏輯容許的狀況下能夠不訪問數據庫呢？

1 使用緩存

2 使用頁面靜態化

既然不訪問數據庫逃不過去了，那咱們就對數據庫進行優化

3 優化數據庫（包含的內容很是多，好比參數配置，索引優化，sql優化等等）

4 分離數據庫中活躍的數據

5 讀寫分離

6 批量讀取和延遲修改；

7 使用搜索引擎搜索數據庫中的數據；

8 使用NoSQL和Hadoop等技術；

9 進行業務的拆分；

 

高併發的解決方案

其實這個問題必須結合上面的海量數據來討論，什麼狀況下會出現高併發呢？必定是平時訪問量就比較大的狀況，那麼平時訪問量比較大相應的數據存儲也就愈來愈多，這都是相輔相成的，固然也有個例，好比剛需，好比12306，這裏的高併發相比於它的數據來講已經不算海量了。那麼平時訪問量大如何解決呢？由於這裏牽扯到服務器和數據庫的問題，因此要從這兩方面來進行優化

1 增長web服務器數量，也就是作集羣，作負載均衡。既然一臺服務器沒法完成任務，那就多用幾臺，幾臺不夠用機房

 在通向第二種解決方法以前，還有沒有除了數據庫服務器以外能作的一些優化手段呢？固然有

1.1 頁面緩存

1.2 cdn

1.3 反向代理

1.4 應用程序和靜態資源分離（好比專供下載的資源單獨放在一塊兒，給這臺服務器提供很高的帶寬資源）

2 增長數據庫服務器數量，一樣作集羣，作負載均衡。

 

 

海量數據的解決方案

1 使用緩存

好多事情都是相輔相成的，相比來講使用緩存更可能是用來解決高併發問題的，由於海量數據致使了訪問的緩慢，容易形成高併發問題的嚴重性，又由於數據庫通常是web訪問的瓶頸，因此咱們在業務邏輯容許的狀況下儘可能先避免操做數據庫，因而，就有了緩存。將必要的數據存放在內存中，而沒必要每次都去數據庫中讀取形成沒必要要的性能浪費和加快訪問速度---這就是緩存帶來的好處。那使用緩存以及選用管理緩存軟件時應該注意些什麼東西呢？

2 頁面靜態化---不想解釋，還有什麼值得去解釋呢？

3 數據庫優化

3.1 數據庫表結構涉及

3.2 數據類型的選用

3.3 sql優化

3.4 索引優化

3.5 配置優化

須要注意的地方實在太多，應該做爲單獨的一章拿出來說

4 分離數據庫中的活躍數據

爲何要分離呢？說一個我實際環境中遇到的問題吧！有一個表只有10幾個字段，表有130萬條數據，但大小已經到了5G的數據，這自己是不太合理的，這麼少的數據佔用了太多的數據，說明其中有些字段存儲了大量的字符串（好比說文章內容等），每次檢索這個表時大部分是用不到這些大字段內容的，但卻須要耗時比較長，產生不少的慢日誌。這時咱們能夠考慮將表進行垂直切分，將活躍數據分離開來，這樣能大大加快訪問速度

5 讀寫分離

 

 

相關網址http://blog.csdn.net/u012373815/article/details/71435926

http://blog.csdn.net/u014723529/article/details/41892001

————————————————版權聲明：本文爲CSDN博主「_從頭再來_」的原創文章，遵循 CC 4.0 BY-SA 版權協議，轉載請附上原文出處連接及本聲明。原文連接：https://blog.csdn.net/sanyaoxu_2/article/details/78992113