最近，我在研究学习关于现在项目中存在很常见的问题“在文件下载的时候，文件也很大，比如15M”，访问的并发量也大。我们的做法是：
把整个文件存放在数据库中，每次下载从数据库中读取，这样的结果导致系统反应缓慢，可能死去。
后来我们做了一个文件系统，就是下载的时候，从文件系统直接下载，不用从数据库读取了，这样速度是快点，在这个过程中，我们也采用了压缩流。下载速度好写，、
我看了这样的结果后，我的想法是，我觉得这样你没有从根本问题出发来解决问题，这样，并发量一再多那么一点，就不行了，反正这个下载过程的原理都是一样的，都是二进制文件读取，我没有想到什么好的方法解决？我唯一想到的就是把文件系统做一个文件系统集群？这样肯定好得多，不知道这个问题有什么更好的技术？
可参考 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
谢谢的建议：
我在看设计模式的时候，我发现原型模式，我怎么都不怎么明白，在实际项目中，我们什么情况下可以用的原型模式了？
常规做法，不管走哪条路，最终还是从文件系统存取。所区别的只是，是让数据库管理，还是不让数据库管理？通过数据库，当然带来许多方便性和灵活性，但是得付出代价－－系统开销大了。
至于并发，如果直接访问文件系统，并发就得自己来做。更麻烦的是，还要妨害其它软件对这些文件的访问。
对，说的是这样，但是要每个行业的领域里面，这些业务的需求和实现的不可避免的，所以也只有这样做，当然肯定会有不好之处，可以适当的设计解决不好之处！