準備工作
閱讀：GFS論文
背景
- GFS是Google在2003年發(fā)出的經典論文挠锥，其作為分布式文件系統(tǒng),實際應用在Google的MapReduce框架實現(xiàn)中,作為原始數(shù)據(jù)和最終結果存儲的基礎服務十兢。
- 為其他上層基礎系統(tǒng)比如BigTable提供服務,Hadoop中的HDFS就是其開源實現(xiàn)。
- 這篇文章討論了諸如一致性耘擂、容錯胆剧、網絡性能等分布式系統(tǒng)工程中的經典問題，啟發(fā)了后續(xù)很多分布式文件系統(tǒng)的發(fā)展醉冤。
為什么閱讀GFS的論文
- GFS使用了map/reduce的架構
- 好的性能 & 良好的并行I/O性能
- 其是一篇好的系統(tǒng)論文:從apps到網絡都有細節(jié)說明
- 包含分布式的許多概念：performance, fault-tolerance, consistency
- 使用廣泛（Bigtable秩霍、Spanner篙悯、Hadoop）
一致性是什么
一致性是保證分布式系統(tǒng)正確的條件。在有多個副本铃绒，并且并發(fā)下變得尤其困難鸽照。
一致性是分布式系統(tǒng)中最關鍵的問題，基本所有分布式系統(tǒng)都必須討論這個問題匿垄。
考慮如果在一個程序中寫，但是在另一個程序的副本中讀取的情況归粉。
強的一致性會保證在另一個程序中讀取到的一定是發(fā)生在最后一次寫入之后椿疗。
弱的一致性無法對其進行保證，可能會讀取到過時的數(shù)據(jù)糠悼。
強一致性可以保證讀到最新的寫信息届榄，但是對性能肯定會造成影響，好的系統(tǒng)設計就是在這兩點中進行平衡倔喂。
理想的一致性模型
分布式文件系統(tǒng)需要達成的“理想的“一致性就是多節(jié)點上面操作文件表現(xiàn)處理單機跟本地文件系統(tǒng)一樣铝条。
如果兩個應用程序同時寫入同一文件怎么辦？
在單機席噩，數(shù)據(jù)常常有一些混合的內容班缰。即兩個程序的處理可能是交錯的。
如果兩個應用程序同時寫入同一目錄怎么辦
在單機悼枢，使用了鎖埠忘。一個應用程序處理完畢后，再處理第二個馒索。
挑戰(zhàn)
多磁盤
機器故障莹妒，操作無法完成。
網絡分區(qū)绰上，可能不能夠到達所有的機器和磁盤旨怠。
挑戰(zhàn)難以解決的原因
需要客戶端和服務器之間的通信
協(xié)議可能會變得復雜
不同的模型一致性考慮不同的權衡
+ 可串行性(serializability)
+ 順序一致性(sequential consistency)
+ 線性一致性(linearizability)
+ 單項一致性模型(entry consistency)
+ 松散一致性(release consistency)
GFS的目標
- GFS中節(jié)點失效就是常見的（每天1000臺機器中大約3臺失效）
- 高性能：大量
- 有效的使用網絡
設計
master存儲（directories, files, names）
存儲64MB的塊，每個塊就作為一個linux文件蜈块。
每個塊在三臺服務器上面做備份（保證可用性鉴腻，負載均衡）
塊為什么這么大（攤銷間接費用、減少master中的狀態(tài)大邪俳摇）
master掌握目錄的層次結構
文件夾中有哪些文件
對于文件，維護信息:哪些節(jié)點存儲了此文件信峻。
master在內存中維護狀態(tài)（每個塊的64字節(jié)元數(shù)據(jù)）
主數(shù)據(jù)庫具有用于元數(shù)據(jù)的私有倦青、可恢復數(shù)據(jù)庫
操作日志刷新到磁盤
檢查點
master快速恢復
shadow masters略微落后于master
客戶端讀
發(fā)送文件名和塊索引給master
master回復具有該塊的服務器集
回復版本號
client緩存信息
請求塊服務器
版本號（如果版本號錯誤盹舞，重新連接master）
primary
primary是一個副本節(jié)點中比較高級的節(jié)點产镐。
修改現(xiàn)有文件
client請求master 塊的位置 和primary的位置
master回復塊服務器，版本以及primary的位置
client根據(jù)網絡拓撲計算副本鏈
客戶端將數(shù)據(jù)發(fā)送到第一個副本節(jié)點癣亚，然后此副本節(jié)點轉發(fā)給其他人
副本節(jié)點會ack丑掺，表明數(shù)據(jù)已被接收
client 告訴primary寫入數(shù)據(jù)
primary分配序列號并寫入
primary 告訴其他副本寫入
全部成功后述雾，回復client
如果另一個客戶端并發(fā)在同一位置寫入數(shù)據(jù)，該怎么辦玻孟？
c1 與c2 可能會交替的寫入唆缴，結果是一致性的黍翎，但是不能保證的面徽。
添加文件
client 請求master 塊的位置匣掸。
client將數(shù)據(jù)發(fā)送給副本，但是沒有指定偏移量碰酝。
當數(shù)據(jù)在所有的塊服務器上后霎匈，client聯(lián)系primary
primary分配序列號
primary檢查是否能夠剛好添加到一個塊中
primary為添加選擇偏移量送爸，進行添加
轉發(fā)請求到其他副本
失敗后進行重試
不能使用下一個可用偏移量，因為在失敗的節(jié)點中可能會有空字節(jié)碱璃。
GFS支持原子操作弄痹，保證至少一次添加，主Chunk服務器選擇記錄需要添加到的文件位置肛真，然后發(fā)送給其他副本。
如果和一個副本的聯(lián)系失敗爽航，那么主Chunk服務器會告訴客戶端重試，如果重試成功讥珍，有些副本會出現(xiàn)追加兩次的情況(因為這個副本追加成功兩次)历极。
當GFS要去填塞chunk的邊緣時，如果追加操作跨越chunk的邊緣趟卸，那么文件也可能存在空洞。
失敗情況
塊服務器的失敗會引起client重試。
master失敗會導致GFS不可用锄列，shadow master會服務只讀的狀態(tài)×谟剩可能會返回過時的數(shù)據(jù)竣况。
總結
性能筒严，容錯，一致性（performance, fault-tolerance, consistency）的案例研究
優(yōu)勢
大量的順序讀取和寫入
追加文件高效
大的吞吐量
數(shù)據(jù)容錯（3個副本）
劣勢
master服務器的容錯
小文件（master服務器的瓶頸）
client會看到過時的數(shù)據(jù)（弱的一致性）
追加可能重復
GFS案例問答
為什么添加數(shù)據(jù)執(zhí)行至少一次"at-least-once"語義鸭蛙，而不是精準的一次摹恨？
實現(xiàn)困難规惰，primary需要保留重復的狀態(tài)睬塌。狀態(tài)必須在服務器之間復制歇万，以便如果primary出現(xiàn)故障, 此信息不會丟失。
應用程序如何知道塊的哪些是有數(shù)據(jù)的塊勋陪，哪些是重復的數(shù)據(jù)
可以在有效記錄的開頭做標識（magic number）就可以知道有數(shù)據(jù)的塊。
檢測重復的塊可以為每個記錄都有一個特殊的UID標識诅愚。
論文中提到的reference counts是什么意思
- 他們是實現(xiàn)快照copy-on-write（寫時復制）的一部分寒锚。
- 當GFS創(chuàng)建快照時违孝，它不復制塊刹前，而是增加每個塊的引用計數(shù)器雌桑。這使得創(chuàng)建快照的成本不高。 如果客戶端寫入了一個塊校坑，并且主服務器注意到引用計數(shù)大于1拣技，此時，主服務器會首先創(chuàng)建一個副本耍目，以便客戶端可以更新副本（而不是快照的一部分）膏斤。
