论坛首页 Java企业应用论坛

多机集群对上载文件的处理方式小结

浏览 4150 次
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
作者 正文
   发表时间:2013-02-04  
    公司为了好几个产品间的数据同步与共享,要求产品部做出个方案来,对于这个问题,要满足两个条件:1 应用集群2 多机集群,所以针对多机应用集群的上载文件处理可以采用以下几种方式。
1. 存入数据库
将上载的文件存入数据库可以很好解决这个问题,目前主流数据库对大字段都有很好的支持,如oracle等。
  应用范围:集群中的各个应用共用一个数据库(或数据库集群),对于文件的读取则不再有任何问题。
  缺点:1. 如果不同的应用对数据的处理量较大,则存库的内容就会导致数据库的数据量非常大,数据库的开销较大,影响整个应用的性能。
        2. 对于应用集群共用一个库,不是很现实,尤其是那些有自己应用系统特殊权限的,对库的控制较严。
2. 采用共享目录
设置一个共享目录,将上载文件存储在这个共享目录中,集群中的各个应用均访问这个共享目录即可。
对于共享目录,现在有比较成熟的技术,如NFS。

独立的文件服务器
把上传下载的部分独立成web系统,对不同的系统应用提供单独的接口。
应用范围:需要自己开发组件,控制上传与下载。可以利用socket、FTP协议与服服务器端做连接。
优缺点:
     1. 自己写服务端与客户端组件。纯socket通信、或者是借用mina框架,并发性、性能不好不一定有很好的效果。
     2. 利用开源的组件搭建服务端。只需写客户端。 像FTP服务器,本身就支持大文件的数据传输。自己开发客户端,但是对上传下载的控制,不好处理。对第三方组件的依赖性,第三方组件对系统环境的依赖性等都比较繁琐。
     3. 第三方开源的文件服务器。例如 淘宝的开源文件系统 :TFS。以及像 fastFS。Hadoop的hdfs等等。其都是建立在特定的应用中。TFS就是正对小文件的海量存储。虽然在性能、集群、容灾方面都有不存的表现,但是对于不同的应用,不一定满足自己的应用。
 
     从以上角度来看,共享目录还是中小企业比较实用并且有效的方法。大家有什么看法,可以继续探讨。技术上,方案上,随便说。。。
   发表时间:2013-02-09  
对你的具体业务不是太了解,就随便说一下。

以上三种方案中 
方案 1.基本上就不用考虑了,唯一的优点就是简单,不管是从性能还是从上线后风险评估这个方案都不靠谱

方案 2.如果公司或者项目组以前在这方面有过类似的经验,而且项目时间计划充足的情况下 可行,

方案 3.无可厚非,自己做的东西肯定是最放心的,如果出问题也好查。


其实我觉得最简单的方案,直接用ftp服务器就行,调ftp的接口。不管是大文件还是小文件ftp都支持的很好(主要是web项目,如果文件上传或者下载失败了没事儿提示用户在做一次操作就行了啊)
0 请登录后投票
   发表时间:2013-02-10  
用mongodb吧,它是专门存储共享文件用的。原本我们用ECM可惜,效果不是太好。
0 请登录后投票
   发表时间:2013-02-12  
longfeisoft 写道
用mongodb吧,它是专门存储共享文件用的。原本我们用ECM可惜,效果不是太好。

兄弟,我没用过mongodb,既然是数据库,那么如果多个系统之间共享数据,不是每个系统都需要有该数据库的访问权限???
0 请登录后投票
   发表时间:2013-02-12  
zxywithal 写道
对你的具体业务不是太了解,就随便说一下。

以上三种方案中 
方案 1.基本上就不用考虑了,唯一的优点就是简单,不管是从性能还是从上线后风险评估这个方案都不靠谱

方案 2.如果公司或者项目组以前在这方面有过类似的经验,而且项目时间计划充足的情况下 可行,

方案 3.无可厚非,自己做的东西肯定是最放心的,如果出问题也好查。


其实我觉得最简单的方案,直接用ftp服务器就行,调ftp的接口。不管是大文件还是小文件ftp都支持的很好(主要是web项目,如果文件上传或者下载失败了没事儿提示用户在做一次操作就行了啊)



我们的业务是想在系统中通过组件调用,跟共享的数据进行打交道,如果是ftp服务器,必须还要依赖第三方的ftp服务器,这样在只要写客户端就好了,但是这样不好写组件啊 
0 请登录后投票
   发表时间:2013-02-13   最后修改:2013-02-13
-- 我想了想,还是多看看你的业务场景,上载~~嗯~~~我的经验是用NAS
0 请登录后投票
论坛首页 Java企业应用版

跳转论坛:
Global site tag (gtag.js) - Google Analytics