做了读写分离之后，交易不再因为报表变慢了。但业务方很快提出了新问题："报表上的数字和实际对不上。"
交易库和分析库分开，解决了资源竞争，却引入了数据延迟。
数据延迟从哪里来？
主从复制延迟
异步复制模式下，从库数据天然落后于主库。正常情况可能只有几十毫秒，但写入压力大或网络抖动时可能飙升到秒级甚至更高。
ETL 和数据管道延迟
从交易库到分析库需要经过抽取、转换、加载，每个环节都引入额外延迟。复杂 ETL 流程可能需要数十分钟到数小时。
批处理调度延迟
定时 T+1 同步意味着分析库数据至少滞后一天。对于需要实时数据支撑的场景，一天延迟几乎等于数据不可用。
数据延迟对业务的影响
- 实时经营看板数据不准，决策滞后
- 风控系统基于旧数据判断，漏掉风险
- 运营活动效果无法实时评估
- 客户服务读到滞后数据，体验下降
几种缩短延迟的方案
优化主从复制：把延迟压到最低
并行复制允许多线程同时回放不同库/表的 binlog 事件，显著提升从库追上速度。半同步复制事务提交时等待至少一个从库确认接收再返回成功，减少数据丢失风险。适合延迟容忍度在毫秒到秒级的场景。局限：异步复制的本质决定了延迟只能缩小，不能消除。
缩短 ETL 周期：从 T+1 到分钟级
从每天一次改为每小时甚至每 5 分钟。适合需要小时级数据的场景。局限：同步频率越高，对交易库的读取压力越大，运维成本随之上升。
实时数据管道：基于 binlog/CDC 的秒级同步
利用 CDC 工具（Canal、Debezium、Flink CDC 等）实时捕获数据变更，流式推送到分析库，延迟降到秒级。适合需要秒级时效性的场景。局限：管道本身的延迟、积压、故障恢复都需要关注。CDC 只能同步变更，复杂转换仍需额外处理。
HTAP 数据库：从架构层面消除延迟
交易和分析共享同一套数据，行存和列存引擎通过内置复制机制实时同步，不需要外部 ETL。TiDB 的 TiFlash 通过 Raft learner 机制实时同步 TiKV 数据，行存和列存之间的延迟可以控制在毫秒级。适合对数据时效性要求高、希望避免维护独立分析库和 ETL 管道的场景。
从"够不够用"到"够不够快"
关键不在于追求数据的绝对实时，而在于清楚业务对时效性的真实需求，选择延迟与成本最匹配的方案。过度投入和投入不足都会造成浪费。