大話 | 大話程序猿眼裏最全的高併發,快收藏!

Hi ! 我是小小,今天是本週的第六篇,本月的最後一篇,你還好嗎?我是小小,咱們本週的內容是大話高併發架構

前言

高併發常常會發生在有大量用戶量,用戶高彙集的業務場景,例如秒殺活動,定時領取紅包。
爲了讓業務能夠在高併發的時候可以至關好的運行,並給用戶一個良好的交互體驗,因此,考慮各類高併發的場景,設計高併發架構。css

服務器架構

業務從初期到成熟,從單一到集羣,最後到分佈式,須要有服務器的負載均衡,數據的主從複製,nosql的各類集羣,靜態文件上傳cdn等等。
須要用到的服務器架構以下html

服務器

負載均衡,如阿里雲的slb 或者是nginx
資源監控
分佈式node

數據庫

主從分離,集羣
DBA表優化,索引優化
分佈式mysql

nosql

redis:主從分離,集羣
mongodb: 主從分離,集羣
memcache:主從分離,集羣nginx

cdn

html
css
js
imageweb

併發測試

對於高併發業務,須要進行高併發的業務測試,經過大量的數據分析評估整個架構支撐的併發量。
測試併發使用的工具以下
阿里雲性能測試
jmetter
visual studio 性能負載測試
Microsoft Web Application Stress Toolredis

實現方案

通用方案

日用戶流量大,可是比較分散,偶爾會有用戶聚合的狀況sql

場景

用戶簽到,用戶中心,用戶訂單mongodb

服務器架構

說明

這些場景,基本都是用戶進入app後會操做,這些用戶不會高彙集,同時這些表又是大的數據表,業務不少,因此須要減小DB的查詢,優先查詢緩存,若是緩存不存在,再命中DB。
因此須要使用緩存,爲了下降緩存,因此使用分佈式的緩存,對DB實現hash分組,把用戶分佈到不一樣的緩存中,不會影響查詢效率。數據庫

方案

用戶簽到

  1. 計算用戶分佈的key,redis hash中查找用戶今日簽到的消息
  2. 能查詢到,返回查詢的信息
  3. 若是沒有查詢到,DB查詢今日是否搶到過,若是搶到過,信息同步redis
  4. 若是db也沒有查詢到,進行簽到邏輯,db添加今日簽到記錄。這是一個事物
  5. 緩存簽到信息到redis,返回簽到信息

用戶訂單

  1. 這裏只緩存第一頁訂單信息
  2. 用戶訪問訂單列表,若是是第一頁讀緩存,若是不是讀DB
  3. 計算出用戶分佈的key,redis hash中查找用戶訂單信息
  4. 若是能查詢到用戶訂單信息,返回訂單信息
  5. 若是不存在用戶信息,就直接db查詢第一頁 訂單數據,而後緩存redis,返回訂單信息

用戶中心

  1. 計算用戶key,redis hash 中查找出用戶訂單信息
  2. 能查找到,返回用戶信息
  3. 若是未找到,緩存redis,返回用戶信息
以上的僅僅是一個相對於比較簡單的併發架構

消息隊列

用於緩存秒殺,活動,用戶在一瞬間涌入產生的高併發的請求

場景:

定時領取紅包。

架構

說明

場景中的定時領取是一個高併發的業務,秒殺活動會在一瞬間涌入。
這種業務會直接命中DB,會致使數據的崩潰。
設計這種業務的時候,須要使用消息隊列,能夠把參與的用戶信息添加到消息隊列中,而後緩慢的消耗。

方案

  1. 定時領取紅包:
    使用redis的list
    當用戶參與活動,用戶信息push到隊列中
    書寫多個線程去pop數據,進行發放紅包的業務。

一級緩存

一級緩存就是使用站點服務器去緩存數據,只緩存部分請求量大的數據,而且數據量還須要控制,一級緩存須要設置秒爲單位的過時時間,具體業務場景看業務場景而定,目的是有高併發的時候可讓數據獲取命中到一級緩存,減小nosql的壓力。

架構圖

場景

APP首屏的數據接口

靜態化數據

對於更新不頻繁,而且數據容許短期內的延遲,能夠經過數據靜態化成json,xml,html等數據文件上傳cdn,而後拉取數據的時候優先拉取cdn,而後再緩存,最後數據庫,用於減輕db的壓力。

分層,分割,分佈式

大型網站須要很好的支撐高併發,這須要很長的規劃設計,主要須要以下

  1. 分層:
    系統在橫向維度切分紅幾個部分,每一個部門負責一部分相對簡單而且單一的職責,而後經過上層,對下層的完整依賴造成一個完整的系統。
    例如把一個電商分爲,應用層,服務層,數據層。
    應用層:網站首頁,用戶中心
    服務層:訂單服務,用戶管理服務
    數據層:關係型數據庫,nosql數據庫。
  2. 分割
    在縱向對業務進行切分
    例如,用戶中心能夠分割成爲帳戶信息模塊,訂單模塊,充值模塊,提現模塊,優惠券模塊
  3. 分佈式
    分佈式應用和服務,把應用進行分佈式部署。
    當業務達到必定用戶量的時候,須要對服務器進行負載均衡,數據庫,緩存主從集羣
    分佈式靜態資源,靜態資源上傳cdn
    分佈式計算,使用hadoop進行大數據分佈式計算

集羣

對於用戶訪問集中的服務器,搭建集羣,經過負載均衡共同對外提供服務,當有更多的用戶訪問的時候,只須要加機器便可。

ngixn反向代理
slb
數據庫的主從分離

異步

在高併發業務場景中,若是涉及到數據庫操做,主要壓力是在數據庫服務器上,當鏈接數量達到最大值的時候,有其餘鏈接數據庫的請求操做的時候,就須要有空閒的鏈接。

場景

自動彈窗簽到
雙十一搶紅包
雙十一訂單入庫

設計

使用消息隊列,把入庫的內容放入到消息隊列中,業務接口直接返回提示,高峯期延遲到帳。
而後再寫獨立程序從消息隊列中,讀取進行入庫操做,入庫成功之後刷新緩存,若是入庫失敗,記錄日誌,方便查詢反饋和從新持久化。

補充

其餘場景,例如短信發送

面向服務

soa 面向服務架構設計
微服務更加細膩度的服務化。

例子

用戶行爲跟蹤記錄統計

說明

經過上報應用模塊,操做事件,事件對象,等數據,記錄用戶操做行爲。
例如用戶在某個商品模塊點擊了某一件商品,或者看了某一件商品。

架構

node.js web 應用負載均衡
redis主從集羣
mysql主從複製
nodejs + express + ejs + redis + mysql

冗餘自動化

當高併發業務出現單擊的時候,須要快速的有備用的替代,因此須要自動化執行這些操做

冗餘

數據庫備份
備份服務器

自動化

自動化監控
自動化報警
自動化降級

關於做者

我是小小,一枚生於二線,活在一線城市的程序猿,我是小小,咱們下期再見。image

相關文章
相關標籤/搜索