每天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小时后反映到查询界面都不算晚。

这可以在数据库服务器上放置一个触发器;数据有变动就自动通知外围节点,让这些节点更新数据即可。总之,全都是最最简单的基础逻辑,找“会快排的程序员”都有点大材小用了。插播一条广告:需要开通正版JetBrains全家桶的可以联系我,56元一年,正版授权,官网可查有效期,有需要的加我微信:poxiaozhiai6,备注:910。

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

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

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

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

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

我当年在这种公司上班,就被某同事打了小报告,说我代码行数太少,一万行写完都不算多的功能,让我连注释一起300行给搞定了(注释率50%,也就是只有150行有效代码),使得公司受到了重大损失……

得,两不待见,我还不辞职,等着干嘛呢?

技术
今日推荐
阅读数 7017
阅读数 2018
阅读数 1515
阅读数 1303
阅读数 1303
阅读数 1134
下载桌面版
GitHub
百度网盘(提取码:draw)
Gitee
云服务器优惠
阿里云优惠券
腾讯云优惠券
华为云优惠券
站点信息
问题反馈
邮箱:ixiaoyang8@qq.com
QQ群:766591547
关注微信