Hi ! 我是小小,今天是本週的第六篇,本月的最後一篇,你還好嗎?我是小小,咱們本週的內容是大話高併發架構
高併發常常會發生在有大量用戶量,用戶高彙集的業務場景,例如秒殺活動,定時領取紅包。
爲了讓業務能夠在高併發的時候可以至關好的運行,並給用戶一個良好的交互體驗,因此,考慮各類高併發的場景,設計高併發架構。css
業務從初期到成熟,從單一到集羣,最後到分佈式,須要有服務器的負載均衡,數據的主從複製,nosql的各類集羣,靜態文件上傳cdn等等。
須要用到的服務器架構以下html
負載均衡,如阿里雲的slb 或者是nginx
資源監控
分佈式node
主從分離,集羣
DBA表優化,索引優化
分佈式mysql
redis:主從分離,集羣
mongodb: 主從分離,集羣
memcache:主從分離,集羣nginx
html
css
js
imageweb
對於高併發業務,須要進行高併發的業務測試,經過大量的數據分析評估整個架構支撐的併發量。
測試併發使用的工具以下
阿里雲性能測試
jmetter
visual studio 性能負載測試
Microsoft Web Application Stress Toolredis
日用戶流量大,可是比較分散,偶爾會有用戶聚合的狀況sql
用戶簽到,用戶中心,用戶訂單mongodb
這些場景,基本都是用戶進入app後會操做,這些用戶不會高彙集,同時這些表又是大的數據表,業務不少,因此須要減小DB的查詢,優先查詢緩存,若是緩存不存在,再命中DB。
因此須要使用緩存,爲了下降緩存,因此使用分佈式的緩存,對DB實現hash分組,把用戶分佈到不一樣的緩存中,不會影響查詢效率。數據庫
以上的僅僅是一個相對於比較簡單的併發架構
用於緩存秒殺,活動,用戶在一瞬間涌入產生的高併發的請求
定時領取紅包。
場景中的定時領取是一個高併發的業務,秒殺活動會在一瞬間涌入。
這種業務會直接命中DB,會致使數據的崩潰。
設計這種業務的時候,須要使用消息隊列,能夠把參與的用戶信息添加到消息隊列中,而後緩慢的消耗。
一級緩存就是使用站點服務器去緩存數據,只緩存部分請求量大的數據,而且數據量還須要控制,一級緩存須要設置秒爲單位的過時時間,具體業務場景看業務場景而定,目的是有高併發的時候可讓數據獲取命中到一級緩存,減小nosql的壓力。
APP首屏的數據接口
對於更新不頻繁,而且數據容許短期內的延遲,能夠經過數據靜態化成json,xml,html等數據文件上傳cdn,而後拉取數據的時候優先拉取cdn,而後再緩存,最後數據庫,用於減輕db的壓力。
大型網站須要很好的支撐高併發,這須要很長的規劃設計,主要須要以下
對於用戶訪問集中的服務器,搭建集羣,經過負載均衡共同對外提供服務,當有更多的用戶訪問的時候,只須要加機器便可。
在高併發業務場景中,若是涉及到數據庫操做,主要壓力是在數據庫服務器上,當鏈接數量達到最大值的時候,有其餘鏈接數據庫的請求操做的時候,就須要有空閒的鏈接。
自動彈窗簽到
雙十一搶紅包
雙十一訂單入庫
使用消息隊列,把入庫的內容放入到消息隊列中,業務接口直接返回提示,高峯期延遲到帳。
而後再寫獨立程序從消息隊列中,讀取進行入庫操做,入庫成功之後刷新緩存,若是入庫失敗,記錄日誌,方便查詢反饋和從新持久化。
soa 面向服務架構設計
微服務更加細膩度的服務化。
用戶行爲跟蹤記錄統計
經過上報應用模塊,操做事件,事件對象,等數據,記錄用戶操做行爲。
例如用戶在某個商品模塊點擊了某一件商品,或者看了某一件商品。
node.js web 應用負載均衡
redis主從集羣
mysql主從複製
nodejs + express + ejs + redis + mysql
當高併發業務出現單擊的時候,須要快速的有備用的替代,因此須要自動化執行這些操做
數據庫備份
備份服務器
自動化監控
自動化報警
自動化降級
我是小小,一枚生於二線,活在一線城市的程序猿,我是小小,咱們下期再見。