（以下圖片來源出自讀書會成員講義）

在談分散式以前，首先來談談單機運作的概念。當我們的服務是單機運作時，伺服器的架構設計通常會是以下其中一種：

• 一個服務在一台電腦運行
• 多個服務在一台電腦運行

這種狀況下若是要擴展系統容量，只能升級電腦資源獲提升程式效率，這種方式也被稱為「垂直擴展（Vertical Scaling）」。

不過這樣的架構又衍生出兩個問題：

• 單機能力的提升是有極限的
• 單點故障的風險（Single Point of Failure）： 若只依靠單機運行，假設今天資料庫的主機掛了，你的服務也就 GG 了。換句話說就是缺少容錯能力，無法在維持服務的前提下升級。

為了解決以上的問題，有個解法誕生了：

嘗試開很多個機器跑同一個服務，也就是採用分散式架構

在開了很多台機器後，我們似乎得到以下的好處：

• 來自 client 的請求可以分配到這幾台主機之一，減緩單一主機的壓力。
• 因為第一點，某種程度降低了服務的等待時間。
• 提高了系統的容錯能力，即是一個分區容錯（Partition Tolerence）的系統，當節點間通訊失敗也不會影響系統正常運作。
• 採用分散式架構後，甚至可以在不同地理區域就近服務使用者。

這種增加節點的擴容方式，被稱作水平擴展（Horizontal Scaling

然而，事情不像外表看起來那麼單純又美好，進入分散式世界後所需要考慮的事情變得更多更複雜了。

在上一篇文章中我們提及 transaction 可以解決資料一致性的問題，然而在分散式架構下我們無法僅靠 transaction 就確保一致性，必須額外搭配共識（Consensus）的機制。

接下來介紹幾個名詞：

• Consistency 一致性 : 保證在各個有儲存資料的分區都一定拿得到最新版本的資料。
• Availability 可用性：當存取資料庫時一定可以拿到資料，不會出錯（不會出現拿不到資料的狀況，但拿到的資料不保證是最新版本。）
• Partitioning Tolerance 分區容忍：文章前段有提及，即使任一節點發生錯誤，整個系統還是能正常運作。

問題來了，有辦法同時達到 C (一致性),、A (可用性)、P (分區容忍) 嗎？

答案是沒辦法。明天我們來看看 CAP 理論是什麼。