工业系统对数据可靠性的要求不是"尽量不丢"，而是"不可丢失"。电力调度系统的事故追忆数据（SOE）丢失，无法还原故障时序；化工安全监测的报警数据丢失，事故调查失去证据链；核电仪控系统的运行数据丢失，监管合规无法满足。这些场景中，数据丢失不是技术故障，而是合规和安全事件。时序数据库的高可用架构设计，必须从"数据不可丢失"这一底线出发，而非从"系统尽量不宕机"出发。
工业数据可靠性的分层要求
不同工业场景对数据可靠性的要求有层次差异，高可用架构的投入应与业务要求匹配。
电力行业是最严格的场景之一。DL/T 860（IEC 61850中国版）规定变电站监控系统数据可用性不低于99.95%，事件顺序记录（SOE）分辨率1毫秒。电力调度数据网要求通信中断恢复后数据完整补传，SOE数据不可覆盖、不可篡改。核电行业要求更严——仪控系统数据保留周期5-10年，期间不可有断点，满足核安全法规HAF的审计要求。
化工安全监测数据的保留要求通常为3-5年。安全联锁系统（SIS）的动作记录、可燃气体检测仪的浓度数据，在事故调查时是关键证据。如果因数据库故障导致某段时间数据缺失，事故分析可能出现盲区。
常规工业生产数据（OEE、设备状态、工艺参数）的保留要求1-3年，可用性要求99.5%-99.9%。这类数据丢失影响生产分析质量但不涉及安全合规，高可用投入可适度降低。
高可用层级 | 保障目标 | 技术手段 | 适用场景 |
写入高可用 | 数据不丢失 | 多副本+WAL | 安全监测/核电/电力 |
存储高可用 | 数据不损坏 | 磁盘冗余+副本校验 | 全场景 |
服务高可用 | 查询不中断 | 故障切换+客户端重连 | 监控看板/调度系统 |
多副本机制：写入路径的数据冗余
多副本是写入高可用的核心。数据写入时同时写入多个副本节点，单节点故障时其他副本仍有完整数据。副本数的选择是可靠性与成本的权衡。
同步复制保证强一致性。写入请求在所有副本确认落盘后才返回成功。三副本同步写入时，需要三个节点都写入成功才返回。优点是数据零丢失——主副本故障时，从副本有完整数据。缺点是写入延迟增加——必须等待最慢的副本完成。三副本同步写入的延迟是单副本的1.5-2倍。
异步复制追求高性能。写入请求在主副本落盘后立即返回成功，从副本异步追上。优点是写入延迟低——只需等待主副本。缺点是存在数据丢失窗口——主副本故障时，尚未同步到从副本的数据丢失。窗口大小取决于同步延迟，通常在毫秒到秒级。
TDengine默认采用三副本同步写入机制。写入请求由Vnode的主副本（Leader）接收，同步到两个从副本（Follower）后返回。三副本部署要求至少3个物理节点。如果资源受限可以配置单副本，但此时无高可用保障——单节点磁盘故障数据丢失。
副本数的选择不总是越多越好。三副本是工业场景的标配——容忍1个节点故障。五副本在极高可靠性要求场景下使用——容忍2个节点同时故障。但五副本的写入延迟是三副本的1.3-1.5倍，存储成本增加67%。实践中五副本仅用于核电、电力调度等极少数场景。
WAL：写入路径的最后防线
WAL（Write-Ahead Log，预写日志）是数据库的"黑匣子"。每条数据写入数据文件之前，先写入WAL日志文件。如果写入过程中系统崩溃，重启后通过回放WAL恢复未完成的数据写入。
WAL的工作流程：写入请求到达Vnode→数据追加到WAL文件（顺序写，性能高）→数据写入内存数据结构→异步刷盘到数据文件→WAL对应段可删除。如果Vnode在"写入WAL"和"刷盘到数据文件"之间崩溃，重启后从WAL中读取这段数据重放写入。
WAL的可靠性取决于落盘策略。同步刷盘（wal_fsync_period=0）每条写入都fsync到磁盘，可靠性最高但写入延迟增加。周期刷盘（wal_fsync_period=3000）每3秒批量fsync一次，正常情况下最多丢3秒数据，写入性能更好。工业安全场景应配置同步刷盘或1秒以内周期刷盘。
WAL与多副本的关系：WAL防单节点崩溃后的数据丢失，多副本防整个节点故障。两者是互补的。三副本+WAL同步刷盘的架构下，数据丢失需要同时满足：主副本和两个从副本同时崩溃（概率极低），且三副本的WAL都未落盘（需要三个节点同时断电且磁盘缓存未刷盘）。这种概率在实践中可忽略。
集群故障切换机制
节点故障后，集群需要自动完成故障检测、角色切换和客户端重连，整个过程对上层应用透明。
Vnode级别的故障切换是TDengine的核心高可用机制。每个Vnode包含一个数据分片的三个副本。主副本（Leader）处理读写请求，从副本（Follower）同步数据。Leader故障后，集群通过Raft协议选举新的Leader。选举过程：Follower检测到Leader心跳超时（默认3倍心跳间隔，约4.5秒）→发起选举请求→获得多数票（三副本中2票）的Follower成为新Leader→新Leader接替读写服务。
Mnode（管理节点）的高可用保障元数据服务不中断。Mnode管理集群拓扑、子表路由、用户权限等元数据信息。TDengine集群部署3个Mnode副本，通过Raft选举保证Mnode高可用。单个Mnode故障不影响元数据服务。Mnode选举的代价高于Vnode选举——元数据是全局的，选举期间（约10-30秒）集群管理操作受限（不能建表、不能修改用户），但数据读写不受影响——Vnode各自独立运行。
客户端自动重连是服务高可用的最后一环。客户端SDK维护到集群的连接池，连接断开后自动重连。重连后SDK从Mnode获取最新的Vnode路由表，将读写请求路由到新的Leader。整个过程对应用透明——应用层看到的是短暂的查询失败或超时，重试后恢复正常。
数据一致性模型的工程取舍
强一致性和最终一致性在工程中的取舍不是"越强越好"，而是匹配业务需求。
强一致性的场景：安全联锁动作记录、保护装置跳闸事件、故障录波数据。这些数据一旦写入就必须立即可读且准确。三副本同步写入+WAL同步刷盘提供强一致保障。代价是写入延迟——单条数据写入延迟从异步模式的1-2毫秒增加到5-10毫秒。
最终一致性的场景：常规温度监测、环境参数采集、设备状态轮询。这些场景允许几秒的数据延迟。采用异步副本或降低刷盘频率，写入延迟控制在1毫秒以内，写入吞吐提高3-5倍。
TDengine在同一集群内支持Vnode级别的副本策略配置。不同超级表可以配置不同的副本数。安全监测类超级表配置三副本同步写入，常规监测类超级表配置单副本或两副本异步写入。这种按需配置的策略在保证安全数据可靠性的同时，降低常规数据的存储和写入成本。
灾备与跨机房高可用
单机房高可用不足以应对机房级故障——供电中断、网络中断、火灾等。跨机房灾备在电力和核电行业是强制要求。
跨机房数据同步有两种模式。异步同步将数据从主机房复制到灾备机房，延迟在秒到分钟级。主机房故障时切换到灾备机房，可能丢失少量数据。同步双活将写入同时提交到两个机房，延迟增加（跨机房网络往返延迟，同城1-3毫秒，异地10-50毫秒），但无数据丢失。
TDengine的跨集群数据复制功能通过taosX实现，支持从一个集群到另一个集群的实时数据同步。同步可以按超级表粒度配置，选择需要灾备的数据。对于电力调度场景，可以将关键测点数据同步到灾备集群，非关键数据不同步以节省灾备机房带宽。
灾备切换的自动化是另一个工程要点。主机房故障时，应用需要自动切换到灾备机房。这需要全局负载均衡（GSLB）或DNS切换配合，以及客户端的多端点连接配置。TDengine客户端支持配置多个集群端点，主端点不可达时自动切换到备用端点。
结语
时序数据库的高可用架构不是单点技术的堆砌，而是写入路径（WAL+多副本）、存储路径（磁盘冗余+副本校验）、服务路径（故障切换+客户端重连）三条线的系统设计。每条线都有多种技术选项，选择依据是业务对数据可靠性和可用性的具体要求。三副本同步写入+WAL同步刷盘是工业安全场景的标准配置，异步副本和降低刷盘频率是成本敏感场景的务实选择。高可用的真正挑战不在正常状态下的架构设计，而在故障场景下的恢复行为——选举多久完成、数据回放多少、客户端重连是否透明——这些细节决定了系统在真实故障中的表现。架构选型时应模拟故障场景做混沌测试，验证恢复行为是否符合预期，而非仅依赖架构图上的冗余设计。
