分布式系统核心原理

CAP定理与权衡实践

CAP定理

• 一致性（Consistency）

  • 强一致性：所有读写操作均基于最新数据（如银行转账）。
  • 最终一致性：数据副本经过一段时间后达到一致（如社交媒体的点赞数）。
  • 技术实现：两阶段提交（2PC）、Paxos/Raft共识算法。

• 可用性（Availability）

  • 响应要求：系统必须在有限时间内返回结果（即使数据可能过时）。
  • 设计原则：无单点故障、快速失败（Fail Fast）、优雅降级。

• 分区容错性（Partition Tolerance）

  • 必然性：分布式系统必须容忍网络分区（因网络不可靠是客观存在）。
  • 设计策略：冗余部署、多副本同步、自动故障转移。

CAP的权衡实践

• CP系统（一致性+分区容错）

  • 特点：在分区发生时，优先保证一致性，牺牲可用性（拒绝部分请求）。
  • 典型系统：ZooKeeper选举Leader期间服务不可写，保证数据一致性；Etcd基于Raft协议，分区时少数派节点不可用。
  • 适用场景：金融交易系统（如支付结算），分布式锁服务（如避免重复扣款）。

• AP系统（可用性+分区容错）

  • 特点：分区发生时，允许返回旧数据，优先保证服务可用性。
  • 典型系统：Eureka服务注册中心在分区时允许节点独立运行。
  • 适用场景：社交媒体（如点赞、评论功能）；实时性要求不高的数据展示（如商品详情页缓存）。

• CA系统（理论存在，实际不成立）

  • 矛盾点：分布式系统必须面对网络分区，无法完全放弃P。
  • 误解案例：单机数据库（如MySQL主从架构）看似CA，但本质非分布式系统。

CAP的实际工程权衡

• 强一致性优先（CP） ：如订单支付、库存扣减，使用分布式事务（如Seata的AT模式）或同步复制。

• 高可用优先（AP） ：如用户会话管理、**Feed流，使用最终一致性（如Redis跨机房异步复制）。

• 混合策略——分而治之：不同子系统采用不同CAP策略。

  • 订单服务（CP） ：强一致性保证支付原子性。
  • 商品服务（AP） ：允许缓存短暂不一致，优先展示页面。

• BASE（Basically Available, Soft state, Eventually consistent）

  • 基本可用：允许降级响应（如返回默认库存值）。
  • 软状态：中间状态允许不同步（如订单“处理中”状态）。
  • 最终一致：通过异步补偿达成一致（如Saga模式）。

网络分区的应对策略

• 检测与响应

  • 心跳检测：通过ZooKeeper或Consul监控节点健康状态。
  • 多数派仲裁：只有多数节点存活时允许写入（如Paxos要求多数派同意）。
  • Fencing机制：旧Leader被隔离后禁止写操作（如ZooKeeper的ZXID校验）。

• 恢复后的数据调和

  • Last Write Wins（LWW） ：以最新时间戳为准（简单但可能丢数据）。
  • 向量时钟（Vector Clock） ：通过逻辑时间戳合并冲突（如DynamoDB）。
  • 人工干预：记录冲突日志供运维介入（如金融对账系统）。

共识算法

Paxos算法

• 角色：

  • Proposer（提议者） ：发起提案（如提议某个值）。
  • Acceptor（接受者） ：接受或拒绝提案。
  • Learner（学习者） ：学习最终达成一致的值。

• 流程：

  • Prepare阶段：Proposer发送提案编号（n）给Acceptors。
  • Promise阶段：Acceptor承诺不再接受编号小于n的提案，并返回已接受的最高编号提案。
  • Accept阶段：Proposer选择多数派Acceptors接受的最高值，发送Accept请求。
  • Learn阶段：一旦提案被多数派接受，Learner广播最终值。

Raft算法

• 设计目标：简化Paxos的理解与实现，明确角色划分。

• 角色：

  • Leader（领导者） ：唯一处理客户端请求的节点，负责日志复制。
  • Follower（跟随者） ：被动接收Leader的日志条目。
  • Candidate（候选者） ：在Leader失效时发起选举。

• Leader选举：

  • Follower在超时（Election Timeout）后成为Candidate，发起选举。
  • 获得多数派投票的Candidate成为新Leader。

• 日志复制：

  • Leader接收客户端请求，将日志条目广播给Followers。
  • 多数派确认后提交日志，应用到状态机。

