為什么這么設(shè)計(jì)（Why’s THE Design）是一系列關(guān)于計(jì)算機(jī)領(lǐng)域中程序設(shè)計(jì)決策的文章，我們?cè)谶@個(gè)系列的每一篇文章中都會(huì)提出一個(gè)具體的問題并從不同的角度討論這種設(shè)計(jì)的優(yōu)缺點(diǎn)、對(duì)具體實(shí)現(xiàn)造成的影響。如果你有想要了解的問題，可以在文章下面留言。

數(shù)據(jù)庫(kù)管理系統(tǒng)在今天已經(jīng)是軟件的重要組成部分，開源的 MySQL、PostgreSQL 以及商業(yè)化的 Oracle 等數(shù)據(jù)庫(kù)已經(jīng)隨處可見，幾乎所有的服務(wù)都需要依賴數(shù)據(jù)庫(kù)管理系統(tǒng)存儲(chǔ)數(shù)據(jù)。

database-banner

圖 1 - 數(shù)據(jù)庫(kù)

數(shù)據(jù)庫(kù)不會(huì)丟失數(shù)據(jù)聽起來(lái)像是理所當(dāng)然的事情，持久化能力也應(yīng)該是數(shù)據(jù)庫(kù)的最基本保障，但是在這個(gè)復(fù)雜的世界上想要保證數(shù)據(jù)不丟失是很困難的。在今天，我們能找到很多數(shù)據(jù)庫(kù)出現(xiàn)問題導(dǎo)致數(shù)據(jù)丟失的例子：

• MongoDB 在過去很長(zhǎng)的一段時(shí)間都不能保證持久性，很容易就會(huì)丟失數(shù)據(jù)[^1]；

• RocksDB DeleteRange 功能導(dǎo)致的數(shù)據(jù)丟失問題[^2]；

• 騰訊云硬盤故障，導(dǎo)致創(chuàng)業(yè)公司線上生產(chǎn)數(shù)據(jù)完全丟失[^3]；

無(wú)論是開源數(shù)據(jù)庫(kù)還是云服務(wù)商提供的服務(wù)，都有可能發(fā)生數(shù)據(jù)丟失的。本文將數(shù)據(jù)庫(kù)丟失數(shù)據(jù)的原因歸結(jié)到以下的幾個(gè)方面，我們將詳細(xì)展開介紹這些原因：

• 人為因素導(dǎo)致的運(yùn)維和配置錯(cuò)誤是數(shù)據(jù)庫(kù)丟失數(shù)據(jù)的首要原因；

• 數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)使用的磁盤損壞導(dǎo)致數(shù)據(jù)丟失；

• 數(shù)據(jù)庫(kù)的功能和實(shí)現(xiàn)復(fù)雜，數(shù)據(jù)沒有及時(shí)刷入磁盤就有丟失的風(fēng)險(xiǎn)；

人為錯(cuò)誤

人為錯(cuò)誤是造成數(shù)據(jù)丟失的首要原因。在騰訊云數(shù)據(jù)丟失事故中，我們會(huì)發(fā)現(xiàn)，雖然事故的起因是硬件故障，但是最終導(dǎo)致數(shù)據(jù)完整性受損的還是運(yùn)維人員的不當(dāng)操作：

第一是正常數(shù)據(jù)搬遷流程默認(rèn)開啟數(shù)據(jù)校驗(yàn)，開啟之后可以有效發(fā)現(xiàn)并規(guī)避源端數(shù)據(jù)異常，保障搬遷數(shù)據(jù)正確性，但是運(yùn)維人員為了加速完成搬遷任務(wù)，違規(guī)關(guān)閉了數(shù)據(jù)校驗(yàn)；

第二是正常數(shù)據(jù)搬遷完成之后，源倉(cāng)庫(kù)數(shù)據(jù)應(yīng)保留24小時(shí)，用于搬遷異常情況下的數(shù)據(jù)恢復(fù)，但是運(yùn)維人員為了盡快降低倉(cāng)庫(kù)使用率，違規(guī)對(duì)源倉(cāng)庫(kù)進(jìn)行了數(shù)據(jù)回收。

