分布式文件系統(tǒng)概要設(shè)計(jì)

1、分布式文件系統(tǒng)概要設(shè)計(jì)（初稿）三人行研發(fā)組2011-9-10修訂歷史日期版本描述作者2011-9-100.1概要設(shè)計(jì)初稿張琨2011-10-100.2概要設(shè)計(jì)完善熊書宜一 需求分析與目標(biāo)設(shè)定業(yè)務(wù)需求：1. 提供整站的UGC文件存儲與讀取2. 為后期在線網(wǎng)絡(luò)存儲打下基礎(chǔ)技術(shù)目標(biāo)：1. 方便讀寫海量規(guī)模的大文件2. 易于掌握，對外接口統(tǒng)一而簡單3. 易于運(yùn)維和擴(kuò)展4. 服務(wù)穩(wěn)定同時數(shù)據(jù)安全二 系統(tǒng)架構(gòu)設(shè)計(jì)主流選型 1、MogileFS Key-Value型元文件系統(tǒng)，不支持FUSE，應(yīng)用程序訪問它時需要API，主要用在web領(lǐng)域處理海量小圖片，效率相比mooseFS高很多。 2、FastDFS 國

2、人在mogileFS的基礎(chǔ)上進(jìn)行改進(jìn)的key-value型文件系統(tǒng)，同樣不支持FUSE，提供比mogileFS更好的性能。 3、MooseFS(我目前使用的) 支持FUSE，相對比較輕量級，對master服務(wù)器有單點(diǎn)依賴，用perl編寫，性能相對較差，其master非常占內(nèi)存?(測試結(jié)果貌似是chunkserver)國內(nèi)用的人比較兩者的區(qū)別主要在于： 1、HBase依賴于HDFS；MongoDB直接存儲在本地磁盤中 2、HBase按照列族將數(shù)據(jù)存儲在不同的文件中；MongoDB不分列，整個文檔都存儲在一個（或者說一組）文件中，通過一個有一個通用的.ns文件保存名稱空間（Column-based

3、和Document-Based之間的區(qū)別應(yīng)該是指這個地方吧） 3、HBase一個region只有一個HRegionServer對外提供服務(wù)（沒有負(fù)載均衡的概念）；MongoDB的shards（類似于region）支持負(fù)載均衡（主從結(jié)構(gòu)，通過日志進(jìn)行同步，這個HBase也在開發(fā)計(jì)劃當(dāng)中） 4、HBase根據(jù)文件的大小來控制region的分裂；MongoDB根據(jù)負(fù)載來決定shards的分裂架構(gòu)設(shè)計(jì)調(diào)研mongodb 的Auto-Sharding 能夠做到：。 當(dāng)各Sharding間負(fù)載和數(shù)據(jù)分布不平衡時，自動rebalancing    /這是我需要測試的。 簡單方便

4、的添加和刪除節(jié)點(diǎn)。 自動故障轉(zhuǎn)移。 可擴(kuò)展至上千臺節(jié)點(diǎn)MongoDB集群包括一定數(shù)量的mongod（分片存儲數(shù)據(jù)）、mongos（路由處理）、config server、clients。以下會一一介紹。1 > shards：一個shard為一組mongod，通常一組為兩臺，主從或互為主從，這一組mongod中的數(shù)據(jù)是相同的， 具體可見mongodb分布式之?dāng)?shù)據(jù)復(fù)制。數(shù)據(jù)分割按有序分割方式，每個分片上的數(shù)據(jù)為某一范圍的數(shù)據(jù)塊，故可支持指定分片的范圍查詢，這同 google的BigTable 類似。數(shù)據(jù)塊有指定的最大容量，一旦某個數(shù)據(jù)塊的容量增長到最大容量時，這個數(shù)據(jù)塊會切分成為兩塊；當(dāng)分片

