|
轉(zhuǎn)載請說明出處：http://blog.csdn.net/cywosp/article/details/23970017
在分布式文件系統(tǒng)中，為了提高系統(tǒng)的性能，常常會引入不同類型的緩存存儲系統(tǒng)（算法優(yōu)化所帶來的的效果可能遠遠不如緩存帶來的優(yōu)化效果）。在軟件中緩存存儲系統(tǒng)一般可分為了兩類：一、分布式緩存，例如：Memcached、Redis、淘寶的Tair等，二、本地緩存，例如：Facebook的flushcache等，其中本地緩存又可以分為兩種：本地磁盤緩存（現(xiàn)在一般都采用讀寫性能比較優(yōu)異的SSD來做存儲）和本地內(nèi)存緩存。在系統(tǒng)中，為了提高緩存存儲系統(tǒng)的性能以及熱點數(shù)據(jù)的命中率，一般在本地磁盤緩存中也會引入內(nèi)存緩存用于存儲經(jīng)常訪問的數(shù)據(jù)。有時為了減少客戶端對服務(wù)器的請求，也會在客戶端上使用緩存，當(dāng)然這是要考慮安全問題的。在這里，本文主要討論分布式文件系統(tǒng)下的本地磁盤緩存。
1. 本地磁盤緩存與操作系統(tǒng)的關(guān)系
根據(jù)操作系統(tǒng)對硬件的管理以及文件系統(tǒng)的存儲邏輯，本地磁盤緩存在操作系統(tǒng)中的位置可大概分為一下三種：
 一、處于Storage Controller層，OS與應(yīng)用相互獨立，與硬件相關(guān)聯(lián)，由硬件來做讀寫保護
二、處于Device Driver層，與應(yīng)用獨立，與硬件獨立，需要第三方來完成讀寫保護，處于這一層的本地緩存系統(tǒng)有Facebook的flushcache
三、處于File System層，OS與應(yīng)用相關(guān)聯(lián)，與硬件獨立，需要第三方來完成讀寫保護，這一層的本地緩存是在應(yīng)用中使用最為廣泛的，本文所討論的本地緩存也是基于此層
2. 存儲設(shè)備以及空間
根據(jù)現(xiàn)有的硬件存儲技術(shù)，SSD的隨機讀寫性能以非常優(yōu)異，并且其使用壽命也得到了很好的保證，因此被廣泛的應(yīng)用于數(shù)據(jù)需要持久化存儲和高速讀寫的服務(wù)器中。根據(jù)性價比來考慮，一般的分布式文件系統(tǒng)的服務(wù)器機器中不會放置太大的SSD來做緩存存儲設(shè)備?！?4GB至128GB的SSD是主流。
3. 磁盤緩存系統(tǒng)在分布式文件系統(tǒng)中的地位
緩存系統(tǒng)在整個分布式中以多種形態(tài)存在，常見的有以單獨一個進程運行的方式存在，這種方式類似于C/S模式，需要進程間的通信；另外就是直接寄宿于分布式文件系統(tǒng)的進程中，由分布式文件系統(tǒng)的進程直接調(diào)用緩存的接口來進行數(shù)據(jù)讀寫操作，本文主要討論后一種。
4. 分布式文件系統(tǒng)中，本地磁盤緩存的存儲策略大概有一下所示的三種：
 一、Write Around策略，該策略主要是讀緩存，不直接寫本地磁盤緩存，而是直接將數(shù)據(jù)寫入分布式持久化存儲當(dāng)中，在讀取數(shù)據(jù)時，如果發(fā)現(xiàn)緩存中沒有對應(yīng)的數(shù)據(jù)則向分布式持久化存儲請求，然后再將請求后的數(shù)據(jù)寫入緩存中。優(yōu)點在于沒有一致性問題，數(shù)據(jù)不會丟失，利于數(shù)據(jù)集中讀取。缺點在于，分布式文件系統(tǒng)中直接將數(shù)據(jù)寫入持久化存儲速度會比較慢，對于用戶體驗會有很大的影響。
