Java面試總結如何處理項目的高併發、大數據

1.HTML靜態化

若是網站的請求量過大，咱們能夠將頁面靜態化提供訪問來緩解服務器壓力，可以緩解服務器壓力加大以及下降數據庫數據的頻繁交換。適合於某些訪問了過大，可是內容不常常改變的頁面，如首頁、新聞頁等

2.文件服務器

顧名思義，文件服務器就是將文件系統單獨拿出來提供專一於處理文件的存儲訪問系統，甚至於對個文件服務器。由於對於圖片這種資源的訪問存儲是web服務最耗資源的地方，將文件服務器單獨部署既能夠將壓力轉移，交給專門的系統處理，又能夠分擔風險，若是圖片服務器出現問題，那麼主服務器可以保證正常，頂多就是文件請求不到。

3.負載均衡

負載均衡將是大型網站解決高負荷訪問和大量併發請求採用的終極解決辦法。

負載均衡創建在現有網絡結構之上，它提供了一種廉價有效透明的方法擴展網絡設備和服務器的帶寬、增長吞吐量、增強網絡數據處理能力、提升網絡的靈活性和可用性。其原理就是將大量工做分攤到多個操做單元上進行執行，例如Web服務器、FTP服務器、企業關鍵應用服務器和其它關鍵任務服務器等，從而共同完成工做任務。

 

四個分類

軟件負載均衡

解決方案是指在一臺或多臺服務器相應的操做系統上安裝一個或多個附加軟件來實現負載均衡，如DNS Load Balance，CheckPoint Firewall-1 ConnectControl等，它的優勢是基於特定環境，配置簡單，使用靈活，成本低廉，能夠知足通常的負載均衡需求。

軟件解決方案缺點也較多，由於每臺服務器上安裝額外的軟件運行會消耗系統不定量的資源，越是功能強大的模塊，消耗得越多，因此當鏈接請求特別大的時候，軟件自己會成爲服務器工做成敗的一個關鍵；軟件可擴展性並非很好，受到操做系統的限制；因爲操做系統自己的Bug，每每會引發安全問題。

硬件負載均衡

解決方案是直接在服務器和外部網絡間安裝負載均衡設備，這種設備一般稱之爲負載均衡器，因爲專門的設備完成專門的任務，獨立於操做系統，總體性能獲得大量提升，加上多樣化的負載均衡策略，智能化的流量管理，可達到最佳的負載均衡需求。

負載均衡器有多種多樣的形式，除了做爲獨立意義上的負載均衡器外，有些負載均衡器集成在交換設備中，置於服務器與Internet連接之間，有些則以兩塊網絡適配器將這一功能集成到PC中，一塊鏈接到Internet上，一塊鏈接到後端服務器羣的內部網絡上。

通常而言，硬件負載均衡在功能、性能上優於軟件方式，不過成本昂貴。

本地/全局

負載均衡從其應用的地理結構上分爲本地負載均衡(Local Load Balance)和全局負載均衡(Global Load Balance，也叫地域負載均衡)

本地負載均衡是指對本地的服務器羣作負載均衡，全局負載均衡是指對分別放置在不一樣的地理位置、有不一樣網絡結構的服務器羣間做負載均衡。

本地負載均衡能有效地解決數據流量過大、網絡負荷太重的問題，而且不需花費昂貴開支購置性能卓越的服務器，充分利用現有設備，避免服務器單點故障形成數據流量的損失。其有靈活多樣的均衡策略把數據流量合理地分配給服務器羣內的服務器共同負擔。即便是再給現有服務器擴充升級，也只是簡單地增長一個新的服務器到服務羣中，而不需改變現有網絡結構、中止現有的服務。

全局負載均衡主要用於在一個多區域擁有本身服務器的站點，爲了使全球用戶只以一個IP地址或域名就能訪問到離本身最近的服務器，從而得到最快的訪問速度，也可用於子公司分散站點分佈廣的大公司經過Intranet（企業內部互聯網）來達到資源統一合理分配的目的。

全局負載均衡有如下的特色：

