还剩4页未读,继续阅读
文本内容:
大数据存储需求管理需求动态添加删除用户用户容量控制用户流量,网速控制用户灵活配置性能需求响应时间lops指标吞吐量指标稳定性24小时无故障服务大数据量情况iops指标无明显变动大数据量下吞吐量指标无明显变化系统负载在一定阀值下服务监控系统完善主要是对cpu内存,网络,io容错高可用在无自然灾害性的真个机房出现故障的情况下24小时服务系统奔溃后可恢复服务容灾备份可扩展性支持在线横向扩容支持在线纵向扩容节点自动感知数据格式支持二进制小文件图片文件视频文件大文件大文件随机读大文件随机写1不容易实现)接口大小文件支持类posix的接口支持rest接口(前期不一定实现)最好能支持读写别离的锁测试写测试随机写测试读测试随机读测试并发读写测试上量读写测试测试平台分布式测试平台本质是一个必行任务系统,可以有多种的实现方式,原理如下如由控制节点发出测试开场的指令,测试机根据挂载的测试任务,进展并发测试,完毕后,将结果返回给任务分发机器,经过统计,返回给测试任务控制机实现方式使用自动化测试框架(未使用过)自写并行任务分发系统,进展测试利用hadoop等开源软件进展测试,入mapreduce可以再map中进展测试任务,由reduce汇总测试结果,reduce个数设置成1整体框架灰色表示第一版本不需要实现的局部,现在需要是先的局部部署的局部主要是在分布式存储和开放服务以及上层的接口图片应用需求创立用户创立命名空间,即文件夹创立操作员,该操作员只能操作指定的用户空间上传,下载,删除,获取图片属性,去除缓存图片类型识别,动态转换设置图片特有格式如请求〃img.fw/xx.jpg可用〃img.fw/xx.jpg!small访问small格式的图片,small格式定义为:10*5的图片,或是其他类型,如等高,等宽等每一个命名空间可以有不同的格式限定实时性保证为支持如相册实现方法根据图片的特性和和应用,图片存储主要是得构造是如下其中黑色线条表示在实现中可不必实现例如,某张图片原图格式是jpeg1024*768大小,在请求是的时候请求的是200*100的大小,请求图片存储时并没有需要的的大小,需要经过转换,缓存服务拿到原图,在图片处理服务处理后,将处理后的图片缓存在本地的缓存中,因为这类的请求,并不是持久性的请求,比方客户页面在更改,第一版按照200宽的等宽显示,两天后,客户页面修改,将缩略图改为300等宽,这样,如果存储到图片存储中,因为前端的修改,图片请求的格式在不断的变化,如果存储起来,会浪费很多存储空间,这种变化的可能会导致存储的数十倍的浪费分布式系统分布式系统是需要的,主要是两个方面,第一是自动进展冗余备份,其次是提供动态扩容的方便,选择适宜的分布式系统是对比好重要的前置机在图片存储服务,甚至大局部的文件存储服务中,读写的差异很大,读写请求的数量差异也很大,一张图片,写次数屈指可数,读的次数多大千万次,读服务请求的数量也很多,读写请求的完成质量也有差异,写请求失败,数据很有可能丧失,或者造成•段时间内整体读服务不能完成而读请求失败一次,影响却很小,可以通过其他节点,或者备份节点弥补,所以在上面的架构体系统,将读写请求分开以前置机来出来方案Tfs或者fastdfs这个用作用图片存储的优点是这两个系统开发意图就是为了图片存储,也为图片存储做了大量的优化,对大量小图片的支持很好,访问速度,稳定性,数据一致性保证都很好都不需要二次开发,直接可以使用,并且提供了nginx的模块,可以很容易配置访问方式缺点是都不支持posix类接口,实质是属于key-value类型接口在作为云端存储的时,需要在外围做大量的开发工作,维护user-namespace-pic的关系使用如kv方式存储底层是用大型的分布式文件系统,上层是用key-value存储存储文件的方式也可以对百亿级别的图片文件进展存储,但是文件需要经过切片进展存储,如果切片大小4k常规图片的大小是20k左右,比方图片是21k可以通过将图片文件切成4k固定的大小,分prefix+0-6的方式存入key-value存储中,并且将相应的图片数据存入对应的顺序的key中,在读取图片的时候,将6个key取出,按照顺序组个数据,即可复原图片Kv方式也可以是用bitcast方式存储文件,即图片存在文件里,kv只存储文件名到元数据的以及数据位置的索引,但是在合并时需要做额外很多的处理,比方图片的删除,需要从kv中删除,并且从数据文件中删除图片的那段数据,合并需要额外的调度,kv系统的自动合并并不能满足需求大文件存储需求数个性设置多用户请求支持随即读支持,支持客户端请求文件内任意位置任意长度的数据断点续传功能校验功能大文件存储的几个问题文件分块支持文件分块,为随即读提供分块机制,可以多情况下,可以提供多机并行读取,可在集群中自动分配,并自我修复,如果出现某台服务器宕机,可以再其他机器复制,保证数据的安全和向外提供服务的性能支持追加对某些大文件,可能客户未必会一次性的将数据全部传送到服务器上,需要恢复上一次的传输状态,这样就需要一个端点续传,即追加功能的实现,对并行的断点续传暂时先不考虑安全校验因为要支持追加模式的存储,为了保证数据的完整性,要对文件的内容保证是完整的,通过对文件的md5或者shal等校验方式,保证上传的文件与源文件的一致性性能要求为了使数据能及时到达前端的缓存,底层的文件系统,需要对性能有一定的要求,如果前端节点是100那没上传一个文件,在一样的时间内,需要有将数据分发到一定数据节点的能力,甚至更高因为中心存储,做数据持久化存储,前端缓存节点,可能会在一定周期内淘汰冷数据,比方说一个设置不当,某几个节点,在拿到5g的is镜像文件后,一小时后从存储中淘汰,而两小时后又有用户请求从该节点请求文件,并且cdn调度该节点做缓存,该节点需要从中心存储中取出文件,缓存则中心节点,需要能应对这样的请求支持并发请求同时的多客户端接入,必须支持多客户端同时相应请求,负责会有客户端饿死,处于性能的考虑,尽量让一个文件,分布在多个磁盘,server±保证性能Gluster比方是有两个,10个客户同时请求,每个请求的数据段也不同,因为gluster是按照源文件存储,对这种访问,存储服务器只能不断的根据请求的顺序,不同进展磁盘寻到,不能充分利用多磁盘带来的性能提升即使是私有数据格式的文件分块方式,也存在这种问题,只能是尽量减少寻到次数尽量降低寻道时间文件大小限制对没有私有数据格式的文件存储,文件按照原有的数据格式进展存储,这样的文件会有大小限制,受限于磁盘的大小,gluster现在是我们重点攻关的工程,在这方面就存在磁盘大小的限制一些块存储系统,如hdfs等文件系统,则不会出现文件大小限制问题,因为本身hdfs不受制于磁盘大小的限制,受制于namenode节点内存的限制,如果文件很大,倒是内存存不下inode会导致文件无法存下去文件大小限制并不是一个很棘手的问题,因为现阶段,服务器磁盘都是用2T的磁盘,单个磁盘容量已经足够大,很少有能突破这个极限的大文件存在响应时间对单个一个range请求,响应时间不宜过长,按照常规的说法,应该在10ms以内流量控制对客户端做流量控制,如上海节点可能网络状况较好,一段时间内,请求大量数据,占用大带宽,导致新疆节点一直在排队请求,得不到数据,对新疆节点的服务造成影响测试测试Gluster。