国产性70yerg老太,色综合在,国产精品亚洲一区二区无码,无码人妻束缚av又粗又大

目的：分析海量小文件的存儲(chǔ)及訪問(wèn)的解決方法，研究實(shí)例系統(tǒng)的架構(gòu)方法及其在實(shí)際案例中的應(yīng)用。
基本思路：
1、調(diào)查研究海量小文件訪問(wèn)及存儲(chǔ)的現(xiàn)狀及問(wèn)題
2、研究TFS的結(jié)構(gòu)及組成
3、研究并建立基于TFS架構(gòu)實(shí)例系統(tǒng)
4、分析基于TFS的實(shí)例系統(tǒng)在實(shí)際中的應(yīng)用
作品的科學(xué)性、先進(jìn)性及獨(dú)特之處
1、分布式系統(tǒng)實(shí)例系統(tǒng)擺脫了傳統(tǒng)分布式文件系統(tǒng)依靠NameServer服務(wù)器進(jìn)行分配存儲(chǔ)池的資源，容易造成單節(jié)點(diǎn)故障的缺點(diǎn)，采用以文件名直接定位存儲(chǔ)位置，客戶端可以直接解析文件名得到文件的存儲(chǔ)位置，直接訪問(wèn)存儲(chǔ)服務(wù)器；
2、系統(tǒng)并發(fā)訪問(wèn)及存儲(chǔ)能解決海量小文件同步的問(wèn)題。
作品的實(shí)際應(yīng)用價(jià)值和現(xiàn)實(shí)意義
實(shí)際價(jià)值：
1、本項(xiàng)目可以實(shí)現(xiàn)一個(gè)存儲(chǔ)海量小文件的存儲(chǔ)平臺(tái)，屬于TB乃至PB級(jí)的存儲(chǔ)平臺(tái)；
2、解決服務(wù)器后端存儲(chǔ)平臺(tái)解決海量小文件的讀寫(xiě)超高磁盤(pán)IO等待的瓶頸；
3、解決web并發(fā)海量小文件的超長(zhǎng)延時(shí)的問(wèn)題。
現(xiàn)實(shí)意義：
1、參考該設(shè)計(jì)文檔可以搭建解決并發(fā)海量小文件的分布式存儲(chǔ)系統(tǒng)實(shí)例；
2、為高校建設(shè)信息資源庫(kù)以及OA辦公共享系統(tǒng)的存儲(chǔ)架構(gòu)提供參考方案；

