编者按
7✕24 小时 “永远在线”，是市民热线系统的生命线。面对这一核心挑战，吉奥时空在市民热线项目中选择了 TiDB 云原生分布式数据库。他们不仅实现了平滑迁移，更关键的是完成了在云平台与物理机间的“不停机”在线迁移、以及在线处理节点故障和服务器减配等高难度运维操作，为政务系统的高可用性提供了宝贵的实践参考。
业务背景：高可用性压倒一切
吉奥时空是由武汉大学李德仁院士创办的科技成果转化企业，同时也是国家高新技术企业。公司的核心业务板块包括自然资源、城市治理和国产生态。
市民热线系统自 2008 年起由该公司维护，随着数据量不断增加、第三方接口日益增多，系统逐步暴露出几个核心痛点：
- 停机之痛：系统技术栈落后，每次进行系统迭代、数据库迁移或服务器扩容、减配时，都必须停机。对于要求 7x24 小时服务的政务系统来说，每年停机几个小时是不可接受的。
- 性能瓶颈：早期设计的表结构和业务逻辑，在数据量激增后变得不合理，导致报表统计和数据查询越来越慢，严重影响用户体验。
- 国产化要求：作为政府民生项目，数据库、中间件等基础软件都需要逐步迁移到国产生态上。
基于这些情况，公司在 2022 年决定对业务架构方案进行彻底改造。
选型之路：为什么是 TiDB？
在 2022 年的重构中，公司转向 Java 技术栈。对于数据库，我们提出了几个硬性要求：开源软件优先、满足国产化要求、必须同时支持 OLTP 和 OLAP 场景、并能具备完善的开源社区人才生态以及开发生态。
公司考察了多个开源数据库产品方案，最终焦点落在 PG 内核产品、MySQL 主从方案和 TiDB 三者上。经过综合评估，公司最终选择了 TiDB，主要基于以下几个关键优势：
- MySQL 高度兼容：开发人员几乎不需要额外的学习成本，直接使用 MySQL 开发框架，可以快速适应。
- 在线弹性伸缩：TiDB 的在线水平弹性扩容和缩容能力非常出色，业务无需维护分片键逻辑以及路由分片维护，这完美契合了业务“不能停机”的核心诉求。
- HTAP 架构：TiDB 具备 OLTP 和 OLAP 的混合处理能力，能很好地解决棘手的报表查询慢的问题，HTAP 具备天然的物理隔离能力，提供实时分析决策运营能力。
- 强大的监控：TiDB 完善运管监控生态闭环，基于 Pormetheus 提供了非常好的监控界面以及 Dashboard 可观测性能力，能快速定位问题。
- 开源与社区：TiDB 在人才社区具有 4 万规模，开源内核项目一直位居于 DB-Engine 关系型数据库全球排名 Top 50 以内，符合的开源基础软件选型的初步要求。
实践成果：三年“几乎没有停过业务”
从 2022 年开始迁移，武汉市民热线使用 TiDB 已经三年多了。这套系统架构复杂，包含了 7 个子系统、30 个微服务、8 个模型算法以及 30 多个接口单位。业务使用 TiDB 作为分布式关系型 NewSQL 数据库，Redis 和 ES 作为非结构化数据库。
线上 TiDB 集群版本为 v5.4.0，数据量约 800G，部署架构为 3 TiDB、3 TiKV、3 PD、2 TiFlash 以及 HA 组件。
使用 TiDB 带来的收益非常显著：
- 真正的高可用：自使用 TiDB 以来，业务“几乎就没有停过”，全年 SLA 高可用能力达到 99.995%。
- “不停机”迁移：实现了从云平台到物理机的在线迁移。当初为解决 IO 问题，通过 TiDB 的扩容和缩容能力，逐个迁移 TKV、TiFlash、TiDB 和 PD Leader 节点，整个过程业务没有受到影响。
- 查询性能飞跃：原有架构需要半小时甚至更久的报表查询，现在速度至少快了 3 倍，复杂 SQL 在分钟级提供准实时报表处理。
- 运维便捷：TiDB 生态项目中提供完整的 TiUP 工具，支持黑屏操作的一键安装、部署实施方便，运维体验很好。
宝贵经验：在线处理紧急故障
在三年多的使用中，我们也积累了一些在私有化架构方案应对极端情况的实战经验：
经验一：云平台高 IO 问题的排查
我们最初将数据库部署在云平台，但很快发现 TiKV 的 IO 持续高达 80%。经过排查，SQL 优化和配置更改都无效。最终发现，问题出在云厂商的底层架构：他们的 SSD 磁盘是通过光纤连接的远程磁盘阵列，而不是直连。
这种网络延迟，即使是毫秒级的，对于 TiKV 这种对网络高度敏感的组件也是致命的，可能导致心跳超时和 Leader 切换。这个教训让我们意识到，为分布式数据库选择基础设施时，必须高度关注网络拓扑和延迟。
经验二：在线处理服务器减配
由于使用的是租用服务器，我们遇到了政务系统特有的“在线减配”需求。在一次操作中，我们需要对一台主节点（231 服务器）进行减配。我们在线上直接关闭了该节点的 keepalived、检测脚本和 haproxy 软件等 HA 组件，系统立刻自动跳转到了备份节点，整个切换过程对业务“一下都没有影响”，业务连续性保障性进一步完善。
经验三：通过监控秒级定位业务卡顿
有一次，话务员紧急反馈“电话接不进来”，业务发生卡顿。我们立刻查看 TiDB 监控平台，发现一个 TiDB 节点的负载异常高。将问题节点下线后，业务瞬间恢复正常。随后我们再从容地进行数据平衡和节点迁移。这充分证明了 TiDB 监控系统的强大和架构的韧性。
未来规划：拥抱向量化与更广阔的推广
我们对 TiDB 的未来使用也有清晰的计划：
- 版本升级：我们计划在“不能停业务”的前提下，从 5.4 版本升级。我们希望新版本能解决 5.4 中 TiDB 节点内存持续积累直到 OOM 的问题，并希望开放 TiKV Follower 读功能，以减少热点，进一步提升数据库性能。
- 集成向量化能力：目前，市民热线的人工智能功能（如智能坐席助手、智能分拨、类似案件自动归类）是依赖 ES 实现的。我们了解到 TiDB 新版本（如 V8.5）将支持向量搜索功能。如果 TiDB 自身具备此能力，我们将考虑移除 ES，用 TiDB 统一处理，这将大大简化技术栈和维护成本。
- 推广至更多地市：吉奥时空在全国很多地市都有市民热线业务。基于武汉的成功经验，我们计划在其他地市的市民热线系统中也推广使用 TiDB。
从传统数据库到 TiDB 分布式数据库，武汉市民热线系统的演进，不仅仅是一次数据库的国产化替代，更是面向现代化数字政府建设的一次架构飞跃。在“7✕24小时”这一刚性约束下，吉奥时空利用 TiDB 的分布式高可用与 HTAP 架构，成功破解了政务系统“停机维护”的传统魔咒。
该应用实践证明，现代化的数据底座与关键的民生应用相结合，能够真正实现技术韧性与业务连续性的统一。这不仅提升了城市治理的响应效率，也为未来承载更大数据量、集成更多 AI 应用奠定了坚实的基础。