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

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

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

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

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

纸上谈兵

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上面下文哪个小区哪栋楼哪个超市该黄了，先 update 社区登记居住在对应小区的 set 码 = 黄，然后 update 超市那个码几天内扫过的 set 码 = 黄，齐活。
运营商排查出来之后，把号码报过来，update 注册手机号码是这些的 set 码 = 黄。
错了？自己申诉，审核过了 set 码 = 绿。
上面下文了该绿了，set 码 = 绿。
谁敢做自动的，责任谁来承担？

至少去过机关，去过家属院小区的手机必须是绿的

@murmur 是这样的 没毛病 还真以为是啥高科技呢。。 不扫=没去过

你的问题里少了时间这个要素

1.某地崩掉不是技术问题，而是 kW 级别的总预算，最后分到设备与带宽上，只剩 xxW 。接任务的老板又不是傻子，不可能自己贴钱。落马那个 XX 也被没冤，收了 xxxW 回扣的。

2.这不是技术题，如果最初预算能全拿来堆设备，找个正经拿证的系统架构师来做设计，你就算用 Node.js 做也能扛下来。

3.B 站是在蹭流量。

凡是提到「缓存」的**必须**解决延迟问题，想当然的说**延迟可以接受**的是不行的，万一有一个红码没及时更新，导致影响面扩大了，责任就是你的了。

这类工具要的是第一是**准确性**，第二是**稳定性**，最后才是性能优化。

如前面所说，这是一个社会题，技术特性反倒不是最重要的，大不了加机器。

这不是一个挺典型国外大厂的 system design 的题目么？为什么这么多人有疑问？挺好的结合实际项目的，按照 system design 面试的方法做就好了呀。除了任何一个 system design 都需要考虑的基础：数据库怎么选择 /设计，服务怎么分，api 怎么设计，各个组件如果有瓶颈了怎么 scale ，怎么做 data partitioning/sharding ，怎么做缓存，如果某个服务崩了怎么办，需不需要一些定时的 scheduler ，需不需要一些 message queue 配合 worker 来处理并发。还有一些特有的点，比如和地理位置相关的 geohashing 。挺好的一道题，被这么多人吐槽，话说国内面试没有 system desgin 轮么？

"附近" 可以认为是手机基站，在相同时间区间连接的手机，不需要什么 geo

同意上面有有个人说的，考察快速检索两点距离。
我个人思路是：地图和时间分块。做一些过滤。
地图上，简单点可以四叉树；当然六边形网格更加适合。根据距离要求确定网格的粒度，这样可以快速排除掉无关的空间位置。
时间也是一样的，区间段。
通过时间和空间的快速过滤，可以避免大量无效的查询。另外上面的需要设计对应的数据结构，还要考虑边界。比如一个人正好出现在网格边界。所以检索的时候至少要找外圈一层的时空格子。这样过滤下来，剩下的数据量看看。如果还大再想办法过滤，如果不大随便就搞定了。

我理解标黄也不需要那么实时性，所以数据库读出来到内存，可以根据上面我说的数据结构分布式快速检索。检索做在内存里也 ok 了。

如果要实时性强，考虑缓存之类的。

@caixiangyu17 这才是正解，楼上在讨论什么运营商，什么国情，什么预算，路走偏了。
这种明显就是系统设计的题目，面试而已，又没让他们真的做

至于 HA 之类的，这种更类似个 batch job 。完成了刷入线上缓存或数据库。由展示端做对应的 HA 之类的考虑。

学会压缩图片

@littiefish 人要学会分辨什么是段子

技术帖就聊技术，别说那些有的没的。

说说我之前做的类似一个项目的做法吧，查找指定时间指定区域内的经过的车辆。

原始数据是轨迹点（坐标、时间），因为数据量比较大，使用 hbase 存储，rowkey 设计为 reverse(yyyyMMddHH+geohash[8])。
查询时，计算出覆盖指定区域的 geohash[8] 集合，将查询时间段拆分为多条 yyyyMMddHH ，然后组合成查询 rowkey ，通过 hbase 前缀扫描，初步筛选出数据，然后再做精确匹配。

健康码这个也类似，拿到红码的轨迹点，然后挨个点定时定位查找轨迹区域内的其他轨迹点就行了。

@hidemyself ？？所以这个面试有什么意义

gov 推送数据-健康码缓存-读取展示数据，中间有任何难度么

真正导致卡的原因
1 、他连缓存的 CDN 钱都不肯出
2 、地铁、写字楼等地方密集打开健康码，直接导致附近 4g 压力剧增
3 、健康码用途不单纯，带有其他功能吗，增加了数据量，比如核酸、口罩、还有接种疫苗奖励的小花花

@humpy 是你们在对技术理想化，吹牛逼化，健康码从广州来看，就是谁扫谁黄，别人都打电话叫你核酸了，码还是绿的，就是最简单的证明

健康码说实在的就是个摆设，他都不去看这谁的码，是图片还是码，有意义么

除非全市全区大范围变色，没什么意义，你永远不要低估我国为了防疫在背后的行动

真正的防疫过程是

