磁盘I/O那些事
計算機硬件性能在過去十年間的發展普遍遵循摩爾定律，通用計算機的CPU主頻早已超過3GHz，內存也進入了普及DDR4的時代。然而傳統硬盤雖然在存儲容量上增長迅速，但是在讀寫性能上并無明顯提升，同時SSD硬盤價格高昂，不能在短時間內完全替代傳統硬盤。傳統磁盤的I/O讀寫速度成為了計算機系統性能提高的瓶頸，制約了計算機整體性能的發展。
硬盤性能的制約因素是什么？如何根據磁盤I/O特性來進行系統設計？針對這些問題，本文將介紹硬盤的物理結構和性能指標，以及操作系統針對磁盤性能所做的優化，最后討論下基于磁盤I/O特性設計的技巧。
硬盤內部主要部件為磁盤盤片、傳動手臂、讀寫磁頭和主軸馬達。實際數據都是寫在盤片上，讀寫主要是通過傳動手臂上的讀寫磁頭來完成。實際運行時，主軸讓磁盤盤片轉動，然后傳動手臂可伸展讓讀取頭在盤片上進行讀寫操作。磁盤物理結構如下圖所示：
由于單一盤片容量有限，一般硬盤都有兩張以上的盤片，每個盤片有兩面，都可記錄信息，所以一張盤片對應著兩個磁頭。盤片被分為許多扇形的區域，每個區域叫一個扇區，硬盤中每個扇區的大小固定為512字節。盤片表面上以盤片中心為圓心，不同半徑的同心圓稱為磁道，不同盤片相同半徑的磁道所組成的圓柱稱為柱面。磁道與柱面都是表示不同半徑的圓，在許多場合，磁道和柱面可以互換使用。磁盤盤片垂直視角如下圖所示：
早期的硬盤每磁道扇區數相同，此時由磁盤基本參數可以計算出硬盤的容量：存儲容量=磁頭數*磁道（柱面）數*每道扇區數*每扇區字節數。由于每磁道扇區數相同，外圈磁道半徑大，里圈磁道半徑小，外圈和里圈扇區面積自然會不一樣。同時，為了更好的讀取數據，即使外圈扇區面積再大也只能和內圈扇區一樣存放相同的字節數（512字節）。這樣一來，外圈的記錄密度就要比內圈小，會浪費大量的存儲空間。
如今的硬盤都使用ZBR（Zoned Bit Recording，區位記錄）技術，盤片表面由里向外劃分為數個區域，不同區域的磁道扇區數目不同，同一區域內各磁道扇區數相同，盤片外圈區域磁道長扇區數目較多，內圈區域磁道短扇區數目較少，大體實現了等密度，從而獲得了更多的存儲空間。此時，由于每磁道扇區數各不相同，所以傳統的容量計算公式就不再適用。實際上如今的硬盤大多使用LBA（Logical Block Addressing）邏輯塊尋址模式，知道LBA后即可計算出硬盤容量。
影響磁盤的關鍵因素是磁盤服務時間，即磁盤完成一個I/O請求所花費的時間，它由尋道時間、旋轉延遲和數據傳輸時間三部分構成。
1. 尋道時間
Tseek是指將讀寫磁頭移動至正確的磁道上所需要的時間。尋道時間越短，I/O操作越快，目前磁盤的平均尋道時間一般在3-15ms。
2. 旋轉延遲
Trotation是指盤片旋轉將請求數據所在的扇區移動到讀寫磁盤下方所需要的時間。旋轉延遲取決于磁盤轉速，通常用磁盤旋轉一周所需時間的1/2表示。比如：7200rpm的磁盤平均旋轉延遲大約為60*1000/7200/2 = 4.17ms，而轉速為15000rpm的磁盤其平均旋轉延遲為2ms。
3. 數據傳輸時間
Ttransfer是指完成傳輸所請求的數據所需要的時間，它取決于數據傳輸率，其值等于數據大小除以數據傳輸率。目前IDE/ATA能達到133MB/s，SATA II可達到300MB/s的接口數據傳輸率，數據傳輸時間通常遠小于前兩部分消耗時間。簡單計算時可忽略。
機械硬盤的連續讀寫性能很好，但隨機讀寫性能很差，這主要是因為磁頭移動到正確的磁道上需要時間，隨機讀寫時，磁頭需要不停的移動，時間都浪費在了磁頭尋址上，所以性能不高。衡量磁盤的重要主要指標是IOPS和吞吐量。
1. IOPS
IOPS（Input/Output Per Second）即每秒的輸入輸出量（或讀寫次數），即指每秒內系統能處理的I/O請求數量。隨機讀寫頻繁的應用，如小文件存儲等，關注隨機讀寫性能，IOPS是關鍵衡量指標。可以推算出磁盤的IOPS = 1000ms / (Tseek + Trotation + Transfer)，如果忽略數據傳輸時間，理論上可以計算出隨機讀寫最大的IOPS。常見磁盤的隨機讀寫最大IOPS為： - 7200rpm的磁盤 IOPS = 76 IOPS - 10000rpm的磁盤IOPS = 111 IOPS - 15000rpm的磁盤IOPS = 166 IOPS
2. 吞吐量
吞吐量（Throughput），指單位時間內可以成功傳輸的數據數量。順序讀寫頻繁的應用，如視頻點播，關注連續讀寫性能、數據吞吐量是關鍵衡量指標。它主要取決于磁盤陣列的架構，通道的大小以及磁盤的個數。不同的磁盤陣列存在不同的架構，但他們都有自己的內部帶寬，一般情況下，內部帶寬都設計足夠充足，不會存在瓶頸。磁盤陣列與服務器之間的數據通道對吞吐量影響很大，比如一個2Gbps的光纖通道，其所能支撐的最大流量僅為250MB/s。最后，當前面的瓶頸都不再存在時，硬盤越多的情況下吞吐量越大。
雖然15000rpm的磁盤計算出的理論最大IOPS僅為166，但在實際運行環境中，實際磁盤的IOPS往往能夠突破200甚至更高。這其實就是在系統調用過程中，操作系統進行了一系列的優化。
那么操作系統是如何操作硬盤的呢？類似于網絡的分層結構，下圖顯示了Linux系統中對于磁盤的一次讀請求在核心空間中所要經歷的層次模型。從圖中看出：對于磁盤的一次讀請求，首先經過虛擬文件系統層（VFS Layer），其次是具體的文件系統層（例如Ext2），接下來是Cache層（Page Cache Layer）、通用塊層（Generic Block Layer）、I/O調度層（I/O Scheduler Layer）、塊設備驅動層（Block Device Driver Layer），最后是物理塊設備層（Block Device Layer）。
虛擬文件系統層（VFS Layer）
VFS（Virtual File System）虛擬文件系統是一種軟件機制，更確切的說扮演著文件系統管理者的角色，與它相關的數據結構只存在于物理內存當中。它的作用是：屏蔽下層具體文件系統操作的差異，為上層的操作提供一個統一的接口。正是因為有了這個層次，Linux中允許眾多不同的文件系統共存并且對文件的操作可以跨文件系統而執行。
VFS中包含著向物理文件系統轉換的一系列數據結構，如VFS超級塊、VFS的Inode、各種操作函數的轉換入口等。Linux中VFS依靠四個主要的數據結構來描述其結構信息，分別為超級塊、索引結點、目錄項和文件對象。
超級塊（Super Block）：超級塊對象表示一個文件系統。它存儲一個已安裝的文件系統的控制信息，包括文件系統名稱（比如Ext2）、文件系統的大小和狀態、塊設備的引用和元數據信息（比如空閑列表等等）。VFS超級塊存在于內存中，它在文件系統安裝時建立，并且在文件系統卸載時自動刪除。同時需要注意的是對于每個具體的文件系統來說，也有各自的超級塊，它們存放于磁盤。
索引結點（Inode）：索引結點對象存儲了文件的相關元數據信息，例如：文件大小、設備標識符、用戶標識符、用戶組標識符等等。Inode分為兩種：一種是VFS的Inode，一種是具體文件系統的Inode。前者在內存中，后者在磁盤中。所以每次其實是將磁盤中的Inode調進填充內存中的Inode，這樣才是算使用了磁盤文件Inode。當創建一個文件的時候，就給文件分配了一個Inode。一個Inode只對應一個實際文件，一個文件也會只有一個Inode。
目錄項（Dentry）：引入目錄項對象的概念主要是出于方便查找文件的目的。不同于前面的兩個對象，目錄項對象沒有對應的磁盤數據結構，只存在于內存中。一個路徑的各個組成部分，不管是目錄還是普通的文件，都是一個目錄項對象。如，在路徑/home/source/test.java中，目錄 /, home, source和文件 test.java都對應一個目錄項對象。VFS在查找的時候，根據一層一層的目錄項找到對應的每個目錄項的Inode，那么沿著目錄項進行操作就可以找到最終的文件。
文件對象（File）：文件對象描述的是進程已經打開的文件。因為一個文件可以被多個進程打開，所以一個文件可以存在多個文件對象。一個文件對應的文件對象可能不是惟一的，但是其對應的索引節點和目錄項對象肯定是惟一的。
Ext2文件系統
VFS的下一層即是具體的文件系統，本節簡要介紹下Linux的Ext2文件系統。
一個文件系統一般使用塊設備上一個獨立的邏輯分區。對于Ext2文件系統來說，硬盤分區首先被劃分為一個個的Block，一個Ext2文件系統上的每個Block都是一樣大小的。但是不同Ext2文件系統，Block大小可能不同，這是在創建Ext2系統決定的，一般為1k或者4k。由于Block數量很多，為了方便管理，Ext2將這些Block聚集在一起分為幾個大的塊組（Block Group），每個塊組包含的等量的物理塊，在塊組的數據塊中存儲文件或目錄。Ext2文件系統存儲結構如下圖所示：
Ext2中的Super Block和Inode Table分別對應VFS中的超級塊和索引結點，存放在磁盤。每個塊組都有一個塊組描述符GDT（Group Descriptor Table），存儲一個塊組的描述信息，例如在這個塊組中從哪里開始是Inode表，從哪里開始是數據塊等等。Block Bitmap和Inode Bitmap分別表示Block和Inode是否空閑可用。Data Block數據塊是用來真正存儲文件內容數據的地方，下面我們看一下具體的存儲規則。
在Ext2文件系統中所支持的Block大小有1K、2K、4K三種。在格式化時Block的大小就固定了，且每個Block都有編號，方便Inode的記錄。每個Block內最多只能夠放置一個文件的數據，如果文件大于Block的大小，則一個文件會占用多個Block；如果文件小于Block，則該Block的剩余容量就不能夠再被使用了，即磁盤空間會浪費。下面看看Inode和Block的對應關系。
Inode要記錄的數據非常多，但大小僅為固定的128字節，同時記錄一個Block號碼就需要4字節，假設一個文件有400MB且每個Block為4K時，那么至少也要十萬筆Block號碼的記錄。Inode不可能有這么多的記錄信息，因此Ext2將Inode記錄Block號碼的區域定義為12個直接、一個間接、一個雙間接與一個三間接記錄區。Inode存儲結構如下圖所示：
最左邊為Inode本身（128 bytes），里面有12個直接指向Block號碼的對照，這12筆記錄能夠直接取得Block號碼。至于所謂的間接就是再拿一個Block來當作記錄Block號碼的記錄區，如果文件太大時，就會使用間接的Block來記錄編號。如上圖當中間接只是拿一個Block來記錄額外的號碼而已。 同理，如果文件持續長大，那么就會利用所謂的雙間接，第一個Block僅再指出下一個記錄編號的Block在哪里，實際記錄的在第二個Block當中。依此類推，三間接就是利用第三層Block來記錄編號。
Page Cache層
引入Cache層的目的是為了提高Linux操作系統對磁盤訪問的性能。Cache層在內存中緩存了磁盤上的部分數據。當數據的請求到達時，如果在Cache中存在該數據且是最新的，則直接將數據傳遞給用戶程序，免除了對底層磁盤的操作，提高了性能。Cache層也正是磁盤IOPS為什么能突破200的主要原因之一。
在Linux的實現中，文件Cache分為兩個層面，一是Page Cache，另一個Buffer Cache，每一個Page Cache包含若干Buffer Cache。Page Cache主要用來作為文件系統上的文件數據的緩存來用，尤其是針對當進程對文件有read/write操作的時候。Buffer Cache則主要是設計用來在系統對塊設備進行讀寫的時候，對塊進行數據緩存的系統來使用。
磁盤Cache有兩大功能：預讀和回寫。預讀其實就是利用了局部性原理，具體過程是：對于每個文件的第一個讀請求，系統讀入所請求的頁面并讀入緊隨其后的少數幾個頁面（通常是三個頁面），這時的預讀稱為同步預讀。對于第二次讀請求，如果所讀頁面不在Cache中，即不在前次預讀的頁中，則表明文件訪問不是順序訪問，系統繼續采用同步預讀；如果所讀頁面在Cache中，則表明前次預讀命中，操作系統把預讀頁的大小擴大一倍，此時預讀過程是異步的，應用程序可以不等預讀完成即可返回，只要后臺慢慢讀頁面即可，這時的預讀稱為異步預讀。任何接下來的讀請求都會處于兩種情況之一：第一種情況是所請求的頁面處于預讀的頁面中，這時繼續進行異步預讀；第二種情況是所請求的頁面處于預讀頁面之外，這時系統就要進行同步預讀。
回寫是通過暫時將數據存在Cache里，然后統一異步寫到磁盤中。通過這種異步的數據I/O模式解決了程序中的計算速度和數據存儲速度不匹配的鴻溝，減少了訪問底層存儲介質的次數，使存儲系統的性能大大提高。Linux 2.6.32內核之前，采用pdflush機制來將臟頁真正寫到磁盤中，什么時候開始回寫呢？下面兩種情況下，臟頁會被寫回到磁盤：
回寫開始后，pdflush會持續寫數據，直到滿足以下兩個條件：
Linux 2.6.32內核之后，放棄了原有的pdflush機制，改成了bdi_writeback機制。bdi_writeback機制主要解決了原有fdflush機制存在的一個問題：在多磁盤的系統中，pdflush管理了所有磁盤的Cache，從而導致一定程度的I/O瓶頸。bdi_writeback機制為每個磁盤都創建了一個線程，專門負責這個磁盤的Page Cache的刷新工作，從而實現了每個磁盤的數據刷新在線程級的分離，提高了I/O性能。
回寫機制存在的問題是回寫不及時引發數據丟失（可由sync|fsync解決），回寫期間讀I/O性能很差。
通用塊層
通用塊層的主要工作是：接收上層發出的磁盤請求，并最終發出I/O請求。該層隱藏了底層硬件塊設備的特性，為塊設備提供了一個通用的抽象視圖。
對于VFS和具體的文件系統來說，塊（Block）是基本的數據傳輸單元，當內核訪問文件的數據時，它首先從磁盤上讀取一個塊。但是對于磁盤來說，扇區是最小的可尋址單元，塊設備無法對比它還小的單元進行尋址和操作。由于扇區是磁盤的最小可尋址單元，所以塊不能比扇區還小，只能整數倍于扇區大小，即一個塊對應磁盤上的一個或多個扇區。一般來說，塊大小是2的整數倍，而且由于Page Cache層的最小單元是頁（Page），所以塊大小不能超過一頁的長度。
大多情況下，數據的傳輸通過DMA方式。舊的磁盤控制器，僅僅支持簡單的DMA操作：每次數據傳輸，只能傳輸磁盤上相鄰的扇區，即數據在內存中也是連續的。這是因為如果傳輸非連續的扇區，會導致磁盤花費更多的時間在尋址操作上。而現在的磁盤控制器支持“分散/聚合”DMA操作，這種模式下，數據傳輸可以在多個非連續的內存區域中進行。為了利用“分散/聚合”DMA操作，塊設備驅動必須能處理被稱為段（segments）的數據單元。一個段就是一個內存頁面或一個頁面的部分，它包含磁盤上相鄰扇區的數據。
通用塊層是粘合所有上層和底層的部分，一個頁的磁盤數據布局如下圖所示：
I/O調度層
I/O調度層的功能是管理塊設備的請求隊列。即接收通用塊層發出的I/O請求，緩存請求并試圖合并相鄰的請求。并根據設置好的調度算法，回調驅動層提供的請求處理函數，以處理具體的I/O請求。
如果簡單地以內核產生請求的次序直接將請求發給塊設備的話，那么塊設備性能肯定讓人難以接受，因為磁盤尋址是整個計算機中最慢的操作之一。為了優化尋址操作，內核不會一旦接收到I/O請求后，就按照請求的次序發起塊I/O請求。為此Linux實現了幾種I/O調度算法，算法基本思想就是通過合并和排序I/O請求隊列中的請求，以此大大降低所需的磁盤尋道時間，從而提高整體I/O性能。
常見的I/O調度算法包括Noop調度算法（No Operation）、CFQ（完全公正排隊I/O調度算法）、DeadLine（截止時間調度算法）、AS預測調度算法等。
Noop算法：最簡單的I/O調度算法。該算法僅適當合并用戶請求，并不排序請求。新的請求通常被插在調度隊列的開頭或末尾，下一個要處理的請求總是隊列中的第一個請求。這種算法是為不需要尋道的塊設備設計的，如SSD。因為其他三個算法的優化是基于縮短尋道時間的，而SSD硬盤沒有所謂的尋道時間且I/O響應時間非常短。
CFQ算法：算法的主要目標是在觸發I/O請求的所有進程中確保磁盤I/O帶寬的公平分配。算法使用許多個排序隊列，存放了不同進程發出的請求。通過散列將同一個進程發出的請求插入同一個隊列中。采用輪詢方式掃描隊列，從第一個非空隊列開始，依次調度不同隊列中特定個數（公平）的請求，然后將這些請求移動到調度隊列的末尾。
Deadline算法：算法引入了兩個排隊隊列分別包含讀請求和寫請求，兩個最后期限隊列包含相同的讀和寫請求。本質就是一個超時定時器，當請求被傳給電梯算法時開始計時。一旦最后期限隊列中的超時時間已到，就想請求移至調度隊列末尾。Deadline算法避免了電梯調度策略（為了減少尋道時間，會優先處理與上一個請求相近的請求）帶來的對某個請求忽略很長一段時間的可能。
AS算法：AS算法本質上依據局部性原理，預測進程發出的讀請求與剛被調度的請求在磁盤上可能是“近鄰”。算法統計每個進程I/O操作信息，當剛剛調度了由某個進程的一個讀請求之后，算法馬上檢查排序隊列中的下一個請求是否來自同一個進程。如果是，立即調度下一個請求。否則，查看關于該進程的統計信息，如果確定進程p可能很快發出另一個讀請求，那么就延遲一小段時間。
前文中計算出的IOPS是理論上的隨機讀寫的最大IOPS，在隨機讀寫中，每次I/O操作的尋址和旋轉延時都不能忽略不計，有了這兩個時間的存在也就限制了IOPS的大小。現在如果我們考慮在讀取一個很大的存儲連續分布在磁盤的文件，因為文件的存儲的分布是連續的，磁頭在完成一個讀I/O操作之后，不需要重新尋址，也不需要旋轉延時，在這種情況下我們能到一個很大的IOPS值。這時由于不再考慮尋址和旋轉延時，則性能瓶頸僅是數據傳輸時延，假設數據傳輸時延為0.4ms，那么IOPS=1000 / 0.4 = 2500 IOPS。
在許多的開源框架如Kafka、HBase中，都通過追加寫的方式來盡可能的將隨機I/O轉換為順序I/O，以此來降低尋址時間和旋轉延時，從而最大限度的提高IOPS。
塊設備驅動層
驅動層中的驅動程序對應具體的物理塊設備。它從上層中取出I/O請求，并根據該I/O請求中指定的信息，通過向具體塊設備的設備控制器發送命令的方式，來操縱設備傳輸數據。這里不再贅述。
在上一節中我們了解了Linux系統中請求到達磁盤的一次完整過程，期間Linux通過Cache以及排序合并I/O請求來提高系統的性能。其本質就是由于磁盤隨機讀寫慢、順序讀寫快。本節針對常見開源系統闡述一些基于磁盤I/O特性的設計技巧。
采用追加寫
在進行系統設計時，良好的讀性能和寫性能往往不可兼得。在許多常見的開源系統中都是優先在保證寫性能的前提下來優化讀性能。那么如何設計能讓一個系統擁有良好的寫性能呢？一個好的辦法就是采用追加寫，每次將數據添加到文件。由于完全是順序的，所以可以具有非常好的寫操作性能。但是這種方式也存在一些缺點：從文件中讀一些數據時將會需要更多的時間：需要倒序掃描，直到找到所需要的內容。當然在一些簡單的場景下也能夠保證讀操作的性能：
數據是被整體訪問，比如HDFS
- HDFS建立在一次寫多次讀的模型之上。在HDFS中就是采用了追加寫并且設計為高數據吞吐量；高吞吐量必然以高延遲為代價，所以HDFS并不適用于對數據訪問要求低延遲的場景；由于采用是的追加寫，也并不適用于任意修改文件的場景。HDFS設計為流式訪問大文件，使用大數據塊并且采用流式數據訪問來保證數據被整體訪問，同時最小化硬盤的尋址開銷，只需要一次尋址即可，這時尋址時間相比于傳輸時延可忽略，從而也擁有良好的讀性能。HDFS不適合存儲小文件，原因之一是由于NameNode內存不足問題，還有就是因為訪問大量小文件需要執行大量的尋址操作，并且需要不斷的從一個datanode跳到另一個datanode，這樣會大大降低數據訪問性能。
知道文件明確的偏移量，比如Kafka
- 在Kafka中，采用消息追加的方式來寫入每個消息，每個消息讀寫時都會利用Page Cache的預讀和后寫特性，同時partition中都使用順序讀寫，以此來提高I/O性能。雖然Kafka能夠根據偏移量查找到具體的某個消息，但是查找過程是順序查找，因此如果數據很大的話，查找效率就很低。所以Kafka中采用了分段和索引的方式來解決查找效率問題。Kafka把一個patition大文件又分成了多個小文件段，每個小文件段以偏移量命名，通過多個小文件段，不僅可以使用二分搜索法很快定位消息，同時也容易定期清除或刪除已經消費完的文件，減少磁盤占用。為了進一步提高查找效率，Kafka為每個分段后的數據建立了索引文件，并通過索引文件稀疏存儲來降低元數據占用大小。一個段中數據對應結構如下圖所示：
在面對更復雜的讀場景（比如按key）時，如何來保證讀操作的性能呢？簡單的方式是像Kafka那樣，將文件數據有序保存，使用二分查找來優化效率；或者通過建索引的方式來進行優化；也可以采用hash的方式將數據分割為不同的桶。以上的方法都能增加讀操作的性能，但是由于在數據上強加了數據結構，又會降低寫操作的性能。比如如果采用索引的方式來優化讀操作，那么在更新索引時就需要更新B-tree中的特定部分，這時候的寫操作就是隨機寫。那么有沒有一種辦法在保證寫性能不損失的同時也提供較好的讀性能呢？一個好的選擇就是使用LSM-tree。LSM-tree與B-tree相比，LSM-tree犧牲了部分讀操作，以此大幅提高寫性能。
- 日志結構的合并樹LSM（The Log-Structured Merge-Tree）是HBase，LevelDB等NoSQL數據庫的存儲引擎。Log-Structured的思想是將整個磁盤看做一個日志，在日志中存放永久性數據及其索引，每次都添加到日志的末尾。并且通過將很多小文件的存取轉換為連續的大批量傳輸，使得對于文件系統的大多數存取都是順序的，從而提高磁盤I/O。LSM-tree就是這樣一種采用追加寫、數據有序以及將隨機I/O轉換為順序I/O的延遲更新，批量寫入硬盤的數據結構。LSM-tree將數據的修改增量先保存在內存中，達到指定的大小限制后再將這些修改操作批量寫入磁盤。因此比較舊的文件不會被更新，重復的紀錄只會通過創建新的紀錄來覆蓋，這也就產生了一些冗余的數據。所以系統會周期性的合并一些數據，移除重復的更新或者刪除紀錄，同時也會刪除上述的冗余。在進行讀操作時，如果內存中沒有找到相應的key，那么就是倒序從一個個磁盤文件中查找。如果文件越來越多那么讀性能就會越來越低，目前的解決方案是采用頁緩存來減少查詢次數，周期合并文件也有助于提高讀性能。在文件越來越多時，可通過布隆過濾器來避免大量的讀文件操作。LSM-tree犧牲了部分讀性能，以此來換取寫入的最大化性能，特別適用于讀需求低，會產生大量插入操作的應用環境。
文件合并和元數據優化
目前的大多數文件系統，如XFS/Ext4、GFS、HDFS，在元數據管理、緩存管理等實現策略上都側重大文件。上述基于磁盤I/O特性設計的系統都有一個共性特點就是都運行在這些文件系統之上。這些文件系統在面臨海量時在性能和存儲效率方面都大幅降低，本節來探討下海量小文件下的系統設計。
常見文件系統在海量小文件應用下性能表現不佳的根本原因是磁盤最適合順序的大文件I/O讀寫模式，而非常不適合隨機的小文件I/O讀寫模式。主要原因體現在元數據管理低效和數據布局低效：
元數據管理低效：由于小文件數據內容較少，因此元數據的訪問性能對小文件訪問性能影響巨大。Ext2文件系統中Inode和Data Block分別保存在不同的物理位置上，一次讀操作需要至少經過兩次的獨立訪問。在海量小文件應用下，Inode的頻繁訪問，使得原本的并發訪問轉變為了海量的隨機訪問，大大降低了性能。另外，大量的小文件會快速耗盡Inode資源，導致磁盤盡管有大量Data Block剩余也無法存儲文件，會浪費磁盤空間。
數據布局低效：Ext2在Inode中使用多級指針來索引數據塊。對于大文件，數據塊的分配會盡量連續，這樣會具有比較好的空間局部性。但是對于小文件，數據塊可能零散分布在磁盤上的不同位置，并且會造成大量的磁盤碎片，不僅造成訪問性能下降，還大量浪費了磁盤空間。數據塊一般為1KB、2KB或4KB，對于小于4KB的小文件，Inode與數據的分開存儲破壞了空間局部性，同時也造成了大量的隨機I/O。
對于海量小文件應用，常見的I/O流程復雜也是造成磁盤性能不佳的原因。對于小文件，磁盤的讀寫所占用的時間較少，而用于文件的open()操作占用了絕大部分系統時間，導致磁盤有效服務時間非常低，磁盤性能低下。針對于問題的根源，優化的思路大體上分為：
小文件合并 小文件合并為大文件后，首先減少了大量元數據，提高了元數據的檢索和查詢效率，降低了文件讀寫的I/O操作延時。其次將可能連續訪問的小文件一同合并存儲，增加了文件之間的局部性，將原本小文件間的隨機訪問變為了順序訪問，大大提高了性能。同時，合并存儲能夠有效的減少小文件存儲時所產生的磁盤碎片問題，提高了磁盤的利用率。最后，合并之后小文件的訪問流程也有了很大的變化，由原來許多的open操作轉變為了seek操作，定位到大文件具體的位置即可。如何尋址這個大文件中的小文件呢？其實就是利用一個旁路數據庫來記錄每個小文件在這個大文件中的偏移量和長度等信息。其實小文件合并的策略本質上就是通過分層的思想來存儲元數據。中控節點存儲一級元數據，也就是大文件與底層塊的對應關系；數據節點存放二級元數據，也就是最終的用戶文件在這些一級大塊中的存儲位置對應關系，經過兩級尋址來讀寫數據。
- 淘寶的TFS就采用了小文件合并存儲的策略。TFS中默認Block大小為64M，每個塊中會存儲許多不同的小文件，但是這個塊只占用一個Inode。假設一個Block為64M，數量級為1PB。那么NameServer上會有 1 * 1024 * 1024 * 1024 / 64 = 16.7M個Block。假設每個Block的元數據大小為0.1K，則占用內存不到2G。在TFS中，文件名中包含了Block ID和File ID，通過Block ID定位到具體的DataServer上，然后DataServer會根據本地記錄的信息來得到File ID所在Block的偏移量，從而讀取到正確的文件內容。TFS一次讀過程如下圖所示：
元數據管理優化 一般來說元數據信息包括名稱、文件大小、設備標識符、用戶標識符、用戶組標識符等等，在小文件系統中可以對元數據信息進行精簡，僅保存足夠的信息即可。元數據精簡可以減少元數據通信延時，同時相同容量的Cache能存儲更多的元數據，從而提高元數據使用效率。另外可以在文件名中就包含元數據信息，從而減少一個元數據的查詢操作。最后針對特別小的一些文件，可以采取元數據和數據并存的策略，將數據直接存儲在元數據之中，通過減少一次尋址操作從而大大提高性能。
- TFS中文件命名就隱含了位置信息等部分元數據，從而減少了一個元數據的查詢操作。在Rerserfs中，對于小于1KB的小文件，Rerserfs可以將數據直接存儲在Inode中。
本文從磁盤性能指標出發，探究了操作系統與磁盤的交互以及對磁盤讀寫的優化，最后列舉了一些常用開源系統中基于磁盤I/O特性的設計特點。期望通過展現磁盤I/O的特性，為存儲系統設計和解決一些系統性能問題提供一種新思路。
喻梟，2016年加入美團，就職于美團酒店旅游事業群境內度假研發組。專注Java后臺開發，對并發編程和大數據有濃厚興趣。
最后發個廣告，美團酒旅事業群境內度假研發組長期招聘Java后臺、架構方面的人才，有興趣的同學可以發送簡歷到jinmengzhe#meituan.com。
總結
- 上一篇： 机器学习从理论到工程的第二步-开发环境与
- 下一篇： 线性代数应该这样讲（二）