原文来源： https://tidb.net/blog/900b3544
导语
面对全省 1.4 亿人口、30 万 QPS 并发的极限压力，山东健康码与电子健康卡系统成功完成了从 MySQL/Oracle 到 TiDB 的架构升级。本文基于山东腾安信息科技有限公司数据库负责人李冲在 TiDB 地区活动济南站的经验分享，深度复盘 TiDB 在政务大数据场景中的落地实践与经验。
 作者：李冲｜山东腾安信息数据库负责人业务挑战：数字政务的“极限大考”
在过去几年中，如果要寻找一个最能考验数据库“高并发、高可用、高弹性、高稳定”的业务场景，各省市的“健康码”与“电子健康卡”无疑是具有代表性的场景。
对于 TiDB 数据库而言，这场“大考”来得尤为猛烈。TiDB 承担了山东省大数据局、省卫健委以及烟草行业等多个核心民生平台的主要存储业务。其中，山东省健康码与电子健康卡项目，覆盖了全省 1.4 亿人口，面临着日均 2-3 亿条数据写入、峰值 QPS 突破 30 万的极限压力。
“这不仅是技术问题，更是民生底座的稳定性考验。”李冲在回顾项目历程时坦言。在如此庞大的数据量级下，展码记录单表突破 1300 亿行，传统单机数据库架构如履薄冰。面对海量数据存储以及全省跨地域的数据实时同步需求，如何在保证业务不停摆的前提下，完成从 MySQL/Oracle 向国产分布式数据库的架构升级？这是一场关于架构韧性的深度突围。
选型逻辑：当传统架构撞上“数据高墙”
在项目初期，或者是为了快速上线，或者是沿用旧有习惯，团队曾使用 MySQL 和 Oracle 支撑业务。但随着用户量的爆发式增长，传统架构的“隐形天花板”很快显现。
MySQL 的“分库分表”之痛
在健康码项目初期，主要是基于 MySQL 快速搭建了系统。但随着数据量激增，MySQL 的局限性暴露无遗。首先是写入性能瓶颈，随着表数据增长，B+Tree 的深度增加导致写入效率急剧下降，而业务端每天有数亿条数据必须实时落库。其次是扩展性噩梦，虽然可以通过分库分表来缓解压力，但这不仅增加了业务层的开发复杂度，更在后续扩容时带来了巨大的运维成本。李冲形象地比喻道：“MySQL 的扩展存在上限，且主节点故障会影响 100% 的写入，这在民生项目中是不可接受的。”
Oracle 的“资源争抢”困局
电子健康卡项目原本使用 Oracle 数据库，但由于与多个业务系统共用集群，当电子健康卡的高并发请求涌入时，不仅自身响应变慢，甚至影响了同一数据库上的其他业务。此外，在国产化的大趋势下，Oracle 始终存在供应链安全隐患。
为什么最终选择 TiDB？
在对比了多种方案后，团队最终锁定了平凯数据库 TiDB，主要基于六大核心逻辑：
- 国产且优秀（合规性）：平凯数据库 TiDB 是国产自主研发的数据库，完全符合国产化替代要求，在健康码等民生项目中消除了供应链安全隐患。
- 真正的分布式（高弹性）：这是应对政务流量洪峰的“救命稻草”。TiDB 支持计算与存储的独立在线水平扩展，能在不停机的情况下轻松应对突发流量或平滑缩容。
- MySQL 强兼容（低成本）：高度兼容 MySQL 生态，使得上层业务几乎无需改动代码即可迁移，极大地降低了开发人员的学习成本和系统的改造维护成本。
- HTAP 能力（实时分析）：从 TiDB 3.0 到后续版本引入 TiFlash（列存），真正实现了一套架构同时满足高频交易（OLTP）和复杂报表分析（OLAP）的需求，做到实时数仓一体化。
- 高可用容灾（高可靠）：基于 Raft 协议的多副本机制，支持节点自动均衡与故障自愈。在扩容、迁移或节点故障时，避免了传统数据库的停机风险，RTO 小于 30 秒。
- 人才储备与信任（软实力）：团队在健康码实战中积累了丰富的 TiDB 运维开发经验，且 TiDB 在过往政府项目中表现平稳，建立了深刻的信任基础。
深度复盘：两大核心民生项目的架构演进
案例 1：山东省健康码——从 MySQL 到 TiDB 的架构跃迁
健康码项目的架构演进，是一个典型的从“因为急用所以简单”到“因为重要所以强壮”的过程。
项目的 1.0 阶段处于 2020 年底疫情初期，为快速响应需求，团队使用 MySQL 构建应用。到了 2021 年的 2.0 阶段，随着数据量暴涨，引入了 TiDB v3.0 集群，利用其扩缩容机制应对流量。最终在 3.0 阶段，为确保绝对的数据安全，构建了双数据中心的主备集群高可用架构。
亿级流量下的集群设计
最终的架构是一个庞然大物：主数据中心部署了 30 个 TiDB 节点用于计算，130 多个 TiKV 节点用于存储，承载微信、支付宝等端的展码请求。备数据中心则部署了 90 多个 TiKV 节点，通过 TiDB Binlog（早期方案）与主库同步。为了互不干扰，团队利用 HAProxy 进行读写分离与流量分发，将 15 个 TiDB 节点专门用于对外服务，另外的节点用于内部统计查询和核酸数据同步。
特别值得一提的是“场所码”场景，涉及全省 900 多万个场所信息的管理和每日 3000 多万次的扫码记录写入。通过 TiDB 的原生分布式能力，系统成功抗住了高峰期的并发写入压力，并在后期业务调整时，通过缩容操作平稳释放了资源，避免了硬件浪费。
案例 2：电子健康卡——“1+16”省市数据同步的破局
如果说健康码是“高并发”的代表，那么电子健康卡解决的则是“数据孤岛”与“网络复杂性”的难题。
该项目旨在解决医疗卫生机构“一院一卡、互不相通”的问题。但山东省网络环境复杂，省平台与 16 个地市之间通过专网连接，网络抖动时有发生。如果所有流量都直接打到省平台，不仅数据库压力大，且一旦专网中断，地市业务将瘫痪。为此，团队设计了一套“1+16”分布式架构：建立一个省级集群作为数据中心，负责全省数据的汇总与分析；同时在每个地市独立部署 TiDB 集群，保障本地业务的实时性与高可用。
核心技术攻坚：解决“环形同步”死循环
最棘手的问题在于省市数据的双向实时同步。方案采用了 TiCDC + Kafka 构建流式数据管道，地市数据变更通过 TiCDC 写入 Kafka 同步至省库，反之亦然。这就带来了一个经典的分布式难题：数据环形复制（Loopback）——省库同步给市库的数据，会被市库的 CDC 再次捕获并回传给省库，形成死循环。
团队通过在 CDC-SINK 服务中植入智能校验逻辑解决了这一难题。在数据同步前，系统先对数据做 Hash 计算并存入缓存。当 Kafka 消息环形回来时，系统会比对 Hash 值与缓存，如果命中则说明是“回环数据”，直接丢弃。这一精巧的设计，成功保障了 17 个集群间数据的一致性与稳定性。
一线运维的“五个最佳实践”
结合数年的运维实战，李冲总结了五条极具价值的“运维最佳实践”，正在或计划使用分布式数据库的团队可作参考。
- 计算存储必须物理隔离
在云化部署或虚拟化环境中，曾出现因混合部署导致 CPU 资源争抢，虚拟化层无法有效隔离，导致查询延迟抖动。在规划阶段，计算节点和存储节点必须在物理层面打散，或根据硬件特性（CPU vs 磁盘）进行针对性分配。
- 警惕虚拟存储池的“邻居干扰”
如果虚拟机挂载的是共享的分布式存储池（如 Ceph），而该存储池同时服务于其他高 I/O 业务，会产生严重的“邻居干扰” 。条件允许应尽量直通物理盘（NVMe SSD），若必须使用虚拟存储，务必划分独立的存储池以实现 I/O 隔离。
- 负载均衡的“带宽陷阱”
在高并发场景下，代理节点本身可能成为瓶颈。建议运维团队确认网卡带宽规格，并采用多组 HAProxy 策略，将不同类型的业务流量拆分，既避免单点带宽瓶颈，又保留了高可用能力。
- 百亿级大表的“生存法则”
面对 70 亿条业务记录这样的超级大表，数据归档是必修课。直接使用 DELETE 语句删除过期数据在 TiDB（以及所有 MVCC 机制的数据库）中是灾难性的，不仅速度慢，还会产生大量 Tombstone 记录影响读性能。建议按时间创建分区，通过drop partition方式删除数据，高效且不影响性能.归档时则推荐使用 Dumpling 工具配合 Filter 筛选条件进行冷备。
- GC（垃圾回收）的时间艺术
TiDB 基于 MVCC（多版本并发控制）机制，GC 负责清理旧版本数据。GC 时间的设置是一门艺术：时间太短可能导致长事务失败，或者备份工具（如 Dumpling）因找不到快照点而报错（Snapshot too old）；时间太长则会导致历史版本堆积，查询变慢，占用大量存储空间。建议将 GC 的运行时间窗口调度到业务低峰期（如半夜），并在执行大表删除操作后密切关注 GC 状态。
结语：国产数据库的生态与未来
从健康码、电子健康卡，到如今融合政务、医疗、交通等多元场景的 “鲁通码”，TiDB 已在山东省青岛、烟台、淄博等多个地市落地生根。作为支撑政务服务的关键数据底座，TiDB 凭借透明分布、高弹性、高稳定性及 HTAP 等核心能力，以低门槛接入、敏捷迭代的优势，大幅降低了核心政务系统的建设与运营成本，为政府数字化转型注入强劲动力。
国产数据库的突围之道不仅是简单的软件替换，更是完整生态的构建。稳定的产品版本、完善的生态工具、懂业务的团队，正是构建这一生态的三大支柱。在政务大数据 “极限施压” 的实战考场上，TiDB 与山东腾安信息的合作交出了高分答卷，不仅验证了技术方案的可靠性，更为数字政务底层架构改造提供了一条可复制、可推广的演进路径。
