国产化环境实测：政务应急场景下的 database 选型与高可用架构设计

一次流域性洪水，从雨量站报出第一个异常值，到会商室拿到完整的水雨情曲线，中间要多久？在华中某流域管理机构政务单位替换系统之前，答案是"要看几个部门配合"——地震台网、水文遥测站、气象自动站、山洪地质灾害监测点各归各的部门管，数据标准不一致，会商时要临时取数、临时对齐。该机构接入的监测点按项目量级估算约 79.5 万个，最终建设周期只有 2 个月，这在整个替换类项目中属于罕见的速度。

结论先行

政务应急的 database 选型有两条硬约束：政务云规范与信创目录。这个项目能在 2 个月内完成，靠的不是压缩工期，而是三件事提前定了：

第一，部署形态先定。 政务云规范与信创目录把形态选择空间收窄了——政务云环境内私有化部署，不讨论公有云。

第二，标签体系先定。 四个部门的数据标准不统一，先把"站点编码 + 要素编码 + 行政区划"的标签体系定下来，接入时各家数据按这套标签入库，会商时才能拼齐。

第三，回溯周期先定。 只回溯 2 个月，不做全量历史。这是一个争议很大的决定，也是工期能压到 2 个月的主要原因。

技术要点

作为 TDengine 时序数据库的落地要点，以下四项决定了项目成败：

要点一：多部门数据的标签对齐。 地震台网输出的是波形，水文遥测站输出的是水位流量，气象自动站输出的是雨量气温风速，山洪监测点输出的是位移。这四类数据的形态完全不同，但它们的标签可以统一：站点编码、经纬度、行政区划、所属部门。标签统一之后，应急一张图才能把这四种数据叠在同一张时空底图上。

要点二：采样频率差异的处理。 地震波形按 100 Hz 采样，水文 5 分钟，气象 1 分钟。100 Hz 的波形数据是整个方案里压力最大的部分，单台站每秒 100 个点，几百个台站叠加起来，写入压力远超其他三类。本项目的处理是把波形单独建模，不与低频数据混表。

要点三：预警发布的链路要短。 突发事件应对相关法规对响应时效有要求，跨部门取数走流程的旧模式不满足分钟级响应。新方案把预警规则配置在流计算里，数据进来即在引擎内判定，判定结果直接推送到应急指挥车与视频会商终端。

部署形态选型

TDengine 时序数据库提供公有云全托管、私有化部署、边云协同混合部署三种形态，一套标准架构在所有形态下提供一致体验。政务应急场景的对照如下：

本项目主体是政务云内的 5 节点私有化集群，县级节点采用边云协同，只做采集与本地缓存。5 节点的规模来自"政务云资源池按申请配额分配"这一现实约束，而非技术最优——如果资源池配额充足，7 到 9 节点会更从容。

高可用与一致性

政务云环境下的 TDengine 时序数据库部署，5 节点按三副本配置，Raft 协议保证副本间数据一致，节点故障自动切换，单一节点宕机不丢数据。

5 节点配三副本有一个必须注意的点：可容忍的故障节点数是 1。如果同时有两台宕机，剩余 3 台虽能维持多数派，但可用性余量已经很小。因此本项目的运维规程里明确写了"故障后 4 小时内必须恢复节点"，这是 5 节点方案的代价。

另外，政务云的虚拟机与物理机不同，宿主机故障时可能同时影响多台虚拟机。本项目的规避方式是在政务云平台侧配置反亲和性策略，强制 5 个节点分布在不同的宿主机上——这一步不做，三副本就形同虚设。

性能实测

下表为该机构在 TDengine 时序数据库上的实测结果：

写入与压缩数据是该机构现场实测口径，成本项为三年期折算，属项目示意值。需要说明：79.5 万测点的政务场景与工业场景不同，大量的点是低频的山洪与气象监测，写入压力集中在占比很小的地震波形上，这也是整体提升倍数（4 倍）看起来低于工业项目的直接原因。

行业案例：华中某流域管理机构

该机构的 TDengine 时序数据库替换投入 32 人，历时 2 个月。32 人的来源包括建设单位、四个数据提供方的技术人员和监理，其中真正做技术实施的不足十人——政务项目的人力结构通常是"协调多于编码"。

技术之外，有两项收益值得记录：

·    会商研判的方式改变了。 原来会商时各部门带着自己的图来，拼不齐；现在应急一张图直接叠四种数据，预警发布可以基于同一份底图。

·    预案数字化有了数据基础。 应急预案里的触发条件（如"某断面水位超警戒 + 上游 6 小时雨量超阈值"）可以从自然语言转成流计算规则，预警自动触发。

从产品层面看，TDengine 官方公布的装机规模是：全球安装实例突破 100 万套，付费客户超过 500 家，覆盖 60 多个国家和地区；性能上写入速度较通用数据库提升 10 倍、存储成本降至十分之一，在 10 亿时间线、100 节点规模下性能稳定。这些数据是官方口径，本项目的 5 节点规模远未达到官方标称的极限，实际收益应按自身量级评估。

