设计不会崩溃的健康码系统

在疫情仍未结束的今天，手机端的健康码为快速识别风险人群提供了很大便利。然而，一旦其后台系统不能及时提供查询服务，用户就会面临无法自证清白的尴尬。那么，能否通过有限的资源提供可靠的服务呢？

本文试图通过利用现代信息科技，逐步设计一个低成本（日均成本 1 块钱），且不会崩溃的健康码服务系统。

声明：本文中所有分析如虚拟机价格基于网络公开信息，实际情况可能不同。

如果你希望了解如何能最优化的快速检测新冠病毒，可以参考“新冠检测的最优分组算法”。

需求分析

首先分析功能需求，系统至少要能实现如下两个基本操作：

查询：给定身份证号，可以及时返回是否具有风险（如红绿码，更复杂的可以进一步返回风险值大小或位置信息，此处忽略）；
更新：后台数据可以进行更新，包括用户在健康和风险状态之间的转换。

性能需求上，如果以省为单位提供服务，则需要支持亿级别用户数；如果以市为单位，则千万级用户数即可。

此处假设以省为单位，支持 1 亿用户的日常查询。若用户平均每天查询 10 次（早 8 点到晚 8 点），则吞吐率约为 24 千次/秒（100,000,000*10/12/3600）。假设峰值为平均值的 10 倍，则系统需要支持的最高吞吐率为 240 千次/秒。

用户身份证号为 18 位，用字符串存储需要 36 字节，用数字存储需要 8 字节。相对于网络协议报头来讲几乎可以忽略不计。

假设单个请求消息为 200 字节，则峰值访问带宽为 2402008 Kbps = 384 Mbps，保守估计 400 Mbps 带宽可以满足。

问题特点分析

问题最难的部分在于如何支持高速率的查询。考虑到通常情况下，风险者比率较小（否则就无需健康码服务了），这是一个典型的稀疏数据查询问题。

对类似问题，通常思路为仅存储稀疏数据（风险者身份证号），如果查询不到，说明非风险者。

假设风险者比率为 1%，则实际存储数据为 1 百万条身份证号（字符串存储下约 36 MB，容易全部放入内存），并不算大规模数据集。

初步设计

最简单的设计，将所有风险者数据直接存储到数据库。选用常见开源实现 MySQL，容易实现单机千次每秒查询。应用常见优化手段（缓存、索引、内存引擎等）后，即可实现单机超过万次每秒查询性能。

粗略估计整体系统需要 24 台服务器。以租用公有云虚拟机为例，4 核 8 G 虚拟机的日均价格不到 1 元人民币，24 台共计 24 元。400 Mbps 带宽的每天费用约为 1000 人民币。

整体算下来，日均成本为 1024 元人民币。

考虑到这套服务能支撑亿级别的用户，这个结果已经很不错了。但是科技工作者做事不达极致是不会罢休的，让我们看看能否进一步优化。

优化方案一：替换数据库

首先，由于查询仅需要确认某数据是否存在，并且数据量不大，对读写一致性容忍度较高，因此可以考虑替换为 NoSQL 类数据库如 Redis。

普通服务器上 NoSQL 类数据库的查询可以达到 100 千次/秒，成功将服务器数量减少为 3 台。

此方案的 日均成本为 1003 元人民币。

优化方案二：使用布隆过滤器

布隆过滤器（Bloom Filter）是一种经典的用于查询元素是否在集合存在的数据结构。它存在误判的情况，即如果判断存在，实际上可能不存在；但是如果判断不存在，则必然不存在。

这个特性十分适合判断风险人群的情况。假如布隆过滤器认为某人无风险（大部分情况下），则必然是无风险；如果认为有风险，可以再通过数据库来进行确认。

存储一百万条数据，误判率为 3% 时，布隆过滤器只需要 1 MB 大小内存数据结构，查询性能可以轻松达到百万次。实际上，很多高性能数据库也采用了该数据结构（如 Redis）以提高性能。

此时，只需要 1 台服务器即可轻松处理所有查询。

日均成本为 1001 人民币。

优化方案三：预置过滤器

读者可能会发现，服务器数量从 24 台优化到了 1 台，但是总体费用几乎没下降，这是因为带宽费用占了绝大部分成本。那么，网络带宽是否有优化的空间呢？

最直接的思路就是干脆把过滤器下载到客户端本地。这样绝大多数无风险用户通过本地查询即可得到结果，只有少数风险用户和误判用户需要发到服务器进行处理。

估算下来，带宽需求降低到了原来的 1%，日均成本降低到了 5 元人民币。

优化方案四：利用内容分发网络

细心的读者可能会想到另一个问题，当客户端预置的过滤器需要更新时，还是会占用不少的网络带宽。这就轮到内容分发网络（Content Delivery Network，CDN）出场了。

内容分发网络会提前在不同地理位置部署多个边缘服务器，将需要分发的数据提前缓存到边缘服务器上，其带宽成本要低于直接从核心网络上分发。

这样，即使客户端每天都需要更新数据，也不会是太大问题。

如果，连这点钱也不想掏呢？

终极方案：分布式网络应用

网络的本质无非是要传输数据。如果客户端之间能直接彼此发送数据，那么服务器端的分发压力不就大大降低了吗？这正是 P2P 网络所擅长的。

通过让客户端支持 P2P 组网分发，完美解决了客户端过滤器更新问题。

再进一步，服务器可将过滤器和完整数据都通过 P2P 网络分发到客户端，客户端自行本地查询即可。用存储换计算，同时即便服务器宕机或网络故障也不会影响健康码的展示。

更懒惰一些，如果连会进行 P2P 组网的客户端都不想开发，那干脆把数据加密后放到现成的 P2P 网络（IPFS 可以了解下）里好了。客户端可以随时下载数据解密后再进行更新。

这样做的话，服务器连查询服务都不需要提供了，日均成本降低为 1 块钱。

总结

总结下，本文展示了设计一套高性能并发查询系统的逐步演化过程：通过选用合适的数据库和系统优化，所需服务器数量降低到 10%。使用布隆过滤器成功实现单机支撑海量查询请求。通过客户端预置过滤器又降低了服务器压力为原来的 1%。通过内容分发网络实现客户端数据的快速更新。结合 P2P 技术，极大提升了系统的可扩展性和可靠性，并最终降低日均成本为 1 块钱。

当然，本文仅从理论角度分析可能的设计方案，而从系统设计到实现落地之间，必然还有不少工作要做。在实际生产中，至少还需要考虑如下方面：

负载均衡：假设通过客户端预置服务器地址的方式进行负载均衡。
安全防范：假设服务器所在数据中心提供了基本的安全防范系统。
隐私保护：假设客户端通过加密方式能较好地保护用户隐私。
......

科技作为第一生产力，不正是为了让每个人的生活更加美好和轻松吗？

本文亦发表于设计不会崩溃的健康码系统。

===== 关于 TechFirst 公众号 =====

专注金融科技、人工智能、数据科学、分布式系统相关领域的热门技术与前瞻方向。欢迎投稿！

如果你喜欢公众号内容，欢迎鼓励一杯 coffee~