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

一个如此简单的场景，会接二连三的崩溃，东软的架构师可以下岗了。就这个系统如果硬件资源到位，一个APP开发工程师 一个后端开发工程师3天就开发出来了，而且比现在稳定，为什么这么

一个如此简单的场景，会接二连三的崩溃，东软的架构师可以下岗了。就这个系统如果硬件资源到位，一个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年之前基本遇到长假必崩，后来经过几次优化现在基本不崩了，他们做了以下优化，包括不同站点分时段放票（降低同一时段抢票的人数）；余票查询上阿里云；全缓存数据库（以前登录都崩，没做缓存直接查数据库一看就是外包做的）；引入下单排队机制（其实就和大家在购票窗口排队一个原理）；下单扣减库存超时未付款释放库存；两地双中心双活共同提高服务（其实应该两地三中心实现异地容灾）等等。

那对于核酸检测系统要提升并发性能，可以做以下几个优化：

1.参考12306分时段放票、天猫双十一分时段抢优惠券，实行分时段核酸检测，不要统一集中在一个时段做核酸。

2.大白手上的App支持本地缓存异步上报登记（类似微信支付和支付宝网络离线扣款，解决部分核酸检测点4G网络不稳定的问题）

3.基于后台实时监控，进行资源自动扩缩容（硬件扩容不能解决所有问题，12306当年不缺资源）

4.增加一个消息队列，在系统后台收到大白提交的核酸检测登记请求后，直接先进消息队列，而不是直接写数据库，启动一个缓冲作用，保护数据库，数据库只能承受1000的并发，那就先存消息队列（就像一个蓄水池一样），然后在慢慢的异步消费入库，可以保证系统不崩。本人建议按照批次号最后一位0-9十个数字打散到十个消息队列中，这样每个消息队列每秒也就2000条消息的并发。这个场景很像网站访问日志的记录，kafka作为一个高并发高可靠分布式消息队列很适合该场景。

5.由于需要存的只有5个字段，本人建议就存mysql即可，但是单库无法支撑2万/s的并发，需要分库分表检测批次号或者居民健康码编号分100个库100个表，100×100＝10000，相当于单表每秒并发写入数是2，毫无压力。有人说这个表就存5个字段，核酸结果出来存在那，其实结果可以存在其它单独的核酸检测结果表里面，和这个登记表没关系。

6.系统增加限流保护，比如系统每秒最大只支持10000并发，那就限流10000，这样超过10000的并发请求就会被拦截，保障系统不会被压垮。

就这个场景以上几点足够解决东软遇到的问题了。最后再补充猜测一下核酸检测的整体流程：1、居民排队做核酸 2、大白通过核酸检测登记系统登记核酸批次号与居民健康码的绑定关系 3、居民核酸采样 4、核酸采样送检 5、检测机构出批次核酸检测结果报告 6、核酸检测机构把结果推送给东软的检测系统，产出居民核酸检测结果 7、东软核酸检测登记系统把居民检测结果推送给天府通供居民查询核酸检测结果以及红黄绿码的标识。 第6步和第7步也可能是天府通直接从核酸检测结果和东软检测登记系统同时拉去批次检测结果和批次登记的健康码，自己做数据合并。

以上就是本人对于核酸检测系统崩溃的分析和建议，有不同观点者，可以共同讨论。

成都市民排长队没做到核酸，如何看待9月2日成都核酸系统再次崩溃？

成都市民排长队没做到核酸，9月2日成都核酸系统再次崩溃只不过是服务器出现问题而已，在疫情比较紧张的时候我们作为市民应该多一点耐心才对。

一、成都市民排长队没做到核酸

成都目前的疫情出现了反复的状况，所以当地迅速就开展起了全民核酸，谁知道排队到自己的时候，扫码进入系统却出现了崩溃的情形，这才是真的令人崩溃的地方。随着成都核酸系统一而再再而三的崩溃目前，不少的人都对其中的原因进行探讨，而且更多的人对于这种崩溃行为也表示不理解，但按照我个人看法来说，我们有时候还是需要转换一下思维，将心比心地想对方所想，这时候才能够知道崩溃不是政府部门所愿。

二、9月2日成都核酸系统再次崩溃只是服务器出现问题

其实我们要相信政府部门的回应，按照目前相关部门回应的消息来看，由于采集系统的服务器有问题，所以他们已经对服务器进行了紧急更换。从这天开始进行服务器的更换之后，他们也会更新新的系统，这最终是能够解决排队出问题的问题的。目前相关部门已经对出现的问题进行紧急处理，这也是需要了解到的地方。

三、在疫情紧张的时候我们还是要多点耐心

这次出现核酸系统崩溃的状况之后，不少的人都在网络上谴责相关部门的行为不到位，而且也认为这是政府工作做得不好，但实际上这却是要求太高了。在疫情比较紧张的时候，数百万人一起拥进去同一个系统，服务器崩溃是再正常不过的事情；既然政府部门以及企业已经进行了相应的修复行为，而且最终也没有造成那么多市民不变，我们完全没有必要一直嘴炮，我们还是要对政府部门和相关企业更为宽容一些，疫情之下更是需要多点耐心。

成都核酸码崩溃，东软集团回应多个“忽略”反让舆情升级，事态将如何发展？

成都的核酸码崩溃了，也就是说他后面的这个系统已经崩坏了，就导致了非常多的人他们要等待非常久的时间才能够去做到核酸，而且现在对于成都的一些市民来说每天都要去进核酸检测，这也就导致了他们半夜都在排队做核酸不仅是苦了工作人员，更是对这些程度市民来说也是一种折磨，自己觉也睡不好，并且感觉自己的一整天都在排队做核酸了工作也没法工作生活也生活不好，这也就导致了他们一些负面情绪的爆发，东软集团它回应了多个忽略，反而让这一次的舆情升级，可能在大众看来的话已经是难以控制了，就是对于东软集团来说的话，他们其实也是收钱办事的一方。

但是对于当地的成都市民来说他们没有办法去指责其他的但是他们就找到了，东软集团的这样的一个漏洞所以他们全部都去指责东岸集团给他们带来了一些困扰，其实在这里也是要告诉大家的一件事情就是，可能双方就都退一步吧退，大家都说的好退一步海阔天空，东软集团，他其实他自己肯定也是，在做这个系统的时候，可能没有那么的十全十美但是，大家也要知道成都市民其实是非常的人多的话，哪一个系统都是会崩溃的，就包括我们在上网课是一一样的，人数一旦到达了一个上线，或者说管理员后期处理的不及时的话，就会产生一个崩溃的这种界面。

当然，我们都相信这种问题，你肯定是能够尽快的解决的，也希望再一次的疫情能够早一点的离我们而去，不要再继续打扰我们的生活以及我们的的学习和工作了。在这里也是要和这些医护人民员说一声，你们辛苦了！