二、Write Through策略，該策略在讀取數(shù)據(jù)方面與Write Around差不多，但是在數(shù)據(jù)寫入方面有很大的區(qū)別，數(shù)據(jù)在寫入的過程中，寫入本地緩存的同時也將數(shù)據(jù)寫入分布式持久化存儲中。優(yōu)點在于沒有一致性問題，數(shù)據(jù)不會丟失，利于數(shù)據(jù)集中讀取。缺點在于寫入速度將會比較慢，不過這取決于分布式持久化存儲的寫入性能。
三、Write Back策略，該策略主要是讀寫緩存共用，將數(shù)據(jù)先寫到本地緩存中，然后再通過異步的方式將臟數(shù)據(jù)同步到分布式持久化存儲中，在本地讀取數(shù)據(jù)Miss后才向分布式持久化存儲請求，并回寫到本地緩存中。優(yōu)點在于寫入速度快，利于數(shù)據(jù)集中讀取，缺點在于會產(chǎn)生一致性問題以及數(shù)據(jù)可能會丟失。雖然這種策略容會導(dǎo)致數(shù)據(jù)的丟失，但是在不同層次的存儲方案中其是常常被采用個的一種。
5. 存儲數(shù)據(jù)類型
在分布式文件系統(tǒng)中，本地緩存效率極高，數(shù)據(jù)直接存儲于服務(wù)器本地，對數(shù)據(jù)的操作就是對本地文件的操作，但是由于分布式的特征，本地緩存中的數(shù)據(jù)其它節(jié)點無法訪問，那么如果相同的一份數(shù)據(jù)被多臺機器緩存于本地，一旦該數(shù)據(jù)在其中一臺機器中被修改，這就會導(dǎo)致一定數(shù)據(jù)的不一致，因此本地緩存最好只用于存儲靜態(tài)數(shù)據(jù)——一旦寫入就再也不會修改的數(shù)據(jù)，例如文件的數(shù)據(jù)塊內(nèi)容、圖片等等。
6. 索引
根據(jù)項目實踐，在分布式文件系統(tǒng)中數(shù)據(jù)塊的網(wǎng)絡(luò)傳輸占用了絕大多數(shù)的時間，根據(jù)對數(shù)據(jù)隨機訪問概率的統(tǒng)計數(shù)據(jù)來分析，當(dāng)一個文件被連續(xù)多次訪問之后，其在最近一段時間內(nèi)被訪問到的概率非常之高，因此，為了減少對同一文件的網(wǎng)絡(luò)IO，設(shè)計一個高效且符合實際的場景的本地磁盤緩存非常有必要。高效的緩存系統(tǒng)，必然少不了索引，利用索引快速定位對應(yīng)數(shù)據(jù)的文件路徑，然后盡可能的挖掘磁盤的讀寫潛力，讓系統(tǒng)瓶頸落在對磁盤的讀寫上。同時，索引還可以很好的用于控制磁盤當(dāng)前的使用空間；如果采用Write
Back策略，還可以高效計算還未被同步到分布式持久化存儲的存儲大??；對索引的管理還可以提高緩存的命中率，什么樣的數(shù)據(jù)可以被刪除，什么時候刪除等等。
緩存中一般都采用Key-Value的鍵值對形式將數(shù)據(jù)存儲，Key由應(yīng)用傳入為了區(qū)分Value唯一的標(biāo)志，為了能加速查找和減少索引的內(nèi)存占用空間，緩存內(nèi)部會將Key的內(nèi)容進行MD5計算，然后存儲在索引的數(shù)據(jù)結(jié)構(gòu)中；Value的內(nèi)容則以一個文件，或者多個Value存入一個文件中。由于使用SSD作為最后的Value存儲，這里我們就簡單的將每一個Key作為一個文件存儲。另外，為了處理大量的小文件導(dǎo)致文件系統(tǒng)的inode耗盡的問題，可以將小于8KB的數(shù)據(jù)用leveldb來存儲（leveldb對小數(shù)據(jù)的存儲性能非常高）。
索引的組織方式有很多種，常用的有標(biāo)準(zhǔn)庫的map，list，其它效率更高的有紅黑樹、B+樹等等，這些也都是一種索引在內(nèi)存中的存儲和組織方式，其核心還是離不開對Key值的查找比較。在操作系統(tǒng)中，字符串的比較效率往往要低于系統(tǒng)整數(shù)類型，比如對兩個32位MD5字符串的比較需要系統(tǒng)進行32次的比較，如果我們將MD5的值用4個unsigned int或者2個unsigned
long long來存儲的話（這里是在64位操作系統(tǒng)上的），那么直接利用CPU能對整型數(shù)進行計算的特性只需要比較4次或者2次即可，這樣既可以節(jié)省16個字節(jié)的內(nèi)存空間，同時還能加速比較，快速定位。
在索引的內(nèi)存占用方面我們不必太過于擔(dān)心，現(xiàn)在的服務(wù)中一般的內(nèi)存配置都是十幾GB，用1GB的內(nèi)存來存儲索引也不算太坑老板。假如每個索引所占字節(jié)數(shù)為32，那么1024 * 1024 * 1024 / 32 = 33554432個索引，如果每個索引所對應(yīng)內(nèi)容的平均大小為4KB，那么需要的磁盤空間為33554432 * 4KB = 134217728KB
≈ 128GB，128GB的容量正好與第2點中所說的存儲相符。當(dāng)然如果你開發(fā)的分布式文件系統(tǒng)就是用于存儲小文件的，那么這些算法就需要額外考慮了。
7. 緩存的更新
在緩存系統(tǒng)中，由于容量有限，因此，在還有數(shù)據(jù)繼續(xù)寫入的情況下必須刪除一些已存在緩存，騰出空間。在我們已知的常用緩存老化方法中大概有如下幾種：
先進先出（FIFO: First In, First Out）
最近最少使用（LRU: Least Recently Used）
最少使用頻率（LFU: Least Frequently Used）
隨機刪除（Random）
在實際開發(fā)過程中，有時還會采用一些其它的方式，比如，在每個數(shù)據(jù)中加入生命周期的管理——設(shè)置該數(shù)據(jù)在一定時間內(nèi)自動失效并將其刪除，這種方式需要對系統(tǒng)的時間有很精確的要求，系統(tǒng)時間不能隨便被更改。
在分布式系統(tǒng)中，由于緩存會被老化或者刪除，那么就會產(chǎn)生當(dāng)緩存被老化后，某一時刻有同一數(shù)據(jù)被多人從同一臺服務(wù)器中訪問，所有的訪問都會到緩存系統(tǒng)中查找，此時，發(fā)現(xiàn)緩存中數(shù)據(jù)不存在，那么都到分布式持久化存儲中讀取，返回之后，所有請求的操作會將同一份數(shù)據(jù)再回寫到緩存系統(tǒng)中的問題。對于這個問題我暫時還沒有找到什么比較好的處理方法，只能從緩存存儲的數(shù)據(jù)以及業(yè)務(wù)邏輯上處理。像第5點所說的，緩存只用于存儲靜態(tài)數(shù)據(jù)，那樣數(shù)據(jù)就可以覆蓋，而不會產(chǎn)生一致性的問題。
如果在緩存策略中采用了Write Back策略，那么就需要做，在緩存中還未被持久化到分布式持久化存儲的數(shù)據(jù)的特殊處理，這一類數(shù)據(jù)在備份持久化之前不能被內(nèi)部的主動老化策略所刪除。
8. 性能和命中率
在支持多線訪問的緩存系統(tǒng)中，為提高索引的查找性能，避免鎖的高頻率碰撞，一般在設(shè)計索引的組織方式時會采用hash table的方法，使用多個hash桶，根據(jù)對應(yīng)的hash算法來分散索引的存儲，這種方法簡單，易于實現(xiàn)，但其也存在無法動態(tài)添加hash桶的缺點。每個hash桶中放置的是一個LRU鏈表，LRU是緩存系統(tǒng)中最常見的數(shù)據(jù)替換算法，每次淘汰最久沒有被訪問的數(shù)據(jù)。每一個hash桶中只對LRU進行上鎖，這樣就能減少一部分的鎖碰撞。memcached中也才用了hash
table加LRU鏈表來管理內(nèi)存的方法，其高效的管理，使得memcached被廣泛用于網(wǎng)站的緩存中，其內(nèi)存管理示意圖如下：
 memcache以slab方式管理內(nèi)存塊，從系統(tǒng)申請1MB大小的大塊內(nèi)存并劃分為不同大小的chunk，不同slab的chunk大小依次為80字節(jié)，80 * 1.25，80 * 1.25^2, …。向memcache中添加item時，memcache會根據(jù)item的大小選擇合適的chunk。
