通過前面的分析已經知道
io排程器主要是為了解決臨近
io合併的問題。磁介質儲存盤最大的效能瓶頸在於尋道。當使用者訪問乙個指定位址時，磁碟首先需要進行尋道操作，找到訪問位址所屬的區域。這種操作往往是毫秒級別的，相對於效能不斷提公升的
cpu而言，這種效能顯然是不可接受的。所以，磁碟最大的問題在於機械操作引入的尋道時間過長，對外表現就是隨機讀寫效能太差了。
為了彌補這種效能弱點，
linux
作業系統系統在設計的時候引入了
io排程器，盡最大可能將隨機讀寫轉換成大塊順序讀寫，減少磁碟抖動，降低若干
io操作之間的尋道時間。
io排程器的目的就在於此，它的初衷是面向儲存介質設計的。因此，當乙個系統的儲存介質發生變化之後，
io排程器就需要改變。例如，針對
ssd儲存介質，傳統意義上的
io排程演算法就不再適用了。
ssd不存在機械操作，不存在漫長的尋道時間問題，因此，不存在傳統磁介質的隨機讀寫問題。但是，
ssd存在寫放大的問題，乙個小寫會引入大量的資料讀寫操作，從而使得
io效能下降。所以，傳統磁碟的
io排程器在
ssd面前就沒有價值了，可以採用最簡單的
noop
排程器對
io進行後向合併就可以了，而寫放大等問題往往都在
ssd內部的
firmware
解決了。
考慮一下，如果設計的
io排程器完全面向儲存介質，那麼設計的排程演算法只需要考慮
io請求的前向
/後向合併就可以了，這樣的
io合併減少了磁頭的抖動，就像一部電梯一樣，一直往乙個方向移動。這種演算法看上去很完美，但是，在實踐中我們會發現有些請求會長時間得不到服務，就像一輛電梯廠時間停在乙個樓層，其他樓層的人長時間得不到服務。特別對於一些讀操作，往往是同步請求，如果長時間得不到服務，那麼會大大影響應用的效能。所以，僅僅簡單的考慮儲存介質的特性，進行
io的前向
/後向合併是不夠的，還需要考慮
io的本身屬性。 從
io的屬性來看，最需要區分的是讀寫請求，讀寫請求的優先順序是不一樣的，大多數寫請求可以非同步完成，讀請求需要同步完成，所以，對於讀寫請求可以分開處理。雖然分開之後可能會引入更多的磁碟抖動，但是，應用的整體效能還是會提高。
考慮了io的基本屬性之外，是不是就夠了呢？其實還是不夠的。例如在乙個伺服器中存在多個應用，這些應用會訪問相同的儲存，有些應用讀請求多，有些應用寫請求多，如果僅僅考慮
io的基本屬性，那麼對於這些不同的應用就會表現出不同的
io效能。有些應用得到較多的
io頻寬，效能較好；有些應用得到較少的頻寬，效能較差。這顯然是不合理的，由於排程演算法的策略問題，導致乙個系統中，不同應用具有不同的
io效能。為了解決這個問題，需要考慮應用屬性。
在現有的
linux
系統中，提供了多種
io排程器，這些排程器有些僅僅考慮了儲存介質屬性（
noop
），有些考慮了
io屬性（
deadline
），還有的考慮了應用屬性（
cfq）。不同排程器的設計考慮範疇不同，所以複雜度也有很大差別。下面會對
linux
中的這幾種排程器進行闡述。
《待續。。。>
乙個IO的傳奇一生（12） 磁碟陣列1
在乙個io的旅程中基本上都會經歷乙個非常重要站點，他就是raid。提起raid，基本上是無人不曉，每個人都能說上一點。例如raid5 raid6之類的概念，此外，raid可以提高資料可靠性，但是考慮到io 效能等問題，很多人都會採用硬體raid卡對io進行加速。諸如此類的東西，或許大家都知道。從表面...
英特爾前任 CEO 安迪 格魯夫的傳奇一生
安迪 格魯夫，前英特爾公司首席執行官,曾經是乙個納粹占領地的青年,是 只有偏執狂才能生存 的管理哲學的靈感，英特爾財政危機的拯救者，已經過世，享年79歲。他是乙個善變的，但有遠見的領導人，他幫助英特爾的微處理器成為了個人電腦內的中心技術。格魯夫賭上整個公司的豪賭 在80年代中期把英特爾的重心從儲存晶...
乙個web請求的一生
之前看過一些這方面的資料，有幾個博主寫的很不錯，但是側重點不太一樣。我從自己的理解把內容總結一下，主要是方便自己記憶和理解。先假設請求的連線是 http localhost 8080 wcc index.jsp 請求從web到容器tomcat 如果是網域名稱訪問，那麼會有乙個尋找對應ip的過程 客戶...