當我們在生產線上用一臺服務器來提供數(shù)據(jù)服務的時候，我會遇到如下的兩個問題：

　　(1)一臺服務器的性能不足以提供足夠的能力服務于所有的網(wǎng)絡請求。

(2)我們總是害怕我們的這臺服務器停機，造成服務不可用或是數(shù)據(jù)丟失。

于是我們不得不對我們的服務器進行擴展，加入更多的機器來分擔性能上的問題，以及來解決單點故障問題。 通常，我們會通過兩種手段來擴展我們的數(shù)據(jù)服務：

(1)數(shù)據(jù)分區(qū)：就是把數(shù)據(jù)分塊放在不同的服務器上(如：uid % 16，一致性哈希等)。

(2)數(shù)據(jù)鏡像：讓所有的服務器都有相同的數(shù)據(jù)，提供相當?shù)姆铡?/p>

對于第一種情況，我們無法解決數(shù)據(jù)丟失的問題，單臺服務器出問題時，會有部分數(shù)據(jù)丟失。所以，數(shù)據(jù)服務的高可用性只能通過第二種方法來完成——數(shù)據(jù)的冗余存儲(一般工業(yè)界認為比較安全的備份數(shù)應該是3份，如：Hadoop和Dynamo)。

但是，加入更多的機器，會讓我們的數(shù)據(jù)服務變得很復雜，尤其是跨服務器的事務處理，也就是跨服務器的數(shù)據(jù)一致性。這個是一個很難的問題。 讓我們用最經典的Use Case：“A帳號向B帳號匯錢”來說明一下，熟悉RDBMS事務的都知道從帳號A到帳號B需要6個操作：

1)從A帳號中把余額讀出來。

2)對A帳號做減法操作。

3)把結果寫回A帳號中。

4)從B帳號中把余額讀出來。

5)對B帳號做加法操作。

6)把結果寫回B帳號中。

為了數(shù)據(jù)的一致性，這6件事，要么都成功做完，要么都不成功，而且這個操作的過程中，對A、B帳號的其它訪問必需鎖死，所謂鎖死就是要排除其它的讀寫操作，不然會有臟數(shù)據(jù)的問題，這就是事務。那么，我們在加入了更多的機器后，這個事情會變得復雜起來：

1)在數(shù)據(jù)分區(qū)的方案中：如果A帳號和B帳號的數(shù)據(jù)不在同一臺服務器上怎么辦?我們需要一個跨機器的事務處理。也就是說，如果A的扣錢成功了，但B的加錢不成功，我們還要把A的操作給回滾回去。這在跨機器的情況下，就變得比較復雜了。

2)在數(shù)據(jù)鏡像的方案中：A帳號和B帳號間的匯款是可以在一臺機器上完成的，但是別忘了我們有多臺機器存在A帳號和B帳號的副本。如果對A帳號的匯錢有兩個并發(fā)操作(要匯給B和C)，這兩個操作發(fā)生在不同的兩臺服務器上怎么辦?也就是說，在數(shù)據(jù)鏡像中，在不同的服務器上對同一個數(shù)據(jù)的寫操作怎么保證其一致性，保證數(shù)據(jù)不沖突?

同時，我們還要考慮性能的因素，如果不考慮性能的話，事務得到保證并不困難，系統(tǒng)慢一點就行了。除了考慮性能外，我們還要考慮可用性，也就是說，一臺機器沒了，數(shù)據(jù)不丟失，服務可由別的機器繼續(xù)提供。 于是，我們需要重點考慮下面的這么幾個情況：

1)容災：數(shù)據(jù)不丟、結點的Failover

2)數(shù)據(jù)的一致性：事務處理

3)性能：吞吐量 、 響應時間

前面說過，要解決數(shù)據(jù)不丟，只能通過數(shù)據(jù)冗余的方法，就算是數(shù)據(jù)分區(qū)，每個區(qū)也需要進行數(shù)據(jù)冗余處理。這就是數(shù)據(jù)副本：當出現(xiàn)某個節(jié)點的數(shù)據(jù)丟失時可以從副本讀到，數(shù)據(jù)副本是分布式系統(tǒng)解決數(shù)據(jù)丟失異常的唯一手段。所以，在這篇文章中，簡單起見，我們只討論在數(shù)據(jù)冗余情況下考慮數(shù)據(jù)的一致性和性能的問題。簡單說來：

1)要想讓數(shù)據(jù)有高可用性，就得寫多份數(shù)據(jù)。

2)寫多份的問題會導致數(shù)據(jù)一致性的問題。

3)數(shù)據(jù)一致性的問題又會引發(fā)性能問題。

這就是軟件開發(fā)，按下了葫蘆起了瓢。