大型網站架構“三高”(高併發、高可用、高性能)

来源:https://www.cnblogs.com/rainbow-1/archive/2022/05/20/16293543.html
-Advertisement-
Play Games

從演化歷史看大型網站架構 楊傳偉 (石家莊鐵道大學信息科學與技術學院,河北省,石家莊市,050043) 摘 要:本文以大型網站系統的特點、大型網站架構演化發展歷程以及大數據與高併發為切入和論述點,由淺入深、由簡到繁地對大型網站架構設計展開敘述,首先通述其特點,之後介紹大型網站架構的歷史發展歷程,從其 ...


從演化歷史看大型網站架構

楊傳偉

(石家莊鐵道大學信息科學與技術學院,河北省,石家莊市,050043)

摘 要:本文以大型網站系統的特點、大型網站架構演化發展歷程以及大數據與高併發為切入和論述點,由淺入深、由簡到繁地對大型網站架構設計展開敘述,首先通述其特點,之後介紹大型網站架構的歷史發展歷程,從其發展歷程中總結出每一代架構是如何一步步發現問題並解決問題的。最後會以大數據和高併發為重點,著重介紹秒殺架構設計是如何實現高併發的。通過這篇文章,您可以對大型網站架構有一個整體的認識和瞭解。

關鍵詞:高併發;大數據;分散式

 


0  引言

一個成熟的大型網站(如淘寶、京東等)的系統架構並不是開始設計就具備完整的高性能、高可用、安全等特性,它總是隨著用戶量的增加,業務功能的擴展逐漸演變完善的,在這個過程中,開發模式、技術架構、設計思想也發生了很大的變化,就連技術人員也從幾個人發展到一個部門甚至一條產品線。所以成熟的系統架構是隨業務擴展而完善出來的,並不是一蹴而就;不同業務特征的系統,會有各自的側重點,例如淘寶,要解決海量的商品信息的搜索、下單、支付,例如騰訊,要解決數億的用戶實時消息傳輸,百度它要處理海量的搜索請求,他們都有各自的業務特性,系統架構也有所不同。儘管如此我們也可以從這些不同的網站背景下,找出其中共用的技術,這些技術和手段可以廣泛運行在大型網站系統的架構中,下麵就通過介紹大型網站系統的特點和演化過程,來認識這些技術和手段。

1  大型網站系統的特點

高併發,大流量:需要面對高併發用戶,大流量訪問。Google 日均 PV 35 億,日IP訪問數 3 億;騰訊 QQ 的最大線上用戶數 1.4 億 (2011年數據)。

高可用:系統 7 x 24 小時不間斷服務。

海量數據:需要存儲、管理海量數據,需要使用大量伺服器。Facebook 每周上傳的照片數量接近10 億,百度收錄的網頁數目有數百億,Google 有近百萬台伺服器為全球用戶提供服務。

用戶分佈廣泛,網路情況複雜:許多大型互聯網站都是為全球用戶提供服務的,用戶分佈範圍廣,各地網路情況千差萬別。在國內,還有各個運營   商網路互通困難的問題。

安全環境惡劣:由於互聯網的開放性,使得互聯網站更容易受到攻擊,大型網站幾乎每天都會被黑客攻擊。

需求快速變更,發佈頻繁:和傳統軟體的版本發佈頻率不同,互聯網產品為快速適應市場,滿足用戶需求,其產品發佈頻率極高。一般大型網站的產品每周都有新版本發佈上線,中小型網站的發佈更頻繁,有時候一天會發佈幾十次。

漸進式發展:幾乎所有的大型互聯網網站都是從一個小網站開始,漸進地發展起來的。Facebook是扎克伯格同學在哈佛大學的宿舍里開發的;Google的第一臺伺服器部署在斯坦福大學的實驗室;阿裡巴巴是在馬雲家的客廳誕生的。好的互聯網產品都是慢慢運營出來的,不是一開始就開發好的,這也正好與網站架構的發展演化過程對應。

2 大型網站架構演化發展歷程

