引言
上篇主要是介紹了一些存儲相關(guān)的知識庆聘，還有通過cdn和存儲網(wǎng)關(guān)進行加速的簡單表述泞边。本篇將對存儲網(wǎng)關(guān)的結(jié)構(gòu)锐借，讀算法及相關(guān)算法進行分析整理问麸。
CSG的結(jié)構(gòu)
這里只附上CSG結(jié)構(gòu)的兩張圖，還是要展示一下它的結(jié)構(gòu)的瞎饲，不然說介紹云存儲網(wǎng)關(guān)完全不說他也不合適…
可以從結(jié)構(gòu)中看出：
1）在云網(wǎng)關(guān)中實現(xiàn)了ISCSI協(xié)議口叙，上篇提到過，該協(xié)議支持用IP而不是光纖實現(xiàn)SAN存儲結(jié)構(gòu)嗅战，是網(wǎng)關(guān)和服務(wù)器剝離的前提。
2）很多結(jié)構(gòu)都是完成本地數(shù)據(jù)與云存儲的契合度優(yōu)化，提高了存儲速度驮捍，并發(fā)性疟呐，穩(wěn)定性，云網(wǎng)還能更像是本地和云的一種適配器东且，加速器和優(yōu)化器启具。
3）對部署和配置的優(yōu)化使CSG服務(wù)大大減少了在本地搭建SAN的時間和人力成本。
本篇將對結(jié)構(gòu)中的讀算法進行簡單分析（主講人就只介紹了讀的優(yōu)化…）
CSG的讀優(yōu)化
傳統(tǒng)的數(shù)據(jù)讀方法
1）FIFO
其實這些方法的精髓都能從名字中體會出來珊泳。FIFO即First in first out鲁冯，先進先出原則，數(shù)據(jù)存儲采用隊列結(jié)構(gòu)色查，當數(shù)據(jù)隊列滿了的時候薯演，新訪問的數(shù)據(jù)插入隊尾，數(shù)據(jù)在隊列中順序移動秧了，淘汰隊首的數(shù)據(jù)跨扮。其中沒有任何的其他邏輯，也就是說無論一個信息有多高的訪問頻率验毡，或者多高的訪問量衡创，都最多只存在于隊列size的周期，之后要重新入隊晶通，這就會對命中率造成影響璃氢，雖然實現(xiàn)簡單，但是效果不好狮辽。
2）LFU
Least Frequently Used 通過頻率淘汰數(shù)據(jù)拔莱，核心思想是如果數(shù)據(jù)過去被訪問多次，那么將來也會有較高的訪問頻率隘竭。實現(xiàn)方式是加入了引用計數(shù)塘秦。雖然查閱資料中大部分描述的是隊列，但是看起來更適合用棧結(jié)構(gòu)來實現(xiàn)动看。新加入數(shù)據(jù)插入到列尾（引用計數(shù)為1）當數(shù)據(jù)被訪問時引用計數(shù)增加對列進行重新排序尊剔，當需要淘汰數(shù)據(jù)的時候?qū)⒘信判蛟谧詈蟮臄?shù)據(jù)刪除。首先可以看出這個算法實現(xiàn)上比較復(fù)雜菱皆，而且每次都要改變計數(shù)并重新排列開銷較大须误，再有就是新進來的數(shù)據(jù)比較容易被淘汰掉，因為起始的計數(shù)較小仇轻，要看實際的淘汰周期合理性京痢。優(yōu)點是確實能保證較高的命中率。
3）LRU
Least Recently Used 通過訪問時間淘汰數(shù)據(jù)篷店。核心思想是如果最近被訪問過祭椰，那么在之后可能會被頻繁訪問臭家。該算法通過鏈表來實現(xiàn)，新數(shù)據(jù)插入到鏈表的表頭方淤，當緩存命中則將命中的緩存移到鏈表的頭部钉赁，當鏈表滿的時候，淘汰鏈表尾部的數(shù)據(jù)携茂。相比于LFU實現(xiàn)起來更簡單你踩，也能保證較高的命中率，但是老數(shù)據(jù)依然容易被“沖掉”讳苦，所以命中率可能不如LFU带膜。
其實比較這幾個方法的時候直接說誰好誰壞是不科學(xué)的，這些算法都是最簡單的模型鸳谜，如果其中的閾值選的好膝藕，更符合實際數(shù)據(jù)的模型，就能保證更好的命中率卿堂，提高存儲的讀寫速度束莫。
CSG的讀算法
如圖所示，其實ppt里面已經(jīng)講的很清楚了草描，該算法是LRU的一個變種览绿，把整個隊列分成冷熱兩部分。顧名思義熱隊列維護了比較長駐的信息穗慕，冷隊列則是一些新的數(shù)據(jù)饿敲。首先，相比于普通的LRU逛绵，它能使已存儲的較為常用的信息更不容易被替代怀各。
簡單來梳理一下幾個關(guān)鍵的信息焦蘑，這個算法關(guān)鍵點一個是m：n的這個比例戒祠，會決定算法的效果。還有就是在熱存儲隊列部分因痛，前k%的信息被再次訪問時是不會前移的胰苏，減少了可能最頻繁調(diào)用信息觸發(fā)的重新排序的開銷硕蛹。非k%部分則會放置到hot隊列隊首。另外cold隊列晉升到hot隊列也需要check時間間隔硕并，大于1s才會放置到hot隊列頭部法焰，這個是為了避免短期的多次訪問使數(shù)據(jù)成為“常駐”，只有在一定時間后仍被訪問才可能是持久數(shù)據(jù)倔毙，另外短期多次訪問該信息也還沒有被淘汰掉埃仪，不用著急變換位置。所以其實可以看出陕赃，hot隊列的元素數(shù)量變化只和cold隊列1s以上重復(fù)調(diào)用有關(guān)卵蛉，所以分界線偏移也不會很頻繁颁股。綜上所述，該模型具有一定的合理性毙玻，全局的順序變化又不頻繁豌蟋，大大減少了開銷廊散。所以作為一種不停訪問的數(shù)據(jù)結(jié)構(gòu)還是很有參考意義的桑滩。
HashTable鎖優(yōu)化
最后我們來討論一下演講人在hashTable上的優(yōu)化，針對這一點其實我是有些疑惑的允睹。要討論這一點我們先引入三個簡單的概念：HashMap运准，HashTable和ConcurrentHashMap。大部分人都用過或者了解這三個結(jié)構(gòu)缭受。我之前的code也習(xí)慣于創(chuàng)建Map的時候直接創(chuàng)建HashMap胁澳，好像已經(jīng)成為了默認的創(chuàng)建模式。比較三者的不同米者，首先前兩個韭畸，HashMap不是線程安全的而HashTable是，后兩者都是線程安全的蔓搞，但是支持的鎖的級別不一樣胰丁。HashTable是全表鎖，而ConcurrentHashMap是Hash單元鎖喂分，是針對Hash表鍵的鎖锦庸，所以力度更細，并發(fā)起來有更高的效率蒲祈。再有就是出錯處理甘萧，ConcurrentHashMap用到的是若一迭代器，也就是說當出現(xiàn)同事寫的情況的時候不是簡單拋出ConcurrentModificationException梆掸，而是在改變的時候創(chuàng)建新的數(shù)據(jù)而不改變原來的扬卷，修改之后再進行替換。提高了性能酸钦。再有就是我了解到在使用Hash表的時候有兩個常用參數(shù)：初始容量和加載因子怪得，之前使用的都是默認的構(gòu)造器（初始容量是十一，加載因子是0.75）初始容量是hash表的初始大小钝鸽，比如初始容量是5汇恤，那么都一個單元對應(yīng)0，5…拔恰；第二個對應(yīng)1因谎，6…；第三個對應(yīng)2颜懊，7…以此類推【5（n-1）+i】i=｛0财岔，1风皿，2，3匠璧，4｝然后加載因子是什么時候Hash表需要翻倍桐款，這個契機是當Hash表種元素大于現(xiàn)有容量乘以加載因子，就擴大為原來容量的一倍夷恍。這些是一些針對Hash表知識的回顧魔眨。
回到這次分享，他提到CSG使用了HashTable+桶鎖酿雪，將原來的全局鎖變成了“桶”級別的鎖遏暴，我覺得應(yīng)該和ConcurrentHashMap沒有什么區(qū)別吧，還是有什么更細粒度的check指黎，從他的分享中沒有領(lǐng)悟到…
總結(jié)
這次的兩篇文章其實和云網(wǎng)關(guān)沒什么太大關(guān)系朋凉，雖然我也準備了一些時間，但是也說不出來很專業(yè)性的內(nèi)容醋安，大部分都是對之前未掌握的知識和不了解的東西的一些查缺補漏杂彭。總的來說是積累了一些本應(yīng)知道的東西吓揪。還有就是針對這次QCon大會亲怠，其實我覺得，從我的角度而言磺芭，我覺得也可以代表一小部分剛剛從事這個行業(yè)不久的人的感受赁炎，就是從這個大會中能夠得到的，第一個是對新東西的開拓钾腺。比如很多分享都是針對互聯(lián)網(wǎng)黑產(chǎn)徙垫，機器學(xué)習(xí)應(yīng)用之類。都好像是敲門磚放棒，讓自己能看到原來他們的一個處理問題的思路是這樣的姻报，這個東西的應(yīng)用場景是這樣的之類。第二點是對一些很多人覺得熟識的而自己還陌生的知識的提醒间螟，分享之后回顧的時候吴旋，能夠重新把這些知識回顧一下。反正就是雖然收到的干貨不多厢破，但是還是很有成長的荣瑟。最后感謝東方海外給我這個機會去見識外面的世界～
