如此超高的性能，有人會(huì )問(wèn)，阿里云到底用了什么秘密技術(shù)？安全系數如何？
本文將從冗余設計思路出發(fā)，分享阿里云是如何建立存儲冗余體系，抵御未知風(fēng)險，解決故障率的。
舞動(dòng)的橋
1940年11月7日，竣工才4個(gè)月的塔科馬海峽大橋在微風(fēng)中大幅度舞動(dòng)，橋上的汽車(chē)急速滑動(dòng)，很快就戲劇性的垮塌。這件事故給建筑工程行業(yè)造成極大的震驚，很違反直覺(jué)，很低的風(fēng)速居然會(huì )吹垮一座鋼鐵建造的大橋，在此之前所有的橋梁專(zhuān)家都沒(méi)有意識到這個(gè)問(wèn)題，事實(shí)上若干年后橋梁結構學(xué)與空氣動(dòng)力學(xué)得到極大發(fā)展，人類(lèi)才徹底解決這個(gè)問(wèn)題。
在工程領(lǐng)域通常將這類(lèi)事前缺少認知，只有發(fā)生后才能意識到的問(wèn)題統稱(chēng)為險惡性問(wèn)題，這類(lèi)問(wèn)題殺傷力極大，對于盤(pán)古這樣的分布式系統同樣會(huì )面臨這類(lèi)險惡性問(wèn)題，既然對問(wèn)題都沒(méi)有認知，又防御何談呢？陽(yáng)光之下并無(wú)新事，我們從各種安全至關(guān)重要的行業(yè)中廣泛的學(xué)習，發(fā)現各個(gè)行業(yè)在面對這類(lèi)問(wèn)題時(shí)，已經(jīng)有較為豐富的經(jīng)驗了，同樣以橋梁為例，早于的塔科馬海峽大橋的金門(mén)大橋（1937年建成通車(chē)）已經(jīng)巍然屹立了80多年，可謂飽經(jīng)風(fēng)霜，后人在分析其設計者留下的設計手稿時(shí)發(fā)現早期的設計者在面對未知世界時(shí)非常謙卑，他們知道有些問(wèn)題他們搞不清楚，可能會(huì )有風(fēng)險，所以他們做了充分的冗余設計來(lái)抵御這種未知的風(fēng)險，通過(guò)充分的冗余來(lái)斬斷可能形成的故障鏈。
其實(shí)存儲是一個(gè)高危行業(yè)，首先要保障的是不錯，不丟，可訪(fǎng)問(wèn)，只有在這個(gè)前提下，極致的性能才有意義。不錯，不丟，可訪(fǎng)問(wèn)，看起來(lái)平淡無(wú)奇，但實(shí)踐下來(lái)常有如履薄冰之感，因為分布式問(wèn)題太過(guò)復雜，因為操作系統、硬件都不是絕對可靠的，因為代碼不可能絕對無(wú)bug，運維也不可能從不出錯。有太多險惡性問(wèn)題，即使行業(yè)先行者也出現過(guò)數據丟失和不可用。在盤(pán)古設計之初我們學(xué)習了上文中冗余設計的做法，承認自己所知有限，在很多地方做了冗余設計來(lái)抵御未知風(fēng)險，并且在長(cháng)期的演進(jìn)中不但強化這類(lèi)冗余設計，絕不為了性能或者其他的目標來(lái)做冗余設計上的妥協(xié)。
這些年來(lái)阿里云存儲團隊的同事們始終心存畏懼，鐵棒磨針，始終專(zhuān)注于提供穩定可靠高性能的存儲，天道酬勤，10年來(lái)我們做到了數據不錯，不丟，非常慶幸。
下面我分享幾個(gè)阿里云在存儲方面的冗余設計：
- E2E的數據校驗
磁盤(pán)可能出錯，內存也會(huì )出現bit反轉，內核和應用程序更可能出錯，甚至我們遇到過(guò)某廠(chǎng)的一塊CPU在做某些特定運算時(shí)就會(huì )出錯，在這樣一堆不可靠的軟硬件環(huán)境下，要構建出一個(gè)穩定可靠的存儲平臺（沒(méi)有哪個(gè)用戶(hù)能接受哪怕一個(gè)bit的錯誤），是非常困難的，一般的做法是端到端的逐層做數據校驗，盤(pán)古很早就做了E2E 的數據校驗。但一次在一個(gè)長(cháng)時(shí)間大壓力的測試環(huán)境上MySQL 報數據錯，核對數據發(fā)現CRC和數據是匹配的，并沒(méi)有出錯，核對另外2份拷貝，發(fā)現另外兩份數據也是CRC自洽的，而且另外兩份完全一致，但與MySQL讀取的這一份差異非常大。初步判定是MySQL讀取的這一份數據出錯了，但這份錯誤的數據是CRC自洽的，這就非常奇怪了，如果是存儲介質(zhì)出錯，不太可能還保持CRC自洽，在讀寫(xiě)鏈路上查看了所有日志，沒(méi)有找到任何異常。調查的同事反復核對三份拷貝，說(shuō)這一份看起來(lái)就不像是這個(gè)文件的數據。
說(shuō)者無(wú)心，聽(tīng)者有意，另外一個(gè)同事想在哪種情況下會(huì )出現這樣的錯誤，由于我們的CRC和數據是邏輯空間上是相鄰的，會(huì )不會(huì )是這片數據其實(shí)不屬于當前文件，而是和另外一個(gè)文件搞串了？大膽假設，小心求證，全盤(pán)掃描后果然證實(shí)了猜想：A和B兩個(gè)文件中間有一部分內容寫(xiě)串了，詳細調查后確認是EXT4 文件系統的BUG，它在做空間管理的時(shí)候出錯，導致A文件的一個(gè)數據片寫(xiě)入到文件B, 文件B中有一個(gè)數據片寫(xiě)入到文件A中，由于寫(xiě)入的流程一致，CRC又和數據放置在一起，導致CRC無(wú)法發(fā)現這個(gè)問(wèn)題，確認問(wèn)題后解決起來(lái)就很簡(jiǎn)單了，要么將CRC和數據分開(kāi)放置，要么在計算CRC的時(shí)候加上文件的一個(gè)特征值。
有E2E的數據校驗是否就安全了呢？呵呵坑深不見(jiàn)底，硬件行業(yè)的人知道磁盤(pán)極小的概率發(fā)生靜默錯誤（讀出來(lái)的數據是錯誤的，但底層接口不報錯，磁盤(pán)本身也不報錯），如果三份拷貝很長(cháng)時(shí)間都未被讀取，而在這個(gè)較長(cháng)的時(shí)間窗口內，如果有三份拷貝所在的3塊盤(pán)都發(fā)生了靜默錯誤，用戶(hù)讀取數據時(shí)，存儲系統就會(huì )發(fā)現3份CRC校驗都不通過(guò)，盡管知道出差錯了，卻沒(méi)有任何辦法修復。為了降低這種情況發(fā)生的概率，我們會(huì )定期掃描冷數據，校驗其CRC。
- 壓縮檢驗
一天新來(lái)的同事問(wèn)大家：“我們在做壓縮的時(shí)候，為啥壓縮完后，立刻又解壓縮一次，并且將解壓數據和原始數據再去比對一次？直接壓縮不就完了嗎？”，眾人笑而不語(yǔ)，他思考良久，也未能找到足夠的理由。團隊內老司機告訴他，壓縮本身是一個(gè)很復雜的東西，有些庫是第三方提供的，盡管我們會(huì )review代碼，有嚴格的引入測試，但沒(méi)人能保障其絕對正確，萬(wàn)一壓縮出來(lái)的內容是錯的怎么辦？CPU也可能存在一些偶發(fā)性的錯誤，如果壓縮時(shí)發(fā)生這類(lèi)小概率的偶發(fā)性錯誤，該怎么辦呢？但戶(hù)數據是絕對不能錯的，所以我們這里采取防御性編程，壓縮完后立即解壓，再和原始內容比對，確保數據不錯。
- PAXOS
說(shuō)到分布式存儲，很多人就言必稱(chēng)PAXOS和RAFT，PAXOS儼然就成了救世主。PAXOS, RAFT 的確是好東西，但并不是所有的場(chǎng)景都適用。在一個(gè)分布式系統中，大家會(huì )認為在一個(gè)較小的時(shí)間窗口內同時(shí)發(fā)生2臺機器failover是一個(gè)小概率事件，但隨著(zhù)集群規模的擴大，集群數量的增多，最終小概率事件長(cháng)期積累，就變成必然事件了，在quorum=3的時(shí)候，PAXOS 協(xié)議是無(wú)法處理double fail的，甚至無(wú)法自愈，需要緊急人為干預才能恢復。想想半夜收到告警，你能在幾分鐘能處理好用戶(hù)的IO HANG？ 適合的才是最好的，實(shí)踐是檢驗真理的唯一標準。
- 磁盤(pán)錯誤
對于做存儲的人來(lái)說(shuō)，磁盤(pán)故障是司空見(jiàn)慣的事情了，本身有一套成熟的處理機制。但百密一疏，我們還是在這上面栽過(guò)跟頭，進(jìn)程主動(dòng)檢測到binary所在的系統盤(pán)故障，老司機當然知道此時(shí)不能再在該盤(pán)上發(fā)起任何IO 操作，日志寫(xiě)入到內存中，調用exit, 安靜的退出，不帶走一片云彩即可。但進(jìn)程居然無(wú)法退出，調用exit 無(wú)法退出！而此時(shí)其它線(xiàn)程還在繼續工作，在干壞事。所有人都覺(jué)得匪夷所思，為啥主線(xiàn)程調用 exit, 進(jìn)程未能退出，其他線(xiàn)程在長(cháng)達幾分鐘內還在繼續干壞事？團隊大牛反復推演，不放過(guò)任何一個(gè)蛛絲馬跡，終于搞明白了，原來(lái)磁盤(pán)故障后，exit這段代碼本身并不在內存中，調用時(shí)會(huì )產(chǎn)生major fault, 中斷處理程序會(huì )嘗試從磁盤(pán)上load相應的代碼段，而磁盤(pán)已經(jīng)故障了，load 被hang住，導致出現前面這些匪夷所思的怪事。
今天云計算已經(jīng)成為互聯(lián)網(wǎng)的基礎設施，隨著(zhù)眾多電力、水務(wù)、醫療企業(yè)上云，阿里云又成了這些基礎設施的基礎設施，任何一個(gè)黑天鵝都有可能帶來(lái)難以估量的影響。只有對這個(gè)未知的世界保持敬畏，保持謙卑，才能走得更遠。
