成都核酸系统崩溃原因分析

前言

这两天成都核酸检测系统接连崩溃，让工作人员和广大市民苦不堪言，因此决定对其背后的技术进行分析，看看这个系统复杂不复杂，是什么原因导致的崩溃

系统架构分析

核酸结果查询服务正常，核酸检测记录无法录入，因此推断分析此系统主要分为核酸录入服务和核酸结果查询服务，架构如下

核酸检查结果通过数据同步任务从数据库同步到redis里面，来支撑高并发访问，由于核酸结果查询正常，主要分析核酸录入的瓶颈在哪

指标计算

• 并发量

2千w人，6小时采样完，系统响应时间为2s,那么并发量为：2千万/(6 * 3600) * 2s=1850，如果考虑到时间在短一点，就按照2小时做完，2千万/(2 * 3600) * 2s=5555

• 带宽

1M宽带理论速度=1Mbit/s=1024 Kbit/s=128 KByte/s，带宽的计算公式为：并发量*平均报文大小/112KB，假设每个报文大小是2KB，那么带宽为1850 *2KB/112KB=33M

瓶颈分析

带宽

经过前面计算带宽为33M,即使需要100M,这块也不是压力，可能会有人说查询服务带宽没考虑在内，因为查询服务正常，所以不需要考虑，如果是共用一个带宽，那么查询服务也会出现问题

数据库

如果使用单台数据库，没做分库分表，每秒1850次访问写入，如果在数据库配置不高的情况下会出现问题（cpu、内存、io）都有可能出现瓶颈点，其次数据量也会快速膨胀，每天晚上有2千万人做核酸，那么会有2千万甚至更多数据插入，经验值mysql 单表在1千万左右性能最佳，如果在往上增长性能就会逐渐下降，所以如果是单点有可能会出现瓶颈，如果要优化一般会进行不同服务器进行分库存储，如下图master和slave都是独立服务器

应用服务器

核酸写入服务节点如果前期不够，会出现性能瓶颈，但是这个还是比较容易扩容的，不应该在连续2天还会出现这种问题，所以应该不是此问题。

负载均衡器

1850的并发对nginx也是能轻松支撑的，所以不是这块问题

网络

看到网络上说是运营商的网络问题导致的，作为从业多年的技术人员，这种情况我遇到过，运营商的网络有可能出现这种情况，但是几率不高而且会很快恢复

总结

经过分析系统功能点不多，业务逻辑不是特别复杂，并发量也不高，数据库的出现瓶颈几率大点，网络的几率很小。。。

以上内容如果不对，请指正，谢谢！

作者：dweizhao
来源：juejin.cn/post/7139156745682845709