目录
- 背景
- 健康码设计
- 最初设计
- 替换数据库
- 使用布隆过滤器
- 预置过滤器
- 利用内容分发网络
- 压测以及可观测性
- 参考文章
背景
- 本文旨在探讨如何设计一个低成本、高可靠性的健康码服务系统，以应对快速识别风险人群的需求
- 健康码系统的功能需求，包括查询和更新两个基本操作。性能需求方面，以省为单位，假设支持1亿用户的日常查询，若用户平均每天查询 10 次(早 8 点到晚 8 点)，则吞吐率约为 24 千次/秒（100,000,000*10/12/3600）。假设峰值为平均值的 10 倍，则系统需要支持的最高吞吐率为 240 千次/秒。用户身份证号为 18 位，用字符串存储需要 36 字节，用数字存储需要 8 字节。相对于网络协议报头来讲几乎可以忽略不计。假设单个请求消息为 200 字节，则峰值访问带宽为 240000 * 200 * 8 bps = 384 Mbps，保守估计 400 Mbps 带宽可以满足
- 查询是系统最难的部分，因为风险者比率较小，这是一个稀疏数据查询问题
健康码设计
- 逐步优化:
- 替换数据库：使用NoSQL类数据库如Redis，减少服务器数量，降低成本
- 使用布隆过滤器：利用布隆过滤器的特性，减少误判，提高查询性能
- 预置过滤器：将过滤器下载到客户端本地，减少带宽需求，降低成本
- 利用内容分发网络（CDN）：通过CDN提前缓存数据，减少更新数据时的带宽占用
- 分布式网络应用：采用P2P网络，让客户端之间直接传输数据，进一步降低服务器压力
- 通过选择合适的数据库和系统优化，可以将服务器数量降低到原来的10%，使用布隆过滤器实现单机支撑海量查询请求，客户端预置过滤器降低了服务器压力为原来的1%，结合CDN和P2P技术，提升了系统的可扩展性和可靠性，最终将日均成本降低到1元人民币
- 在实际生产中，还需要考虑负载均衡、安全防范、隐私保护等方面的问题，还需要完善的压测机制，下面详细介绍各个设计的思路
最初设计
- 选用常见开源实现 MySQL，容易实现单机千次每秒查询。应用常见优化手段（缓存、索引、内存引擎等）后，即可实现单机超过万次每秒查询性能
-
粗略估计整体系统需要 24 台服务器。以租用公有云虚拟机为例，4 核 8 G 虚拟机的日均价格不到 1 元人民币，24 台共计 24 元。400 Mbps 带宽的每天费用约为 1000 人民币
直接读取数据库.png
替换数据库
- 由于查询仅需要确认某数据是否存在，并且数据量不大，对读写一致性容忍度较高，因此可以考虑替换为 NoSQL 类数据库如 Redis。普通服务器上 NoSQL 类数据库的查询可以达到 10万qps，成功将服务器数量减少为 3 台
使用布隆过滤器
-
布隆过滤器特性十分适合判断风险人群的情况。假如布隆过滤器认为某人无风险(大部分情况下)，则必然是无风险；如果认为有风险，可以再通过数据库来进行确认。存储一百万条数据，误判率为 3% 时，布隆过滤器只需要 1 MB 大小内存数据结构，查询性能可以轻松达到百万次。此时，只需要 1 台服务器即可轻松处理所有查询
使用布隆过滤器.png
预置过滤器
- 服务器数量从 24 台优化到了 1 台，但是总体费用几乎没下降，这是因为带宽费用占了绝大部分成本。最直接的思路就是干脆把过滤器下载到客户端本地。这样绝大多数无风险用户通过本地查询即可得到结果，只有少数风险用户和误判用户需要发到服务器进行处理
利用内容分发网络
- 当客户端预置的过滤器需要更新时，还是会占用不少的网络带宽。这就轮到内容分发网络CDN出场了。更进一步还可以使用P2P
压测以及可观测性
- 构建完整的监控体系，提前预警业务事件，提升系统SLA
- 可观测体系: 可观测能力是运维中不可或缺的一部分，帮助及时发现故障并加速故障恢复。通过基础组件、业务指标、用户体验和业务拨测等多个维度构建可观测体系
- 预估业务量并进行扩容，完成性能压测。压测过程中解决瓶颈问题，如单核跑满、负载过高、防火墙故障等
- 架构需要具有自保护能力和对后端应用的保护能力，如增加队列、缓存、限流等
- 变更控制对保持业务稳定运行至关重要，变更请求需经过严格评审和授权后实施
