如果老板要求你的系统接入春晚大流量活动，你会心慌慌吗？

石杉的架构笔记

于 2022-04-18 09:22:24 发布

阅读量401

点赞数 2

分类专栏：微服务架构多线程并发文章标签：微服务高并发 Redis RocketMQ 架构设计

本文链接：https://blog.csdn.net/qq_42046105/article/details/124241645

版权

架构同时被 3 个专栏收录

33 篇文章 13 订阅

订阅专栏

微服务

8 篇文章 7 订阅

订阅专栏

多线程并发

5 篇文章 0 订阅

订阅专栏

今天给大家分享一个话题，就是如果要是你老板突然要求你把负责的系统，要接入到春晚中去抗下春晚带来的超大流量，你会感到心里特别慌，然后特别没底吗？我估计大部分兄弟应该都会感到很慌很没底，不过没事，今天我们就来给大家讲讲，如果咱们系统要接入春晚活动抗下超大并发流量，应该怎么来优化设计。

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

既然说到系统接入春晚大并发流量，那么就得先谈谈没接入之前，你的系统大概长什么样子，其实也挺简单，大家一般日常负责开发的系统，通常都是用spring boot+ssm框架技术栈来写代码，对外基于spring boot的内嵌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就可以提供本地缓存cache，同样基于LRU策略缓存一些数据，最后就是如果tomcat本地缓存里也没有，就可以去redis分布式缓存集群里加载缓存数据。

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

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

下一个问题来了，那么参与春晚活动的时候，除了这种超高并发的大流量读取以外，还可能会因为参与活动发起超高流量的数据写入请求呢？此时应该怎么抗下来呢？因为这个时候，妥妥的是不可能靠什么cdn全国各地服务器、nginx本地缓存给你抗了，那必须你自己扛下来啊。

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

第二，一般来说这种大流量数据写入，往往会采取让我们业务系统收到请求后，先写入到redis缓存里去，然后写一个消息到rocketmq里去，接着再从rocketmq里消费消息后异步落入db里去，因为数据库能抗的写入压力是有限的，大并发流量写入是不适合他的，所以往往会用这种方式来做一个处理，同样的机器配置，redis和rocketmq可以抗几万并发，mysql只能抗几千并发。

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