1樓：宋志強
不同級別的cache作用是不一樣的,作業系統級別的cache主要是為作業系統層提供服務的,使作業系統更高效地工作,cpu級別的快取是為讓運算更高效地執行,應用層的快取是為了讓應用更高效的執行.舉個列子,HBase的L1 Cache只儲存index級別的block,也就是只儲存索引資料,而不是把全部資料都儲存下來,這裡的需求是只需要儲存索引資料就能讓應用更高效的執行,而這種場景下作業系統級別的快取就不太適用了(因為索引資料和原始資料在同一檔案,以及對索引的粒度需求不匹配HBase場景).當然如果的索引在乙個檔案裡面,儲存這個檔案實際就能儲存索引,這種情況就可以利用作業系統的快取了,ElasticSearch就是這樣做的.
不同的場景下有不同的需求,不同的需求就會產生不同的Cache,舉個列子:使用HBase scan資料首先會走HBase的客戶端Cache,然後走HBase服務端的L1 Cache,然後走HDFS的客戶端Cache,然後走HDFS的服務端塊Cache(預設是沒有開啟的),然後是作業系統的Page Cache
2樓：bbhbbh
跟pagecache位址不夠用，大小不夠用沒有關係，索引查詢到的是虛擬位址或者是queue data都可以，根據虛擬位址讀pagecache快取或者沒有找到實體地址去讀磁碟，再更新頁表和更新pagecache，這是乙個pagecache快取查詢的正常流程。
重點是這樣的非聚集快取(索引存在使用者記憶體，資料在pagecache上)去讀它時會發起系統呼叫，引起使用者態到核心態轉化。
而且pagecache只能以虛擬位址構建索引，無法利用業務邏輯建立起k-v快取，還隨時有可能被被覆蓋和被pdflush髒頁回寫
3樓：
簡單說，OS提供了乙個通用的選擇，沒辦法針對應用做個性化定製。
kafka基本是順序讀寫，這點是OS快取可以很好的處理的情況；但是對於更多應用層系統來說，存在資料熱點分布不均的情況，這些OS就不能很好的處理了。
例如MySQL的innoDB快取，如果採用OS的快取策略，來一次全表掃瞄那麼就可以讓InnoDB辛辛苦苦熱起來的資料冷了。
但是InnoDB自己維護快取情況下，就可以處理得很好，例如MySQL的InnoDB會對緩衝資料拆分為young以及old資料；會在整個快取空間中騰出3/8的資料來用快取這種多次訪問的熱點資料；這樣全表掃瞄情況下，至少大多數熱點資料還在記憶體中。
甚至應用層可以在程式中直接指定熱點資料，直接快取起來；還有乙個問題，OS快取單位是頁，不夠應用層靈活。
MySQL :: MySQL 5.5 Reference Manual :: 8.9.1 The InnoDB Buffer Pool
既然開發國產作業系統最大的弊端是應用生態，那為何不開發一款能直接執行exe程式的作業系統？
生態確實是個難點，但是，開發乙個達到商用水準的作業系統本身就是個難點，中國產作業系統可沒做過這個級別的事情。現有的中國產作業系統都是基於Linux，而且往往還是基於別人做好的Linux發行版。像deepin這樣做個桌面環境的已經算工程量大的了。而如果要相容exe，無論是寫乙個相容exe的作業系統或者...
既然華為有能力自研手機作業系統，為什麼不自研電腦作業系統
曼特奧克傑 你把手機設定可旋轉橫著放桌上，再加個鍵盤滑鼠，插上一對音箱，不就是電腦作業系統了？現在很多軟體都可以互通了。不互通的不是因為難，都是為了賺錢。蘋果兩個系統不整合怕扯到蛋。實際上微軟已經整合，可惜手機沒人買。谷歌就沒必要開歷史倒車了。電腦就是跑分更高的巨型手機而已 因為不賺錢。電腦已經是夕...
為什麼現在的作業系統都沒有提供對農曆的原生支援？
言簡意賅 農曆是天文歷 格里曆 公曆 是計算歷。天文歷需要實測，公曆可以計算。可計算和不可計算，才是計算機的難點。農曆根據精確的實測的此刻，能精確估算以後一少部分，優點是幾乎無誤差，缺點是無固定規律，不能推算很遠，需要經常地測量天文。公曆算出了幾百年的平均值，估算以後很遠的平均值，優點有規律可循便於...