該論文主要論述的是基于TFS（TaobaoFileSystem）分布式文件存儲(chǔ)系統(tǒng)對(duì)高校資源共享系統(tǒng)的架構(gòu)設(shè)計(jì)，同時(shí)也討論如何利用好開(kāi)源技術(shù)來(lái)解決存儲(chǔ)的問(wèn)題，從而節(jié)省更多不必要的成本。
該論文首先是對(duì)現(xiàn)在的互聯(lián)網(wǎng)情況進(jìn)行分析，得出在web2.0時(shí)代我們所遇到的一些問(wèn)題，海量的小文件對(duì)web2.0時(shí)代發(fā)展的限制，并造成了需要很高的成本來(lái)進(jìn)行架構(gòu)、維護(hù)等問(wèn)題，還詳細(xì)列舉了海量小文件所造成的各種問(wèn)題，并對(duì)現(xiàn)階段比較火的分布式文件系統(tǒng)技術(shù)進(jìn)行分析，通過(guò)對(duì)多個(gè)文件分布存儲(chǔ)系統(tǒng)的分析，如hadoop、GFS等，我們發(fā)現(xiàn)在對(duì)小文件的支持上不是不能很好的解決問(wèn)題就是技術(shù)沒(méi)有開(kāi)放，我們不能使用。
接著我們將目標(biāo)投向國(guó)內(nèi)淘寶團(tuán)隊(duì)提供的開(kāi)源技術(shù)TFS（TaobaoFileSystem），我們發(fā)現(xiàn)這是一個(gè)對(duì)小文件的存儲(chǔ)支持的很好的一個(gè)存儲(chǔ)平臺(tái)，通過(guò)創(chuàng)新的文件名設(shè)計(jì)來(lái)定位文件存儲(chǔ)位置，將解碼負(fù)載轉(zhuǎn)移到客戶端，充分利用客戶端資源，巧妙的解決了大量元數(shù)據(jù)存儲(chǔ)的問(wèn)題，降低的服務(wù)器成本，同時(shí)采用HA高可用負(fù)載技術(shù)，避免了單點(diǎn)故障的問(wèn)題。
最后我們通過(guò)分析了高校信息資源庫(kù)的基本情況，如大量文檔文件存儲(chǔ)的問(wèn)題，然后針對(duì)TFS分布式文件存儲(chǔ)系統(tǒng)對(duì)海量小文件支持友好的特性，對(duì)高校的信息資源庫(kù)的存儲(chǔ)平臺(tái)進(jìn)行架構(gòu)設(shè)計(jì)，滿足海量小文件存儲(chǔ)，并降低服務(wù)器成本。
1、小文件存儲(chǔ)的現(xiàn)狀
之所以會(huì)討論海量小文件的存儲(chǔ)問(wèn)題，就是在這個(gè)Web2.0的時(shí)代里，這是一個(gè)我們不能回避的問(wèn)題了，目前就我們國(guó)家來(lái)說(shuō)，網(wǎng)民的數(shù)量已經(jīng)增長(zhǎng)到5.6個(gè)億了，在web2.0的時(shí)代每個(gè)用戶都是網(wǎng)絡(luò)信息的創(chuàng)造者，互聯(lián)網(wǎng)的信息量成幾何級(jí)增長(zhǎng)，龐大的用戶量會(huì)產(chǎn)生龐大的信息量，而龐大的信息量又是對(duì)互聯(lián)網(wǎng)后臺(tái)技術(shù)架構(gòu)的沖擊。海量的小文件產(chǎn)生，高并發(fā)，隨機(jī)性，流量大，等等這些隨時(shí)都能讓網(wǎng)絡(luò)服務(wù)崩潰掉。我們可以列舉一下這些根本性的問(wèn)題：
? 海量小文件：電子書(shū)、文檔、郵件、圖片等等，都是小文件的主要來(lái)源，都是KB級(jí)的，幾KB，幾十KB占了很大部分，一個(gè)100MB的文件傳輸可以很快，可是100MB大概分為10000個(gè)10kb的小文件來(lái)傳輸，那么就需要很長(zhǎng)時(shí)間了；
? 海量小文件索引檢索：在現(xiàn)有的文件存儲(chǔ)系統(tǒng)中，單個(gè)目錄下文件數(shù)超過(guò)一定數(shù)量后索引就會(huì)急劇下降，而采用多級(jí)目錄存儲(chǔ)也同樣的限制，超過(guò)臨界值變會(huì)有很大的速度下降；
? 隨機(jī)性，Cache命中率低：一般為了提高訪問(wèn)速度會(huì)進(jìn)行數(shù)據(jù)緩存，可往往是數(shù)據(jù)的訪問(wèn)隨機(jī)性很大，跨度很厲害，緩存數(shù)據(jù)的命中率及其低下；
? 并發(fā)性高：海量數(shù)據(jù)的并發(fā)請(qǐng)求，會(huì)使得服務(wù)器的負(fù)載變得很大，一般表現(xiàn)為請(qǐng)求延時(shí)，當(dāng)超過(guò)一定壓力后，服務(wù)器會(huì)選擇罷工，也就是宕機(jī)了；
? 容災(zāi)備份：這個(gè)說(shuō)到底還是小文件的傳輸問(wèn)題，速率極其低下，可用性很低，而且常常造成數(shù)據(jù)丟失，不能很好的管理，海量的數(shù)據(jù)備份會(huì)消耗大量的時(shí)間和系統(tǒng)資源。
? 碎片化，占用存儲(chǔ)空間：大量的小文件占據(jù)著比本身文件大小還大的存儲(chǔ)空間。
以上這些都是我們?cè)趯?shí)際生產(chǎn)環(huán)境中會(huì)遇到的問(wèn)題，而且每一個(gè)都是很棘手問(wèn)題。
但是具體有沒(méi)有一種好的設(shè)計(jì)方案來(lái)解決這些為題呢？其實(shí)早在十年以前谷歌就已經(jīng)解決了這類(lèi)問(wèn)題，但是由于沒(méi)有技術(shù)沒(méi)有開(kāi)源出來(lái)，所以我們只能通過(guò)一些論文得知其設(shè)計(jì)思想的大概，谷歌是采用自己的GFS(google file system)，通過(guò)數(shù)據(jù)流的形式來(lái)存儲(chǔ)大量的小文件，并通過(guò)一種叫做chunk的方式進(jìn)存儲(chǔ)（可以理解為數(shù)據(jù)塊，每個(gè)64MB），避免碎片化的問(wèn)題，用NameServer來(lái)記錄存儲(chǔ)每個(gè)chunk的元數(shù)據(jù)，這樣客戶端在訪問(wèn)數(shù)據(jù)的時(shí)候可以直接訪問(wèn)存儲(chǔ)數(shù)據(jù)，減少NameServer的壓力，簡(jiǎn)化了設(shè)計(jì)。對(duì)于容災(zāi)備份，谷歌并沒(méi)有采用RAID機(jī)制，而是直接用優(yōu)化算法將一份數(shù)據(jù)復(fù)制幾份到其他服務(wù)器，這樣反而降低了成本，也提高磁盤(pán)的讀寫(xiě)性能。
源于谷歌的這種設(shè)計(jì)思想，以致后來(lái)apache開(kāi)發(fā)的hadoop分布式存儲(chǔ)系統(tǒng)也有類(lèi)似的架構(gòu)，但是hadoop針對(duì)的對(duì)象偏向于大文件，大數(shù)據(jù)，對(duì)小文件的支持并不是很友好，不過(guò)也有一些例外，比如中國(guó)電子教學(xué)共享系統(tǒng)Bluesky就是采用HDFS進(jìn)行存儲(chǔ)的，他們具體是怎樣做到的呢？基于hadoop都是要根據(jù)自己的需求進(jìn)行二次開(kāi)發(fā)，編寫(xiě)程序來(lái)實(shí)現(xiàn)的。設(shè)計(jì)思想是根據(jù)一種web與地理信息系統(tǒng)（GIS）產(chǎn)生的一種新系統(tǒng)WebGIS。結(jié)合WebGIS中數(shù)據(jù)的相關(guān)性特征，以一種地理位置相近的數(shù)據(jù)合并為大文件，并在大文件里將這些小文件建立索引的思路，將教學(xué)資源里的同一個(gè)科目，種類(lèi)等某種相關(guān)信息進(jìn)行歸類(lèi)合并，建立索引。當(dāng)用戶在訪問(wèn)Bulesky資源系統(tǒng)里面的ppt文件、doc文檔等等時(shí)，同屬于相關(guān)的PPT、doc等文件也會(huì)被預(yù)先加載到內(nèi)存，以提高其訪問(wèn)效率。這樣一來(lái)，用戶在連續(xù)的訪問(wèn)時(shí)，速度會(huì)明顯提高。但是，我們并不建議采用這種設(shè)計(jì)方案。主要的原因有一下幾個(gè)：
? 可維護(hù)性差，運(yùn)營(yíng)維護(hù)成本比較大；
? Hadoop file system是采用java語(yǔ)言開(kāi)發(fā)的，在實(shí)際上的服務(wù)器集群生產(chǎn)環(huán)境效率并不是很高效，經(jīng)常是以機(jī)器換性能，不能夠很好的利用到每臺(tái)機(jī)器的實(shí)際性能，需要花費(fèi)大量的資金用于購(gòu)買(mǎi)設(shè)備；
? 不能解決客戶端訪問(wèn)的隨機(jī)性，而且采用相關(guān)性數(shù)據(jù)的加載，當(dāng)并發(fā)足夠大的時(shí)候很容易收到內(nèi)存溢出攻擊。
綜合以上的分析情況，對(duì)于一個(gè)好的文件存儲(chǔ)系統(tǒng)，我們認(rèn)為應(yīng)該具備哪些性能特點(diǎn)呢？
? 采用可靠，強(qiáng)大的開(kāi)發(fā)語(yǔ)言，對(duì)于服務(wù)器集群而言，最重要的是穩(wěn)定性，其次就是系統(tǒng)資源的占用不能過(guò)大，數(shù)據(jù)處理效率要高，我們可以對(duì)比一下我們所熟悉的Android和蘋(píng)果的IOS,Android是采用java開(kāi)發(fā)的，而IOS是采用古老的ObjectivC（屬于C語(yǔ)言）開(kāi)發(fā)的，兩個(gè)系統(tǒng)的穩(wěn)定性以及可靠性我們可以很清楚的感受到；
? 不能存在單點(diǎn)故障：現(xiàn)在很多分布式存儲(chǔ)會(huì)存在單點(diǎn)故障的風(fēng)險(xiǎn)，一旦單點(diǎn)存在瓶頸，那么將大大限制該系統(tǒng)的擴(kuò)張性以及可靠性，如NFS；
? 對(duì)于集群里的每臺(tái)機(jī)器都能盡可能的優(yōu)化，提高其利用率，而不是存在以機(jī)器數(shù)量換性能的情況；
? 可維護(hù)性較高，不會(huì)造成一個(gè)集群一旦投入生產(chǎn)環(huán)境，需要雇用一個(gè)專(zhuān)業(yè)能力很強(qiáng)的技術(shù)人員進(jìn)行維護(hù)；
? 具有很強(qiáng)的可拓展性，隨著數(shù)據(jù)的增多，以及業(yè)務(wù)的拓展，需要集群在生產(chǎn)環(huán)境中能適時(shí)的根據(jù)需求進(jìn)行擴(kuò)展，提升；
當(dāng)然，除了以上這些，還有許許多多的問(wèn)題會(huì)存在，比如元數(shù)據(jù)數(shù)量過(guò)多，索引慢，磁盤(pán)的I/O瓶頸等等，在一個(gè)實(shí)際的生產(chǎn)環(huán)境中，需要注意的會(huì)更多更多，很多時(shí)候還需要定制優(yōu)化，比如上文提到的谷歌的服務(wù)器，都是谷歌內(nèi)部定制的，但是這些技術(shù)很多都是沒(méi)有公開(kāi)的，都是受到專(zhuān)利保護(hù)的。
2、基于TFS的解決方案
其實(shí)，在今年的“雙十一”光棍節(jié)中，淘寶再一次引起了人們的關(guān)注，我們來(lái)看看下面的一組數(shù)據(jù)：2012.11.11當(dāng)天，支付寶總銷(xiāo)售額為191億元。11日零時(shí)開(kāi)始的第一分鐘，超過(guò) 1000萬(wàn)人登陸天貓平臺(tái)；11日當(dāng)天。平臺(tái)總共涌入2.13億網(wǎng)民；11日當(dāng)天的訂單量為1億580萬(wàn)筆；支付寶核心數(shù)據(jù)庫(kù)集群處理了41億個(gè)事務(wù)，執(zhí)行285億次SQL數(shù)據(jù)語(yǔ)言，訪問(wèn)1931億次內(nèi)存數(shù)據(jù)塊。核心MySQL(開(kāi)源數(shù)據(jù)庫(kù)管理系統(tǒng))集群一天支持了20億個(gè)事務(wù)；看完這組數(shù)據(jù)，足以感到震撼，如此之高的并發(fā)，流量如此之大，可見(jiàn)其后端服務(wù)集群是多么穩(wěn)定，強(qiáng)大呀。我們可以打開(kāi)淘寶首頁(yè)，或者天貓首頁(yè)，你會(huì)發(fā)現(xiàn)其實(shí)每個(gè)頁(yè)面都會(huì)有很多圖片，原圖，縮略圖等等，而且你并不會(huì)覺(jué)得圖片加載不了，或者太慢，即使我們刷屏的話，也就好似不斷的跳轉(zhuǎn)頁(yè)面，也不會(huì)覺(jué)得有什么圖片加載過(guò)慢，或者不能顯示的問(wèn)題，或者說(shuō)出現(xiàn)問(wèn)題的情況極少。
我們接下來(lái)再看一組數(shù)據(jù)，這是淘寶系統(tǒng)公布的一組數(shù)據(jù)：
? 圖片的總量為：998TB
? 文件數(shù)量為：286億多個(gè)(80%為小于18kb的對(duì)象，8kb以下的更是占到了61%)
? 圖片的平均大?。?7.45kb
從這組數(shù)據(jù)可以看到，著寫(xiě)都是很典型的小文件，如此大量的小文件，如果以現(xiàn)在普通分布式文件系統(tǒng)，或者普通的文件系統(tǒng)來(lái)進(jìn)行架構(gòu)，那簡(jiǎn)直就是一種噩夢(mèng)，首先是會(huì)產(chǎn)生大量的元數(shù)據(jù)，其次是在備份問(wèn)題998TB，以2MB/S，這個(gè)要備份到什么時(shí)候？再而就是以現(xiàn)在的普通的機(jī)械磁盤(pán)來(lái)說(shuō)，超高的I/O等待就會(huì)讓你抓狂，最后是根據(jù)淘寶的實(shí)際情況來(lái)看，熱點(diǎn)數(shù)據(jù)的命中是很難把握的，對(duì)數(shù)據(jù)緩存加載到內(nèi)存這個(gè)實(shí)現(xiàn)不是很容易。
分析完數(shù)據(jù)，回過(guò)頭來(lái)我們?cè)俜治鎏詫毜拇鎯?chǔ)系統(tǒng)——TFS(taobao file system)，這個(gè)就是淘寶現(xiàn)在生產(chǎn)環(huán)境中在使用的存儲(chǔ)系統(tǒng)，先應(yīng)用官方的一段描述：
TFS是一個(gè)高可擴(kuò)展、高可用、高性能、面向互聯(lián)網(wǎng)服務(wù)的分布式文件系統(tǒng)，主要針對(duì)海量的非結(jié)構(gòu)化數(shù)據(jù)，它構(gòu)筑在普通的Linux機(jī)器集群上，可為外部提供高可靠和高并發(fā)的存儲(chǔ)訪問(wèn)。TFS為淘寶提供海量小文件存儲(chǔ)，通常文件大小不超過(guò)1M，滿足了淘寶對(duì)小文件存儲(chǔ)的需求，被廣泛地應(yīng)用在淘寶各項(xiàng)應(yīng)用中。它采用了HA架構(gòu)和平滑擴(kuò)容，保證了整個(gè)文件系統(tǒng)的可用性和擴(kuò)展性。同時(shí)扁平化的數(shù)據(jù)組織結(jié)構(gòu)，可將文件名映射到文件的物理地址，簡(jiǎn)化了文件的訪問(wèn)流程，一定程度上為T(mén)FS提供了良好的讀寫(xiě)性能。一個(gè)TFS集群由兩個(gè)!NameServer節(jié)點(diǎn)（一主一備）和多個(gè)!DataServer節(jié)點(diǎn)組成。這些服務(wù)程序都是作為一個(gè)用戶級(jí)的程序運(yùn)行在普通Linux機(jī)器上的。

廣東交通職業(yè)技術(shù)學(xué)院第四屆“挑戰(zhàn)杯”廣東大學(xué)生課外學(xué)術(shù)科技作品競(jìng)賽三等獎(jiǎng)