当分布式系统网络抽风时：一个超简单的模拟Demo，手把手验证CAP定理的‘三选二’困境-酒店常州论坛

当分布式系统网络抽风时：一个超简单的模拟Demo，手把手验证CAP定理的‘三选二’困境

分布式系统就像一支交响乐团，每个乐手（节点）都需要完美配合才能演奏出和谐乐章。但当指挥棒（网络）突然失灵时，乐手们是继续各奏各的调（AP），还是停下来等待统一指令（CP）？今天我们就用两个Spring Boot服务搭建微型实验室，亲手"拔掉网线"观察这个经典困境。

1. 实验准备：搭建最小化分布式系统

1.1 环境配置清单

JDK 17+（推荐Amazon Corretto）
Spring Boot 3.2.x
Lombok（减少样板代码）
Postman或curl（用于API测试）

# 快速初始化项目 curl https://start.spring.io/starter.tgz \ -d dependencies=web,lombok \ -d javaVersion=17 \ -d type=gradle-project \ -d baseDir=node01 \ | tar -xzvf - cp -r node01 node02

1.2 双节点数据同步设计

我们模拟一个简易的键值存储系统，两个节点通过REST API通信：

// 公共数据模型 @Data public class KVStore { private String key; private String value; private long version; // 用于冲突检测 }

节点通信矩阵：

操作类型	节点A行为	节点B行为
写请求	更新本地数据+异步同步	接收同步请求更新数据
读请求	返回本地最新数据	返回本地最新数据
网络故障	记录待同步队列	记录待同步队列

2. CAP现象模拟实验

2.1 正常场景测试

首先启动两个节点（端口8080和8081），测试无网络分区时的情况：

# 节点1写入数据 curl -X PUT http://localhost:8080/api/kv \ -H "Content-Type: application/json" \ -d '{"key":"name","value":"Alice"}' # 从节点2读取验证 curl http://localhost:8081/api/kv/name

预期结果：两个节点返回相同的"Alice"值

2.2 制造网络分区

使用Linux的iptables模拟网络中断：

# 阻断节点间通信 sudo iptables -A INPUT -p tcp --dport 8081 -j DROP # 在节点1执行 sudo iptables -A INPUT -p tcp --dport 8080 -j DROP # 在节点2执行

此时系统进入分区状态，我们进行以下测试：

在节点1更新数据为"Bob"
立即在节点2查询该键
观察系统行为差异

2.3 CP模式实现

在application.properties中配置CP策略：

# CP模式配置 cap.mode=CP sync.timeout=5000 # 同步超时时间(ms)

当节点检测到网络分区时：

if (networkPartitionDetected && "CP".equals(capMode)) { throw new ServiceUnavailableException("等待集群恢复..."); }

CP模式特征表：

指标	表现
读响应	503 Service Unavailable
写响应	拒绝所有写操作
数据状态	所有节点最终强一致
适用场景	金融交易、医疗系统

2.4 AP模式实现

切换为AP模式配置：

# AP模式配置 cap.mode=AP stale.data.allowed=true

对应处理逻辑：

if ("AP".equals(capMode)) { return localDataStore.get(key); // 可能返回陈旧数据 }

AP模式行为对比：

操作	节点A响应	节点B响应
初始值	"Alice"	"Alice"
分区后写A	成功更新为"Bob"	无感知
分区后读B	"Bob"	"Alice"
网络恢复后	最终同步为"Bob"	最终同步为"Bob"

3. 深度解析CAP决策树

3.1 业务场景匹配指南

根据你的业务特征选择策略：

CP优先场景：

银行账户余额变更
药品库存管理系统
航空订座系统

AP优先场景：

社交媒体点赞数
商品评论显示
新闻推荐系统

3.2 混合策略实践

实际系统中常采用折中方案：

// 分级一致性示例 public Object readData(String key, ConsistencyLevel level) { switch (level) { case STRONG: return getWithSync(key); case EVENTUAL: return localStore.get(key); case QUORUM: return getWithQuorum(key); } }

一致性级别对照表：

级别	延迟	一致性保证	可用性
Strong	高	线性一致性	低
Quorum	中	多数节点一致	中
Eventual	低	最终一致	高

4. 进阶实验：真实场景模拟

4.1 网络抖动模拟

使用tc命令制造不稳定网络：

# 添加300ms延迟+10%丢包 sudo tc qdisc add dev eth0 root netem \ delay 300ms loss 10%

4.2 脑裂处理方案

实现简单的epoch标记防止脑裂：

// 世代标记验证 if (requestEpoch < currentEpoch) { throw new StaleRequestException("请求来自旧世代"); }

4.3 监控指标设计

建议采集的关键指标：

# HELP cap_decision_points CAP决策点计数 # TYPE cap_decision_points counter cap_decision_points{type="CP"} 42 cap_decision_points{type="AP"} 178 # HELP partition_duration_seconds 网络分区持续时间 # TYPE partition_duration_seconds gauge partition_duration_seconds 23.7

在实验过程中，当我们将节点间的延迟调整到500ms以上时，发现一个有趣现象：即使物理网络连接正常，由于同步超时，系统也会进入逻辑分区状态。这时采用Quorum读写的策略，能在保证一定可用性的同时提供合理的一致性保障。

企业官网建设流程全解析