刷健康码,从入门到重启

背景

前几天的早晨我早写字楼门口干等了半小时,背后的原因竟然是健康码的二维码刷不出来,保安小哥还一直跟我讲,支付宝出不来你用微信啊,用微信啊。。

他们用的相同的接口,我用微信有卵用啊,冷风中我甩了甩仅有的几根秀发,扬长而去。。。

作为程序员的我就开始了内心的吐槽大会:这咋做的啊,不行呀,这就打不开了,肯定没做优化,肯定没用缓存,肯定没做压力测试。。。。。

下面作为技术的视角来分析下这个场景的实现,以及可以怎么去优化。这只是我YY哈,真实场景别人是怎么实现的我也不清楚哈。

需求分析

每个人都有一个对应的健康码,健康码分为几种颜色,也就对应了几个状态。本质上就是通过健康码的颜色能否区分这个用户是否去过高风险地址。


首先第一个问题就是需要根据多维度的数据去计算出这个码的颜色,比如根据用户的行动轨迹去分析。至于实际上有哪些维度我也不知道,大概猜测行动轨迹肯定是其中一点。


大概的存储也很简单,就是userId code等字段,这个场景如果需要历史数据可以单独归档即可,只留最近一天的数据提供查询即可。

实现剖析

最简单的方案就是每次查询实时去分析,这样结果的真实性更高,不足点在于体验不是很好,如果逻辑多的话肯定是无法在1s内给用户响应的,所以在上面分析的时候我们设计了一张表进行存储,肯定是提前计算好的,比如一天一次,半天一次之类的形式。


那我们基于已经有表的形式去做分析,这个业务场景就是很典型的读多写(凌晨写)少的场景。如果不做任何改动,每次请求直接查询表直接响应即可。在高并发场景下只能依赖数据库的并发能力来扛住这些请求,很容易出现系统挂掉,响应慢的情况,也就是为什么我在门口等了半小时的原因。

增加缓存

最好的方式就是加缓存了,直接将码的内容缓存起来,前端根据内容生成健康码即可。首先这种场景不能再查询之后加缓存,因为大部分人的监控码可能也就早晨进公司的时候用一次,所以不适合查询后再写缓存的操作。。。。


等等,手机重启好了,扫描二维码,哎哟,哎呀,健康码出来啦,好了,可以通过了,

大招

重启手机!  若还是不行,那就再来看我的分析。(不过基本没卵用)


来源:博客园  (有修改)

发表评论 取消回复

很抱歉,您暂时无法发布评论。需要 登录 后才能发布。