TiDB 中的 TiFlash 作为行列混合存储引擎，通过 Raft Learner 机制从 TiKV 异步同步数据，为 OLAP 查询提供列式副本。当业务依赖 TiFlash 做近实时分析时，副本同步延迟直接决定了查询结果的新鲜度。理解其背后的同步原理、掌握核心监控指标并针对性优化，是运维 TiDB 混合负载集群的关键能力。
TiFlash 副本同步的基本机制
TiFlash 不以主副本身份参与 Raft 投票，而是作为 Learner 角色挂载到对应 Region 的 Raft Group 中。TiKV 在写入数据后，将 Raft log 发送给 TiFlash，后者重放日志并转换为列存格式。由于是异步流程，TiFlash 副本天然存在一定延迟，但当延迟持续增大，就说明同步链路出现了瓶颈。
这种架构的优势在于隔离 OLAP 与 OLTP 流量，但代价是副本一致性为最终一致。若延迟过高，前端应用在 TiFlash 上执行的聚合查询可能遗漏最近几秒的写入。因此，监控延迟不是可选项，而是保障分析准确性的必需动作。
核心监控指标解析
在 Prometheus 中，TiFlash 相关指标主要分布于 tiflash_proxy 与 tiflash_summary 两个命名空间。其中 tiflash_proxy_handle_write_raft_data_time 反映 Raft 日志处理耗时，而 tiflash_proxy_raft_store_delay 体现 Raft 层到 Apply 阶段的排队延迟。当后者持续高于数百毫秒，通常意味着 TiFlash 写入线程饱和。
另一个关键指标是 tiflash_coprocessor_execution_time，它虽然偏向查询侧，但高延迟同步会导致 coprocessor 等待数据就绪。此外，Grafana 官方面板中的 “TiFlash Replication” 看板汇总了副本数量、落后 Region 数等，可快速识别异常节点。下表列出常用指标与含义：
| 指标名称 | 所属模块 | 异常阈值参考 | 说明 |
|---|---|---|---|
| tiflash_proxy_raft_store_delay | tiflash_proxy | > 500ms 持续 | Raft 日志apply前排队延迟 |
| tiflash_proxy_handle_write_raft_data_time | tiflash_proxy | > 200ms | 单批日志转列存耗时 |
| tiflash_replica_落后_region_count | tiflash_summary | > 总region 1% | 同步明显落后的region数 |
如何查询具体延迟数据
通过 PromQL 可以直接拉取延迟分布。例如查看 TiFlash 节点中 raft store 延迟的 99 分位：
SELECT quantile(0.99)(value) AS p99_delay FROM metrics_schema.tiflash_proxy_raft_store_delay WHERE instance = '127.0.0.1:8234' AND time >= NOW() - INTERVAL 10 MINUTE;
上述查询利用了 TiDB 自身的 metrics schema，避免运维人员切换监控平台。若返回 p99 延迟远高于均值，说明存在偶发长尾阻塞，需要结合节点资源使用率进一步分析。
常见延迟成因与优化路径
线程与调度瓶颈
TiFlash 的 raft_store_delay 升高，多数情况是 store 层处理线程数不足。可通过调整配置 raftstore-proxy.store-pool-size 增大写线程池。默认值为 4，在高写入场景下建议提升到 8 或 16，但需同步观察 CPU 使用率防止争抢。
另一个隐藏点是后台合并任务（Delta Merge）占用 IO。若 compaction 跟不上写入，apply 线程会被阻塞。此时应适当限制 delta_merge_compaction_threshold，或扩容 TiFlash 节点的磁盘吞吐。以下为修改配置的示例：
[raftstore-proxy] store-pool-size = 12 [delta_merge] compaction_threshold = 256
网络与拓扑隔离
当 TiKV 与 TiFlash 跨机架部署且带宽受限时，Raft 日志发送速率会被流控。使用 pd-ctl 将 TiFlash 标签独立，并确保 TiKV 与 TiFlash 间有万兆互联，可显著降低传输延迟。同时，在 PD 中设置 max-replicas 时，可针对分析型表单独建 placement rule，减少非必要 Region 的同步。
对于延迟极其敏感的业务，还可以启用 TiFlash 的 “快路径” 模式，跳过部分校验直接 apply，但会带来轻微数据风险。示例规则如下：
{
"group_id": "pd",
"id": "tiflash_fast",
"start_key": "",
"end_key": "",
"role": "learner",
"count": 1,
"label_constraints": [
{"key": "engine", "op": "in", "values": ["tiflash"]}
],
"properties": {"fast-apply": "true"}
}
节点扩容与负载均衡
若单节点 TiFlash 磁盘 IO 或 CPU 已达上限，水平扩容是最直接的优化。新增节点后，PD 会自动迁移 Learner 副本，期间可能产生短暂延迟波动。可通过暂停非核心表的同步来平滑过渡：
ALTER TABLE orders SET TIFLASH REPLICA 0;
待新节点稳定后再恢复副本数。整个过程建议配合监控面板观察 tiflash_replica_落后_region_count 的变化，避免批量操作引发集群抖动。
构建可持续的延迟巡检机制
仅靠故障排查不够，应将延迟指标纳入日常巡检。利用 TiDB 的告警规则，在 raft_store_delay 突破阈值时自动通知值班人员。同时，定期执行以下语句审计副本状态：
SELECT table_name, replica_count, available FROM information_schema.tiflash_replica WHERE available = 0;
该查询列出所有不可用副本，帮助提前发现同步中断。将此类检查与 Grafana 看板联动，形成从指标采集、告警到优化的闭环，才能让 TiFlash 在混合负载下保持低延迟运转。