其實(shí)存儲(chǔ)是一個(gè)高危行業(yè)，首先要保障的是不錯(cuò)，不丟，可訪問，只有在這個(gè)前提下，極致的性能才有意義。不錯(cuò)，不丟，可訪問，看起來平淡無奇，但實(shí)踐下來常有如履薄冰之感，因?yàn)榉植际絾栴}太過復(fù)雜，因?yàn)椴僮飨到y(tǒng)、硬件都不是絕對(duì)可靠的，因?yàn)榇�碼不可能絕對(duì)無bug，運(yùn)維也不可能從不出錯(cuò)。有太多險(xiǎn)惡性問題，即使行業(yè)先行者也出現(xiàn)過數(shù)據(jù)丟失和不可用。在盤古設(shè)計(jì)之初我們學(xué)習(xí)了上文中冗余設(shè)計(jì)的做法，承認(rèn)自己所知有限，在很多地方做了冗余設(shè)計(jì)來抵御未知風(fēng)險(xiǎn)，并且在長期的演進(jìn)中不但強(qiáng)化這類冗余設(shè)計(jì)，絕不為了性能或者其他的目標(biāo)來做冗余設(shè)計(jì)上的妥協(xié)。

　　這些年來阿里云存儲(chǔ)團(tuán)隊(duì)的同事們始終心存畏懼，鐵棒磨針，始終專注于提供穩(wěn)定可靠高性能的存儲(chǔ)，天道酬勤，10年來我們做到了數(shù)據(jù)不錯(cuò)，不丟，非常慶幸。

　　下面我分享幾個(gè)阿里云在存儲(chǔ)方面的冗余設(shè)計(jì)：

　　磁盤可能出錯(cuò)，內(nèi)存也會(huì)出現(xiàn)bit反轉(zhuǎn)，內(nèi)核和應(yīng)用程序更可能出錯(cuò)，甚至我們遇到過某廠的一塊CPU在做某些特定運(yùn)算時(shí)就會(huì)出錯(cuò)，在這樣一堆不可靠的軟硬件環(huán)境下，要構(gòu)建出一個(gè)穩(wěn)定可靠的存儲(chǔ)平臺(tái)（沒有哪個(gè)用戶能接受哪怕一個(gè)bit的錯(cuò)誤），是非常困難的，一般的做法是端到端的逐層做數(shù)據(jù)校驗(yàn)，盤古很早就做了E2E 的數(shù)據(jù)校驗(yàn)。但一次在一個(gè)長時(shí)間大壓力的測(cè)試環(huán)境上MySQL 報(bào)數(shù)據(jù)錯(cuò)，核對(duì)數(shù)據(jù)發(fā)現(xiàn)CRC和數(shù)據(jù)是匹配的，并沒有出錯(cuò)，核對(duì)另外2份拷貝，發(fā)現(xiàn)另外兩份數(shù)據(jù)也是CRC自洽的，而且另外兩份完全一致，但與MySQL讀取的這一份差異非常大。初步判定是MySQL讀取的這一份數(shù)據(jù)出錯(cuò)了，但這份錯(cuò)誤的數(shù)據(jù)是CRC自洽的，這就非常奇怪了，如果是存儲(chǔ)介質(zhì)出錯(cuò)，不太可能還保持CRC自洽，在讀寫鏈路上查看了所有日志，沒有找到任何異常。調(diào)查的同事反復(fù)核對(duì)三份拷貝，說這一份看起來就不像是這個(gè)文件的數(shù)據(jù)。

　　說者無心，聽者有意，另外一個(gè)同事想在哪種情況下會(huì)出現(xiàn)這樣的錯(cuò)誤，由于我們的CRC和數(shù)據(jù)是邏輯空間上是相鄰的，會(huì)不會(huì)是這片數(shù)據(jù)其實(shí)不屬于當(dāng)前文件，而是和另外一個(gè)文件搞串了？大膽假設(shè)，小心求證，全盤掃描后果然證實(shí)了猜想：A和B兩個(gè)文件中間有一部分內(nèi)容寫串了，詳細(xì)調(diào)查后確認(rèn)是EXT4 文件系統(tǒng)的BUG，它在做空間管理的時(shí)候出錯(cuò)，導(dǎo)致A文件的一個(gè)數(shù)據(jù)片寫入到文件B, 文件B中有一個(gè)數(shù)據(jù)片寫入到文件A中，由于寫入的流程一致，CRC又和數(shù)據(jù)放置在一起，導(dǎo)致CRC無法發(fā)現(xiàn)這個(gè)問題，確認(rèn)問題后解決起來就很簡單了，要么將CRC和數(shù)據(jù)分開放置，要么在計(jì)算CRC的時(shí)候加上文件的一個(gè)特征值。

