计算高可用与存储高可用的本质差异

高可用问题在”计算”和”存储”这两类场景里的难度天差地别，根源在于两者能不能被”随意搬到另一台机器”这件事上有本质区别。计算指业务的逻辑处理，它有一个关键特点：同样的算法配上同样的输入数据，不管在哪台机器上跑，产出的结果都完全一样，因此把计算从一台机器迁移到另一台机器，对业务不会造成任何影响——计算高可用的复杂度大体上就等同于此前讲高性能时”单机变双机”的复杂度（新增任务分配器、连接管理、分配算法），并不会额外引入新的难题。存储则完全不同：数据要从一台机器搬到另一台机器，必须经过线路传输，传输本身需要时间——同机房内部是几毫秒级别，跨机房则是几十到上百毫秒（比如广州到北京稳定情况下ping延时约50ms，不稳定时可能到1秒以上），而且传输线路本身还可能中断、拥塞、错包丢包，故障时间短则十几分钟、长则数小时（如支付宝2015年光缆被挖断导致业务受影响超过4小时）。这意味着系统在某个时间点上，数据几乎必然是不一致的——按照”数据+逻辑=业务”这个公式，数据不一致，即使逻辑完全一样，最终业务表现出来的结果也会不同：如果用户存了1万块钱的写入还没同步到另一个机房，用户恰好被路由到那个机房查询，就会看到余额没有增加，第一反应很可能是怀疑钱被盗。因此存储高可用真正的难点，从来不是”怎么把数据备份出去”这个技术动作本身，而是”怎么减少或规避数据不一致给业务带来的负面影响”这个更根本的问题——分布式领域的CAP定理正是从理论上证明了这一点：一致性、可用性、分区容错性三者不可能同时满足，架构设计必须结合具体业务在其中做取舍。

结构图：

flowchart LR
  A["计算高可用"] --> A1["同样算法+同样输入<br/>=在哪台机器算结果都一样"]
  A1 --> A2["可随意迁移，不影响业务<br/>复杂度≈高性能场景的双机架构"]
  B["存储高可用"] --> B1["数据搬迁需经线路传输<br/>同机房几毫秒/跨机房几十~上百毫秒<br/>线路还可能中断数小时"]
  B1 --> B2["系统在某时间点必然数据不一致<br/>数据+逻辑=业务 → 不一致直接导致业务表现异常"]
  B2 --> B3["难点不在于怎么备份数据<br/>而在于如何减少/规避不一致对业务的影响<br/>→ CAP定理：C/A/P不可能同时满足"]