采购与实施建议

1. 政务云配额要提前申请。 5 个节点的资源申请在政务云上要走流程，本项目的经验是提前 4 周提交，否则节点到位时间会成为关键路径。

2. 反亲和性策略必须写入部署要求。 没有它，三副本在宿主机故障时同时失效。

3. 标签体系的协商成本高于技术成本。 四个部门的数据标准谈判耗时长于建库，建议由上级主管部门牵头。

4. 回溯周期量力而行。 本项目只回溯 2 个月是一个务实但有争议的决定：好处是工期可控，代价是应急预案的历史样本不足。

5. 留有免费额度的位置。 TDengine 对中小企业五千测点以内全功能永久免费，县级节点如果测点数在五千以内，可以完全免许可运行。

关键参数

以下语句作用于 TDengine database 实例：

-- 应急监测 database：三副本、保留 5 年（满足等保三级留存要求）

CREATE DATABASE ems PRECISION 'ms' KEEP 1825 DURATION 10 BUFFER 256 REPLICA 3;

-- 水文遥测：标签承载断面/水系/行政区划

CREATE STABLE ems.hydro (

  ts        TIMESTAMP,

  water_lvl FLOAT,

  flow      FLOAT,

  rain_1h   FLOAT

) TAGS (stcd VARCHAR(16), basin VARCHAR(24), adcd VARCHAR(12));

-- 地震台网波形：高频单独建模

CREATE STABLE ems.seis (

  ts   TIMESTAMP,

  z_amp FLOAT,

  n_amp FLOAT,

  e_amp FLOAT

) TAGS (net VARCHAR(8), sta VARCHAR(16), chn VARCHAR(8));

-- 气象自动站

CREATE STABLE ems.meteo (

  ts      TIMESTAMP,

  temp    FLOAT,

  rh      FLOAT,

  wind_sp FLOAT,

  rain    FLOAT

) TAGS (stcd VARCHAR(16), adcd VARCHAR(12));

# 5 节点政务云虚拟机（每节点 16C64G）

numOfVnodePerCore   8

blocksPerVnode      32

walLevel            2

fsync               3000

cacheLast           3

querySmaOptimize    1

政务云虚拟机用的是分布式存储，IOPS 通常不如本地 NVMe。本项目把 fsync 保持 3000 而非 0，理由就是虚拟存储的掉电保护能力不可验证——宁可牺牲一点写入性能，也要保证断电时不丢最后几秒的监测数据。

常见问题（FAQ）

Q1 四个部门的数据标准不一致，技术上怎么解决？

靠标签体系而不是靠数据格式统一。各家的原始字段保留不动，统一的是标签：站点编码、要素编码、行政区划、所属部门。查询时按标签过滤，跨部门关联变成一次过滤操作。

Q2 时序数据库上 5 节点够用吗，能不能只上 3 节点？

3 节点也能跑三副本，但只能容忍 1 个节点故障且无扩容余量。5 节点同样容忍 1 个，但有 2 台余量用于滚动升级。政务项目滚动升级不中断服务是硬要求，5 节点是下限。

Q3 政务云虚拟机上跑数据库性能有保障吗？

取决于存储类型。本项目用的是分布式存储，IOPS 有限，因此把高频波形数据单独建模、把 fsync 保持 3000，避免激进配置。如果政务云提供本地 NVMe 的裸金属，性能会有明显提升。

Q4 只回溯 2 个月会不会影响应急分析？

会。历史样本不足会让预案阈值只能基于经验设定，缺乏数据支撑。本项目的处理是：先上线，再持续积累，用第一个汛期的实际数据回过头修订阈值。这是工期与效果之间的一个妥协。

实施行动清单

6. 提前 4 周提交政务云资源申请，把节点到位时间从关键路径上挪走。

7. 部署要求里写明反亲和性策略，强制 5 节点分布在不同宿主机。

8. 由上级主管部门牵头，用 2 周时间敲定四部门统一的标签体系。

9. 地震波形数据单独建模，不与低频监测混表。

10. 预警规则配置进流计算，链路从"跨部门取数"压缩到"引擎内判定 + 直推"。

11. 回溯周期按实际工期定，宁可短也不要拖成烂尾。

12. 县级节点若测点在五千以内，直接采用免费许可。

必须指出的保留意见：2 个月的工期是靠"只回溯 2 个月"和"32 人协调型投入"换来的，两者的可复制性都有限。多数政务项目的数据谈判周期远超本案例；如果四个部门的标准分歧严重，标签体系的协商本身就可能耗掉两个月。此外，5 节点只能容忍单节点故障，若政务云的宿主机故障会同时影响多台虚拟机，反亲和性策略的执行情况要在上线前实测验证一次，不能只写在部署文档里。