核酸第一次可疑-封闭相关场所-二次确诊-隔离你的亲朋好友还有同事、你去过的地方的工作员工-附近区域大范围核酸筛查-全区或者全市核酸筛查

我怎么感觉这不是一个技术问题
是一个产品问题

这问题就跟面试的时候问怎么设计电商系统 100%不发生超卖， 但是京东这种头部电商明明是会发生超卖然后通过市场机制解决的.....

真实案例. 我朋友， 俩口子开车路过市立医院门口那条路， 一个黄了， 一个还是绿的.........所以只要放下 100%的执念， 就能海阔天空.......

把所有红点范围内的记录找出来，再在找出来的记录中把人找出来，再把这些人的绿码变成黄码。

@westoy 电商不超卖是程序员的执念，老板根本就不同意好不好。

一个参考方案 [ [官方双语] 接触者追踪一定会牺牲隐私么？-哔哩哔哩] https://b23.tv/leo5niI

四点原则：
0 、健康码只是尽可能降低传播风险的辅助手段，目的不是 100%消除风险；
1 、健康码状态不应是实时的，应该存在“有效期”、“窗口期”；（类似数字证书 CRL ）
2 、数据尽可能本地处理、点对点处理；
3 、验证、扫码尽可能点对点处理，尽可能核验方单点、稳定、安全的网络连服务，而不是被核验方多点、不稳定、不安全的网络连服务；

@xuanbg 没事的，可以砍单，所以有了 pdd

@murmur
面试是用来筛选候选人的不是吗？
候选人给出方案，面试官针对提出问题，候选人给出后续的想法，面试官根据候选人的方案，思考方式，思路来评估这个候选人是不是要的人，这就是意义。

正如国内很多公司会问，如何设计一个秒杀系统，如何设计一个排名系统，如何设计一个抽奖系统，如何设计一个健康码系统？

他关心的是方案和解决问题的方式，你列举的卡的原因，怎么去解决，如果出现别的问题，怎么去解决，这些都是可以用来考验或者说区分候选人的。

至于怎么防疫，行政层面怎么操作，这些和主楼的问题有关系吗？
主楼只是提出“怎么设计后台架构”这样一个问题，方案是方案，跟你的实际操作其实并没有多大关系

geohash 了解一下
一个 query 就能搞定

数据来源：
1. 运营商的时空轨迹数据：运营商负责大数据筛查，定时发到大数据局
2. 交通数据：交通部门定时发到大数据局
3. 扫码数据：大数据局人工手动设置
4. 宾馆住宿的民政数据：民政部门定时发到大数据局
这些数据全部都是进行跑批异步的去设置人员状态。

加速：
1. 短时间（比如 30 分钟）人员状态缓存，防止多次重复查询
2. 传输是不要传图片，传值和颜色，图片由前端生成
3. 小程序都是静态资源存到腾讯 /阿里里，一般不用考虑 cdn

1. 后台计算。
2. 后台录入。

所以健康码读写速度，这个不是解决并发问题吗？ 提高带宽、解决 IO 读写，优化结构，本地和线下缓存。

我这核酸登记的入口今天卡了好几次，感觉就是数据库扛不住了

皇帝家的锄头一定是金的

管你多少人加缓存加队列这种 "加一层"o r 改异步的思路都够解决大部分问题了。你能想到的，稍微有点经验的外包会想不到？

@wangxin13g 技术就这么简单

但是真的是舍不得给钱买带宽

广州现在也就地铁查码比较严格，其余的地方都睁一只眼闭一只眼，有时候医院的保安去休息也是随便进，只查门诊不查住院部，口子大开

然后有人就问了，艹就这一个破码为什么这么卡

以广州健康码为例，这 app 包括了

健康码、口罩预约、核酸监测、疫苗预约、自查上报、购药、公积金、社保、医保......

也就是说平时这个码的流量真不大，只有疫情严重严查才会有巨大并发

@murmur 是 我目前知道的几起问题都是因为带宽 负载,实际上软件层面的问题并不多。

@murmur 人家在问这种面试题如何回答、system design 如何做比较可行，你搁这一口一个瞎胡闹，一口一个啥意义，那你可以选择不回答这个问题，或者是 block 楼主，而不是在这说一些毫无意义的话

想知道红 A 遇到绿 B ，
绿 B 再遇到绿 C ，
最后 C 会不会黄呢？

@cybird 他提供的视频本身就是个广告，既然带广告性质，参考性不大，而且哪里说设计后台架构不考虑业务纯纸上谈兵的

这个题目确实不难…服务端峰值状态用 k8s 自动扩容就行；当然基站过载的问题软件解决不了。。

人员轨迹如果有时序日志数据的话（估计有多数据源综合的问题），用地理位置配合计算即可。历史数据跑个批处理，实时数据直接流处理出结果。

至于只说 geohash 的…在系统设计题目里，估计拿不到什么分。

1. 传染
点：一定空间范围内的人构成一个点。

传染：一旦一个人变色会创造一个感染体，这个人所在的点会被感染。该点会开始向周围一级路径上的其他点进行传染。
每次传染，感染体的传染能力会下降。
传染源不会再被同一个感染体传染。

