【分散式-6.824】Lecture3-GFS

1.WYH HARD？

performance -->sharding
faults      -->tolerance
repl        -->inconsistency
consistency -->low performance 

2.問題

單機也會存在強一致性問題,比如C1,C2都向伺服器端的某個值發起+1操作,C3，C4都請求讀,
此時C3和C4讀取到的資料是一樣的嗎？

另外,單機的容錯能力很差,如果它crash或者磁碟壞了,那就什麼都不剩了.所以在現實生活中的分散式
系統我們實際上都會構建一個複製系統,但是當我們有副本的時候,這又引起新的問題.
這裡有一個非常糟糕的關於副本的設計.這裡提出這個糟糕的方案是為了讓我們知道在GFS中也會有這個.

Bad Replication Design
假設我們有兩臺server,每臺都有一份完整的資料副本,然後在磁碟上,它們都有這樣一個key-value表格.
直觀上,我們當然想要這兩張表完全一致,所以當有一臺server失敗了，我們可以讀寫另一臺伺服器,這就
意味著每一個寫操作都必須在所有的server處理,另外read只能在單臺server處理,否則就無法容錯了.
因為如果read必須同時和兩臺伺服器打交道,就無法在失去其中一臺伺服器的情況下倖免,所以問題就來了,
如果客戶端C1和C2想要同時執行這些寫操作,假設C1和C2都分別想將SHARED_VALUE這個變數更新成1和2，
它們分別向兩臺伺服器都傳送寫請求,於是問題出現了,C1和C2的請求完成後,SHARED_VALUE的值變成了多少？

這裡我們沒有做任何事情來保障兩臺伺服器以相同的順序處理這兩個請求.這是一個非常糟糕的設計.
如果S1先執行C1的請求再處理C2的請求,但S2先執行C2的請求再執行C1的請求,就會導致S1和S2上
SHARED_VALUE值得不一致性.如果此時C3和C4都來請求同一個變數,假設它們的請求落到不同的服務
器,分別落到S1和S2上,那麼請求的資料就不一致了.

當然,這個問題是可以修復的,修復這個問題的關鍵在於S1和S2之間需要進行更多的通訊,某些地方也會變得
更加地複雜,因為想獲得強一致性,不可避免地需要更多的開銷.有大量的方案可以獲得更好的一致性,
也有大量的方案可以獲得讓人感覺一定程度上還可接受的一致性.


沒有同步措施,就是一個disastrous model.


一些關於GFS的思考,如何修復這些問題,他們做的挺好了,但是還不夠完美.

GFS是在2003年提出的,已經有很長的時間了,那時候的web發展到相當規模了,人們也在建立大型網站,
此外,分散式系統領域也有了幾十年的研究,人們至少在學術界知道如何去構建各種型別的高度並行化的
且具備容錯性的系統,但是學術上的點子很少有能應用在工業上.但是自從這篇論文發表以後,像谷歌這
樣的大型萬丈才開始真正建立嚴格意義上的分散式系統.這件事讓人熱血沸騰,當然也包括我,作為學術界
的一份子,我切實地體會到了所有想法在工業界的實現.在谷歌,有海量的資料,這些資料躲到單個磁碟根本
無法儲存,就比如說整個網際網路抓取的網頁副本,或者在這篇文章後邊一點有個巨大的Youtube視訊,他們
就會有一份比如中間檔案的東西用來建立索引用於搜尋,他們的web伺服器顯然會有大量的日誌檔案,以便
供給未來分析的時候使用.他們有大量的資料集,並且使用大量的磁碟來儲存它們,藉助MapReduce這樣的
工具可以快速地處理這些資料,因此它們需要能夠高度並行化得訪問海量資料,所以它們的目標是：
這個儲存系需要大容量,速度快,它們還需要一個檔案系統,從某種意義上來說,這個檔案系統必須是全球的
(覆蓋在這個資料中心上),各種不同的應用程式都能從中讀取資料,有一種建立大型儲存系統的方法,假如
你有一些特殊的應用程式或者採集程式,你可以編寫一個專門的儲存系統,專門適應這些特別的應用程式.
如果你隔壁辦公室的人也需要用到大型儲存,他們就得自己去編寫自己的村塾系統,而無法複用你的程式.
你要是有一個通用的全球的可用的儲存系統,這就意味著我儲存大量的從網頁中抓取的資料,並且你也想要
看我抓取的網頁,因為我們在一個沙盒(sandbox)裡折騰且使用了相同的儲存系統,只要訪問控制允許的化,
你就可以讀取我存的檔案,所以就有了構建檔案系統的想法.任何在谷歌的人都可以給任何檔案命名或者讀取
它,其目的就是為了共享.