做一个不崩溃的核酸系统有多难？

每天2000万，假设可以均摊到1小时（3600秒），那么每秒只有不到1万的并发量。

假设数据量为10亿，也就是1G条记录；给每条记录16字节存储空间（身份证号编码为二进制，考虑地区/年份可以压缩，48位整数足矣；哪怕不压缩，64位整数也就是8个字节怎么都够了；剩下8个字节足够记录上次核酸检测时间、红黄码状态以及疫苗信息了）……

换句话说，16G内存就够把全国所有数据放进内存；而我的PC机是32G内存；对服务器来说，256G甚至1T内存早在十几年前已是平常。

然后，还可以根据身份证号前3位或者前6位（地区码）分散到多台服务器。

也就是根据你的身份证信息，哪个省的就自动dispatch到对应省份的服务器处理。这样一台服务器只需储存1~2亿条信息就足够用了——20台16G内存的虚拟机实例，资源充足到足够你肆意挥霍的。

然后，系统启动过程是：

1、从数据库载入属于本服务器的所有信息（2~4亿条），这是个较为缓慢的过程。

2、开始提供服务。

前面提到过，哪怕按2000万次访问集中在1小时内完成这个最苛刻的指标，每秒也只需服务5556人。

按每人需要返回2K数据计算（1k都绰绰有余！除非你在服务器端生成二维码），每秒数据量大约是12M不到。

这个业务都是短链接。也就是可以认为用户查询过程是：TCP握手，发送用户身份证号（可本地识别），获取数据，断开连接。

那么，这里实际上不太需要考虑什么C10k问题（考虑也容易，Windows用完成端口Linux用epoll即可；其实可以直接用libevent写出跨平台程序的），一条100M的链路足够了。

按身份证号在数组中搜索信息，在搞好身份证号-下标映射算法时，效率是O(1)；没有搞好、用二分法查找，效率O(lnN)，对10亿人，至多30次搜索就能找到。对于内存搜索，相对于网络的蜗牛速率，这个延迟可以忽略不计。

换句话说，不需要任何特殊技术，20台16G内存的虚拟机实例，简单的在数组中访问下标（或者二分查找）、封装返回，以及100M对外服务总带宽，就足以支持10亿用户的每小时2000万次查询——性能大有盈余。

换成1G总带宽，一小时够2亿人用的——注意我说的是总带宽。如果20台16G内存的虚拟机实例各自拥有100M对外服务带宽，它实际上已经足够支持全国使用了。

当然，实际不能这么简陋。万一虚拟机本身不够稳定、或者有人连二分查找程序都能写崩溃呢……

这时候，我们可以另外搞一些虚拟机作为备份；这些虚拟机可以使用现成的zookeeper管理，一个节点坏了，另一个节点可以马上顶上……

另外就是数据更新问题。核酸数据没有太高的实时性，检查结果出来1小时后反映到查询界面都不算晚。

这可以在数据库服务器上放置一个触发器；数据有变动就自动通知外围节点，让这些节点更新数据即可。总之，全都是最最简单的基础逻辑，找“会快排的程序员”都有点大材小用了。

但是呢，我曾经在类似的公司做过事，也知道对接的甲方的水平……

所以，这样一个“庞大”“复杂”“史无前例”的系统，最终如果按我的设计，顶天两三千行C代码以及两三千行js代码就交差了——你猜甲方会不会掏钱？

不不不，这都不是甲方懂不懂的问题了；而是，就这么几行代码，你想让他们掏多少？他们怎么向上面交代？

所以啊，从一开始就不能让会写程序的人掺和，不然三两下搞完了，怎么看都不配拿几十万……

妙在这东西太简单，你就找一群棒槌，他们瞎凑合出来也能交差，至多多买点服务器、多出点事故——但只有这样，才更能证明钱花得值，不是吗？