iT邦幫忙

DAY 7
0

分散式資料處理,以Stream Computing為例系列 第 7

Day 7: 無強一致性 及 無法決定執行順序 帶來的問題

昨天講到多數系統不允許在副本寫入,因為如果有好幾個寫入同時發生在不同的節點上,資料會不一致。就算能忍受資料不一致,也缺乏一個跨節點且精確同步的時鐘來協調出這些寫入的執行順序,導致事後補救的困難。

假設有兩個節點,兩個不同機器的節點已經同步好帳戶餘額=15元,有兩個客戶,一個要提款10元,一個要提15元,但是發到不同的機器上處理。兩個節點都以為都會以為沒問題(餘額>=0),但實際上需要拒絕其中一個請求。

為了避免這種問題,許多資料系統都只允許在一個節點上寫資料。如果有拆partition,那每個partition內會只有一個master及零至多個slave(replica),只有master能寫資料。再極端一點,有些資料系統為了避免讀到不一致的資料,甚至會只允許在master上讀資料,那這樣replica就完全只是備援的角色,沒有分散讀取的能力。

上面那個例子,再退一步想。就算能允許用戶餘額<0,事後再補款。到最後若我們需要整理出執行順序,也會遇到困難。因為在分散式系統裡沒有一個global clock能作為參照。

執行順序這件事,對於某些資料操作的組合是重要的,對於某些資料操作的組合是不重要的。

之前舉的那個是不重要的例子,因為先扣10元、再扣15元;抑或是先扣15元、再扣10元,最後的結果(-10元)都是一樣的。

但如果在中間加上一個計利息的操作,不同的順序就會有不同的結果。假設利息是10%,不同順序的結果:

  • 計利息 -> 扣10元 -> 扣15元:-8
    [*].5元

  • 計利息 -> 扣15元 -> 扣10元:-8
    [*].5元

  • 扣15元 -> 計利息 ->扣10元:-10元

  • 扣15元 ->扣10元 -> 計利息:-10元

  • 扣10元 ->扣15元 -> 計利息:-10元

  • 扣10元 -> 計利息 ->扣15元 :-9
    .5元

沒有global clock的狀況下,我們不能決定上面哪一個是正確的執行順序。


上一篇
Day 6: Replication
下一篇
Day 8: 最終一致性
系列文
分散式資料處理,以Stream Computing為例30

尚未有邦友留言

立即登入留言