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

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

database-banner

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

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

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

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

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

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

• 人為因素導致的運維和配置錯誤是數(shù)據(jù)庫丟失數(shù)據(jù)的首要原因；

• 數(shù)據(jù)庫存儲數(shù)據(jù)使用的磁盤損壞導致數(shù)據(jù)丟失；

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

人為錯誤

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

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

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

減少人為錯誤的最好方式是將數(shù)據(jù)的備份和運維等操作標準化，使用自動化的流程處理涉及數(shù)據(jù)安全的操作，這樣才能降低人為干預帶來的風險。

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

硬件錯誤

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

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

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

raid-strategy

圖 2 - RAID 三大策略

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

• RAID 0 使用了數(shù)據(jù)分割技術(shù)，但是沒有鏡像和奇偶校驗。它對磁盤上的數(shù)據(jù)幾乎不進行任何的保護，任意一塊磁盤磁盤損壞都意味著其中的數(shù)據(jù)無法恢復，但是因為不存在冗余，所以它也會提供較好的性能；

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

• ...

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

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

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

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

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

實現(xiàn)復雜

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

database-and-disk

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

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

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

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

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

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

write-and-fsyn

圖 4 - 寫入和落盤

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

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

總結(jié)

數(shù)據(jù)庫管理系統(tǒng)是軟件工程中最復雜、最重要的系統(tǒng)之一，幾乎所有服務的正常運行都建立在數(shù)據(jù)庫不會丟失數(shù)據(jù)的假設(shè)上。然而因為如下所示的原因，數(shù)據(jù)庫不能完全保證數(shù)據(jù)的安全：

• 運維人員在配置和運維時極有可能因為操作失誤導致數(shù)據(jù)丟失；

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

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

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

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

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

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

如果對文章中的內(nèi)容有疑問或者想要了解更多軟件工程上一些設(shè)計決策背后的原因，可以在博客下面留言，作者會及時回復本文相關(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)于客戶“前沿數(shù)控”數(shù)據(jù)完整性受損的技術(shù)復盤 https://mp.weixin.qq.com/s/8JSPY6vHPhg8pX0JwjqttQ

[^4]: Draven. Dec, 2019. "為什么基礎(chǔ)服務不應該高可用 · 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