目錄
介紹
- 什么是分布式系統
- 為什么需要分布式系統
- 數據庫伸縮（scaling）例子
分布式系統的類別
- 分布式數據存儲
- 分布式計算
- 分布式文件系統
- 分布式消息
- 分布式應用程序
- 分布式分類賬
總結
介紹
隨着技術在各行業的日益擴張，分布式系統變的越來越普遍，這在計算機科學中是一個廣闊而復雜的學習領域。
這篇文章旨在給你介紹一下分布式系統的基礎，讓你看一下分布式系統的不同的類別。本文不會深入細節。
1. 什么是分布式系統
用最簡單的方式定義，分布式系統就是讓終端用戶把一組工作在一起的計算機當做一個單獨的機器來使用。
這些機器共享狀態，並發操作，並且單個機器出現問題不會影響到整個系統的正常工作。
我打算用一個漸進式的例子來介紹分布式，這樣你會有更直觀的感受：讓我們以數據庫為例。傳統的數據庫存儲在單一機器的文件系統中，無論你什么時候獲取或插入數據，你都需要直接訪問這個機器。傳統數據庫如圖：
如果我們要把這個數據庫變為分布式的，我們需要讓這個數據庫同時運行在不同的機器上。用戶必須能夠和他選取的任何一個機器進行會話，並且用戶不應該知道他其實並不是在和一個單獨的機器進行會話—如果用戶插入一條記錄到節點1，那么節點3也必須能返回此記錄。分布式數據庫：
2. 為什么需要分布式系統
使用分布式系統往往是不可避免的。現實的情況的是—分布式系統的管理是非常復雜，其中布滿了各種坑和雷。部署，維護和調試分布式系統非常讓人頭疼，那為什么還要用它呢？
分布式系統讓你獲得的是水平伸縮性（擴展性）。回到前面單個數據庫服務器的例子，提升數據訪問能力的唯一方法就是提升數據庫服務器硬件的性能。這被稱為垂直伸縮（擴展）。
如果可以的話，垂直伸縮挺好的。但是從某個點開始你將會發現，即時是用最好的硬件，也滿足不了訪問的需要，且不說讓主機使用最好的硬件是不是切合實際。
簡單的說，水平伸縮的意思是增加更多的計算機而不是升級單個計算機的硬件。
當達到某個臨界點以后，這要比垂直伸縮便宜的多。然而這並不是分布式的主要應用場合。
垂直伸縮可以使性能一下子猛增到最新的硬件能達到的水平。已經被證明，硬件的能力滿足不了技術公司對於中到大規模的負載的需要。
水平伸縮最好的一點是沒有伸縮的上限—無論什么時候性能下降了，你都可以通過簡單的添加機器（可以添加無數台）來解決。
容易獲得的伸縮性並不是分布式系統唯一的好處。容錯和低延時也同等的重要。
容錯—一個橫跨兩個數據中心由十台機器組成的集群自然比單一機器的容錯性更強。即使一個數據中心着火了，你的程序還能工作。
低延時—一個網絡數據包在世界范圍內的傳輸速度是有光速限制的。比如，一個請求從紐約到悉尼，在光纖中可能的最短的往返時間（從發出請求到請求返回）是160毫秒。分布式系統允許在兩個城市各有一個節點，請求者可以訪問最近的節點。
然而，為了使分布式系統能正常的工作，你需要專門設計運行在那些機器上的軟件，以使得它們
可以同時運行在多台機器上並且可以應對隨之而來的各種問題。事實證明，這很難。
3. 伸縮我們的數據庫
設想一下，我們的網站非常的流行了，我們的數據庫開始需要在每秒鍾處理兩倍於它能力的請求。你的網站性能開始變差了，用戶也感受到了。
讓我們一塊兒來使我們的數據庫滿足更高的要求。
在一個典型的Web應用中，一般來說，讀取數據比插入和修改數據要頻繁的多。
有一種方式可以提高讀的性能，那就是所謂的“主從式復制”（Master-Slave Replication）策略。這里你創建兩個新的數據庫服務器，它們從主數據庫同步數據。注意：對於這兩個新的實例，你只讀取數據。
無論你什么時候插入和修改數據，都在主數據庫進行。而主數據庫將會異步的通知從數據庫來保存這些數據的更改。
恭喜！現在對於讀取數據，性能已經是原來的三倍了。是不是很爽？
缺陷
Duang！我們立刻失去了關系型數據庫中ACID中的C （Consistency），也就是一致性。
你看，現在存在了如下的可能性：我們插入一條記錄到數據庫，然后立刻發起一個讀取此記錄的請求，但是沒有結果返回，就像這條記錄不存在一樣。
插入新的數據到主數據庫和同步新數據到從數據庫並不是同時完成的。這樣就會存在有可能讀取到舊數據的時間窗口。如果不想這樣的話，那么寫操作就得等新數據被同步到所有的從數據庫以后才算完成，這樣寫的性能就會很差。
分布式系統中存在很多平衡和取舍。如果你想適當的進行伸縮，上面的問題是你不得不面對的。
繼續擴展
通過主-從數據庫的方式，我們可以把讀的能力擴展到一定的程度。這很好，但是我們還沒有解決對於寫的問題—寫還是通過單一的服務器進行的。
這里我們並沒有太多的選擇。很簡單，由於一個機器不夠，我們需要把寫的請求分發到多個服務器上。
一種方式是“多主復制”策略。不同於只能讀取數據的“從數據庫”，你擁有多個“主節點”，主節點既可以讀又可以寫。很不幸，你很快會發現情況變的非常復雜，因為你會制造出沖突（比如：插入兩條具有相同ID的記錄）。
讓我們嘗試一下另一種稱作“分片”（Sharding）方式，也稱作“分區”（Partition）。
我們把服務器分成多個小的服務器，每個服務器稱作一個分片。這些分片分別存儲不同的記錄—我們通過創建一套規則來決定哪些記錄去到哪個服務器。這套規則非常重要，它保證了數據以一致的方式分布在分片上。
一種可行規則是基於數據記錄的某種信息來定義區間范圍（比如，用戶記錄以用戶名的首字母A-D）。如圖：
選擇用來分片的鍵（比如上面例字中用戶名的首字母）需要非常的慎重，因為鍵在數據記錄中的分布可能非常的不平均（比如，名字首字母為C的用戶可能比為Z的要多很多）。某個分片如果收到的請求比其他的分片多很多，那么它被稱作“熱點”，這是要必須避免的。一旦分片完成，重新分片的代價是非常昂貴的並且可能會造成長時間的宕機。
為了使我們的例子簡單，假設我們的用戶知道在哪個分片上存儲一條記錄。注意一下，其實有非常多的分片策略，這個例子只是以一種簡單的方式解釋分片的概念。
現在我們更進了一步—我們把寫的性能提升到了原來的N倍，這里N是分片的個數。性能提升幾乎沒有上限了—可以想象一下這種分片的方式可以做到多么細的粒度。
缺陷
軟件工程中所有方面都或多或少的會涉及到平衡取舍，這里也不例外。分片不是一件容易的事情，除非必要，否則最好不要用。
我們查詢數據的時候使用的是記錄的鍵（比如用戶表中的用戶名）而不是使用用來做分片的鍵（比如用戶名的首字母），查詢效率會非常的低，因為查詢需要覆蓋到所有的分片。SQL的JOIN查詢會變的更復雜，效率也更低，變的幾乎不能用了。
去中心化和分布式
在深入討論之前，我想先對這兩個詞區分一下。
雖然這兩個詞看起來很相似並且從邏輯的角度講是一回事兒，但是他們的區別對技術和運營會產生重大的影響。
從技術角度講去中心化依然是分布式系統，但是整個去中心化的系統並不是被單一的參與者所擁有。沒有一個公司可以擁有一個去中心化的系統，否則就不能稱作去中心化了。
這意味着我們接下來討論到的系統可以被認為是“分布式的中心化系統”—它們也正是照此設計的。
如果仔細想一下，你會發現創建一個去中心化的系統要更困難一些，因為你需要應對惡意的參與者。對於普通的分布式系統，你不需要應對這種情況，因為你知道你擁有所有參與的節點。
注意：去中心化和分布式的定義有很多的爭議，並且還可能和其他的定義產生混淆（比如P2P）。在早期的論文中，它們的定義也是不同的。不管怎么樣，我給出的定義是我認為被最廣泛采納的。當下，區塊鏈和加密貨幣讓這些名詞變的非常流行。
下一篇將會討論分布式系統的類別。
作者公眾號（碼年）掃碼關注：
英文原文：
https://hackernoon.com/a-thorough-introduction-to-distributed-systems-3b91562c9b3c