分布式理论与场景浅谈

基本理论

FLP、CAP、BASE 与 ACID

FLP 不可能原理

在异步模型中，只要分布式系统中有一个进程不可用，系统就可能无法达成整体共识。在工程实现中，可以通过处理活锁等问题，让系统在一定时间内达到一致。

上图的 CP 区域还少了一个常见系统：ZooKeeper。

ACID 对应刚性事务，追求强一致性，以 MySQL 等关系型数据库为代表。

BASE 对应柔性事务，通过牺牲强一致性换取一定的可用性。过程中可能存在中间状态，但最终会达到一致，以 Spanner 等分布式系统为代表。

CAP 理论

分布式系统中的一致性（C）、可用性（A）和分区容错性（P）不能同时满足，最多只能满足其中两项。通常来说，依赖网络通信的分布式系统无法舍弃 P，因此会根据选择不同成为 AP 或 CP 系统。

不过，“三选二”的说法很容易造成误解：

1. 分区很少发生。在没有分区的情况下，没有理由牺牲 C 或 A。
2. 对 A 与 C 的取舍可以在同一个系统中反复发生，而且二者都有很多层次，例如可用性和一致性等级都可以变化。

实际使用中，应当根据应用场景做适当取舍。

以 ZooKeeper 为例，它在 CAP 三项上的表现分别是：

• C：最终一致性，一般可以在十几秒内同步到各个节点。
• A：数据始终可用，超过一半节点的数据是最新的；若要保证读取最新数据，需要手动调用 sync。
• P：节点增多会显著增加写入同步延迟，Leader 选举也会更加耗时，可以引入 Observer 节点缓解。

ZooKeeper 是一个 CP 系统，因为任何时刻对它的访问请求都能获得一致的数据，但它不保证每次服务请求都可用，例如发生网络分区时。因此，在服务发现这个场景中，它并不如 AP 系统 Eureka 合适。

分布式事务

业务上实现最终一致性有几种模式：

• 可靠事件模式：使用消息队列配合本地或外部事件表。
• 业务补偿模式：在业务或技术异常时执行补偿。
• TCC 模式：应用层的两阶段提交。
• Saga。

阿里当时还开源了 Fescar。

分布式事务的需求主要来自数据库水平拆分和应用 SOA 化，因为服务调用会涉及跨库事务。从某种角度来说，只有业务复杂（如金融）、服务范围遍及全球（如 Google），或数据量大到需要分库的公司，才会遇到这类需求。

常见的一致性协议包括：

• ZAB
• Raft
• Viewstamped Replication
• Quorum
• Gossip

它们本质上都是 Paxos 协议的变种。

常见的类 Paxos 分布式事务实现包括：

• MySQL XA
• TCC（Try-Confirm-Cancel），已有开源实现

另有一篇很好的参考文章：核心金融场景分布式事务。

分布式锁

通常有两种选择：

• 单机 Redis 或官方分布式锁 Redlock
• ZooKeeper

可以根据业务场景选择。如果对锁的要求不高，例如可以接受 1% 的重复加锁，使用单机 Redis 最简单方便。

分布式系统的实际业务场景

• 微信 PaxosStore
• 阿里 AliSQL X-Cluster
• TiDB（multi-Raft group）
• Google Spanner 等

---

原文发布于 SegmentFault。