5、的數(shù)據(jù)過多時，數(shù)據(jù)塊將被遷移到系統(tǒng)的其他分片 中。另外，新的分片加入時，數(shù)據(jù)塊也會遷移。2 > mongos：可以有多個，相當(dāng)于一個控制中心，負(fù)責(zé)路由和協(xié)調(diào)操作，使得集群像一個整體的系統(tǒng)。mongos可以運(yùn)行在任 何一臺服務(wù)器上，有些選擇放在shards服務(wù)器上，也有放在client 服務(wù)器上的。mongos啟動時需要從config servers上獲取基本信息，然后接受client端的請求，路由到shards服務(wù)器上，然后整理返回的結(jié)果發(fā)回給client服務(wù)器。3 > config server：存儲集群的信息，包括分片和塊數(shù)據(jù)信息。主要存儲塊數(shù)據(jù)信息，每個config serv

6、er上都有一份所有塊數(shù)據(jù)信息的拷貝，以保證每臺config server上的數(shù)據(jù)的一致性。4 > shard key：為了分割數(shù)據(jù)集，需要制定分片key的格式，類似于用于索引的key格式，通常由一個或多個字段組成以分發(fā)數(shù)據(jù)與mysql對比跟mysqld一樣，一個mongod服務(wù)可以有建立多個數(shù)據(jù)庫，每個數(shù)據(jù)庫可以有多張表，這里的表名叫collection，每個collection 可以存放多個文檔（document），每個文檔都以BSON（binary json）的形式存放于硬盤中。跟關(guān)系型數(shù)據(jù)庫不一樣的地方是，它是的以單文檔為單位存儲的，你可以任意給一個或一批文檔新增或刪除字段，而不會

7、對其它文 檔造成影響，這就是所謂的schema-free，這也是文檔型數(shù)據(jù)庫最主要的優(yōu)點(diǎn)。跟一般的key-value數(shù)據(jù)庫不一樣的是，它的value中存儲 了結(jié)構(gòu)信息，所以你又可以像關(guān)系型數(shù)據(jù)庫那樣對某些域進(jìn)行讀寫、統(tǒng)計(jì)等操作?？梢哉f是兼?zhèn)淞薻ey-value數(shù)據(jù)庫的方便高效與關(guān)系型數(shù)據(jù)庫的強(qiáng)大功 能。Nginx按照db到collection（相當(dāng)于表的概念）做的配置location /pics/     gridfs pics            &#

8、160;  field=filename              type=string;    mongo 127.0.0.1:27017;  gridfs：nginx識別插件的關(guān)鍵字pics：db名root_collection: 選擇collection，如root_collection=blog， mongod就會去找blog.files與blog.chunks兩個塊，默認(rèn)是fsfield：查詢字段，保證m

9、ongdb里有這個字段名，支持_id, filename, 可省略, 默認(rèn)是_idtype：解釋field的數(shù)據(jù)類型，支持objectid, int, string, 可省略, 默認(rèn)是intuser：用戶名, 可省略pass：密碼, 可省略mongo：mongodb url配置replica sets的問題問題這時候如果Secondary宕機(jī)，那么Primary會怎么樣呢?Primary會立刻變成Secondary!這時候集群里沒有Primary了!為什么會出現(xiàn)這樣的情況呢。原因 這是和MongoDB的Primary選舉策略有關(guān)的，試想如果情況不是Secondary宕機(jī)，而是網(wǎng)絡(luò)斷開，那么兩個

