关于下载文件过大,并发也很高的时候?

12-02-14 javawebkaifa
最近,我在研究学习关于现在项目中存在很常见的问题“在文件下载的时候,文件也很大,比如15M”,访问的并发量也大。我们的做法是:

把整个文件存放在数据库中,每次下载从数据库中读取,这样的结果导致系统反应缓慢,可能死去。

后来我们做了一个文件系统,就是下载的时候,从文件系统直接下载,不用从数据库读取了,这样速度是快点,在这个过程中,我们也采用了压缩流。下载速度好写,、

我看了这样的结果后,我的想法是,我觉得这样你没有从根本问题出发来解决问题,这样,并发量一再多那么一点,就不行了,反正这个下载过程的原理都是一样的,都是二进制文件读取,我没有想到什么好的方法解决?我唯一想到的就是把文件系统做一个文件系统集群?这样肯定好得多,不知道这个问题有什么更好的技术?

1
banq
2012-02-15 15:52
可参考 Facebook文件存储Haystack:

Photo Store Server : 负责接收HTTP请求,然后翻译成相应的 Haystack存储操作 (将所有元数据加载在内存中)

Haystack Object Store : Index(meta data) + Data

Filesystem(XFS) : Haystack object stores是运行在每个最大容量10TB的文件中

•Storage(Blade server): 2 x quad-core CPUs, 16GB –32GB memory, hardware raid controller with 256MB –512MB of NVRAM cache, 12+ 1TB SATA drives

javawebkaifa
2012-02-17 09:49
谢谢的建议:

我在看设计模式的时候,我发现原型模式,我怎么都不怎么明白,在实际项目中,我们什么情况下可以用的原型模式了?

beepbug
2012-03-09 12:51
常规做法,不管走哪条路,最终还是从文件系统存取。所区别的只是,是让数据库管理,还是不让数据库管理?通过数据库,当然带来许多方便性和灵活性,但是得付出代价--系统开销大了。

至于并发,如果直接访问文件系统,并发就得自己来做。更麻烦的是,还要妨害其它软件对这些文件的访问。

javawebkaifa
2012-03-10 22:57
对,说的是这样,但是要每个行业的领域里面,这些业务的需求和实现的不可避免的,所以也只有这样做,当然肯定会有不好之处,可以适当的设计解决不好之处!

猜你喜欢