實現地理位置無關性，可以遠距離爲用戶提供徹底的透明服務。

除了能避免服務器、數據中心等的單點失效，也能避免因爲ISP專線故障引發的單點失效。

解決網絡擁塞問題，提升服務器響應速度，服務就近提供，達到更好的訪問質量。

 

4.反向代理

客戶端直接訪問的服務器並非直接提供服務的服務器，它從別的服務器獲取資源，而後將結果返回給用戶。

代理服務器和反向代理服務器：

代理服務器是代咱們訪獲取資源，而後將結果返回。例如，訪問外網的代理服務器。反向代理服務器是咱們正常訪問一臺服務器的時候，服務器本身調用了別的服務器。

反向代理就是說，用戶的請求請求到負載均衡的設備上，負載均衡設備再講請求分發到空閒的應用服務器上處理，處理完成以後再經過負載均衡設備返回給用戶，這樣對於用戶來講，後來的分發是不可見的。

反向代理的實現

1）須要有一個負載均衡設備來分發用戶請求，將用戶請求分發到空閒的服務器上

2）服務器返回本身的服務到負載均衡設備

3）負載均衡將服務器的服務返回用戶

代理服務器咱們主動使用，是爲咱們服務的，不須要有本身的域名；反向代理是服務器本身使用的，咱們並不知道，有本身的域名。

5.動靜分離

所謂動靜分離就是將網站靜態資源（HTML，JavaScript，CSS，img等文件）與後臺應用分開部署，提升用戶訪問靜態代碼的速度，下降對後臺應用訪問。上面的文件服務器就是動靜分離的一部分。

動靜分離的一種作法是將靜態資源部署在nginx上，後臺項目部署到應用服務器上，根據必定規則靜態資源的請求所有請求nginx服務器，達到動靜分離的目標。

靜態資源部署至CDN上

咱們的方案是直接將靜態資源所有存放在CDN服務器上。由於以前項目中的JavaScript,CSS以及img文件都是存放在CDN服務器上，將HTML文件一塊兒存放到CDN上以後，能夠將靜態資源統一放置在一種服務器上，便於前端進行維護；並且用戶在訪問靜態資源時，能夠很好利用CDN的優勢——CDN系統可以實時地根據網絡流量和各節點的鏈接、負載情況以及到用戶的距離和響應時間等綜合信息將用戶的請求從新導向離用戶最近的服務節點上。

後端API提供數據

後端應用提供API，根據前端的請求進行處理，並將處理結果經過JSON格式返回至前端。目前應用主要採用Java平臺開發，所以應用服務器主要是Tomcat服務器，如今也開始有部分應用採用 node進行開發，應用服務器也開始使用node服務器。

先後端域名

動靜分離由於靜態資源和應用服務分別部署在不一樣的服務器上，所以會面臨域名策略的選擇。

相同域名

採用相同域名下，用戶請求api時能夠避免跨域所帶來的問題，相對開發更爲快速，工做量也相對小一些。

不一樣域名

先後端採用不一樣域名時，須要先後端開發時兼容跨域請求的狀況，開發量相對上一種會稍多一些。解決跨域方式最經常使用的方式就是採用JSONP，還有一種解決方式使用CORS（HTTP訪問控制）容許某些域名下的跨域請求。

目前在咱們的項目中JSONP方式更多，CORS由於須要瀏覽器支持，所以只會在APP內嵌HTML5，且須要POST方式時中使用。

採用不一樣域名的方式優勢也是很是明顯的，不一樣域名採用兩個域名服務器，不一樣的域名服務器根據請求的不一樣採用不一樣的負載均衡策略；並且不一樣域名也能夠郵箱方式前端攜帶過多的Cookie。

 

優勢

api接口服務化：動靜分離以後，後端應用更爲服務化，只須要經過提供api接口便可，能夠爲多個功能模塊甚至是多個平臺的功能使用，能夠有效的節省後端人力，更便於功能維護。

先後端開發並行：先後端只須要關心接口協議便可，各自的開發相互不干擾，並行開發，並行自測，能夠有效的提升開發時間，也能夠有些的減小聯調時間