　　有E2E的數(shù)據(jù)校驗(yàn)是否就安全了呢？呵呵坑深不見底，硬件行業(yè)的人知道磁盤極小的概率發(fā)生靜默錯(cuò)誤（讀出來的數(shù)據(jù)是錯(cuò)誤的，但底層接口不報(bào)錯(cuò)，磁盤本身也不報(bào)錯(cuò)），如果三份拷貝很長時(shí)間都未被讀取，而在這個(gè)較長的時(shí)間窗口內(nèi)，如果有三份拷貝所在的3塊盤都發(fā)生了靜默錯(cuò)誤，用戶讀取數(shù)據(jù)時(shí)，存儲(chǔ)系統(tǒng)就會(huì)發(fā)現(xiàn)3份CRC校驗(yàn)都不通過，盡管知道出差錯(cuò)了，卻沒有任何辦法修復(fù)。為了降低這種情況發(fā)生的概率，我們會(huì)定期掃描冷數(shù)據(jù)，校驗(yàn)其CRC。

　　一天新來的同事問大家：“我們?cè)谧鰤嚎s的時(shí)候，為啥壓縮完后，立刻又解壓縮一次，并且將解壓數(shù)據(jù)和原始數(shù)據(jù)再去比對(duì)一次？直接壓縮不就完了嗎？”，眾人笑而不語，他思考良久，也未能找到足夠的理由。團(tuán)隊(duì)內(nèi)老司機(jī)告訴他，壓縮本身是一個(gè)很復(fù)雜的東西，有些庫是第三方提供的，盡管我們會(huì)review代碼，有嚴(yán)格的引入測(cè)試，但沒人能保障其絕對(duì)正確，萬一壓縮出來的內(nèi)容是錯(cuò)的怎么辦？CPU也可能存在一些偶發(fā)性的錯(cuò)誤，如果壓縮時(shí)發(fā)生這類小概率的偶發(fā)性錯(cuò)誤，該怎么辦呢？但戶數(shù)據(jù)是絕對(duì)不能錯(cuò)的，所以我們這里采取防御性編程，壓縮完后立即解壓，再和原始內(nèi)容比對(duì)，確保數(shù)據(jù)不錯(cuò)。

　　說到分布式存儲(chǔ)，很多人就言必稱PAXOS和RAFT，PAXOS儼然就成了救世主。PAXOS, RAFT 的確是好東西，但并不是所有的場(chǎng)景都適用。在一個(gè)分布式系統(tǒng)中，大家會(huì)認(rèn)為在一個(gè)較小的時(shí)間窗口內(nèi)同時(shí)發(fā)生2臺(tái)機(jī)器failover是一個(gè)小概率事件，但隨著集群規(guī)模的擴(kuò)大，集群數(shù)量的增多，最終小概率事件長期積累，就變成必然事件了，在quorum=3的時(shí)候，PAXOS 協(xié)議是無法處理double fail的，甚至無法自愈，需要緊急人為干預(yù)才能恢復(fù)。想想半夜收到告警，你能在幾分鐘能處理好用戶的IO HANG？ 適合的才是最好的，實(shí)踐是檢驗(yàn)真理的唯一標(biāo)準(zhǔn)。

　　對(duì)于做存儲(chǔ)的人來說，磁盤故障是司空見慣的事情了，本身有一套成熟的處理機(jī)制。但百密一疏，我們還是在這上面栽過跟頭，進(jìn)程主動(dòng)檢測(cè)到binary所在的系統(tǒng)盤故障，老司機(jī)當(dāng)然知道此時(shí)不能再在該盤上發(fā)起任何IO 操作，日志寫入到內(nèi)存中，調(diào)用exit, 安靜的退出，不帶走一片云彩即可。但進(jìn)程居然無法退出，調(diào)用exit 無法退出！而此時(shí)其它線程還在繼續(xù)工作，在干壞事。所有人都覺得匪夷所思，為啥主線程調(diào)用 exit, 進(jìn)程未能退出，其他線程在長達(dá)幾分鐘內(nèi)還在繼續(xù)干壞事？團(tuán)隊(duì)大牛反復(fù)推演，不放過任何一個(gè)蛛絲馬跡，終于搞明白了，原來磁盤故障后，exit這段代碼本身并不在內(nèi)存中，調(diào)用時(shí)會(huì)產(chǎn)生major fault, 中斷處理程序會(huì)嘗試從磁盤上load相應(yīng)的代碼段，而磁盤已經(jīng)故障了，load 被hang住，導(dǎo)致出現(xiàn)前面這些匪夷所思的怪事。

　　今天云計(jì)算已經(jīng)成為互聯(lián)網(wǎng)的基礎(chǔ)設(shè)施，隨著眾多電力、水務(wù)、醫(yī)療企業(yè)上云，阿里云又成了這些基礎(chǔ)設(shè)施的基礎(chǔ)設(shè)施，任何一個(gè)黑天鵝都有可能帶來難以估量的影響。只有對(duì)這個(gè)未知的世界保持敬畏，保持謙卑，才能走得更遠(yuǎn)。