0%

唐朝和宋朝的困境：分布式系统治理中CAP难题

发表于 分类于

分布式系统的宿命，其实就是唐朝的宿命

当我们把单体应用拆成：

  • SOA
  • 微服务
  • 多节点部署
  • 多数据源
  • 多机房

我们就进入了一个不可逆的世界：

分布式世界。

在单体架构里，你不会遇到 CAP 问题。

因为：

1
单机 = 没有网络分区

事务要么成功，要么回滚。

一致性与可用性并不冲突。

但当你：

  • 把服务拆分
  • 把数据库拆分
  • 把节点部署到不同区域

你就进入了：

1
不可避免的网络不可靠世界

这时候，CAP 定理出现了。

CAP 到底在说什么？

CAP 定理说：

在一个分布式系统中，当网络分区发生时，只能在 C 和 A 之间做选择。

三个核心定义：

C — Consistency（一致性）

每次读：

1
2
要么拿到最新数据
要么报错

强调的是：

数据绝对正确。

A — Availability（可用性）

每次请求：

1
2
必须返回结果
不能报错

但：

不保证数据最新。

P — Partition Tolerance（分区容忍）

即使网络断裂：

1
系统仍然继续运行

不宕机。

最重要的一句话

很多人误解 CAP。

不是说任何时候只能选两个。

而是：

当网络分区发生时，只能在 C 和 A 之间选。

如果网络完美稳定：

1
C + A 可以同时存在

但问题是：

在大规模系统中，网络一定会出问题。

现在，我们把唐朝拉进来

唐帝国，是一个超大规模分布式系统。

  • 长安 = 控制中心
  • 各地节度使 = 区域节点
  • 军队 = 执行集群
  • 税收系统 = 资源调度器

755年安史之乱，相当于：

1
大规模网络分区

中央和地方失去实时控制。

唐朝选择了 AP

为了保证地方能运转，唐朝做了一个关键决策：

1
2
授权节度使
允许地方自治

换句话说：

1
2
3
保证 A（地方能运转）
保证 P（分区后不崩）
放弃 C（中央强一致）

结果是：

  • 地方继续运行
  • 军队可自行征兵
  • 财政可自行管理

但：

中央失去了全局一致控制。

这就是 AP 架构的代价。

AP 架构的后果

AP 架构在电商秒杀场景里没问题：

  • 先让用户下单
  • 最终一致性补偿

但如果这是一个帝国：

  • 地方有军权
  • 地方有财政
  • 地方能世袭

你得到的不是最终一致性。

你得到的是：

1
永久性分裂

唐晚期，就是一个脑裂的集群。

五代十国 = Split Brain

当没有统一主节点时：

  • 多个 Master 同时存在
  • 各自自称合法

这就是五代十国。

典型的：

1
控制平面分裂

宋朝的选择：CP

赵匡胤上台后做了什么？

杯酒释兵权。

本质是：

1
回收节点 root 权限

宋朝的选择非常清晰：

1
2
3
保证 C（一致性）
保证 P（分区容忍）
牺牲 A（地方自主性）

地方没有独立军权。

宁可响应慢，也要强一致。

唐宋的 CAP 对照表

王朝 选择 结果
唐 AP 内部崩溃
宋 CP 内部稳定
后果 唐内乱 宋外患

宋稳定了内部，但代价是：

军事扩展能力下降。

回到分布式事务

在微服务架构中：

  • 每个服务有本地事务
  • 没有全局 ACID
  • 必须设计补偿机制

本质问题：

1
你到底优先什么？

银行转账：

1
2
宁可不可用（A）
也要强一致（C）

电商抢购：

1
2
宁可不一致（C）
也要可用（A）

真正的系统思维

CAP 不是技术定律。

它是：

权力与秩序的底层规律。

所有大规模系统都会面对：

1
一致性 vs 可用性

唐选择让系统“继续跑”。

宋选择让系统“必须统一”。

没有绝对正确。

只有场景取舍。

最后一句话

分布式系统的本质不是技术问题。

是：

当系统不可避免分区时，你愿意牺牲什么？

唐牺牲一致性，换来了短期可用。
宋牺牲可用性，换来了长期稳定。

而所有架构师，都会在历史的不同场景下，重复这个选择。

👇👇👇 扫码体验小程序 👇👇👇

ai-vibe-coding-2026210151912

👇👇👇 扫码关注公众号 👇👇👇

ai-vibe-coding-2026210151858