減輕後端服務器壓力，提升靜態資源訪問速度：後端不用再將模板渲染爲html返回給用戶端，且靜態服務器能夠採用更爲專業的技術提升靜態資源的訪問速度。

缺點

在開發中能夠採用前端緩存不常常變化數據的方式來解決，只有哪些常常發生變化的數據才每次向後端請求。

開發量變大，先後端交流成本升高：後端api返回的數據，每每是有自身邏輯在內的，好比返回數據中的包含status（1-處理中，2-處理成功，3-處理失敗），前端須要理解status的不一樣含義，對應的前端操做須要理解（如，status =1 or status = 2，不可提交）。

在業務高速發展時須要慎重考慮：由於開發量變大，若是在業務開始階段，缺少前端又要求開發速度很快，就須要慎重考慮這種方式的實現成本對業務發展的影響。

6.數據庫sql優化

對於相同功能的sql，若是數據庫的sql沒有作過優化和作過優化的sql比較起來，其處理能力徹底是天壤之別，其差距能夠有幾倍甚至幾十上百上千的速度差距、資源消耗差距。因此對於一個優秀的web應用，sql優化是必須作的。

7.緩存

對於緩存我想你們都不陌生，緩存可讓咱們將一些有時效性的、常常訪問的、不便於存儲數據庫等的數據，咱們能夠將數據存儲在專門的用於緩存的應用程序中，若是有必要，還能夠將緩存應用服務器單獨部署，若是數據量過大，咱們還能夠組成緩存服務器集羣，好比：cache、redis等都是比較專一於緩存數據的。

只因此使用緩存，是由於一是減小數據庫的訪問壓力，二是通常專一於緩存的應用對於數據的讀寫較於數據庫都是很是快的

8.數據庫讀寫分離

讀寫分離是爲了提供程序的性能，隨着用戶的增長，數據庫的壓力也會愈來愈大，對數據庫或者SQL的基本優化可能達不到最終的效果，讀寫分離簡單的說是把對數據庫讀和寫的操做分開對應不一樣的數據庫服務器，這樣能有效地減輕數據庫壓力，也能減輕io壓力。主數據庫提供寫操做，從數據庫提供讀操做。主數據庫提供寫操做，從數據庫提 供讀操做，其實在不少系統中，主要是讀的操做。當主數據庫進行寫操做時，數據要同步到從的數據庫，這樣纔能有效保證數據庫完整性。Quest SharePlex就是比較牛的同步數據工具，據說比oracle自己的流複製還好，mysql也有本身的同步數據技術。mysql只要是經過二進制日誌來複制數據。經過日誌在從數據庫重複主數據庫的操做達到複製數據目的。這個複製比較好的就是經過異步方法，把數據同步到從數據庫。

固然一樣的由於數據的複製同步須要時間，對於一些實時性要求很是高的邏輯可能會有問題。

9.數據庫活躍數據分離

所謂的活躍數據就是常常用到的數據，好比常常活躍的用戶數據等。不活躍數據，好比好長時間不等路的用戶數據，還有幾個月前的數據等等。

對於這種不活躍的數據參與到查詢中，會很大的拖累查詢速度嗎，因此講非活躍數據單獨同步到一個數據庫中，這樣大機率的查詢只須要查活躍數據的數據庫，只有活躍數據的數據庫查不到時，纔去查非活躍數據庫。

10.批量讀取和延遲修改

高併發狀況能夠將多個查詢請求合併到一個。同一查詢，同一返回處理，下降短期內的數據庫請求數量。高併發且頻繁修改的能夠暫存緩存中，而後統一進行修改。

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

一般對於一個服務器的處理的瓶頸大多在於數據庫的瓶頸，對於大數據量的請求處理，單個數據庫處理能力有限，因此咱們能夠部署多個數據庫，而後將數據庫組成一個集羣。

對於數據庫集羣，每一個成熟的數據庫都有本身的解決方案，咱們按照方案進行擴展便可。

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