Java架構-高並發的解決實戰總結方案，看完這些就夠了！

• 2019 年 10 月 7 日
• 筆記

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的數據，這本身是不太合理的，這麼少的數據佔用了太多的數據，說明其中有些字段存儲了大量的字符串（比如說文章內容等），每次檢索這個表時大部分是用不到這些大字段內容的，但卻需要耗時比較長，產生很多的慢日誌。這時我們可以考慮將表進行垂直切分，將活躍數據分離開來，這樣能大大加快訪問速度。

作者：Java架構師筆記 來源：https://www.toutiao.com/a6679623437343785479/