由于目前开发的网站较大，想把web服务器和文件服务器分离，有什么好办法？

目前要实现的功能是：在一台网络服务器上启动了was或者tomcat等web服务器，运行一个很大的网站，用户可以登录网站，然后上传文件和图片等，由于担心硬盘空间的问题，希望用户上传的文件等，能够上传并保存到另一台机器上，同时用户登录后又可以实时查看到自己之前上传的文件。
在网上搜索了一下，感觉nfs和samba可以实现类似的功能，于是我配置了nfs，怎么感觉只是一个文件共享的东东，和我的需求有一定的出入。
请问各位是怎么解决文件量过大的问题的？

取决于你的应用需求：
底层做的话直接扩充RAID，好处是可以对应用层完全透明，也可以用NAS、iSCSI，开源的有一些可以直接拿来用
或者更简易的，直接走ftp的形式，把存储转移到文件服务器，比NFS稳定性更好。
应用层做可以把存储服务剥离出来，存储管理业务放到文件服务器上，提供远程管理接口给WEB应用，同时直接对外提供web浏览接口

我的想法是，配置nfs，一台机器做server，一台机器做client，在client上运行应用服务器WAS，同时mount server上的目录，而用户上传的文件通过http协议直接上传到server上。
当用户访问client的应用服务器时，用nfs共享文件夹的模式，在页面呈现。
不知道这种方式是否可行？

有那么复杂么........把两台机器赋予不同的domain name,比如主机是 www.mysolution.cn, 文件服务器是photo.mysolution.cn,负责图片上传的servlet被部署在photo.mysolution.cn这台机器上,并存储图片的同时把图片的url比如http://photo.mysolution.cn/raylinn/2342S/23235da234.jpg, 写回www.mysolution.cn的数据库中，这样不就结了?

存储方面可以考虑用盘阵来解决
关于图片存储,有一种可行的方案(在历史条件和特定环境下)是各application server来mount nfs export出来的目录,然后按照不同的目录来区分是哪个application server写入,比如bj1,bj2,bj3.控制好目录结构,每个目录的多少及存储图片的量.这是上传图片的问题,一般情况下,建议上传的尽量使用独立的application server,不要和业务的或者说表面的server放在一起.对于已有的图片如何展示,用apache server来mount nfs的相应的目录,早期的时候可以采用一个至两个,以后可以按目录增多,提供图片的浏览服务,可以在apache server之前放一个squid来缓存图片,一个squid可以对应多个apache server,采用交叉的方式,对于图片访问采用独立的域名,比如:image1.xxx.xxx,image2.xxx.xxx,image3.xxx.xxx,这样子squid大约可以有并发1000+的图片吞吐.apache可以做到600+的并发吞吐.由于图片一般情况下属于非频繁修改资源,所以命中squid的cache的可以高达80%以上.
写入图片的时候写相对路径,不建议直接把域名带路径存储,在应用服务器上做转换,比如bj1=>image1.xxx.xxx,bj2=>image2.xxx.xxx,bj3=>image3.xxx.xxx
在相当大程度上可以解决由于上传图片和大图片浏览导致的web server或application server假死的问题.

我目前是利用rsync来做应用服务器与文件服务器的同步.用户上传的时候触发rsync.

一点经验
rsync在目录深的时候会出现问题
可能也许是当时我们没有解决掉

对于存储，考虑到扩展性，当然是直接上分布式的。

有资金支持，上NAS。快速，可靠，有良好技术支持。
如果要开源，直接上GFS。