昨晚，因为核酸系统崩溃，这家公司被骂上了热搜第一

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉亿点点头发...

源码精品专栏

 

昨天晚上，成都因为疫情又一次上了热搜，而这一次，热搜上的词条是一家软件公司的名字。

事情的起因是这样的：

从9月1号开始，成都市政府宣布了为期四天的全员核酸检测。昨天下午，我们小区物业通知了预计14:00-17:00会进行检测，告诉我们会挨个楼栋通知下去检测。

结果一直拖到晚上也没收到通知，我一直忙别的也没留意，结果上网一看，关于成都核酸系统崩溃的各种段子已经满天飞了。

是的，成都核酸检测系统，又崩溃了！

辛苦的大白们没有办法，都用上了这种古老的方式来寻找“信号”。

因为这个系统出了问题，导致核酸检测工作非常缓慢，大量的市民排队等待，平常排队半小时能完成的，昨晚都要排队好几个小时。

到晚上23点半，物业直接通知只给部分人做，其他人可以洗洗睡了。好家伙，不知道有多少人白排了几个小时队。

这好好的系统它咋就崩溃了呢？

有网友挖出了一个中标公告，说这套系统背后使用的是浪潮的服务器：

一千多万的项目，结果就这？

但随后，有疑似浪潮的人出来回复：

人家说的很清楚，上面中标的只是基础运维，这套软件系统的设计另有其人。

随后有人又开喷健康码，喷鹅厂。

但实际上，崩的不是健康码，而是大白使用的核酸采集录入系统，这是两套独立的系统。

再接着，有人爆出这套软件是东软公司做的。

于是一时间，所有人把怒火对准了东软，很快就把东软这个词条送上了微博热搜榜第一的位置。

关于崩溃的原因，也有各种说法在朋友圈、微信群里流传，一时难辨真假。

有说是这套系统背后使用的MySQL使用了超宽的大表：

有说是MySQL单表容量太大，造成性能下降：

还有的说是因为负载均衡不行，没法支撑高并发。

总结起来基本上就两个原因：

1、数据库的问题，数据量大后，查询检索效率低下。

成都全市人口超过2000万，每天一次核酸，那就是单日新增两千万条记录，最近几天一直在做，数据容量很快就是几亿的规模，如果后端用MySQL还不分表，那确实够呛。

2、高并发的问题，同一时间大量请求，服务器扛不住。

一般情况下，使用nginx负载均衡，单机能做到几万的并发量。但成都2000W+的人口规模，全面做核酸的情况下，几万的并发肯定是不够用的。

倘若这套系统背后真的就是一个nginx+mysql(不分表)，那昨晚的情况也就不足为奇了。

好了，吃瓜归吃瓜，我们还是要来点干货，作为一个程序员，要在吃瓜中学会成长。

高并发之路

这篇文章，我们来回答一个问题：到底该怎么做高并发？

让我们从零开始。

1、单机时代

一开始的时候，用户量很少，一天就几百上千个请求，一台服务器就完全足够。

我们用Java、Python、PHP或者其他后端语言开发一个Web后端服务，再用一个MySQL来存储业务数据，它俩携手工作，运行在同一台服务器上，对外提供服务。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://gitee.com/zhijiantianya/ruoyi-vue-pro
• 视频教程：https://doc.iocoder.cn/video/

2、应用与数据库分离

慢慢的，用户量开始多了起来，一台服务器有点够呛，把它们拆开成两台服务器，一台专门运行Web服务，一台专门用来运行数据库，这样它们就能独享服务器上的CPU和内存资源，不用互抢了。

3、缓存系统

后来，用户量进一步增加，每一次都要去数据库里查，有点费时间，引入一个缓存系统，可以有效缩短服务的响应时间。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://gitee.com/zhijiantianya/yudao-cloud
• 视频教程：https://doc.iocoder.cn/video/

4、软件负载均衡

用户量还在增加，一个Web服务的吞吐量开始达到了上限，系统开始出现卡顿。这时候，可以复制多个Web服务出来，再用一个nginx来进行负载均衡，将请求分摊到所有Web服务器上，提高并发量。

5、数据读写分离

