一码通崩溃的技术原因是什么？

我看有人说小程序的图片包太大了没上CDN导致带宽不够，这确实是个问题，但是应该不是一码通崩溃的原因。

因为小程序的图片包应该是有本地缓存的（不确定，我就这么一说），只要小程序不删除，缓存就可以一直用，不会每次都从后台取图片包，所以这方面的压力没有那么大，不会导致一码通崩溃。

从崩溃的情况来看，先崩溃了一次，然后数据回滚就可以用了，后来核酸数据累积又崩溃了一次。基本上可以肯定是后台性能问题。

大概率是弄了个mysql之类的关系数据库，然后核酸数据用联表查询关联二维码数据。

西安有一千多万人，那么绿码表按每人一行就有一千多万行。

核酸检测结果表是每人每次一行，如果西安每人要做xx次核酸，这就是几亿行。

两个表一联表，然后并发量一上来，数据库性能急剧下降，一次查询耗时xx秒，数据库卡了几百个查询不能完成，后面有几十万个查询涌进来挤爆了服务端，整个系统含泪打出了gg。

他们设计可能没有这么简单粗暴，应该是做了一些优化的，比如把核酸检测结果表拆分，加索引，然后给数据库前端加缓存，读写分离，但是只要不跳出这个思路，问题就会一直在。

因为mysql的正常查询（返回时间1xx毫秒以内）的上限大致在单表1千万级（具体看情况），超过这个量，或者这个量还要联表，性能就会急剧下降。换成oracle也不过把这个量放大几倍，本质是一样的。

一码通这种场景不需要强实时，而且还是只读的。最常见的思路是服务端放一个kv数据库，比如redis。按照身份证做key，value用绿码状态+核酸结果列表。如果负载太大就上集群，按照出生日期来分片，1号到31号每天出生的人大致上应该是平均的。然后定时把mysql里面新增的每个人核酸检测结果更新到redis里面。

这样保证负载最大的这个应用与其他应用是分离的，而且一直是可用的，做核酸的登记表之类的应用走mysql，处理一下负载基本上没问题。

另外在修复过程中出现的电信网络可以打开，移动联通网络打不开。很多人认为这个现象表明问题可能出在后端的入口负载均衡，但是我不这么认为。

我的经验判断这是他们主动的选择。

因为这个小程序的请求量远远达不到把服务分发负载均衡冲垮的程度。

在修复过程中如果修复完了就全开，这时候用户会同时一窝蜂涌上来，可能会导致服务再次宕机，正确的选择是先给一部分用户开通，他们先用完了，再给后面的人用，相当于手动错峰。

之前也分析过，大致上就是这么回事吧。