成都核酸检测结果查不到「关于成都核酸检测系统崩溃我想说点啥」

一个如此简单的场景,会接二连三的崩溃 , 东软的架构师可以下岗了 。就这个系统如果硬件资源到位,一个APP开发工程师 一个后端开发工程师3天就开发出来了,而且比现在稳定,为什么这么说看看我下面的分析 , 你就知道了 。
核酸检测涉及几个系统:1、居民使用的健康码系统(天府健康码,里面存放居民个人信息及核酸检测结果)2、核酸检测登记系统(就是大白使用这次崩溃的系统)3、医院核酸检测系统(出核酸检测结果的) 。
核酸检测原理就是居民打开健康码让大白通过核酸检测登记系统扫码进行核酸检测批次和居民健康码进行绑定登记,因为大家否是混检,检测结果是按批次进行出结果的,大白手上的APP每10个人就是一个批次,这个批次号和核酸检测采样管上贴的批次是一致的,所以这个APP就是负责把进行核酸检测的居民健康码和核酸检测批次号进行绑定并上报记录到后台 , 待本批次核酸检测结果出来就默认是这个批次绑定的10位居民核酸结果了,所以大家被捅喉咙的棉签都放在那一个采样管里面 。
那核酸检测登记系统需要登记哪些信息呢?在我看来 , 只需要登记:核酸检测批次号、居民健康码唯一编号、检测时间、检测位置、检测人编号几个信息就足够了 。核酸检测批次号由核酸检测系统自动生成,居民健康码编号由健康码系统生成,这个编号可以查出居民的所有身份信息,检测位置是大白自己登基的临时核酸检测点位置 , 检测人就是大白自己登记的医护人员信息的编号 。
这样看是不是很简单,不需要之前网传的几万个表字段,只需要5个字段就够了 。那系统为啥会崩呢?本人猜测和东软系统设计不合理有关系 。假如四川全省同时有两万个大白使用核酸检测APP上报登记,那这个系统的并发就是每秒两万,假如单台服务器查询和写入能支持1000/s, 那大概需要20台服务器,这个对于政府不是啥问题 , 但是这20台服务器的并发写入直接写入一个单机数据库,除了类似阿里云的云分布式数据库没有哪个数据库能抗的住,但本人猜测东软用的肯定是mysql和oracle里面的一种 , 那是不是就说这两种数据库不行,其实不是数据库不行是用的人不行,用的不对,单台数据库的最大连接数是有限的,正常1000左右,所以如果是向单数据库直接写,肯定不行 。我看有网友说用CK,是可以的,但也要控制写入频次,否则会报错,而且就那5个字段在我看来用mysql就足够了,所以那些说mysql不行的人,应该不是IT行业的 。
接下来我会说下我的看法,欢迎大家评论区留言 。什么是高并发,就是在同一时刻访问到网站服务器的流量超过一个很高的值导致服务器性能下降或者瘫痪,不同网站由于设计的不同扛高并发能力差异也很大,比如京东淘宝双十一峰值流量估计都要上每秒几十万、12306春节抢票每秒能上百万,那怎么设计系统才能让系统扛高并发能力变强呢?可以从硬件配置、高并发系统架构、系统保护、系统监控、系统运维几个方面来提升 。
12306网站在15年之前基本遇到长假必崩,后来经过几次优化现在基本不崩了,他们做了以下优化,包括不同站点分时段放票(降低同一时段抢票的人数);余票查询上阿里云;全缓存数据库(以前登录都崩 , 没做缓存直接查数据库一看就是外包做的);引入下单排队机制(其实就和大家在购票窗口排队一个原理);下单扣减库存超时未付款释放库存;两地双中心双活共同提高服务(其实应该两地三中心实现异地容灾)等等 。