延迟的物理基础：光速限制与地理距离
聊跨云数据复制，第一个绕不开的话题就是——光速。
你可能觉得，光速不是每秒30万公里吗？那应该很快啊。没错，在真空中是这样。但在光纤里，光走得没那么快。我刚开始做跨区域数据同步时，也天真地以为延迟主要来自网络设备。后来被现实狠狠教育了一回。
光在光纤中的真实速度
光纤的核心是石英玻璃，光在其中传播时，折射率大约在1.44到1.48之间。这意味着什么？
- 真空光速：299,792,458 m/s（约30万公里/秒）
- 光纤中光速：约204,000,000 m/s（约20万公里/秒）
说白了，光在光纤里只能达到真空速度的约68%。这个数字，我建议你记在心里。因为所有跨区域延迟估算，都得拿它做基准。
核心公式：单向延迟 ≈ 地理距离（公里） ÷ 200,000（公里/秒）
注意，这只是理论下限。实际延迟还要加上设备处理、信号中继、协议开销等。
地理距离如何决定延迟
你想想看，北京到法兰克福的直线距离大约是7,800公里。按光纤光速算：
7,800 km ÷ 200,000 km/s = 0.039秒 = 39毫秒嗯，39毫秒。听起来不多对吧？但这是单程。数据复制通常涉及往返确认，实际延迟要翻倍。再加上路由绕路、设备跳数，轻松破百毫秒。
我在项目中遇到过，某客户把主库放在美西（弗吉尼亚），备库放在美东（俄勒冈）。他们觉得都是美国，应该很快。结果呢？
- 直线距离：约3,900公里
- 理论单程延迟：约19.5毫秒
- 实测单程延迟：60-80毫秒（路由绕路+设备跳数）
为什么会差这么多？因为海底光缆不是走直线的。它得绕开地质活跃区、避开航道、经过中继站。实际路径往往比直线长30%-50%。
典型跨区域延迟数据
下面这张表，是我根据多个云厂商的实际测试数据整理的。你可以拿它做参考：
| 源区域 | 目标区域 | 直线距离 | 理论单程延迟 | 实测单程延迟 |
|---|---|---|---|---|
| 美西（俄勒冈） | 美东（弗吉尼亚） | 3,900 km | 19.5 ms | 60-80 ms |
| 北京 | 法兰克福 | 7,800 km | 39 ms | 150-200 ms |
| 新加坡 | 伦敦 | 10,800 km | 54 ms | 180-250 ms |
| 东京 | 圣保罗 | 18,500 km | 92.5 ms | 250-350 ms |
| 悉尼 | 孟买 | 10,200 km | 51 ms | 160-220 ms |
注意：实测延迟受海底光缆路由、网络拥塞、运营商BGP策略影响很大。同一对区域，不同云厂商的延迟可能差30%以上。我建议你以实际拨测数据为准，不要只看理论值。
延迟对数据复制的直接影响
搞清楚了物理基础，我们再来看它对数据复制意味着什么。
假设你在北京写了一条数据，要同步到法兰克福的备库。采用同步复制模式：
- 主库写入：本地完成，延迟忽略不计
- 日志传输：北京→法兰克福，单程150-200ms
- 备库确认：法兰克福→北京，单程150-200ms
- 总等待时间：300-400ms
这意味着，你的每一次写入操作，都要等300到400毫秒才能返回成功。对于OLTP业务来说，这几乎是不可接受的。
我曾经帮一个金融客户做过架构评审。他们坚持用同步复制做跨洲灾备，结果业务接口的P99延迟从5毫秒飙到了800毫秒。最后不得不改成异步复制，配合数据校验补偿机制。
一张图看懂延迟的物理基础
下面这张SVG图，把核心逻辑串起来了：
避坑指南
我曾经踩过一个坑，分享给你：
- 别信云厂商的「区域内延迟」宣传：同区域不同可用区，延迟通常1-2ms。但跨区域，尤其是跨大洲，延迟直接跳一个数量级。
- 别忽略路由绕路：北京到法兰克福，理论39ms，实测150-200ms。中间经过的海底光缆中继站、陆地光缆交接点，每个节点都会增加延迟。
- 别把单程当往返：很多同步协议需要至少一次往返确认。设计时一定要算往返延迟，不是单程。
我的建议：做跨区域数据复制架构时，先拿实际拨测数据说话。用云厂商提供的延迟监控工具（比如AWS CloudWatch、Azure Network Watcher）跑一周数据，取P50和P99。别只看平均值，峰值延迟才是杀手。
嗯，这一章的内容就到这里。光速和地理距离是硬约束，理解它们，你才能在设计跨云复制方案时做出合理的选择。