在大型**中,我們不得不面臨高併發的問題,下面分別介紹一些解決方案。
當併發量達到一定程度時,我們可以將靜態資源儲存到專門的伺服器中,這樣主伺服器就可以盡量只處理業務相關的操作。
頁面快取是將應用生成的頁面快取起來,這樣就不需要每次都重新生成頁面,從而節省大量cpu資源。如果靜態頁面中有動態資料,只需在頁面載入成功後非同步拉取最新的伺服器資料即可。常用的框架 freeemarker 和 velocity 都可以根據模板生成靜態頁面。
集群和分布式處理都是使用多台伺服器進行處理的,集群是每台伺服器都具有相同的功能,處理請求時呼叫哪台伺服器都可以,主要起分流的作用。集群有兩種方式:一種是靜態資源集群,另一種是應用程式集群。
應用程式集群的核心問題就是快取資料,這裡可以使用快取框架memcached。應用程式集群如下所示:
反向**指的是客戶端直接訪問的伺服器並不真正提供服務,它從別的伺服器獲取資源然後將結果返回給使用者。反向**和我們常說的vpn**伺服器是有區別的,vpn是我們訪問某個資源失敗,通過一台**伺服器去訪問然後返回結果。反向**是我們能夠訪問伺服器,但是伺服器內部呼叫了別的伺服器來完成業務。
cdn 是一種特殊的集群頁面快取伺服器。cdn的伺服器遍布全國各地的,當接收到使用者的請求後會將請求分配到最合適的 cdn 伺服器節點獲取資料,比如聯通的使用者訪問聯通的節點。
時間描述
2017-09-24
博文完成
csdn:
github:
高併發解決方案
時常看到高併發的問題,但高併發其實是最不需要考慮的東西。為何,他虛無縹緲,很少有 真的需要這些東西,而且其中很多技術,其實你已經在用了。有這個意識就夠了,不需要時刻盯著這個問題。只有很少的 真的能達到高併發。簡單做乙個歸納,從低成本 高效能和高擴張性的角度來說有如下處理方案 1 html靜態化 2 ...
高併發解決方案
將靜態資源分離到靜態站,對靜態資源的請求打到靜態站,增加動態站的請求處理量 頁面靜態化是將程式生成的頁面儲存起來,使用模板技術如freemarker和velocity生成靜態頁面 nginx快取頁面資訊,再次請求時直接從快取中獲取,不需要重新生成,頁面快取記憶體中,提高訪問速度 具有相同處理功能的伺...
高併發解決方案
秒殺場景一般會在電商 舉行一些活動或者節假日在12306 上搶票時遇到。對於電商 中一些稀缺或者 商品,電商 一般會在約定時間點對其進行限量銷售,因為這些商品的特殊性,會吸引大量使用者前來搶購,並且會在約定的時間點同時在秒殺頁面進行搶購。限流 鑑於只有少部分使用者能夠秒殺成功,所以要限制大部分流量,...