今天給大家分享一個話題，就是如果要是你老板突然要求你把你負責的系統(tǒng)，要接入到春晚中去抗下春晚帶來的超大流量，你會感到心里特別慌，然后特別沒底嗎？

我估計大部分兄弟應該都會感到很慌很沒底，不過沒事，今天我們就來給大家講講，如果咱們系統(tǒng)要接入春晚活動抗下超大并發(fā)流量，應該怎么來優(yōu)化設計。

回頭看看：原始系統(tǒng)技術(shù)架構(gòu)

既然說到系統(tǒng)接入春晚大并發(fā)流量，那么就得先談談沒接入之前，你的系統(tǒng)大概長什么樣子。

其實也挺簡單，大家一般日常負責開發(fā)的系統(tǒng)，通常都是用 SpringBoot+SSM 框架技術(shù)棧來寫代碼，對外基于 SpringBoot 的內(nèi)嵌 Tomcat 提供 Http 接口，然后用 Nacos+Dubbo 來 RPC 調(diào)用別的系統(tǒng)，接著就是連接 MySQL 數(shù)據(jù)庫執(zhí)行 CRUD 操作。

如下圖：

基于 CDN 的活動靜態(tài)頁面緩存方案

好，那么接著我們來分析一下，一旦要是這個系統(tǒng)接入了春晚大流量活動以后，超高的流量，可能在平時百倍以上要打到我們的系統(tǒng)來，此時應該如何來優(yōu)化這個系統(tǒng)架構(gòu)。

首先第一個問題，就是對于一些靜態(tài)化的資源，比如說圖片/視頻一類的資源，要是用戶手里拿個 APP 看我們提供的圖片和視頻的時候，這些東西要是都走到我們后臺系統(tǒng)來獲取，大家覺得靠譜嗎？

那明顯不靠譜啊，因為這種圖片和視頻一般都比較大，如果大量的人同時請求我們寫的 Java 系統(tǒng)來請求下載獲取圖片和視頻，那絕對會把系統(tǒng)搞崩潰的。

所以一般來說，這個時候都應該上一個東西，叫做 CDN。這個 CDN 呢，大概意思就是說，在全國各地都搞一批服務器，然后呢，讓 CDN 提前請求我們的后端系統(tǒng)，把一些圖片、視頻一類的靜態(tài)資源都加載到 全國各地的 CDN 服務器上去。

接著呢，全國各地的用戶打卡手機 APP，想要加載圖片和視頻的時候，就近找一個距離自己最近的 CDN 服務器加載圖片和視頻就可以了，這樣就可以讓超高流量分散到全國各地的很多 CDN 服務器上去了。

大家看下圖：

好，那么現(xiàn)在咱們?nèi)珖鞯赜脩舸蜷_手機 APP 查看我們的各種活動的時候，活動的圖片和視頻是可以從全國各地就近找一個 CDN 服務器獲取了，等于這塊大流量是分散到全國各地 CDN 服務器去了。

那么但是活動頁面里可能除了圖片和視頻以外，還有很多別的數(shù)據(jù)是得動態(tài)查詢獲取的呢？

基于 Nginx+Tomcat+Redis 的多級緩存方案

就是說全國各地用戶還是得發(fā)送大量的請求到我們后臺系統(tǒng)來加載一些數(shù)據(jù)，那么對于這種高并發(fā)的數(shù)據(jù)讀取該怎么來抗呢？

簡單，上一套多級緩存架構(gòu)，我們可以在 Tomcat 前面加一層 Nginx 反向代理服務器，在 Nginx 里可以基于 Lua 腳本自己寫代碼，然后在 Nginx 的內(nèi)存里可以基于 LRU 策略緩存一些熱門數(shù)據(jù)。

然后如果是 Nginx 里沒有緩存到的數(shù)據(jù)，可以在我們的業(yè)務系統(tǒng) Tomcat 里用本地 Cache，比如說 Guava 就可以提供本地緩存 Ccache，同樣基于 LRU 策略緩存一些數(shù)據(jù)。

最后就是如果 Tomcat 本地緩存里也沒有，就可以去 Redis 分布式緩存集群里加載緩存數(shù)據(jù)。

基本上通過 Ngxin+Tomcat+Redis 三級緩存架構(gòu)，就可以把高并發(fā)讀取的流量全部抗下來了。

如下圖：

超高并發(fā)寫請求 RocketMQ 削峰填谷方案

下一個問題來了，那么參與春晚活動的時候，除了這種超高并發(fā)的大流量讀取以外，還可能會因為參與活動發(fā)起超高流量的數(shù)據(jù)寫入請求呢？此時應該怎么抗下來呢？

因為這個時候，妥妥的是不可能靠什么 CDN 全國各地服務器、Nginx 本地緩存給你抗了，那必須你自己扛下來啊。

這個時候往往是這樣，首先第一個是機器擴容，因為如果有大流量的數(shù)據(jù)寫入，那確實咱們平時的業(yè)務系統(tǒng)部署的機器數(shù)量可能是不夠多的，所以往往再抗這種大活動的時候，得臨時擴容一批機器出來，這是第一。

第二，一般來說這種大流量數(shù)據(jù)寫入，往往會采取讓我們業(yè)務系統(tǒng)收到請求后，先寫入到 Redis 緩存里去，然后寫一個消息到 RocketMQ 里去，接著再從 RocketMQ 里消費消息后異步落入 DB 里去。

因為數(shù)據(jù)庫能抗的寫入壓力是有限的，大并發(fā)流量寫入是不適合他的，所以往往會用這種方式來做一個處理，同樣的機器配置，Redis 和 RocketMQ 可以抗幾萬并發(fā)，MySQL 只能抗幾千并發(fā)。

所以此時，架構(gòu)如下圖所示：

系統(tǒng)限流防雪崩體系架構(gòu)方案

最后呢，其實還應該再加一個機制，那就是限流，因為在上述這套架構(gòu)上線以前，應該對這套架構(gòu)通過三級緩存可以抗多大讀流量壓力，以及基于寫入 Redis+RocketMQ 異步寫 DB，可以抗多大寫流量壓力，包括臨時擴容一批機器后，整體全鏈路大致可以抗多大的讀寫 TPS，這些都得通過全鏈路壓測去測試出來。

然后應該根據(jù)這個系統(tǒng)能整體抗的最大讀寫壓力，在 Nginx 那一層加入限流機制，一旦要是每秒流量超過了最大值，此時直接限流，不允許繼續(xù)放行，避免系統(tǒng)被壓垮。

如下圖所示：

好了，今天的分享就到這里了，希望大家對于這種普通系統(tǒng)接入大活動超高流量下的架構(gòu)設計能有一定的了解。