设计数据密集型应用（8-9）：从单机到分布式

这两章的内容介绍从单机转向分布式系会遇到的问题，简单提炼一下几个重要概念。

分布式系统中的问题

从单机到分布式会遇到很多新的问题。

1、网络。

网络是不可靠的，随时可能丢包。

网络是有延迟的，而且延迟可能很高。

所以，当你通过网络发送一个数据包的时候，程序必须考虑到这个数据包可能丢失、也可能延迟。

同样的，如果对端没回复，也不一定是因为对方挂了，有可能是网络问题。

2、时钟。

在分布式系统中，不同机器的时钟是无法完全同步的，并且机器的时钟有可能向前或向后跳跃，不保证单调递增。就算是 Google Spanner 中采用的 GPS 原子钟，也只能保证不同机器的时钟误差是在一个几毫秒的范围内。

3、部分故障（partial failures）。

可能出现部分节点故障，这是分布式与单机的最大不同。分布式系统不能因为少部分节点的故障而影响整个系统的可用性。

分布式环境下，只能通过网络通信来检测节点是否故障，但是网络又是不可靠的，所以只能通过“节点超时未应答”来判定节点故障——实际上有可能是网络问题，这种情况如果没有处理好，可能会影响数据一致性。

4、超时。

在单机环境下，一个请求只有成功 or 失败两种状态。

在分布式环境下，还存在第三种状态——超时。

超时的请求，就是一只薛定谔的猫——有可能是成功，也有可能是失败。只能再发个请求去确定一下。

对于一些非常重要的请求，一般将其设计成幂等的来解决，遇到超时可以继续重试。

线性一致性（Linearizability）

Linearizability 是一种强一致性的模型，这个概念一开始应该是出自并发编程领域，感兴趣的话可以参考论文：Linearizability: A Correctness Condition for Concurrent Objects。

对于提供线性一致性的的分布式系统，在这个系统中：

1. 多副本的多份数据在外部看起来就像是一份数据。
2. 所有操作在外部看起来都是原子的。

实现线性一致性的分布式共识算法主要有：

1. Paxos
2. Raft

分布式事务

前面讲到了分片和事务，分布式事务其实就是跨分片的事务。

有不少开源数据库实现了分布式事务，比如：

• TiKV
• CockroachDB
• FoundationDB
• Calvin

想要深入了解分布式事务，这里推荐一些论文：

1. Omid 四部曲：
   1. Omid: Lock-free Transactional Support for Distributed Data Stores
   2. Omid, Reloaded: Scalable and Highly-Available Transaction Processing
   3. A Critique of Snapshot Isolation
   4. Taking Omid to the Clouds: Fast, Scalable Transactions for Real-Time Cloud Analytics
2. Google 家的实现
   1. Large-scale Incremental Processing Using Distributed Transactions and Notifications
   2. Spanner: Google’s Globally Distributed Database
3. Deterministic Database
   1. Calvin: Fast Distributed Transactions for Partitioned Database Systems