減少人為錯(cuò)誤的最好方式是將數(shù)據(jù)的備份和運(yùn)維等操作標(biāo)準(zhǔn)化，使用自動(dòng)化的流程處理涉及數(shù)據(jù)安全的操作，這樣才能降低人為干預(yù)帶來(lái)的風(fēng)險(xiǎn)。

對(duì)于軟件工程師來(lái)說(shuō)，我們應(yīng)該敬畏生產(chǎn)環(huán)境，謹(jǐn)慎地在生產(chǎn)環(huán)境執(zhí)行一切操作，認(rèn)識(shí)到所有的操作都可能對(duì)線上正在運(yùn)行的服務(wù)產(chǎn)生影響，這樣才能降低類似問題發(fā)生的概率。

硬件錯(cuò)誤

我們?cè)?nbsp;為什么基礎(chǔ)服務(wù)不應(yīng)該高可用 一文中曾經(jīng)介紹過任何一個(gè)線上的服務(wù)能夠正常運(yùn)行都是極其偶然的，只要時(shí)間拉的足夠長(zhǎng)，我們就沒有辦法保證服務(wù) 100% 的可用性[^4]。磁盤等硬件如果使用的時(shí)間足夠長(zhǎng)，很有可能會(huì)發(fā)生損壞，根據(jù) Google 論文中的數(shù)據(jù)，5 年內(nèi)硬盤的年平均故障率（Annualized Failure Rates，AFR）為 8.6%[^5]。

2018 年，騰訊云數(shù)據(jù)損壞事故的起因就是磁盤靜默錯(cuò)誤（Silent data corruption）[^6]導(dǎo)致的單副本數(shù)據(jù)錯(cuò)誤。磁盤靜默錯(cuò)誤是沒有被磁盤固件或者宿主操作系統(tǒng)發(fā)現(xiàn)的錯(cuò)誤，包括以下情況：電纜松了、電源供給不可靠、外部震動(dòng)、網(wǎng)絡(luò)引起的數(shù)據(jù)丟失等問題。

正是因?yàn)榇疟P的數(shù)據(jù)損壞非常常見，所以我們需要數(shù)據(jù)冗余的方式保證磁盤在發(fā)生不可修復(fù)讀錯(cuò)誤（Unrecoverable Read Error）時(shí)能夠恢復(fù)磁盤數(shù)據(jù)。獨(dú)立冗余磁盤陣列（Redundant Array of Independent Disks，RAID）是一種能夠?qū)⒍鄠€(gè)物理磁盤組合成一個(gè)邏輯磁盤的數(shù)據(jù)存儲(chǔ)虛擬化技術(shù)，它能夠增加數(shù)據(jù)冗余并提高性能[^7]。

raid-strategy

圖 2 - RAID 三大策略

RAID 主要使用分割（Striping）、鏡像（Mirroring）和奇偶校驗(yàn)（Parity）三大策略管理磁盤中的數(shù)據(jù)，我們這里舉幾個(gè)簡(jiǎn)單的例子：

• RAID 0 使用了數(shù)據(jù)分割技術(shù)，但是沒有鏡像和奇偶校驗(yàn)。它對(duì)磁盤上的數(shù)據(jù)幾乎不進(jìn)行任何的保護(hù)，任意一塊磁盤磁盤損壞都意味著其中的數(shù)據(jù)無(wú)法恢復(fù)，但是因?yàn)椴淮嬖谌哂啵运矔?huì)提供較好的性能；

• RAID 1 使用了數(shù)據(jù)鏡像的功能，但是沒有奇偶校驗(yàn)和數(shù)據(jù)分割。所有的數(shù)據(jù)都會(huì)寫入兩個(gè)相同的磁盤，兩個(gè)磁盤都能對(duì)外提供數(shù)據(jù)讀取的服務(wù)。這種方式降低了磁盤的使用率，但是能夠提高讀取性能并提供備份；

• ...

RAID 使用的分割和鏡像策略與分布式數(shù)據(jù)庫(kù)中的分片（Partition）和副本（Replication）比較相似，分割和分片將數(shù)據(jù)切分后分配到不同的磁盤或者機(jī)器，而鏡像和副本的作用都是復(fù)制數(shù)據(jù)。