10、節(jié)點(diǎn)都會選取自己為 Primary，因?yàn)樗麄兡苓B接上的只有自己這一個節(jié)點(diǎn)。而這樣的情況在網(wǎng)絡(luò)恢復(fù)后就需要處理復(fù)雜的一致性問題。而且斷開的時間越長，時間越復(fù)雜。所以 MongoDB選擇的策略是如果集群中只有自己一個節(jié)點(diǎn)，那么不選取自己為Primary。解決方法 所以正確的做法應(yīng)該是添加兩個以上的節(jié)點(diǎn)，或者添加arbiter，當(dāng)然最好也最方便的做法是添加arbiter，aribiter節(jié)點(diǎn)只參與選舉，幾 乎不會有壓力，所以你可以在各種閑置機(jī)器上啟動arbiter節(jié)點(diǎn)，這不僅會避免上面說到的無法選舉Primary的情況，更會讓選取更快速的進(jìn)行。(因 為如果是三臺數(shù)據(jù)節(jié)點(diǎn)，一個節(jié)點(diǎn)宕機(jī)，另外兩個節(jié)點(diǎn)很

11、可能會各自選舉自己為Primary，從而導(dǎo)致很長時間才能得出選舉結(jié)果)測試環(huán)境192.168.1.43 3個mongod實(shí)例 1個primary 2個secondry 作為sets1192.168.1.44 3個mongod實(shí)例 1個primary 2個secondry 作為sets2192.168.1.190 config server192.168.1.79 route server43上的啟動腳本root 12837 1 0 Sep19 ? 00:00:09 ./mongod -shardsvr -fork -logpath /opt/mongodb/logs/mongodb.log -

12、dbpath /opt/mongodb/db/10001 -port 10001 -replSet set1root 12862 1 0 Sep19 ? 00:00:06 ./mongod -shardsvr -fork -logpath /opt/mongodb/logs/mongodb.log -dbpath /opt/mongodb/db/10002 -port 10002 -replSet set1root 12875 1 0 Sep19 ? 00:00:03 ./mongod -shardsvr -fork -logpath /opt/mongodb/logs/mongodb.log

13、 -dbpath /opt/mongodb/db/10003 -port 10003 -replSet set144上的啟動腳本root 3861 1 0 Sep19 ? 00:00:05 ./mongod -shardsvr -fork -logpath /opt/mongodb/logs/mongodb.log -dbpath /opt/mongodb/db/10001/ -port 10001 -replSet set2root 3874 1 0 Sep19 ? 00:00:13 ./mongod -shardsvr -fork -logpath /opt/mongodb/logs/mo

14、ngodb.log -dbpath /opt/mongodb/db/10002/ -port 10002 -replSet set2root 3887 1 0 Sep19 ? 00:00:01 ./mongod -shardsvr -fork -logpath /opt/mongodb/logs/mongodb.log -dbpath /opt/mongodb/db/10003/ -port 10003 -replSet set2190的啟動腳本root 5040 1 0 Sep19 ? 00:00:22 ./mongod -configsvr -fork -logpath /opt/mong

15、odb/logs/mongodb.log -dbpath /opt/mongodb/db/config1/ -port 20000root 5053 1 0 Sep19 ? 00:00:14 ./mongod -configsvr -fork -logpath /opt/mongodb/logs/mongodb.log -dbpath /opt/mongodb/db/config2/ -port 20001root 5290 1 0 Sep19 ? 00:00:13 ./mongod -configsvr -fork -logpath /opt/mongodb/logs/mongodb.log

16、 -dbpath /opt/mongodb/db/config3/ -port 2000279的啟動腳本00:00:10 ./mongos -fork -logpath /opt/mongodb/logs/mongodb.log -configdb 192.168.1.190:20000,192.168.1.190:20001,192.168.1.190:20002簡單的分析一下這個shard key，當(dāng)不是寫密集操作時，而僅僅是因?yàn)榇鎯臻g不夠了，這個shard key我們可以選用一些無上限范圍的key，如創(chuàng)建時間等，這樣新創(chuàng)建的記錄都會寫入新的分片服務(wù)器上。當(dāng)需要使每個分片均勻分布數(shù)據(jù)時，或者寫入密集時，最好選用有一定范圍值的key ，當(dāng)然這個范圍不能太小，像性別，真假等，這會導(dǎo)致只自動產(chǎn)生兩個分片，所以一定要選擇合適的shard key才能達(dá)到理想的效果。關(guān)于MongoDB數(shù)據(jù)庫的自動分片技術(shù)就介紹到這里，希望通過本次的介紹能夠帶給您一些收獲。一期使用強(qiáng)磁盤型應(yīng)用：192.168.1.135 作為config+route和sets的一部分192.168.1.133 作為sets 的另一部