《分布式文件系统概要设计.docx》由会员分享，提供在线免费全文阅读可下载，此文档格式为docx，更多相关《分布式文件系统概要设计.docx》文档请在天天文库搜索。

1、分布式文件系统概要设计(初稿)三人行研发组2011-9-10修订历史日期版本描述作者2011-9-100.1概要设计初稿张琨2011-10-100.2概要设计完善熊书宜一． 需求分析与目标设定业务需求：1. 提供整站的UGC文件存储与读取2. 为后期在线网络存储打下基础技术目标：1. 方便读写海量规模的大文件2. 易于掌握，对外接口统一而简单3. 易于运维和扩展4. 服务稳定同时数据安全二． 系统架构设计主流选型 1、MogileFS Key-Value型元文件系统，不支持FUSE，应用程序访问它时需要API，主要用在web领域处理海量小图片，效率相比mooseFS高很多。 2、FastDFS 国人在mogileFS的基础上进行改进的key-value型文件系统，同样不支持FUSE，提供比mogileFS更好的性能。 3、MooseFS(我目前使用的) 支持FUSE，相对比较轻量级，对m。

2、aster服务器有单点依赖，用perl编写，性能相对较差，其master非常占内存?(测试结果貌似是chunkserver)国内用的人比较两者的区别主要在于： 1、HBase依赖于HDFS；MongoDB直接存储在本地磁盘中 2、HBase按照列族将数据存储在不同的文件中；MongoDB不分列，整个文档都存储在一个(或者说一组)文件中，通过一个有一个通用的.ns文件保存名称空间(Column-based和Document-Based之间的区别应该是指这个地方吧) 3、HBase一个region只有一个HRegionServer对外提供服务(没有负载均衡的概念)；MongoDB的shards(类似于region)支持负载均衡(主从结构，通过日志进行同步，这个HBase也在开发计划当中) 4、HBase根据文件的大小来控制region的分裂；MongoDB根据负载来决定shards的分裂架构设。

3、计调研mongodb 的Auto-Sharding 能够做到：。 当各Sharding间负载和数据分布不平衡时，自动rebalancing    //这是我需要测试的。 简单方便的添加和删除节点。 自动故障转移。 可扩展至上千台节点MongoDB集群包括一定数量的mongod(分片存储数据)、mongos(路由处理)、config server、clients。以下会一一介绍。1 > shards：一个shard为一组mongod，通常一组为两台，主从或互为主从，这一组mongod中的数据是相同的， 具体可见《mongodb分布式之数据复制》。数据分割按有序分割方式，每个分片上的数据为某一范围的数据块，故可支持指定分片的范围查询，这同 google的BigTable 类似。数据块有指定的最大容量，一旦某个数据块的容量增长到最大容量时，这个数据块会切分成为两块；当分片的数据过多时，数据。

4、块将被迁移到系统的其他分片 中。另外，新的分片加入时，数据块也会迁移。2 > mongos：可以有多个，相当于一个控制中心，负责路由和协调操作，使得集群像一个整体的系统。mongos可以运行在任 何一台服务器上，有些选择放在shards服务器上，也有放在client 服务器上的。mongos启动时需要从config servers上获取基本信息，然后接受client端的请求，路由到shards服务器上，然后整理返回的结果发回给client服务器。3 > config server：存储集群的信息，包括分片和块数据信息。主要存储块数据信息，每个config server上都有一份所有块数据信息的拷贝，以保证每台config server上的数据的一致性。4 > shard key：为了分割数据集，需要制定分片key的格式，类似于用于索引的key格式，通常由一个或多个字段组成。