随着系统的运行和用户的增长，数据量越来越多，数据库的瓶颈开始显现，读写明显变慢。这时候，可以增加新的数据库服务器，将读写进行分离，二者做好数据同步，提高数据库服务的整体I/O性能。

6、数据库分库分表

系统中的数据越来越多，即便是读写分离了，但一张表中的记录越来越多，从几百万到几千万，甚至要过亿了。把它们全部塞在同一张表里，检索查询耗时费力，是时候进行分库分表，把数据拆分一下，提高数据查询效率。

7、硬件负载均衡

再后来，业务发展很不错，用户量激增，以至于强劲的Nginx也扛不住了。

一台不够，那就多整几台，再引入一个硬件负载均衡的服务器，比如F5，将网络流量分发到不同的Nginx服务器上，再一次提高性能。

8、DNS负载均衡

再再后来，用户量还在蹭蹭蹭的增长，强悍如F5这样的硬件负载均衡服务器也扛不住这样的高并发。

老办法，一个不够那就多整几个。这一次，咱们在域名解析上下功夫，不同地区的用户，在访问同一个域名时，解析到不同的IP地址，以此来将流量进一步拆分。

上面就是从最简单的单机到复杂集群的高并发演进之路。

高并发是一个很大的话题，它所涵盖的东西其实远远不止上面这些内容。除了这些之外，像是消息队列、数据库选型、CDN、编程语言中的协程等等技术都能为提高并发助力。

回到这次崩溃事件上，我想着经过一夜的折腾，今天总该好点了吧，结果下午一开始，又继续摆烂了：

在我写这篇文章的时候，当事公司已经发布了说明：

网络：你的意思是怪我咯？

---

---

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。