2.1 初始階段的網站架構

大型網站都是從小型網站發展而來,網站架構也是一樣,是從小型網站架構逐步演化而來。小型網站最開始沒有太多人訪問,只需要一臺伺服器就綽綽有餘,這時的網站架構如下圖所示:

應用程式、資料庫、文件等所有資源都在一臺伺服器上。

        圖2-1 初始網站架構

2.2 應用服務和數據服務分離

隨著網站業務的發展,一臺伺服器逐漸不能滿足需求:越來越多的用戶訪問導致性能越來越差,越來越多的數據導致存儲空間不足。這時就需要將應用和數據分離。應用和數據分離後整個網站使用3台伺服器:應用伺服器、文件伺服器和資料庫伺服器。這3台伺服器對硬體資源的要求各不相同:

(1)應用伺服器需要處理大量的業務邏輯,因此需要更快更強大的CPU;

(2)資料庫伺服器需要快速磁碟檢索和數據緩存,因此需要更快的磁碟和更大的記憶體;

(3)文件伺服器需要存儲大量用戶上傳的文件,因此需要更大的硬碟。

 

 

 

圖2-2 應用服務與數據服務分離

2.3 使用緩存改善網站性能

網站訪問的特點和現實世界的財富分配一樣遵循二八定律:80% 的業務訪問集中在20% 的數據上。既然大部分業務訪問集中在一小部分數據上,那麼如果把這一小部分數據緩存在記憶體中,就可以減少資料庫的訪問壓力,提高整個網站的數據訪問速度,改善資料庫的寫入性能了。網站使用的緩存可以分為兩種:緩存在應用伺服器上的本地緩存和緩存在專門的分散式緩存伺服器上的遠程緩存。

(1)本地緩存的訪問速度更快一些,但是受應用伺服器記憶體限制,其緩存數據量有限,而且會出現和應用程式爭用記憶體的情況。

(2)遠程分散式緩存可以使用集群的方式,部署大記憶體的伺服器作為專門的緩存伺服器,可以在理論上做到不受記憶體容量限制的緩存服務。

 

圖2-3 緩存改善性能

2.4 使用應用伺服器集群改善網站的併發處理能力

使用集群是網站解決高併發、海量數據問題的常用手段。當一臺伺服器的處理能力、存儲空間不足時,不要企圖去更換更強大的伺服器,對大型網站而言,不管多麼強大的伺服器,都滿足不了網站持續增長的業務需求。這種情況下,更恰當的做法是增加一臺伺服器分擔原有伺服器的訪問及存儲壓力。對網站架構而言,只要能通過增加一臺伺服器的方式改善負載壓力,就可以以同樣的方式持續增加伺服器不斷改善系統性能,從而實現系統的可伸縮性。應用伺服器實現集群是網站可伸縮架構設計中較為簡單成熟的一種,如下圖所示:

 

圖2-4 應用伺服器集群

2.5 使用反向代理和CDN加速網站響應

隨著網站業務不斷發展,用戶規模越來越大,由於中國複雜的網路環境,不同地區的用戶訪問網站時,速度差別也極大。有研究表明,網站訪問延遲和用戶流失率正相關,網站訪問越慢,用戶越容易失去耐心而離開。為了提供更好的用戶體驗,留住用戶,網站需要加速網站訪問速度。主要手段有使用 CDN 和方向代理。如下圖所示:

 

圖2-5 反向代理和CDN加速

2.6 使用分散式文件系統和分散式資料庫系統

任何強大的單一伺服器都滿足不了大型網站持續增長的業務需求。資料庫經過讀寫分離後,從一臺伺服器拆分成兩台伺服器,但是隨著網站業務的發展依然不能滿足需求,這時需要使用分散式資料庫。文件系統也一樣,需要使用分散式文件系統。分散式資料庫是網站資料庫拆分的最後手段,只有在單表數據規模非常龐大的時候才使用。不到不得已時,網站更常用的資料庫拆分手段是業務分庫,將不同業務的數據部署在不同的物理伺服器上。如下圖所示:

 