很多現(xiàn)代的操作系統(tǒng)都會(huì)提供基于軟件的 RAID 實(shí)現(xiàn)，一些云服務(wù)廠商也會(huì)使用自研的文件系統(tǒng)或者冗余備份機(jī)制：

• Google 使用 Google 文件系統(tǒng)管理文件，它以塊的方式存儲(chǔ)文件并且通過主服務(wù)管理所有的文件塊[^8]；

• Microsoft 在 Azure 中使用擦除編碼的方式計(jì)算冗余數(shù)據(jù)[^9]；

硬件錯(cuò)誤在生產(chǎn)環(huán)境中很常見，我們只有通過數(shù)據(jù)冗余和校驗(yàn)才能降低數(shù)據(jù)丟失的可能性，但是增加冗余的方式也只能不斷降低數(shù)據(jù)丟失的概率，不能 100% 的避免。

實(shí)現(xiàn)復(fù)雜

數(shù)據(jù)庫(kù)管理系統(tǒng)最終會(huì)將數(shù)據(jù)存儲(chǔ)在磁盤上，對(duì)于很多數(shù)據(jù)庫(kù)來(lái)說(shuō)，數(shù)據(jù)落到磁盤上就意味著持久化完成了。磁盤作為數(shù)據(jù)庫(kù)系統(tǒng)的下層，磁盤能夠穩(wěn)定存儲(chǔ)數(shù)據(jù)是數(shù)據(jù)庫(kù)能夠持久化數(shù)據(jù)的基礎(chǔ)。

database-and-disk

圖 3 - 數(shù)據(jù)庫(kù)依賴磁盤

很多人都誤認(rèn)為使用 write 就能將數(shù)據(jù)寫入到磁盤上，然而這是錯(cuò)誤的。函數(shù) write 不僅不能保證數(shù)據(jù)寫入磁盤，有的實(shí)現(xiàn)甚至都不能保證目標(biāo)空間保留給了寫入的數(shù)據(jù)[^10]。一般情況下，對(duì)文件的 write 只會(huì)更新內(nèi)存中的頁(yè)緩存，這些頁(yè)緩存不會(huì)立刻刷入磁盤，操作系統(tǒng)的 flusher 內(nèi)核線程會(huì)在滿足以下條件時(shí)將數(shù)據(jù)落盤[^11]：

• 空閑內(nèi)存下降到了特定的閾值，需要釋放臟頁(yè)占用的內(nèi)存空間；

• 臟數(shù)據(jù)持續(xù)了一定時(shí)間，最老的數(shù)據(jù)就會(huì)被寫入磁盤；

• 用戶進(jìn)程執(zhí)行 sync 或者 fsync 系統(tǒng)調(diào)用；

如果我們想要將數(shù)據(jù)立刻刷入磁盤，就需要在執(zhí)行 write 后立刻調(diào)用 fsync 等函數(shù)[^12]，當(dāng) fsync 等函數(shù)返回后，數(shù)據(jù)庫(kù)才會(huì)通知調(diào)用方數(shù)據(jù)已經(jīng)成功寫入。

write-and-fsyn

圖 4 - 寫入和落盤

write 和 fsync 在數(shù)據(jù)庫(kù)管理系統(tǒng)中非常重要，它們是提供持久性保證的核心方法，一些開發(fā)者對(duì) write 的理解錯(cuò)誤寫出錯(cuò)誤的代碼就會(huì)導(dǎo)致數(shù)據(jù)丟失。

除了持久化的特性之外，數(shù)據(jù)庫(kù)可能還需要提供 ACID（Atomicity, Consistency, Isolation, Durability）或者 BASE（Basically Available, Soft state, Eventual consistency）的保證，有些數(shù)據(jù)庫(kù)還會(huì)提供分片、副本以及分布式事務(wù)等復(fù)雜功能，這些功能的引入也增加了數(shù)據(jù)庫(kù)系統(tǒng)的復(fù)雜性，而隨著程序復(fù)雜性的增加，出現(xiàn)問題的可能性也隨之增長(zhǎng)。

總結(jié)

