5
回答
java 访问文件系统,读写锁
利用AWS快速构建适用于生产的无服务器应用程序,免费试用12个月>>>   

前提:大部分人都说文件不要放到数据库,放到文件系统。 

问题:把文件存到文件系统的指定目录后, 是否需要读写锁来控制呢? 这个锁应该控制到整个目录呢,还是具体的文件?   如果是具体的文件,  那每个文件的锁需要记录下来,我测试了一下,用map<filepath, Lock> 记录这些文件锁,还是比较耗内存的,100w个文件要15m左右的内存。 消耗比较大。所以在这里求建议,求最佳实践~~

既然很多人这么说,大家经验应该比较丰富的,大家指点一下,或者给个参考。

@红薯  我看了你以前分享的 oschina 关于上传文件存储的那个代码,没有任何 同步、锁的控制,  这样没有问题么?

----------------------------------------------------------------------------------------

算了,自己测试吧, 一时半会儿等不到结果。  把锁放到整个目录上针对2个20M的文件(2级目录)进行读写测试,同时开了300个读线程, 10个写线程, 随机读写这2个文件, 时间上均能接受。

<无标签>
举报
子木007
发帖于4年前 5回/685阅

以下是问题补充:

  • @子木007 :先这样吧, 知道更好的方法再改进~~~~ (4年前)
共有5个答案 最后回答: 4年前
上传个文件 而已 ,没必要搞得这么麻烦把 。又不是 高并发 精细 操作 某个文件
--- 共有 4 条评论 ---
红星xx回复 @坑主 : oschina 的架构是 不需要 tomcat 读的 , 它的附件都被前面的 nginx 拦截了 ,nginx直接将 硬盘上的文件 发出去了。tomcat只处理 上传 IO ,上传完毕后就不关tomcat的事了, 不知道你为什么要测试大量 读 性能。 4年前 回复
子木007回复 @红星xx : 嗯。 业务逻辑上是个方向。 但现在抛开业务不说主要是想知道针对这个锁的问题。 4年前 回复
红星xx回复 @坑主 : 有正规的录入 ,建议从流程上控制 。附件不完整 打回重录 ,上传的话 ,成功就不成功 ,不成功就不成功 ,也很好判断,上传几率很小的 , 就算有漏网之鱼 ,打回重录也可以忍受 。 4年前 回复
子木007不是普通的网站、论坛之类的东西,丢了就丢了,乱了就乱了。 上传的文件都是重要,要审计、认证。 不能那么大意 4年前 回复

呵呵,100w个文件?你内存够吗?能打开那么多文件吗?

linux下

cat /proc/sys/fs/file-max

一般也就几万个,文件描述符都不够用

--- 共有 3 条评论 ---
子木007回复 @RisingV : 谢谢,没想到这个 4年前 回复
RisingV回复 @坑主 : 不是同时打开就可以加个老化算法,根据自己的业务场景,控制住Map的大小 4年前 回复
子木007不可能同时打开。主要是想知道这个锁的粒度 4年前 回复
顶部