圖2-6 分散式文件系統和資料庫

2.7分散式微服務

隨著業務拆分越來越小,存儲系統越來越龐大,應用系統的整體複雜度呈指數級增加,部署維護越來越困難。由於所有應用要和所有資料庫系統連接,在數萬台伺服器規模的網站中,這些連接的數目是伺服器規模的平方,導致資料庫連接資源不足,拒絕服務。

既然每一個應用系統都需要執行許多相同的業務操作,比如用戶管理、商品管理等,那麼可以將這些共用的業務提取出來,獨立部署。由這些可復用的業務連接資料庫,提供共用業務服務,而應用系統只需要管理用戶界面,通過分散式服務調用共用業務服務完成具體業務操作。如下圖所示:

 

圖2-7 分散式微服務

3 秒殺架構設計

什麼是秒殺?通俗一點講就是網路商家為促銷等目的組織的網上限時搶購活動。

比如說京東秒殺,就是一種定時定量秒殺,在規定的時間內,無論商品是否秒殺完畢,該場次的秒殺活動都會結束。這種秒殺,對時間不是特別嚴格,只要下手快點,秒中的概率還是比較大的。 淘寶以前就做過一元搶購,一般都是限量 1 件商品,同時價格低到令人發齒,這種秒殺一般都在開始時間 1 到 3 秒內就已經搶光了,參與這個秒殺一般都是看運氣的,不必太強求。

3.1 秒殺業務特點

瞬時併發量大:秒殺時會有大量用戶在同一時間進行搶購,瞬時併發訪問量突增 10 倍,甚至 100 倍以上都有。

庫存量少:一般秒殺活動商品量很少,這就導致了只有極少量用戶能成功購買到。

業務簡單:流程比較簡單,一般都是下訂單、扣庫存、支付訂單。

3.2 技術難點

現有業務的衝擊:秒殺是營銷活動中的一種,如果和其他營銷活動應用部署在同一伺服器上,肯定會對現有其他活動造成衝擊,極端情況下可能導致整個電商系統服務宕機。

直接下訂單:下單頁面是一個正常的 URL  地址,需要控制在秒殺開始前,不能下訂單,只能瀏覽對應活動商品的信息。簡單來說,需要 Disable 訂單按鈕。

頁面流量突增:秒殺活動開始前後,會有很多用戶請求對應商品頁面,會造成後臺伺服器的流量突增,同時對應的網路帶寬增加,需要控制商品頁面的流量不會對後臺伺服器、DB、Redis 等組件的造成過大的壓力

3.3 架構設計思想

限流:由於活動庫存量一般都是很少,對應的只有少部分用戶才能秒殺成功。所以我們需要限制大部分用戶流量,只准少量用戶流量進入後端伺服器。

削峰:秒殺開始的那一瞬間,會有大量用戶衝擊進來,所以在開始時候會有一個瞬間流量峰值。如何把瞬間的流量峰值變得更平緩,是能否成功設計好秒殺系統的關鍵因素。實現流量削峰填谷,一般的採用緩存和MQ中間件來解決。

非同步:秒殺其實可以當做高併發系統來處理,在這個時候,可以考慮從業務上做相容,將同步的業務,設計成非同步處理的任務,提高網站的整體可用性。

緩存:秒殺系統的瓶頸主要體現在下訂單、扣減庫存流程中。在這些流程中主要用到 OLTP 的資料庫,類似 MySQL、 SQLServer、Oracle。由於資料庫底層採用 B+ 樹的儲存結構,對應我們隨機寫入與讀取的效率,相對較低。如果我們把部分業務邏輯遷移到記憶體的緩存或者 Redis 中,會極大的提高併發效率。

3.4 總結

秒殺系統核心在於層層過濾,逐漸遞減瞬時訪問壓力,減少最終對資料庫的衝擊。通過上面流程圖就會發現壓力最大的地方在哪裡?

