分布式文件系统概要设计

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 国

2、人在mogileFS的基础上进行改进的key-value型文件系统，同样不支持FUSE，提供比mogileFS更好的性能。 3、MooseFS(我目前使用的) 支持FUSE，相对比较轻量级，对master服务器有单点依赖，用perl编写，性能相对较差，其master非常占内存?(测试结果貌似是chunkserver)国内用的人比较两者的区别主要在于： 1、HBase依赖于HDFS；MongoDB直接存储在本地磁盘中 2、HBase按照列族将数据存储在不同的文件中；MongoDB不分列，整个文档都存储在一个（或者说一组）文件中，通过一个有一个通用的.ns文件保存名称空间（Column-based

3、和Document-Based之间的区别应该是指这个地方吧） 3、HBase一个region只有一个HRegionServer对外提供服务（没有负载均衡的概念）；MongoDB的shards（类似于region）支持负载均衡（主从结构，通过日志进行同步，这个HBase也在开发计划当中） 4、HBase根据文件的大小来控制region的分裂；MongoDB根据负载来决定shards的分裂架构设计调研mongodb 的Auto-Sharding 能够做到：。 当各Sharding间负载和数据分布不平衡时，自动rebalancing    /这是我需要测试的。 简单方便

4、的添加和删除节点。 自动故障转移。 可扩展至上千台节点MongoDB集群包括一定数量的mongod（分片存储数据）、mongos（路由处理）、config server、clients。以下会一一介绍。1 > shards：一个shard为一组mongod，通常一组为两台，主从或互为主从，这一组mongod中的数据是相同的， 具体可见mongodb分布式之数据复制。数据分割按有序分割方式，每个分片上的数据为某一范围的数据块，故可支持指定分片的范围查询，这同 google的BigTable 类似。数据块有指定的最大容量，一旦某个数据块的容量增长到最大容量时，这个数据块会切分成为两块；当分片

5、的数据过多时，数据块将被迁移到系统的其他分片 中。另外，新的分片加入时，数据块也会迁移。2 > mongos：可以有多个，相当于一个控制中心，负责路由和协调操作，使得集群像一个整体的系统。mongos可以运行在任 何一台服务器上，有些选择放在shards服务器上，也有放在client 服务器上的。mongos启动时需要从config servers上获取基本信息，然后接受client端的请求，路由到shards服务器上，然后整理返回的结果发回给client服务器。3 > config server：存储集群的信息，包括分片和块数据信息。主要存储块数据信息，每个config serv

6、er上都有一份所有块数据信息的拷贝，以保证每台config server上的数据的一致性。4 > shard key：为了分割数据集，需要制定分片key的格式，类似于用于索引的key格式，通常由一个或多个字段组成以分发数据与mysql对比跟mysqld一样，一个mongod服务可以有建立多个数据库，每个数据库可以有多张表，这里的表名叫collection，每个collection 可以存放多个文档（document），每个文档都以BSON（binary json）的形式存放于硬盘中。跟关系型数据库不一样的地方是，它是的以单文档为单位存储的，你可以任意给一个或一批文档新增或删除字段，而不会

7、对其它文 档造成影响，这就是所谓的schema-free，这也是文档型数据库最主要的优点。跟一般的key-value数据库不一样的是，它的value中存储 了结构信息，所以你又可以像关系型数据库那样对某些域进行读写、统计等操作。可以说是兼备了key-value数据库的方便高效与关系型数据库的强大功 能。Nginx按照db到collection（相当于表的概念）做的配置location /pics/     gridfs pics            &#

8、160;  field=filename              type=string;    mongo 127.0.0.1:27017;  gridfs：nginx识别插件的关键字pics：db名root_collection: 选择collection，如root_collection=blog， mongod就会去找blog.files与blog.chunks两个块，默认是fsfield：查询字段，保证m

9、ongdb里有这个字段名，支持_id, filename, 可省略, 默认是_idtype：解释field的数据类型，支持objectid, int, string, 可省略, 默认是intuser：用户名, 可省略pass：密码, 可省略mongo：mongodb url配置replica sets的问题问题这时候如果Secondary宕机，那么Primary会怎么样呢?Primary会立刻变成Secondary!这时候集群里没有Primary了!为什么会出现这样的情况呢。原因 这是和MongoDB的Primary选举策略有关的，试想如果情况不是Secondary宕机，而是网络断开，那么两个

10、节点都会选取自己为 Primary，因为他们能连接上的只有自己这一个节点。而这样的情况在网络恢复后就需要处理复杂的一致性问题。而且断开的时间越长，时间越复杂。所以 MongoDB选择的策略是如果集群中只有自己一个节点，那么不选取自己为Primary。解决方法 所以正确的做法应该是添加两个以上的节点，或者添加arbiter，当然最好也最方便的做法是添加arbiter，aribiter节点只参与选举，几 乎不会有压力，所以你可以在各种闲置机器上启动arbiter节点，这不仅会避免上面说到的无法选举Primary的情况，更会让选取更快速的进行。(因 为如果是三台数据节点，一个节点宕机，另外两个节点很

11、可能会各自选举自己为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 -

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，当不是写密集操作时，而仅仅是因为存储空间不够了，这个shard key我们可以选用一些无上限范围的key，如创建时间等，这样新创建的记录都会写入新的分片服务器上。当需要使每个分片均匀分布数据时，或者写入密集时，最好选用有一定范围值的key ，当然这个范围不能太小，像性别，真假等，这会导致只自动产生两个分片，所以一定要选择合适的shard key才能达到理想的效果。关于MongoDB数据库的自动分片技术就介绍到这里，希望通过本次的介绍能够带给您一些收获。一期使用强磁盘型应用：192.168.1.135 作为config+route和sets的一部分192.168.1.133 作为sets 的另一部