分类回顾：原系统技术架构基于CDN的主动静态页面缓存方案基于Nginx+Tomcat+Redis多级缓存方案超高并发写请求RocketMQ削峰填谷方案系统限流和防雪崩系统架构方案今天给大家分享一个话题，就是如果你的老板突然让你负责的系统接入春晚，来抵御春节带来的巨大流量Gala，你会觉得很慌张，不知道吗？我想你们中的大多数人都会感到慌乱和绝望，但这没关系。今天我们就来告诉大家，如果我们的系统要接入春晚，如何去优化设计，来抵御巨大的并发流量。回过头来看：既然原来的系统技术架构是指春晚大并发流量的系统接入，那么在接入之前一定要先说说你的系统是什么样子的。事实上，这很简单。日常你负责开发的系统，通常使用SpringBoot+SSM框架技术栈编写代码，基于SpringBoot的嵌入式Tomcat对外提供Http接口，然后使用Nacos+Dubbo进行RPC调用其他系统.下一步是连接到MySQL数据库以执行CRUD操作。如下图所示：基于CDN的主动静态页面缓存方案不错，下面分析一下。这个系统一旦接入春晚大流量活动，超高流量可能会比平时对我们的系统造成一百倍以上的冲击，这时候如何优化系统架构。首先第一个问题，对于一些静态资源，比如图片/视频，如果用户手里拿着一个APP来观看我们提供的图片和视频，如果这些东西都到我们的后台系统，你觉得它可靠吗？显然是不靠谱的，因为这样的图片和视频一般都比较大。如果大量的人请求我们写的Java系统同时下载和获取图片和视频，肯定会把系统搞垮。所以一般来说，这个时候应该有一个叫CDN的东西。至于这个CDN，大概就是说我们有一组遍布全国的服务器，然后让CDN提前请求我们的后台系统加载一些图片、视频等静态资源到遍布全国的CDN服务器上国家。.然后，当全国各地的用户登录手机APP需要加载图片和视频时，就可以找到离自己最近的CDN服务器来加载图片和视频。CDN服务器已启动。看下图：OK，现在全国用户打开手机APP查看我们的各种活动时，可以从附近的全国CDN服务器获取到活动的图片和视频，也就是说这个大流量是分布到全国各地的CDN服务器。那么，除了图片和视频之外，活动页面中可能还有很多其他的数据需要动态查询获取呢？基于Nginx+Tomcat+Redis的多级缓存方案，意味着全国各地的用户还是要向我们发送大量的请求后台系统加载了一些数据，那么如何抵抗这种高并发的数据读取？简单，在上一套多级缓存架构中，我们可以在Tomcat前面加一层Nginx反向代理服务器，在Nginx中可以基于Lua脚本编写自己的代码，然后在Nginx内存中缓存一些流行的数据基于LRU策略。那么，如果数据没有缓存在Nginx中，我们可以在我们的业务系统Tomcat中使用本地缓存。比如Guava可以提供本地缓存Ccache，它也会根据LRU策略缓存一些数据。最后，如果没有Tomcat本地缓存，可以去Redis分布式缓存集群加载缓存数据。基本上通过Ngxin+Tomcat+Redis的三级缓存架构，可以抵御所有高并发读取流量。如下图所示：RocketMQ超高并发写请求削峰填谷方案接下来的问题是，参加春晚的时候，除了超高并发大流量的读，超-高流量也可能因为参与事件而发起数据写入请求呢？这个时候该怎么抵挡呢？因为这时候靠全国各地的CDN服务器和Nginx本地缓存是不可能帮你抗下来的，只好自己扛下来了。这个时候经常会出现这种情况。首先第一件事就是扩展机器的容量，因为如果有大流量的数据写入，确实我们平时业务系统部署的机器数量可能不够用，所以我们经常抗拒这种大型活动。当时要临时扩充一批机器。这是第一个。二、一般来说，这种大流量的数据写入往往采取的形式是让我们的业务系统在收到请求后写入Redis缓存，然后写入消息到RocketMQ，消息落下后再从RocketMQ消费异步进入数据库。因为数据库能承受的写压力是有限的，大并发流量的写不适合他，所以经常用这种方式来处理。同样的机器配置，Redis和RocketMQ可以抗上万并发，MySQL只能抗上千并发。所以这时候的架构如下图所示：系统限流和防雪崩系统架构方案最后，其实还应该加一个机制，就是限流，因为在上面的设置之前of架构上线，这套架构要过三遍。级别缓存能抗多少读流量压力，基于写Redis+RocketMQ异步写DB能抗多少读写流量压力，包括临时扩容后整个链路能抗多少读写TPS一批机器？它必须通过全链路压力测试来测试。然后根据系统整体所能承受的最大读写压力，在Nginx层加入限流机制。一旦每秒流量超过最大值，此时会直接限制电流，不允许再释放，避免系统不堪重负。.如下图所示：好了，今天的分享就到这里。希望大家对这种大型活动、超大流量下的通用系统接入的架构设计有一定的了解。
