導航:首頁 > 萬維百科 > 高並發高流量的大型網站架構設計

高並發高流量的大型網站架構設計

發布時間:2021-03-22 18:04:22

1、如何構建大型高並發網站架構

做網站首先考慮做什麼行業的網站,再者主要在網站上展示哪些內容,怎麼展示,再加上自己根據行業經驗的一些規劃,網站框架就出來了

2、用Java做一個大流量、高並發的網站應該怎麼樣進行底層構架?採用哪些框架技術比較適合?

一個字:分
分而治之,多級分流
瀏覽器端、伺服器前端、中間層、資料庫端
每個地方都有可以分流的可能

3、java開發大型網站(流量大,數據大(上萬G數據))用什麼架構?

分著說,前後台分開。
1、前端使用輕便的方式,servlet/jsp/jstl,使用jdbc或者能控制sql的ORM,不過坦白說用哪個都沒有SQL快,雖然hibernate也能控制sql生成,不會用。

2、前台要分析好,哪些是實時數據,哪些不是,對於那些不適實效很高的,用好緩存。有些東西可以採用生成靜態頁面的方式。

3、後台隨便了,SSH,因為後台操作不是很頻繁。但是如果有導數據,10萬級導入,還是用jdbc。

4、如果是網站,不是什麼重要的業務系統,資料庫設計以快為主,表裡面多冗餘一些外鍵欄位,讓查詢最簡化。

這個軟體方面,還有硬體架構,那更復雜,這里就不說了,畢竟不專業。

4、用Java做一個大流量,高並發的網站應該怎麼樣進行底層構架

架構是為了解決糸統中具有共性的問題而進行定義了減少重復工作量,且易於維護和擴展的技術准則和規范,它產出物和體現為文檔和基礎代碼框架等。
因此選擇那些框架只是架構的一部分,通常是選擇自己善長的,以及對新技術的更新比較及時的;所以現在的Java框架最多為SpringMVC。
所以你提出的大並發是一個問題,但先確定它是不是所有模塊都需要解決這個問題。
而大數據又是另一個問題,同樣每個模塊查詢或者計算都是大數據嗎。
綜上所述將問題定位並分解,並發問題,要考慮帶寬還是區域網,一個應用伺服器最大能支持多少請求連接,你需要多少個,每個應用伺服器是獨立的模塊呢還是齊群。齊群還要注意的登錄一次還是多次,也就是SSO了,是否注意內存共享,如sessionId,是否考慮內存相互同步還是通過分布式的解決等糸列問題。還有一個資料庫有多少連接可以用等跟應用伺服器同理。
那麼大數據呢,要考慮的關鍵為兩個,是計算還是查詢,是實時的業務要求還是可以延時的,查詢可以是緩存,分表分庫,分區,索引等方式。緩存的時候要注意你考慮的帶寬是一個lDC還是多個IDC,數據間怎麼同歩是個分布式問題,如果大數據計算問題是否考慮一下雲計算解決方案等

因此你所說的怎麼架構,如何選框架,這是兩個問題,不是解決你問的大數據大並發,反而是架構工作中的一個塵灰而已。你也知道架構最大的是那裡了吧一一分析到分割。

架構是很難的工作,作不好,別相信用硬體能解決問題。就像使用微軟的 盜版一樣,出了問題可能是用N的成本來解決,N可能是幾萬,也可能是幾萬的N次方。

5、高並發,大流量網站架構時你考慮網卡流量了嗎

肯定的,高流量站點必須考慮自己的寬頻能否帶的動自己的網站,一個100M的寬頻如果是一百個用戶同時訪問那麼就相當於分開就只有每個人1M的寬頻使用了

6、海量高並發系統架構該怎樣設計

高並發情況下要考慮的因素有很多:
伺服器並發處理能力、響應時間專;數據安全及一致性、鎖屬機制;數據存儲及訪問性能...

系統架構按層級(水平)劃分的話,在每一層都需要考慮好壓力的分配,以最前端的網路接入層為例,一般做法是在高配機器上部署支持高並發的web伺服器(如nginx)集群,後端映射個多個業務組件達到並發處理能力;在數據訪問方面充分做好緩存,包括數據緩存、頁面、甚至文件緩存,需要存儲大量數據的情況下則考慮分布式。

不同應用場景的架構設計都存在差異!

7、JAVA高吞吐高並發後端架構設計經驗是什麼意思

有些網站並發量比較高,例如:12306,到了春節的時候,訪問量就非常高回了。以前不是經常卡住、答崩潰嗎?
就是因為架構設計的不行。去年好多了。
高吞吐、高並發指的是一種種業務場景,訪問人數很多,同一時刻點擊也很多。

類似的還有雙十一,雙12。
高峰期的時候 涉及大量的讀寫操作,讀取網頁資源、數據,寫入訂單等等。
小型網站可以通過增加伺服器的方法解決,分離應用程序和資料庫,放在兩台伺服器上。
大型的網站涉及的技術就更多了:緩存技術、讀寫分離、分布式部署伺服器、業務拆分、資料庫優化等等。

8、怎樣具備大規模高並發訪問的Web應用架構設計和開發經驗

理論上經驗這個東西是學不來的.
說一下我的例子.
剛入行的時候,基本就是寫了一些增刪改查.甚至session都不太理解.
隨著入行後,你會遇到各種各樣的問題.在解決問題的過程中,經驗來了.

簡單說一下所謂大規模高並發訪問的web架構吧.

其實,對於大規模高並發不外乎兩點,第一點是及時相應(盡可能優化io).第二點是數據安全.

這兩點控制的好,就沒問題的.所以,我們的架構也就圍繞在這兩點應運而生.
第一點,為了盡可能提高應用的io吞吐量.則需要我們把所有耗時的io操作盡可能的優化,比如全局使用很少更改的一些配置,則可以採用nosql來全局共享(注意,這里的全局是指伺服器集群.如果涉及到了大規模,肯定是多伺服器的).在其次可以增加伺服器緩存.比如2秒鍾從上一條的伺服器讀取配置,存到伺服器級別.以提高效率.還有線程緩存.如果業務復雜可能對一個請求需要查詢多次數據,不變的,老規矩,放到線程緩存.基本也就差不多了.

第二點,因為應用不同,要考慮容錯率.這個部分優化,可以考慮分離業務,把必須要數據安全的業務邏輯提取出來,隊列執行或者特殊處理.

剩下的就是伺服器部署與如何分配,比如多少台web伺服器,資料庫配置,內存伺服器配置等.
這只能是在實際項目和工作過程中來區別對待了.

9、有哪些適合高並發、高流量、高性能網站開發的 PHP 框架推薦?

高並發,高流量,高性能的話,這些都不是php相關的問題,涉及到資料庫,伺服器架構等很多因素。到了這種級別的網站或者應用,php框架產生的影響已經比較小了。

與高並發高流量的大型網站架構設計相關的知識