設計數據密集型應用（8-9）：從單機到分散式

• 2020 年 4 月 1 日
• 筆記

這兩章的內容介紹從單機轉向分散式系會遇到的問題，簡單提煉一下幾個重要概念。

分散式系統中的問題

從單機到分散式會遇到很多新的問題。

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