在前面的 MapReduce 中我們聊到這個(gè)至簡的模型為我們構(gòu)建分布式系統(tǒng)開啟了新的大門写穴，今天我們來聊聊 MapReduce 中負(fù)責(zé)輸入輸出的文件系統(tǒng)案例琼富。
首先我們來了解一下 GFS 的設(shè)計(jì)目標(biāo)：在成千上百臺(tái) Linux 普通機(jī)器存儲(chǔ)巨量數(shù)據(jù)，保證高并發(fā)蜓萄。
前幾篇一直提一致性隅茎，啥是一致性？舉個(gè)例子嫉沽，我在支付寶上存了 100后辟犀，在全國無論什么地方連上哪臺(tái)支付寶的服務(wù)器，我的賬戶上都得增加 100绸硕。如果支付寶全國只有一萬個(gè)人在用堂竟，一臺(tái)機(jī)器一個(gè)數(shù)據(jù)庫就足夠了，但用戶的數(shù)量是數(shù)以億計(jì)玻佩，所以肯定是好多機(jī)器在服務(wù)出嘹，所以如果保證不了一致性，是一秒鐘都干不下去的咬崔。
但話又說回來税稼，不是每家企業(yè)都是像支付寶一樣一分錢都不能錯(cuò)，比如微博垮斯，你關(guān)注的明星發(fā)了一個(gè)動(dòng)態(tài)郎仆，1分鐘后你才刷新到，其實(shí)也是可以接受兜蠕，所以根據(jù)不同業(yè)務(wù)對(duì)一致性的要求不同扰肌，可分為強(qiáng)一致性和弱一致性。
我們以文件系統(tǒng)舉例熊杨，弱一致性的文件讀取操作 read() 可能會(huì)讀不到最新寫入的數(shù)據(jù)狡耻；而強(qiáng)一致性保證 read() 始終讀到最新寫入的數(shù)據(jù)墩剖。不同的場景有不同的一致性策略猴凹，那么理想狀態(tài)下的一致性模型是怎樣的夷狰？
- 文件副本可以像沒有副本的文件系統(tǒng)一樣使用：像多個(gè)客戶端訪問一臺(tái)機(jī)器上某個(gè)磁盤上的文件。
- 如果一個(gè)應(yīng)用正在寫入郊霎，之后的讀取操作應(yīng)該讀到寫入的內(nèi)容沼头。
- 兩個(gè)應(yīng)用并發(fā)寫入同一個(gè)文件。如果該文件不存在书劝，最后文件中可能會(huì)有混合的內(nèi)容进倍。
- 如果兩個(gè)應(yīng)用并發(fā)寫入同一個(gè)目錄，第一個(gè)先寫购对，另一個(gè)后寫猾昆。
理想的攔路虎是什么：機(jī)器故障，網(wǎng)絡(luò)隔離骡苞，要一致性又要高并發(fā)垂蜗。然后會(huì)發(fā)現(xiàn)自相矛盾的理想是不可能實(shí)現(xiàn)的。所以 GFS 在現(xiàn)實(shí)和理想中間找到一個(gè)平衡點(diǎn)解幽√看看現(xiàn)實(shí)是什么：
- 大部分文件都很大，GB 級(jí)別
- 文件不用刪除
- 文件的修改只有追加操作
- 偶爾讀不到最新數(shù)據(jù)也可以接受躲株，畢竟瀏覽網(wǎng)頁不是查看賬戶余額
- 最重要的是片部，數(shù)據(jù)量巨大，并發(fā)量大霜定，性能要求很高
在 GFS 架構(gòu)中有 Client档悠，Master Server 和 Chunk Server 三種角色，文件被分為固定大小的數(shù)據(jù)塊望浩，在 Chunk 上使用多(默認(rèn) 3)臺(tái)機(jī)器進(jìn)行主從備份提高可用性辖所，而 Master 主要管理元數(shù)據(jù)和 Chunk。對(duì)于 Master 操作如修改目錄是強(qiáng)一致性的曾雕，而對(duì)于 Chunk 是弱一致性奴烙。
有道是解決主要矛盾，忽略次要矛盾剖张。既然要提高并發(fā)量和可用性切诀，我們認(rèn)為每個(gè)文件追加操作在所有副本執(zhí)行成功就算本次客戶端操作成功，而對(duì)于一條數(shù)據(jù)重復(fù)添加搔弄，兩條追加記錄中插入其他數(shù)據(jù)都視為正常幅虑，這大大提高了并發(fā)，但要求業(yè)務(wù)代碼區(qū)別每個(gè)記錄的唯一性顾犹。這里并發(fā)性和可用性是主要矛盾倒庵，而一致性則是次要矛盾褒墨。
GFS 對(duì) Master Server 和 Chunk Server 合理分配了各自的負(fù)載重點(diǎn)，讓 Master 保持輕量和簡單的一致性模型擎宝；而 Chunk Server 負(fù)責(zé)實(shí)際的文件數(shù)據(jù)與 Linux 的交互以及主副本與其他備份的復(fù)制優(yōu)化郁妈。
容錯(cuò)方面，Master 采用傳統(tǒng)的 Write Ahead Log 和 CheckPoint 機(jī)制外幾臺(tái)熱備份 Master绍申。而 Chunk Server 采用主從備份噩咪，一致性要求不高。
學(xué)習(xí)一個(gè)系統(tǒng)极阅，場景很重要哦胃碾。GFS 為大規(guī)模讀寫，追加筋搏，吞吐量巨大仆百，一致性要求不高的需求設(shè)計(jì)。所以不適合大量小文件奔脐，多客戶端對(duì)同一文件隨機(jī)修改俄周，master 邏輯復(fù)雜且容易出錯(cuò)的場景。
