您好,歡迎訪問北京冠龍騰翔科技有限公司官網!
010-82326623
13146754585
戴爾DELL服務器報價,戴爾二手服務器,惠普服務器報價,惠普二手服務器,北京戴爾服務器
您的位置:主頁 > 新聞動態 > 行業新聞 >
聯系我們

戴爾DELL服務器報價,戴爾二手服務器,惠普服務器報價,惠普二手服務器,北京戴爾服務器

地址:北京市海淀區學院路29號眷16號樓3單元二層202
手機:13146754585

咨詢熱線010-82326623

高并發下的服務器架構高并發場景演變

發布時間:2021-03-11 09:17人氣:

在如間的網絡環境下,高并發的場景無處不在,特別在面試如何解決高并發是一個躲不過的問題,即使生產環境達不到那么高的qps但是也應該給自己留條后路來應對日后可能發生的高并發場景,不用匆忙的加班加點的進行重構。

在應對日常高并發場景常常會有這么幾個方法:

集群&負載均衡SLB讀寫分離&分庫分表緩存異步隊列(RebbitMQ)分布式系統、微服務接下來就由淺入深分別來介紹下這幾個方法是怎么應用到服務器并且解決高并發的,首先我們先來看下最原始的也是最簡單的服務器與應用程序關系。

圖1

如圖1所示在一臺服務器上承載了數據庫、文件系統、應用程序的所有功能,這就導致即使低qps的情況下服務器的內存或者cpu占比都非常高,用過sqlserver的同僚們都知道為了達到最高效快速的數據查詢、存儲及運算支持sql server默認會盡可能的占用內存及CPU來達到自己的目的,從而導致我們的應用程序在處理一些運算或者請求量相對升高時應用程序就會變得非常慢,這時候我們就該考慮升級我們現有的服務器了,當然最高效也是最便捷的方式是升級硬件(cpu、內存、硬盤),這也是最容易達到瓶頸的畢竟一臺服務的硬件也是有瓶頸的而且費用也是相當相當高昂的,一般情況下我們會選擇我們最開始提到解決高并發方法中分布式來升級我們圖1的單一服務器系統架構。

圖2

如圖2所示我們由一臺服務器轉為三臺服務器互相協作的方式來處理每次請求,這也是簡單的分布式系統每臺服務器各司其職再也不會發生單一應用占用大量cpu或內存的情況導致請求變得緩慢,但是就圖2而言的服務器架構的承載能力也是非常有限的,當請求量上升后可能就扛不住宕機了。

一般這時候我們就要分析發生宕機的原因,從圖2便知只有服務器A或者服務器B最有可能出現問題,根據以往的經驗在請求量升高時數據庫會承載絕大部分的壓力,如果數據庫崩了那么整個應用就會處于不可用的狀態,那么為了緩解數據庫的壓力,我們很自然的就會想到利用緩存,這也是高并發場景下最常用也是最有效最簡單的方案,利用好緩存能讓你的系統的承載能力提示幾倍甚至十幾倍幾十倍。熟悉二八原則的同僚們都知道80%請求的數據都集中在20%的數據上,雖然有些夸張但是意思就是這么個意思。緩存又分為本地緩存和分布式緩存,本著分布式的原則,我們一般都會選用分布式緩存同時也是為后期做分布式集群打下基礎。

圖3

如圖3所示在圖2的基礎上增加了一臺緩存服務器D來儲存我們的緩存數據,一般我們會采用redis來存放緩存數據,至于memcache現在應用的頻率是非常低的。現在當請求到達應用程序時會優先訪問緩存服務器D,若存在緩存數據就直接返回給客戶端如果不存在緩存數據才會去數據庫獲取數據返回給客戶端同時將數據保存到緩存服務器D設置緩存失效時間這樣下次請求時就不用到數據庫查詢數據了從而達到減輕數據庫壓力的目的。雖然緩存能抵擋大部分的請求,但是我們也要做好防止緩存擊穿、穿透和雪崩的問題來提升系統的穩定性。

隨著業務量的增多和繁多的業務種類圖3的系統架構也會慢慢達到瓶頸支撐不住多樣化的業務需求,這時候我們就應該采用集群的方式來達到負載均衡的目的,將請求平均的分散到多臺服務器來拓展應用程序的承載能力。

圖4

如圖示4所示由服務器A-1、服務器A-2共同承載用戶的請求來提高系統的承載能力也就是我們最開始說到集群,出現集群的地方必然少不了負載均衡,圖4我們由nginx來實現請求的分發來達到負載均衡的目的。在設計圖3的架構的時候我們有說到本地緩存,如果是采用本地緩存而不是分布式緩存那么系統架構就存在一個比較大的缺陷,因為一個請求過來是由nginx區分發的如果我們再用本地緩存那么在在服務器A-1和服務器A-2上可能存在大量相同的本地緩存這樣就得不償失了容易造成服務器資源的浪費嚴重的還會拖累服務器的性能,利用分布式緩存的好處在于我們不管有多少個應用服務器所有的緩存都是共享的。

圖4的服務器架構應該是目前中小型應用中最常用的,而且系統的整體承載能力也相當不錯,不過隨著業務的發展流量與日俱增,圖3的服務器架構也很難保證系統的穩定,特別是日常流量峰值的一些時段圖3的系統可能時常會面臨奔潰的危險,這時候就要重新分析各服務器的壓力承載情況了,顯而易見最可能出現問題的就是數據庫服務器,終于要對數據庫下手了,當下最有效的方法就是就寫分離,還是遵循二八原則80%的數據操作都是查詢操作。

圖5

如圖5所示在圖4的基礎上由單一的數據庫變為主從數據庫從庫負責數據的查詢操作主庫負責數據增刪改操作,但請求操作主庫后主庫將操作日志執行到從庫達到主從數據一致的目的,但是主從分離后不可能避免的一個問題就是主從數據一致性會有延遲,數據同步延遲的問題只能盡可能的減小數據延遲的時間,但對一些時效性非常高或者不能容忍數據延遲的請求只能做一些妥協,這類操作的crud都在主庫上操作這樣就避免數據延遲的問題,對一些對于數據時效性不那么嚴格的請求可以將這部分的查詢操作由從庫去承載,對于主從數據庫個人以為和應用集群是一樣的可以理解為集群數據庫只不過在請求的分發上制定了規則(主庫處理更新、從庫處理查詢)。

推薦資訊

?
010-82326623
丁香五月婷婷激情