优化健康码读写速度的面试题

[fyooo]

对于一个地区海量用户，有 3 种状态：红码 /黄码 /绿码。

1. 如果特定地方出现红码，会根据地理位置把附近用户状态设置成黄码
2. 经过一段时间，清零后，黄码变成绿码

怎么设计后台架构？

昨天在 B 站刷到的推荐，有点意思，跟同行探讨一下

[MoYi123]

把有风险的地理位置记下来, 用户查自己的时候看看最近几天有没有这些地方出现过,不就好了. 不就是简单的 curd, 需要什么架构吗?

[ClarkAbe]

匹配地理位置经纬度大小于就行了，就是需要一个后台任务

[villivateur]

这个操作很简单吧？一个健康码对象只需要地理位置、颜色两个属性就够了

[RickyC]

什么叫附近？
何时取得用户 location ，以何时的为准？
这是一道社会题，不是一道技术题

[RickyC]

纸上谈兵

[wzzzx]

@MoYi123 #1 要是有问题的话，需要通知到用户的

[Latin]

@MoYi123 考虑下国情和人口基数 再参考下崩溃的西安健康码

[securityCoding]

这么几个状态要个几毛架构啊，缓存一把梭

[MonoLogueChi]

做一层缓存数据库，把健康码状态直接放入缓存数据库，这样查询操作就变成了最简单的数据库查询。每天深夜的时候主动刷新缓存，同时，绿变黄，黄变红等操作要及时刷新缓存。

[murmur]

没有地理位置这一说，瞎胡闹，都是运营商或者相关部门上报

[paopjian]

健康码改变颜色是后台手动操作的,自动改绿会被骂死的.

[gamexg]

接受西安崩掉的教训，
我是直接会将健康码展示界面的 web 服务器、数据库和后台管理、计算服务分开。

展示用的数据库可能会弄一个 kv 数据库，可能按照每用户甚至每个用户*页面来保存到数据库。
目的是，尽可能减小展示健康码时的压力，只一次 kv 查询解决。而且全部只读，方便扩展。

黄码、红码等后台异步批量去处理，这个稍微有点延迟可以接受。

[akira]

这个问题的核心 应该是如何快速计算 2 点之间的距离

[jiangwei2222]

根据实际情况分析:一个用户的位置肯定得存多条，比如我上班一个地方，工作一个地方，吃饭一个地方，用户位置直接存一个经纬度点

风险地区的话是一个区域，使用 geohash 进行索引
，目前实际情况全国风险地区应该不会超过 10 万个。

查询某人状态或者查询风险区域里面的人都是能命中索引的，合理设置缓存时间，机器堆够，应该没啥复杂的

[jiangwei2222]

本质上难点应该就是如何给地理位置建索引罢了，这个业务逻辑足够简单，直接上 geohash

[dqzcwxb]

缓存和定位而已,很麻烦吗?更多的是社会问题而不是技术问题

[ch2]

@akira 不，核心问题是二维码不要小水管直接传图片，js 要上 cdn

[labulaka521]

应该是算一个用户的活动区域和另外黄码用户的活动区域是否有交集

[murmur]

我感觉有人的思路被限制住了，健康码真的是靠自己定位的么，难道不是每个店门口有个码，进来之后自己扫一下，好了，现在流调人员来了，调出数据库，最近 3 天的人全黄了

然后运营商，摸排走访，电话，大数据

哪里有什么技术，都是背后的辛勤劳动

[FakNoCNName]

为什么不能做个原生 app 呢？
现在这些大厂软件 web 套壳弄得手机一地鸡毛，打开就疯狂下载首页数据。等待加载的过程卡的要命，甚至有些软件不加载完点哪里都没反应，用的人多了加载的更慢。最后让后端调整技术架构，来支撑屎一样的前端产品设计。