高并发口罩抢购项目架构演进记录&优化经验分享

点击上方蓝色字体，关注我 ——

一个在阿里云打工的清华学渣!

本文作者：杨牧原（花名牧原），阿里云技术专家，多年操作系统和应用调试经验，理论功底深厚，实践经验丰富。目前专注 Linux 性能调优，容器集群和系统网络。

本文经原作者授权发于公众号『程序猿石头』，在原文基础上稍作改动。

背景

疫情初期某地政府决定发放一批免费口罩面向该市市民，该市市民均可免费预约领取，预约时间为早上9点-12点，因此该场景为限时抢购类型场景，会面临非常大的定时超大流量超大并发问题，在该项目的落地过程中，涉及的架构演变，做了一些记录和思考。

架构图&分析-V1

原始架构图示&分析（2月2号晚上22点左右的原始架构）

2月2号晚上22点左右的原始架构

1. 客户端走 HTTPS 协议直接访问 ECS；

2. ECS 上使用 Nginx 监听 HTTPS 443 端口；

3. Nginx 反代 Tomcat，Nginx 处理静态文件，Tomcat 处理动态请求；

4. 程序先去 Redis 查缓存，如未命中则去数据库查询数据，同时Redis 与 Mysql 之间的数据同步靠程序控制。

这样架构设计：

• 优点：易管理，易部署；

• 缺点：性能差，无扩展性，存在单点风险；

结果：事实证明该应用一经上线就立刻被打挂了，因未知原因预约页面被泄露，导致还未到预约时间，服务即被打挂。

架构图&分析-V2

随后我方介入，进行架构调整，24点左右找的我们，早上9点要开服，时间太紧，任务太重，程序不能动的情况下，几十万的并发架构如何做？

2月3号早上9点左右的架构，4号也恢复了这个架构）