數(shù)據(jù)庫(kù)管理系統(tǒng)是軟件工程中最復(fù)雜、最重要的系統(tǒng)之一，幾乎所有服務(wù)的正常運(yùn)行都建立在數(shù)據(jù)庫(kù)不會(huì)丟失數(shù)據(jù)的假設(shè)上。然而因?yàn)槿缦滤镜脑?，?shù)據(jù)庫(kù)不能完全保證數(shù)據(jù)的安全：

• 運(yùn)維人員在配置和運(yùn)維時(shí)極有可能因?yàn)椴僮魇д`導(dǎo)致數(shù)據(jù)丟失；

• 數(shù)據(jù)庫(kù)依賴的底層磁盤發(fā)生硬件錯(cuò)誤，導(dǎo)致數(shù)據(jù)無(wú)法恢復(fù)；

• 數(shù)據(jù)庫(kù)系統(tǒng)支持的功能非常多而且復(fù)雜，數(shù)據(jù)沒有及時(shí)落盤就可能造成數(shù)據(jù)丟失；

一旦發(fā)生數(shù)據(jù)丟失的事故，造成的影響就會(huì)非常大，我們?cè)谑褂脭?shù)據(jù)庫(kù)存儲(chǔ)核心業(yè)務(wù)數(shù)據(jù)時(shí)也不能完全信任數(shù)據(jù)庫(kù)的穩(wěn)定性，可以考慮使用熱備以及快照等方式容災(zāi)。到最后，我們還是來(lái)看一些比較開放的相關(guān)問題，有興趣的讀者可以仔細(xì)思考一下下面的問題：

• 除了文中列出的數(shù)據(jù)丟失事故，還有哪些數(shù)據(jù)庫(kù)或者云服務(wù)商丟失過數(shù)據(jù)？

• Redis 的 RDB 和 AOF 機(jī)制什么時(shí)候會(huì)將數(shù)據(jù)落盤？

• 數(shù)據(jù)成功寫入數(shù)據(jù)庫(kù)究竟應(yīng)該如何定義？

如果對(duì)文章中的內(nèi)容有疑問或者想要了解更多軟件工程上一些設(shè)計(jì)決策背后的原因，可以在博客下面留言，作者會(huì)及時(shí)回復(fù)本文相關(guān)的疑問并選擇其中合適的主題作為后續(xù)的內(nèi)容。

[^1]: Brandur. May 7, 2017. "The long road to Mongo's durability" https://brandur.org/fragments/mongo-durability

[^2]: Huachao HUANG. Fri, Sep 8, 2017. "How We Found a Data Corruption Bug in RocksDB" https://pingcap.com/blog/2017-09-08-rocksdbbug/

[^3]: 騰訊云. Aug, 2018. 關(guān)于客戶“前沿?cái)?shù)控”數(shù)據(jù)完整性受損的技術(shù)復(fù)盤 https://mp.weixin.qq.com/s/8JSPY6vHPhg8pX0JwjqttQ

[^4]: Draven. Dec, 2019. "為什么基礎(chǔ)服務(wù)不應(yīng)該高可用 · Why's THE Design?" https://draveness.me/whys-the-design-unstable-infrastructure

[^5]: Eduardo Pinheiro, Wolf-Dietrich Weber and Luiz Andre Barroso. Feb, 2007. "Failure Trends in a Large Disk Drive Population" https://static.googleusercontent.com/media/research.google.com/en//archive/disk_failures.pdf

[^6]: Wikipedia: Silent Data corruption https://en.wikipedia.org/wiki/Data_corruption#Silent

[^7]: Wikipedia: RAID https://en.wikipedia.org/wiki/RAID

[^8]: Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung. Oct, 2003. "The Google File System" https://static.googleusercontent.com/media/research.google.com/en//archive/gfs-sosp2003.pdf

[^9]: Cheng Huang. Jun, 2012. "Erasure Coding in Windows Azure Storage" https://www.cs.princeton.edu/courses/archive/spring13/cos598C/atc12-final181.pdf

[^10]: write(2) - Linux man page https://linux.die.net/man/2/write

[^11]: John Madieu. "The flusher threads" https://www.oreilly.com/library/view/linux-device-drivers/9781785280009/457ca621-7f40-431f-b8f4-2a9ae03201de.xhtml

[^12]: Difference between fflush and fsync https://stackoverflow.com/questions/2340610/difference-between-fflush-and-fsync