• 安全性保证：

  • 选举限制：只有拥有最新日志的Candidate才能成为Leader。
  • 日志匹配：强制Followers的日志与Leader一致。

ZAB协议（ZooKeeper Atomic Broadcast）

• 设计目标：为ZooKeeper设计的高吞吐量原子广播协议。
• Leader选举（Fast Leader Election）：节点通过交换epoch（时代编号）快速选出最新数据的Leader。
• 原子广播：Leader为每个事务生成全局有序的ZXID（事务ID）；Followers按顺序提交事务，确保所有节点状态一致。

分布式事务解决方案

两阶段提交（2PC，Two-Phase Commit）

• 准备阶段（Prepare Phase） ：

  • 协调者（Coordinator） 向所有参与者（Participant） 发送事务请求，询问是否可以提交。
  • 参与者执行事务操作（但不提交），锁定资源，并返回“同意”（Yes）或“拒绝”（No）。

• 提交阶段（Commit Phase） ：

  • 若所有参与者返回“Yes”，协调者发送提交命令，参与者提交事务并释放锁。
  • 若有任一参与者返回“No”，协调者发送回滚命令，参与者撤销操作。

三阶段提交（3PC，Three-Phase Commit）

• CanCommit阶段：协调者询问参与者是否“可能提交”（不锁定资源）。
• PreCommit阶段：若所有参与者同意，协调者发送预提交请求，参与者锁定资源并准备提交。
• DoCommit阶段：协调者发送最终提交或回滚命令。

补偿事务（Saga模式）

• 编排式（Choreography） ：各服务通过事件（如消息队列）自主协调，无中心协调者。
• 编排式缺点：逻辑分散，难维护；需处理事件丢失和重复消费。
• 编排式工具：Kafka、RabbitMQ。
• 编排式（Orchestration） ：协调者服务集中管理事务流程，调用各服务接口（Cadence、AWS Step Functions）定义Saga步骤。

TCC（Try-Confirm-Cancel）

• Try阶段：预留资源（如冻结库存、预扣款）。
• Confirm阶段：确认操作，提交资源（如实际扣款、减少库存）。
• Cancel阶段：回滚Try阶段的预留（如解冻库存、释放预扣款）。
• 幂等性：每个阶段需支持重试（如通过唯一事务ID）。
• 空回滚：Try未执行时收到Cancel，需忽略操作。
• 悬挂控制：Confirm/Cancel可能先于Try到达，需记录状态。

基于消息队列的最终一致性

• 本地事务 + 消息表：业务操作与消息写入本地数据库（原子性保证）；后台任务轮询消息表，将消息投递到MQ。
• 消息消费：下游服务消费消息并执行业务，成功后确认消息；失败时重试或进入死信队列人工处理。
• 事务消息：发送半消息到MQ → 执行本地事务 → 提交/回滚消息；MQ定期检查未确认消息，回调生产者确认状态。

分布式ID生成方案

UUID

• 原理：基于时间、MAC地址或随机数生成128位字符串（如550e8400-e29b-41d4-a716-446655440000）
• 无序性：作为数据库主键会导致B+树频繁分裂，降低写入性能。
• 存储浪费：128位过长（占用36字符），可读性差。
• 适用场景：日志追踪、临时标识等无需有序性的场景。

数据库自增ID

• 原理：通过数据库自增字段（如MySQL AUTO_INCREMENT）生成唯一ID。
• 分库分表：通过步长区分不同分片（如实例1生成1,3,5…，实例2生成2,4,6…）。
• 批量预取：每次从数据库获取一批ID（如1000个）缓存在本地，减少数据库访问。
• 适用场景：中小规模系统，非高并发场景。

Snowflake算法

• 原理：64位ID = 时间戳（41位） + 机器ID（10位） + 序列号（12位）
• 生成流程：同一毫秒内，通过序列号递增生成多个ID（最多4096个/ms）；时间戳回拨时，通过等待或抛出异常处理。
• 机器ID分配：需通过ZK/DB/配置中心保证机器ID唯一。

Redis生成ID

• 原理：利用Redis的原子操作INCR或INCRBY生成递增ID。
• 集群分片：不同业务使用不同Key（如order:id、user:id）。
• 批量预取：每次获取一段ID范围（如1~1000），减少Redis交互。
• 适用场景：需要递增ID且已部署Redis集群的系统。

分布式ID方案对比