MQ 排隊服務,只要 MQ  排隊服務頂住,後面下訂單與扣減庫存的壓力都是自己能控制的,根據資料庫的壓力,可以定製化創建訂單消費者的數量,避免出現消費者數據量過多,導致資料庫壓力過大或者直接宕機。

庫存服務專門為秒殺的商品提供庫存管理,實現提前鎖定庫存,避免超賣的現象。同時通過超時處理任務發現已搶到商品,但未付款的訂單,併在規定付款時間後,處理這些訂單,將恢復訂單商品對應的庫存量。整體架構如下圖所示:

 

 

 

參考文獻:

[1] 阿裡巴巴面試官手冊

[2] 簡書 互聯網三高架構:高併發、高性能、高可用 作者pigness

   https://www.jianshu.com/p/fd8ff58ba5d2

好看請贊,養成習慣!

本文來自博客園,作者:靠譜楊,轉載請註明原文鏈接:https://www.cnblogs.com/rainbow-1/p/16293543.html


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • 在音視頻應用中我們經常涉及到耳機麥克風和設備麥克風的切換。不同聲道的配置。在遇到這種情況的時候,我們如何配置呢? 耳返即耳機採集監聽,在設備上插入耳機(普通耳機或藍牙耳機)後,能從本機耳機側聽到本設備麥克風采集的聲音。 雙聲道即兩個聲音通道,聽到聲音時可以根據左耳和右耳對聲音相位差來判斷聲源的具體... ...
  • 對於運營者來說,消息推送一直是提升用戶活躍與轉化的重要工具,如何在提升轉化的情況下,同時不降低用戶的接受程度,這一直是運營不斷追求的目標。 好的推送不只在於優質的推送內容,還需要把握合適的時機。在合適時機把用戶喜歡的內容推送給他們,才能有效促進推送轉化。作為一名用戶,大家每天都會在各個時間點收到不同 ...
  • 堆積了兩天一起發的,先祝大家節日快樂 後面任務很繁重,還有登錄註冊組件還有後臺管理頁面,真的繁重,我現在感覺每天全天時間都在學都不一定學得完,主要想在六月一號之前把整個項目過一遍。看看能不能創造奇跡 一.防抖和節流 拋出一個問題,就是我們的三級聯動,正常情況你慢慢的去滑動是沒有bug的,但是當你快速 ...
  • 一、引言 繼上次實現文件上傳功能後,產品經理又提出了新的需求:上傳圖片預覽及進度條效果。本次就來搞定這個功能,這次開發基於上次的隨筆,需要的小伙伴們自取 -- 如何使用Ajax實現簡單的文件上傳。 二、瞭解原理 要想實現文件預覽效果,這裡使用的是 FileReader 對象。使用它的 readAsD ...
  • /* 下述代碼近供參考 水仙花數是指一個3位數,它的每個位上的數字3次冪之和等於它本身。 例如:(1的3次方+5的3次方+3的3次方=153),請列印所有的水仙花數。 */ // 第一種方式 for(var a=0;a<10;a++) { for(var b=0;b<10;b++) { for( v ...
  • in操作符作用: 遍歷類型 基本用法 type roles = "tester" | "developer" | "manager"; const staffCount: { [k in roles]: number } = { tester: 100, developer: 200, manage ...
  • 索引:對象或數組的對應位置的名字 數組的索引就是 number 類型的 0,1,2,3... 對象的索引就是 string 類型的屬性名 數字索引簽名:通過定義介面用來約束數組 type numberIndex{ [index:number]:string } const testArray:num ...
  • DRY原則 DRY 原則,它的英文描述為:Don’t Repeat Yourself。中文直譯為:不要重覆自己。也可以理解為:不要寫重覆的代碼。 我們從實現邏輯重覆、功能語義重覆和代碼執行重覆,這三種代碼重覆來說明DRY原則。 實現邏輯重覆 例如有兩個函數isValidUserName() 和 is ...
一周排行
    -Advertisement-
    Play Games
  • 前言 本文將以 C# 語言來實現一個簡單的布隆過濾器,為簡化說明,設計得很簡單,僅供學習使用。 感謝@時總百忙之中的指導。 布隆過濾器簡介 布隆過濾器(Bloom filter)是一種特殊的 Hash Table,能夠以較小的存儲空間較快地判斷出數據是否存在。常用於允許一定誤判率的數據過濾及防止緩存 ...
  • 目錄 一.簡介 二.效果演示 三.源碼下載 四.猜你喜歡 零基礎 OpenGL (ES) 學習路線推薦 : OpenGL (ES) 學習目錄 >> OpenGL ES 基礎 零基礎 OpenGL (ES) 學習路線推薦 : OpenGL (ES) 學習目錄 >> OpenGL ES 轉場 零基礎 O ...
  • 「簡單有價值的事情長期堅持做」 這是成功最簡單,但也最難學的秘訣。不經過訓練,人很難意識到時間複利的威力。 仙劍奇俠傳的「十里坡劍神」和金庸群俠傳的「十級野球拳」,就是簡單的事情持之以恆反覆做,最後就有巨大的威力 唐家三少成為網文收入第一,最重要的一步是十四年從未斷日更 這樣的案例很多,一開始可能成 ...
  • 迎面走來了你的面試官,身穿格子衫,挺著啤酒肚,髮際線嚴重後移的中年男子。 手拿泡著枸杞的保溫杯,胳膊夾著MacBook,MacBook上還貼著公司標語:“我愛加班”。 面試開始,直入正題。 面試官: 看你簡歷上面寫著精通MySQL,我先問你事務的特性是什麼? 老生常談,這個還有誰不會背的嗎? 我: ...
  • 基礎知識 python是一門腳本語言,它是解釋執行的。 python使用縮進做為語法,而且python2環境下同一個py文件中不能同時存在tab和空格縮進,否則會出錯,建議在IDE中顯示縮進符。 python在聲明變數時不寫數據類型,可以type(xx)來獲取欄位的類型,然後可以int(),list ...
  • 為什麼要多線程下載 俗話說要以終為始,那麼我們首先要明確多線程下載的目標是什麼,不外乎是為了更快的下載文件。那麼問題來了,多線程下載文件相比於單線程是不是更快? 對於這個問題可以看下圖。 橫坐標是線程數,縱坐標是使用對應線程數下載對應文件時花費的時間,藍橙綠代表下載文件的大小,每個線程下載對應文件2 ...
  • 詳細講解python爬蟲代碼,爬微博搜索結果的博文數據。 爬取欄位: 頁碼、微博id、微博bid、微博作者、發佈時間、微博內容、轉發數、評論數、點贊數。 爬蟲技術: 1、requests 發送請求 2、datetime 時間格式轉換 3、jsonpath 快速解析json數據 4、re 正則表達式提... ...
  • 背景: 一般我們可以用HashMap做本地緩存,但是HashMap功能比較弱,不支持Key過期,不支持數據範圍查找等。故在此實現了一個簡易的本地緩存,取名叫fastmap。 功能: 1.支持數據過期 2.支持等值查找 3.支持範圍查找 4.支持key排序 實現思路: 1.等值查找採用HashMap2 ...
  • 目錄 一.簡介 二.效果演示 三.源碼下載 四.猜你喜歡 零基礎 OpenGL (ES) 學習路線推薦 : OpenGL (ES) 學習目錄 >> OpenGL ES 基礎 零基礎 OpenGL (ES) 學習路線推薦 : OpenGL (ES) 學習目錄 >> OpenGL ES 轉場 零基礎 O ...
  • 本章是系列文章的第八章,用著色演算法進行寄存器的分配過程。 本文中的所有內容來自學習DCC888的學習筆記或者自己理解的整理,如需轉載請註明出處。周榮華@燧原科技 寄存器分配 寄存器分配是為程式處理的值找到存儲位置的問題 這些值可以存放到寄存器,也可以存放在記憶體中 寄存器更快,但數量有限 記憶體很多,但 ...