2. 空间移动
由运营商定期上报更新，个人的位置从一个点转移到另一个点之后，会根据所在的点更新自己的状态，进行同化

3. 自愈
如果一个点在一段时间内不被感染，该点会进行自愈。

4. 投石子
一旦有确认的情况，这个人会导致自己所在的点变色，于是湖里扔下了一颗石子。

@rizon #56 我跑题了。
但是去掉我上面说的怎么计算感染这个逻辑之后。
健康码就是一个纯粹的高并发读操作查询问题，而且还不需要做全国范围的。。。

@murmur
面试官想考察你的系统设计能力，你去跟面试官扯社会问题吗

考虑到题目是「优化」健康码，而不是「设计」健康码，如果你是在广州的话，所有谈到地理信息的目测都可以挂掉了。

粤康码、穗康码都没有收集定位信息，哪里来的地理位置你算。在这个系统里面，真的 LBS 的估计就只有通信行程卡。

就是系统设计，你能把你的方案说出来说服面试官就行了。
上面说 k8s 的，那是运维层面了。
之前我面试也被面过哈里发塔电梯系统设计，当时也是想到什么说什么，后来一查，有个屁标准答案，电梯算法到现在都是个难题。

我还好奇上面的人在喷谁，多看了几层。。发现早就 block 那个人了。。。

@banmuyutian 那只能说我的吹牛逼功夫不够，我认为健康码就是社会问题，在安卓和 ios 隐私保护越来越完善的今天，你能不能取到精确定位，甚至有没有定位都是两说

没什么可以吹的，我只能跟你谈业务和社会问题

为什么那么鄙视社会问题，连阿里都想清楚了，双十一一天抢购是个很 sb 的问题，系统压力大，快递压力大，用户体验差，明明促销 2 个月可以轻松解决，为什么要死磕优化

健康码这个东西需要优化的不是技术方案，而是行政管理方案。

其实健康码本身也是个系统设计问题，数据来源有用户的主动上报管理，的对于单个人员的置黄红，不同地方政策不一样所以需要每个地级市都要一个健康码，以及如何从运营商那边获得人员驻留轨迹，如何扛住系统压力。

SELECT 谁 FROM stream( 谁, 时间, 地点) // "场所码" 了解一下
JOIN table(地点, 开始时间, 前预警期, 后预警期) // 也可以换成流 不过 是 windowed stream
ON 时间 > 开始时间 - 预警期 AND 时间 < 开始时间 + 后预警期

或者 基于设备之间互发现的做法 "apple 暴露通知" 了解一下

位置这个数据可不是只记最新的. 一般都会需要有追溯的功能, 根据追溯时间长度精度, 这个存储的难度可大可小.

这贴都有阴阳怪气的 还有给它点赞的

我会提醒他看看我的简历，让他猜猜实际上我们是怎么做的。

有点意思，系统设计问题最大的乐趣就是看看大家的思路，与自己的想法的碰撞

无论怎么设计，总是不可能依靠技术解决 100%的问题，但面试只是为了考察能力嘛

最关键的是 地理位置 是从哪里获取的， 如果是运营商提供，那还用费脑筋？

这种系统设计再加上一个算法题可比八股面试有意思太多了，而且也更能面试出候选人的水平，但是遗憾的是这种水平的面试对面试官的要求也比较高，所以并不好推广

@liudaolunhuibl 也许面试官也不会[手动狗头]

@undefine2020 这里有一个很有意思的问题，可能我们都没想到，甚至都不知道答案

如果我 A 地成了密接（ A 地因为没有出现大范围传播所以是低风险），但是在我确认密接的时候上了火车，等我下车要检查 B 地的码

如果 AB 两地自行收集数据，那么这个东西就是一坨 shit ，我在 B 地因为没有数据（假设这个地方的火车站马虎到不去看新闻，不知道哪里是需要观察的区域），是绿码，畅通无阻
如果我到 B 地也黄了，那说明国家背后有一套强大的系统共享通行数据，这就不是我们考虑的事了

有人说我们再抬杠，我想说你一点生活常识没有，八股文背傻了是吧

我同事因为发烧去了一次发热门诊就黄了，至于什么时候黄，谁关心呢，反正在核酸结果出来之前他是不能离开医院的，在这 6 个小时内系统有充足的时间刷新缓存、收集数据

同理，可能你的数据还没刷新，因为你核酸监测异常，疾控中心就会给你打电话让你别动，相关人员就开始封锁你的单元楼，然后大家焦急的等复核结果，这个行动远比健康码快的多

所以这个东西纯技术有什么意义？？

@murmur 这个肯定是错杀 1W 的设计原则，上头会有规定的

@4771314 这个极海还是挺强的，面试视频干货很多，早就关注了

请不要在这里讨论技术问题
-> stack overflow
-> segment fault
-> 掘金
...

我有个朋友就是负责某省健康码的，表示没这么难。。
也就是常见的工程上的解决方式就行了，相反最难的还是跟大数据局的领导开会扯蛋撕逼

@humpy 把 yyyyMMddHH 换成 epoch 可以进一步优化查询效率