，作为9月2日成都核酸检测的亲历者，和所有成都市民一样，经历了核酸系统崩溃后的排队崩溃和心理崩溃。昨天排了至少一个小时的队，前台依旧没有动静。我去了志愿者扫码注册的地方，观察了很久。也在网上看了各种分析，有很多声音。作为一个程序员，我想分享一下我的看法。发此内容前，看到东软发布了一份声明，大致可以概括为：第一次死机是成都政府系统故障造成的，第二次是因为网络不通。总而言之，不是东软自己软件的问题。你怎么看这个说法？我会在最后告诉你。我先从技术角度对这个问题做一个整体的分析。首先，网络上有几个传说，但传说只是传说，这个罪不应该归咎于他们。首先：说是网络信号有问题。这种说法显然是在打脸。运营商资源非常丰富。其实那时候排队的人特别多，大家都在看视频聊天，一切都很顺利，一点延迟都没有。号召大家放弃信号通道，设置成飞行模式，完全是想多了，运营商表示不会同意。其次：有人认为是天府健康通的问题。这个问题也得到了澄清。成都核酸检测可通过刷身份证或扫描天府健康通健康码进行。如果健康码确实有问题，那么市民可以用身份证做核酸。但从市民的反馈来看，这两种方式都无法成功。很显然，问题自然出现在了核酸系统的末端。我们还可以看到，这两个系统也是由两个不同的厂商支持的。另外，根据热心人士提供的信息，天府健康通的规划容量是完全够用的。第三：有人认为是数据库的问题。这个确实可以，但是不是数据库本身的问题，而是数据设计的问题。即使用了MySQL，也不能说是数据库本身的问题。比如有一个炉子和一个小锅，你一次不能煮很多，但是你可以分开多煮几锅，所以你不能把这个锅扔给别人。MySQL数据库，而这个数据库的设计必须由核酸系统厂商（神秘厂商）设计。分析了几个传言，核酸系统的问题到底出在哪里？成都市民不出小区，所有检测点都进小区，业务量一下子增加好几倍，确实对核酸系统提出了非常高的要求。对于这种高并发的业务系统，如何提高系统的稳定性和可靠性确实是一个技术活。这不是某一点上的简单问题，而是需要在多个环节加以控制的系统工程。否则就很难达到目的。我站在程序员的角度，列出几个可能有问题的链接。第一：接入网关的能力非常重要，是互联网架构中不可或缺的一环。主要功能是身份验证和限流。鉴权的目的是防止非法访问，阻断不合规、非法的访问请求；二是限流。我们的系统设计必须有一个上限。超过上限怎么办？与其让系统崩溃，还不如把请求控制在设计的流量范围内，系统还能运行。例如：我们设计的交通是四车道。当车流达到四车道负荷时，将限制车辆进入，以保证四车道交通的连续运行。如果没有限行的话，结果就是那四条车道变成了停车场，全部堵死，谁也跑不了。当某些系统在设计时考虑到此链接时就是这种情况。它可能会慢一些，但不会崩溃，也不会无法使用。成都核酸系统很可能存在这样的问题。2号以前在区县用过，没问题。2号在大面积使用时，经常出现系统卡死、不停旋转的情况，操作员被迫终止程序重新登录。高速公路变停车场二：应用服务器扩展能力的扩展分为纵向扩展和横向扩展。所谓纵向扩张很好理解。就是把处理能力低的服务器升级到高配置，比如：增加CPU，增加内存等，但这往往是有局限性的。服务器的纵向扩展能力是有限的，不可能是无限的。扩张。二是横向扩展，也就是增加数量，就是一个服务不够了再增加一个，10个不够就增加到20个，没有办法通过资源去扩展。从成都核酸系统2号的情况来看，无论是扫描身份证读取身份基本信息，还是读取天府健康通健康码获取用户信息，速度都比较慢。怀疑是这里的处理服务器能力不够。非常灵活，支持横向扩展。通过申请政务云资源，应该可以很快升级。第三：业务缓存大家都知道数据存放在数据库中，每次读写都需要大量的磁盘IO，是性能瓶颈。高频数据可以存储在内存中，大大提高读写性能。效率，同时不需要每次都去访问数据库，不仅减轻了数据库的压力，还大大提高了效率。但是内存中的数据并不能长期保存，最后必须写入磁盘。因此，在设计架构时必须充分考虑数据一致性和安全性问题，以防止数据丢失和不一致。根据2号的表现，成都的核酸系统将被检测人员的信息加入到被检测人员名单中需要很长时间，而且很容易卡在这个环节，所以大概率是在写的时候，如果数据出现异常，可能会直接写入数据库，导致数据库拥堵，所以无法判断是否使用了缓存技术。第四：数据库性能优化这是最后一个环节，包括：分库，分表，读写分离，也是最容易出问题的地方。一种是使用分库，也就是对数据库进行瘦身。不要将所有数据放在一个数据库中。就像你不能把高新区的人都安排在一个小区里一样。如果安排在一个小区里，每个人都必须从小区门口经过，很容易造成阻塞，也就是请求拥塞。二是使用分表，也就是说单表的数据不能太多，也避免了读写时的拥堵。它类似于社区中的不同建筑物。如果所有的人都住在一栋楼里，这些人进出的时候会很拥挤，入口会堵，电梯也会堵，所以可以分成不同的楼，大家可以分开进行以减少拥堵的可能性。划分表格的方法有很多种。可以按日期分表，每天一组，也可以按地区分表。不同地区的数据存储在不同的表中。这样一来，单表的数据量会变小，读写拥堵的可能性大大降低，这也是提高数据库性能的一个很好的手段。第三种是使用读写分离，也就是分成不同的库，有的库主要负责写数据，有的库负责查询数据，一个主库负责写，然后复制几个库到支持查询，这样可以减少数据库的负载共享也可以大大提高性能。成都的核酸系统在写数据的时候也可能出现异常。很可能是没有采用分库分表的技术，导致写数据的时候并发量大，写不出来。事实上，核酸系统的业务并不复杂。主要流程为：登录人员登录对应的检测点后，选择单检、混检1（10混）、混检2（20混）。如果选择混检1，则扫描试管上的条码生成一组，然后扫描检测人员，10人后，选择封管，即可完成一组操作。但是即使业务逻辑不复杂，也会出现这么差的性能，那我分析的主要问题还是在架构设计上，没有考虑高并发场景。很有可能没有考虑限流机制（阈值要根据压测的容量来设置）；没有考虑缓存机制，导致需要直接读写数据库，对数据库造成很大压力；数据库分库不考虑表，导致数据库异常繁忙，大并发时没办法正常写入。所以我觉得跟网络关系不大，跟天府健康通，跟政务云资源关系不大（按需分配，政务云资源是动态分配的，满足业务需求不会太大的挑战）。真心建议核酸系统开发公司认真分析，找出问题根源，认真优化，不要让我们再次遇到这样的情况！（本文为投稿，作者为成都程序员）