5、以分发数据与mysql对比跟mysqld一样，一个mongod服务可以有建立多个数据库，每个数据库可以有多张表，这里的表名叫collection，每个collection 可以存放多个文档(document)，每个文档都以BSON(binary json)的形式存放于硬盘中。跟关系型数据库不一样的地方是，它是的以单文档为单位存储的，你可以任意给一个或一批文档新增或删除字段，而不会对其它文 档造成影响，这就是所谓的schema-free，这也是文档型数据库最主要的优点。跟一般的key-value数据库不一样的是，它的value中存储 了结构信息，所以你又可以像关系型数据库那样对某些域进行读写、统计等操作。可以说是兼备了key-value数据库的方便高效与关系型数据库的强大功 能。Nginx按照db到collection(相当于表的概念)做的配置location /pics/ {    gri。

6、dfs pics               field=filename              type=string;    mongo www.wenku365.com:27017;  }gridfs：nginx识别插件的关键字pics：db名[root_collection]: 选择collection，如root_collection=blog， mongod就会去找blog.files与blog.chunks两个块，默认是fs[field]：查询字段，保证mongdb里有这个字段名，支持_id, filename, 可省略, 默认是_id[type]：解释field的数据类型，支持objectid, int, string, 可省略, 默认是int[user]：用户名, 可省略[pass]：密码, 可省略mongo：mongodb url配置replica sets的问题　　问题　　这时。

7、候如果Secondary宕机，那么Primary会怎么样呢?Primary会立刻变成Secondary!这时候集群里没有Primary了!为什么会出现这样的情况呢。　　原因　 　这是和MongoDB的Primary选举策略有关的，试想如果情况不是Secondary宕机，而是网络断开，那么两个节点都会选取自己为 Primary，因为他们能连接上的只有自己这一个节点。而这样的情况在网络恢复后就需要处理复杂的一致性问题。而且断开的时间越长，时间越复杂。所以 MongoDB选择的策略是如果集群中只有自己一个节点，那么不选取自己为Primary。　　解决方法　 　所以正确的做法应该是添加两个以上的节点，或者添加arbiter，当然最好也最方便的做法是添加arbiter，aribiter节点只参与选举，几 乎不会有压力，所以你可以在各种闲置机器上启动arbiter节点，这不仅会避免上面说到的无法选举P。

8、rimary的情况，更会让选取更快速的进行。(因 为如果是三台数据节点，一个节点宕机，另外两个节点很可能会各自选举自己为Primary，从而导致很长时间才能得出选举结果)测试环境192.168.1.43 3个mongod实例 1个primary 2个secondry 作为sets1192.168.1.44 3个mongod实例 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 --dbpath /opt/mongodb/db/10001 --port 10001 --re。

9、plSet 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 --dbpath /opt/mongodb/db/10003 --port 10003 --replSet set144上的启动脚本root 3861 1 0 Sep19 ? 00:00:05 ./mongod --shardsvr --fork --logpath 。

10、/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/mongodb.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 s。

11、et2190的启动脚本root 5040 1 0 Sep19 ? 00:00:22 ./mongod --configsvr --fork --logpath /opt/mongodb/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 。

12、--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，当不是写密集操作时，而仅仅是因为存储空间不够了，这个shard key我们可以选用一些无上限范围的key，如创建时间等，这样新创建的记录都会写入新的分片服务器上。当需要使每个分片均匀分布数据时，或者写入密集时，最好选用有一定范围值的key ，当然这个范围不能太小，像性别，真假等，这会导致只自动产生两个分片，所以一定要选择合适的shard key才能达到理想的效果。关于MongoDB数据库的自动分片技术就介绍到这里，希望通过本次的介绍能够带给您一些收获。一期使用强磁盘型应用：192.168.1.135 作为config+route和sets的一部分192.168.1.133 作为sets 的另一部分备份Mongodb master-slave 本系统的最终设计方案 (小熊这个地方补充上)1. 切图服务 和 monogdb 的对接Client调用ImageMagic++接口，处理完后的数据直接通过Monodb的C++版api存入mongodb中。目前提供 3r-Image.jar2. Java 文件存储和mongodb的对接Client调用mongodb的java api存入，读取文件于mongodb中。目前提供 3r-chameleon-nosql-mongodb.jar扩展与容量规划三． 难点与要点汇总四．后期扩展与运维。