目录回头看看：原始系统技术架构基于 CDN 的活动静态页面缓存方案基于 Nginx+Tomcat+Redis 的多级缓存方案超高并发写请求 RocketMQ 削峰填谷方案系统限流防雪崩体系架构方案

今天给大家分享一个话题，就是如果要是你老板突然要求你把你负责的系统，要接入到春晚中去抗下春晚带来的超大流量，你会感到心里特别慌，然后特别没底吗?

我估计大部分兄弟应该都会感到很慌很没底，不过没事，今天我们就来给大家讲讲，如果咱们系统要接入春晚活动抗下超大并发流量，应该怎么来优化设计。

回头看看：原始系统技术架构

既然说到系统接入春晚大并发流量，那么就得先谈谈没接入之前，你的系统大概长什么样子。

其实也挺简单，大家一般日常负责开发的系统，通常都是用 SpringBoot+SSM 框架技术栈来写代码，对外基于 SpringBoot 的内嵌 Tomcat 提供 Http 接口，然后用 Nacos+Dubbo 来 RPC 调用别的系统，接着就是连接 MySQL 数据库执行 CRUD 操作。

如下图：

基于 CDN 的活动静态页面缓存方案

好，那么接着我们来分析一下，一旦要是这个系统接入了春晚大流量活动以后，超高的流量，可能在平时百倍以上要打到我们的系统来，此时应该如何来优化这个系统架构。

首先第一个问题，就是对于一些静态化的资源，比如说图片/视频一类的资源，要是用户手里拿个 APP 看我们提供的图片和视频的时候，这些东西要是都走到我们后台系统来获取，大家觉得靠谱吗?

那明显不靠谱啊，因为这种图片和视频一般都比较大，如果大量的人同时请求我们写的 Java 系统来请求下载获取图片和视频，那绝对会把系统搞崩溃的。

所以一般来说，这个时候都应该上一个东西，叫做 CDN。这个 CDN 呢，大概意思就是说，在全国各地都搞一批服务器，然后呢，让 CDN 提前请求我们的后端系统，把一些图片、视频一类的静态资源都加载到 全国各地的 CDN 服务器上去。

接着呢，全国各地的用户打卡手机 APP，想要加载图片和视频的时候，就近找一个距离自己最近的 CDN 服务器加载图片和视频就可以了，这样就可以让超高流量分散到全国各地的很多 CDN 服务器上去了。

大家看下图：

好，那么现在咱们全国各地用户打开手机 APP 查看我们的各种活动的时候，活动的图片和视频是可以从全国各地就近找一个 CDN 服务器获取了，等于这块大流量是分散到全国各地 CDN 服务器去了。

那么但是活动页面里可能除了图片和视频以外，还有很多别的数据是得动态查询获取的呢?

基于 Nginx+Tomcat+Redis 的多级缓存方案

就是说全国各地用户还是得发送大量的请求到我们后台系统来加载一些数据，那么对于这种高并发的数据读取该怎么来抗呢?

简单，上一套多级缓存架构，我们可以在 Tomcat 前面加一层 Nginx 反向代理服务器，在 Nginx 里可以基于 Lua 脚本自己写代码，然后在 Nginx 的内存里可以基于 LRU 策略缓存一些热门数据。

然后如果是 Nginx 里没有缓存到的数据，可以在我们的业务系统 Tomcat 里用本地 Cache，比如说 Guava 就可以提供本地缓存 Ccache，同样基于 LRU 策略缓存一些数据。

最后就是如果 Tomcat 本地缓存里也没有，就可以去 Redis 分布式缓存集群里加载缓存数据。

基本上通过 Ngxin+Tomcat+Redis 三级缓存架构，就可以把高并发读取的流量全部抗下来了。

如下图：

超高并发写请求 RocketMQ 削峰填谷方案

下一个问题来了，那么参与春晚活动的时候，除了这种超高并发的大流量读取以外，还可能会因为参与活动发起超高流量的数据写入请求呢?此时应该怎么抗下来呢?

因为这个时候，妥妥的是不可能靠什么 CDN 全国各地服务器、Nginx 本地缓存给你抗了，那必须你自己扛下来啊。

这个时候往往是这样，首先第一个是机器扩容，因为如果有大流量的数据写入，那确实咱们平时的业务系统部署的机器数量可能是不够多的，所以往往再抗这种大活动的时候，得临时扩容一批机器出来，这是第一。

第二，一般来说这种大流量数据写入，往往会采取让我们业务系统收到请求后，先写入到 Redis 缓存里去，然后写一个消息到 RocketMQ 里去，接着再从 RocketMQ 里消费消息后异步落入 DB 里去。

因为数据库能抗的写入压力是有限的，大并发流量写入是不适合他的，所以往往会用这种方式来做一个处理，同样的机器配置，Redis 和 RocketMQ 可以抗几万并发，MySQL 只能抗几千并发。

所以此时，架构如下图所示：

系统限流防雪崩体系架构方案

最后呢，其实还应该再加一个机制，那就是限流，因为在上述这套架构上线以前，应该对这套架构通过三级缓存可以抗多大读流量压力，以及基于写入 Redis+RocketMQ 异步写 DB，可以抗多大写流量压力，包括临时扩容一批机器后，整体全链路大致可以抗多大的读写 TPS，这些都得通过全链路压测去测试出来。

然后应该根据这个系统能整体抗的最大读写压力，在 Nginx 那一层加入限流机制，一旦要是每秒流量超过了最大值，此时直接限流，不允许继续放行，避免系统被压垮。

如下图所示：

好了，今天的分享就到这里了，希望大家对于这种普通系统接入大活动超高流量下的架构设计能有一定的了解。

关键词： 全国各地 这个时候 业务系统 削峰填谷 一般来说