java Web高併發解決方案

以前我將高併發的解決方法誤認爲是線程或者是隊列能夠解決,由於高併發的時候是有不少用戶在訪問,致使出現系統數據不正確、丟失數據現象,因此想到 的是用隊列解決,其實隊列解決的方式也能夠處理,好比咱們在競拍商品、轉發評論微博或者是秒殺商品等,同一時間訪問量特別大,隊列在此起到特別的做用,將 全部請求放入隊列,以毫秒計時單位,有序的進行,從而不會出現數據丟失系統數據不正確的狀況。html

今天我通過查資料,高併發的解決方法有倆種,一種是使用緩存、另外一種是使用生成靜態頁面;還有就是從最基礎的地方優化咱們寫代碼減小沒必要要的資源浪費:(java

1.不要頻繁的new對象,對於在整個應用中只須要存在一個實例的類使用單例模式.對於String的鏈接操做,使用StringBuffer或者StringBuilder.對於utility類型的類經過靜態方法來訪問。程序員

2. 避免使用錯誤的方式,如Exception能夠控制方法推出,可是Exception要保留stacktrace消耗性能,除非必要不要使用 instanceof作條件判斷,儘可能使用比的條件判斷方式.使用JAVA中效率高的類,好比ArrayList比Vector性能好。)web

首先緩存技術我一直沒有使用過,我以爲應該是在用戶請求時將數據保存在緩存中,下次請求時會檢測緩存中是否有數據存在,防止屢次請求服務器,致使服務器性能下降,嚴重致使服務器崩潰,這只是我本身的理解,詳細的資料仍是須要在網上收集;數據庫

使用生成靜態頁面我想你們應該不模式,咱們見過不少網站當在請求的時候頁面的後最已經變了,在轉換成htm後,訪問速度將提高,由於靜態頁面不帶有服務器組件;在這裏我就多多介紹一下:緩存

1、什麼是頁面靜態化:安全

簡 單的說,咱們若是訪問一個連接 ,服務器對應的模塊會處理這個請求,轉到對應的jsp界面,最後生成咱們想要看到的數據。這其中的缺點是顯而易見的:由於每次請求服務器都會進行處理,如 果有太多的高併發請求,那麼就會加劇應用服務器的壓力,弄很差就把服務器 搞down 掉了。那麼如何去避免呢?若是咱們把對 test.do 請求後的結果保存成一個 html 文件,而後每次用戶都去訪問 ,這樣應用服務器的壓力不就減小了?服務器

那麼靜態頁面從哪裏來呢?總不能讓咱們每一個頁面都手動處理吧?這裏就牽涉到咱們要講解的內容了,靜態頁面生成方案… 咱們須要的是自動的生成靜態頁面,當用戶訪問 ,會自動生成 test.html ,而後顯示給用戶。mybatis

2、下面咱們在簡單介紹一下要想掌握頁面靜態化方案應該掌握的知識點:併發

一、 基礎- URL Rewrite

什麼是 URL Rewrite 呢 ? URL 重寫。用一個簡單的例子來講明問題:輸入網址 ,可是實際上訪問的倒是 abc.com/test.action,那咱們就能夠說 URL 被重寫了。這項技術應用普遍,有許多開源的工具能夠實現這個功能。

二、 基礎- Servlet web.xml

若是你還不知道 web.xml 中一個請求和一個 servlet 是如何匹配到一塊兒的,那麼請搜索一下 servlet 的文檔。這可不是亂說呀,有不少人就認爲 /xyz/*.do 這樣的匹配方式能有效。

若是你還不知道怎麼編寫一個 servlet ,那麼請搜索一下如何編寫 servlet.這可不是說笑呀,在各類集成工具漫天飛舞的今天,不少人都不會去從零編寫一個 servlet了。

3、基本的方案介紹

java高併發,如何解決,什麼方式解決 - 我學坊 - 勵志-我學坊

其中,對於 URL Rewriter的部分,可使用收費或者開源的工具來實現,若是 url不是特別的複雜,能夠考慮在 servlet 中實現,那麼就是下面這個樣子:

 

java高併發,如何解決,什麼方式解決 - 我學坊 - 勵志-我學坊

 

總 結:其實咱們在開發中都不多考慮這種問題,直接都是先將功能實現,當一個程序員在幹到1到2year,就會感受光實現功能不是最主要的,安全性能、質量等等纔是 一個開發人員最該關心的。今天我所說的是高併發,個人解決思路是,一、採用分佈式應用設計二、分佈式緩存數據庫三、代碼優化

Maven,Springmvc mybatis shiro, Druid, Restful, Dubbo, ZooKeeper,Redis,FastDFS,ActiveMQ,Nginx 
1.     項目核心代碼結構截圖

分佈式框架介紹 - kafkaee - kafkaee的博客

   項目模塊依賴

分佈式框架介紹 - kafkaee - kafkaee的博客

特別提醒:開發人員在開發的時候能夠將本身的業務REST服務化或者Dubbo服務化

2.    項目依賴介紹

   2.1 後臺管理系統、Rest服務系統、Scheculer定時調度系統依賴以下圖:

 

分佈式框架介紹 - kafkaee - kafkaee的博客

       2.2 Dubbo獨立服務項目依賴以下圖:

 

分佈式框架介紹 - kafkaee - kafkaee的博客

3.  項目功能部分截圖:

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客
 

zookeeper、dubbo服務啓動 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客
 

dubbo管控臺 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 REST服務平臺

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

 

分佈式框架介紹 - kafkaee - kafkaee的博客

相關文章
相關標籤/搜索