在項目中，為了權(quán)衡性能和命中率之間的關(guān)系，有時候常常會降低命中率來換取性能。在數(shù)據(jù)老化時可以將LRU的最少使用的前幾個一起老化，減少每次只老化一個就得鎖住當(dāng)前的LRU鏈表的頻率，從而加速索引的查找和寫入，其次是增加hash桶個數(shù)，減少hash沖突，同時也減少了對同一LRU鏈表的操作。
9. 索引的持久化
在Google的好文《Introduction to Distributed System Design》中有闡明關(guān)于分布式的設(shè)計：design for failure。因此，在分布式文件系統(tǒng)中做好故障處理是及其重要有極其困難的，但是做好進程內(nèi)的狀態(tài)保存，當(dāng)程序重啟后能及時恢復(fù)到崩潰前的狀態(tài)還是能夠容易實現(xiàn)的。在緩存系統(tǒng)中，數(shù)據(jù)的索引尤為重要，因此可將其持久化，待程序重新啟動后就可以重建索引。這里建議可以使用google的leveldb來做索引的持久化，其高效的讀寫性能，并不會對系統(tǒng)的性能太大的影響?！@里不考慮機器突然斷電的情況。
總結(jié)
在現(xiàn)在的系統(tǒng)中，緩存無處不在，如果能合理的利用緩存，那么整個系統(tǒng)的性能將會得到大大個提高。那么如何判定一個緩存系統(tǒng)是高效的呢？在實際開發(fā)過程中，我們總結(jié)出：現(xiàn)在開源的緩存項目很多，但是符合自身項目需求的卻寥寥無幾，因此，設(shè)計一個滿足自身業(yè)務(wù)需求的緩存系統(tǒng)時，切記不要過度設(shè)計，簡單且滿足需求，夠用就行。
|
|
|
來自： WindySky > 《 每天進步一點點》