谢谢支持哟 (*^__^*）

事情的起因是这样的：

从9月1号开始，成都市政府宣布了为期四天的全员核酸检测。昨天下午，我们小区物业通知了预计14:00-17:00会进行检测，告诉我们会挨个楼栋通知下去检测。

结果一直拖到晚上也没收到通知，我一直忙别的也没留意，结果上网一看，关于成都核酸系统崩溃的各种段子已经满天飞了。

是的，成都核酸检测系统，又崩溃了！

辛苦的大白们没有办法，都用上了这种古老的方式来寻找“信号”。

因为这个系统出了问题，导致核酸检测工作非常缓慢，大量的市民排队等待，平常排队半小时能完成的，昨晚都要排队好几个小时。

到晚上23点半，物业直接通知只给部分人做，其他人可以洗洗睡了。好家伙，不知道有多少人白排了几个小时队。

这好好的系统它咋就崩溃了呢？

有网友挖出了一个中标公告，说这套系统背后使用的是浪潮的服务器：

一千多万的项目，结果就这？

但随后，有疑似浪潮的人出来回复：

人家说的很清楚，上面中标的只是基础运维，这套软件系统的设计另有其人。

随后有人又开喷健康码，喷鹅厂。

但实际上，崩的不是健康码，而是大白使用的核酸采集录入系统，这是两套独立的系统。

再接着，有人爆出这套软件是东软公司做的。

于是一时间，所有人把怒火对准了东软，很快就把东软这个词条送上了微博热搜榜第一的位置。

关于崩溃的原因，也有各种说法在朋友圈、微信群里流传，一时难辨真假。

有说是这套系统背后使用的MySQL使用了超宽的大表：

有说是MySQL单表容量太大，造成性能下降：

还有的说是因为负载均衡不行，没法支撑高并发。

总结起来基本上就两个原因：

1、数据库的问题，数据量大后，查询检索效率低下。

成都全市人口超过2000万，每天一次核酸，那就是单日新增两千万条记录，最近几天一直在做，数据容量很快就是几亿的规模，如果后端用MySQL还不分表，那确实够呛。

2、高并发的问题，同一时间大量请求，服务器扛不住。

一般情况下，使用nginx负载均衡，单机能做到几万的并发量。但成都2000W+的人口规模，全面做核酸的情况下，几万的并发肯定是不够用的。

倘若这套系统背后真的就是一个nginx+mysql(不分表)，那昨晚的情况也就不足为奇了。

好了，吃瓜归吃瓜，我们还是要来点干货，作为一个程序员，要在吃瓜中学会成长。

高并发之路

这篇文章，我们来回答一个问题：到底该怎么做高并发？

让我们从零开始。

1、单机时代

一开始的时候，用户量很少，一天就几百上千个请求，一台服务器就完全足够。

我们用Java、Python、PHP或者其他后端语言开发一个Web后端服务，再用一个MySQL来存储业务数据，它俩携手工作，运行在同一台服务器上，对外提供服务。

2、应用与数据库分离

慢慢的，用户量开始多了起来，一台服务器有点够呛，把它们拆开成两台服务器，一台专门运行Web服务，一台专门用来运行数据库，这样它们就能独享服务器上的CPU和内存资源，不用互抢了。

3、缓存系统

后来，用户量进一步增加，每一次都要去数据库里查，有点费时间，引入一个缓存系统，可以有效缩短服务的响应时间。

4、软件负载均衡

用户量还在增加，一个Web服务的吞吐量开始达到了上限，系统开始出现卡顿。这时候，可以复制多个Web服务出来，再用一个nginx来进行负载均衡，将请求分摊到所有Web服务器上，提高并发量。

5、数据读写分离

随着系统的运行和用户的增长，数据量越来越多，数据库的瓶颈开始显现，读写明显变慢。这时候，可以增加新的数据库服务器，将读写进行分离，二者做好数据同步，提高数据库服务的整体I/O性能。

6、数据库分库分表

系统中的数据越来越多，即便是读写分离了，但一张表中的记录越来越多，从几百万到几千万，甚至要过亿了。把它们全部塞在同一张表里，检索查询耗时费力，是时候进行分库分表，把数据拆分一下，提高数据查询效率。

7、硬件负载均衡

再后来，业务发展很不错，用户量激增，以至于强劲的Nginx也扛不住了。

一台不够，那就多整几台，再引入一个硬件负载均衡的服务器，比如F5，将网络流量分发到不同的Nginx服务器上，再一次提高性能。

8、DNS负载均衡

再再后来，用户量还在蹭蹭蹭的增长，强悍如F5这样的硬件负载均衡服务器也扛不住这样的高并发。

老办法，一个不够那就多整几个。这一次，咱们在域名解析上下功夫，不同地区的用户，在访问同一个域名时，解析到不同的IP地址，以此来将流量进一步拆分。

上面就是从最简单的单机到复杂集群的高并发演进之路。

高并发是一个很大的话题，它所涵盖的东西其实远远不止上面这些内容。除了这些之外，像是消息队列、数据库选型、CDN、编程语言中的协程等等技术都能为提高并发助力。

回到这次崩溃事件上，我想着经过一夜的折腾，今天总该好点了吧，结果下午一开始，又继续摆烂了：

在我写这篇文章的时候，当事公司已经发布了说明：

网络：你的意思是怪我咯？

事情的起因是这样的：

从9月1号开始，成都市政府宣布了为期四天的全员核酸检测。昨天下午，我们小区物业通知了预计14:00-17:00会进行检测，告诉我们会挨个楼栋通知下去检测。

结果一直拖到晚上也没收到通知，我一直忙别的也没留意，结果上网一看，关于成都核酸系统崩溃的各种段子已经满天飞了。

是的，成都核酸检测系统，又崩溃了！

辛苦的大白们没有办法，都用上了这种古老的方式来寻找“信号”。

因为这个系统出了问题，导致核酸检测工作非常缓慢，大量的市民排队等待，平常排队半小时能完成的，昨晚都要排队好几个小时。

到晚上23点半，物业直接通知只给部分人做，其他人可以洗洗睡了。好家伙，不知道有多少人白排了几个小时队。

这好好的系统它咋就崩溃了呢？

有网友挖出了一个中标公告，说这套系统背后使用的是浪潮的服务器：

一千多万的项目，结果就这？

但随后，有疑似浪潮的人出来回复：

人家说的很清楚，上面中标的只是基础运维，这套软件系统的设计另有其人。

随后有人又开喷健康码，喷鹅厂。

但实际上，崩的不是健康码，而是大白使用的核酸采集录入系统，这是两套独立的系统。

再接着，有人爆出这套软件是东软公司做的。

于是一时间，所有人把怒火对准了东软，很快就把东软这个词条送上了微博热搜榜第一的位置。

关于崩溃的原因，也有各种说法在朋友圈、微信群里流传，一时难辨真假。

有说是这套系统背后使用的MySQL使用了超宽的大表：

有说是MySQL单表容量太大，造成性能下降：

还有的说是因为负载均衡不行，没法支撑高并发。

总结起来基本上就两个原因：

1、数据库的问题，数据量大后，查询检索效率低下。

成都全市人口超过2000万，每天一次核酸，那就是单日新增两千万条记录，最近几天一直在做，数据容量很快就是几亿的规模，如果后端用MySQL还不分表，那确实够呛。

2、高并发的问题，同一时间大量请求，服务器扛不住。

一般情况下，使用nginx负载均衡，单机能做到几万的并发量。但成都2000W+的人口规模，全面做核酸的情况下，几万的并发肯定是不够用的。

倘若这套系统背后真的就是一个nginx+mysql(不分表)，那昨晚的情况也就不足为奇了。

好了，吃瓜归吃瓜，我们还是要来点干货，作为一个程序员，要在吃瓜中学会成长。

高并发之路

这篇文章，我们来回答一个问题：到底该怎么做高并发？

让我们从零开始。

1、单机时代

一开始的时候，用户量很少，一天就几百上千个请求，一台服务器就完全足够。

我们用Java、Python、PHP或者其他后端语言开发一个Web后端服务，再用一个MySQL来存储业务数据，它俩携手工作，运行在同一台服务器上，对外提供服务。

2、应用与数据库分离

慢慢的，用户量开始多了起来，一台服务器有点够呛，把它们拆开成两台服务器，一台专门运行Web服务，一台专门用来运行数据库，这样它们就能独享服务器上的CPU和内存资源，不用互抢了。

3、缓存系统

后来，用户量进一步增加，每一次都要去数据库里查，有点费时间，引入一个缓存系统，可以有效缩短服务的响应时间。

4、软件负载均衡

用户量还在增加，一个Web服务的吞吐量开始达到了上限，系统开始出现卡顿。这时候，可以复制多个Web服务出来，再用一个nginx来进行负载均衡，将请求分摊到所有Web服务器上，提高并发量。

5、数据读写分离

随着系统的运行和用户的增长，数据量越来越多，数据库的瓶颈开始显现，读写明显变慢。这时候，可以增加新的数据库服务器，将读写进行分离，二者做好数据同步，提高数据库服务的整体I/O性能。

6、数据库分库分表

系统中的数据越来越多，即便是读写分离了，但一张表中的记录越来越多，从几百万到几千万，甚至要过亿了。把它们全部塞在同一张表里，检索查询耗时费力，是时候进行分库分表，把数据拆分一下，提高数据查询效率。

7、硬件负载均衡

再后来，业务发展很不错，用户量激增，以至于强劲的Nginx也扛不住了。

一台不够，那就多整几台，再引入一个硬件负载均衡的服务器，比如F5，将网络流量分发到不同的Nginx服务器上，再一次提高性能。

8、DNS负载均衡

再再后来，用户量还在蹭蹭蹭的增长，强悍如F5这样的硬件负载均衡服务器也扛不住这样的高并发。

老办法，一个不够那就多整几个。这一次，咱们在域名解析上下功夫，不同地区的用户，在访问同一个域名时，解析到不同的IP地址，以此来将流量进一步拆分。

上面就是从最简单的单机到复杂集群的高并发演进之路。

高并发是一个很大的话题，它所涵盖的东西其实远远不止上面这些内容。除了这些之外，像是消息队列、数据库选型、CDN、编程语言中的协程等等技术都能为提高并发助力。

回到这次崩溃事件上，我想着经过一夜的折腾，今天总该好点了吧，结果下午一开始，又继续摆烂了：

在我写这篇文章的时候，当事公司已经发布了说明：

网络：你的意思是怪我咯？

我是轩辕，欢迎关注我，我们下次再见。