4. 时序数据库高可用架构选型
时序数据库（TSDB）承载的是设备指标、监控采样、传感器读数这类持续写入、按时间窗口聚合查询的数据。它的高可用选型与 OLTP 数据库有明显差异：写入吞吐量极大、单点数据价值随时间衰减、查询多为近期热数据。因此，副本机制、分片策略、一致性协议、故障切换这四件事必须放在一起权衡，而不是各自独立选型。
一、副本机制：决定“一份数据存几处”
副本机制回答的是数据冗余度问题。常见形态有三种：
- 单副本：无冗余，节点故障即数据不可用，仅适合可重采的临时指标。
- 同步多副本：写入需多数派确认后才返回成功，强一致但写延迟受最慢副本影响。
- 异步/半同步副本：主副本先确认，其余副本后台追平，写延迟低，但故障时可能丢最近若干秒数据。
时序场景中，副本数通常取 2 或 3。副本数 3 能容忍 1 个节点故障且仍保持多数派可写；副本数 2 在故障时容易退化为单点，多数派协议下甚至无法写入。因此生产环境推荐 3 副本，并配合机架/可用区打散，避免同一物理故障域内多个副本同时失效。
二、分片策略：决定“数据如何切分与分布”
分片（Sharding）解决的是单节点容量与写入吞吐上限。时序数据天然可按时间切分，因此主流策略是时间分片 + 标签哈希分片的组合：
- 按时间分片：如每 7 天一个 shard，便于冷热分离、按时间范围裁剪查询、过期数据整片删除。
- 按标签（series/tag）哈希分片：将不同设备、不同指标散列到不同节点，避免单节点热点。
分片键选择直接决定负载均衡。若只按时间分片，同一时间窗口内所有写入仍集中到同一分片，无法横向扩展写吞吐；若只按标签哈希，则时间范围查询要扫描全部分片。因此实际选型多为两级分片：先按时间划分 shard group，再在组内按 series 哈希分布到多个副本组。
三、一致性协议：决定“写入何时算成功”
一致性协议是副本与分片之上的协调层。时序库常用三类：
- Raft / Paxos 类共识：强一致，写入需多数派落盘，适合元数据、配置、关键指标。
- Quorum（NWR）模型：写 W 份、读 R 份，只要 W+R>N 即可保证读到最新值，灵活但需自行处理冲突。
- 最终一致 / 反熵：写入本地即返回，后台通过 Merkle 树或摘要比对修复副本，延迟最低但短期可能读到旧值。
时序数据大多可接受“秒级最终一致”，因此常见组合是：元数据走 Raft 强一致，指标数据走 Quorum 或最终一致。这样既保证集群拓扑、分片映射不脑裂，又让高频写入不被共识开销拖慢。
四、故障切换与数据零丢失的权衡
故障切换（Failover）的目标是：检测到节点失效后，副本组内重新选出主副本并继续服务。检测通常依赖心跳超时（如 3~5 秒）加租约（Lease）机制，避免双主。切换过程中，“零丢失”与“低延迟”本质冲突：
- 要零丢失，写入必须等多数派确认，故障时未确认的数据不会丢，但正常写入延迟升高。
- 要低延迟，写入本地即返回，故障时未同步的尾部数据会丢失，只能靠重采或补传弥补。
工程上的折中是分级策略：对不可重采的关键指标（如计费、安全告警）启用同步多数派，接受较高写延迟；对可重采的监控指标启用异步副本，用“允许丢最近 N 秒”换取吞吐。同时设置 write_timeout 与 replication_factor 参数，让不同 measurement 走不同一致性级别。
五、选型决策要点
把四要素串起来看，选型可以按以下顺序推进：
- 先定数据可丢性：哪些指标不可重采？这些走同步多数派；其余走异步。
- 再定分片粒度：按写入速率估算单分片承载上限，确定时间窗口与哈希分片数。
- 然后定副本数与打散域：3 副本跨 3 个可用区，保证单区故障仍有多数派。
- 最后定切换参数：心跳超时、租约时长、选举超时需与写入超时匹配，避免误切与双主。
综上，时序数据库高可用选型的核心不是追求单一指标最优，而是按数据价值分级：关键数据用同步多数派保零丢失，海量监控数据用异步副本保吞吐，分片策略保证水平扩展，一致性协议保证元数据不脑裂，故障切换参数保证切换既不过早也不过晚。四者匹配，才能在高可用与成本、延迟之间取得可接受的平衡。