浏览 3452 次
锁定老帖子 主题:文件批量压缩上传解决方案
精华帖 (0) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
---|---|
作者 | 正文 |
发表时间:2013-11-04
Linux系统下面有个A目录,他会不断的产生数据,不同类别的数据用不同的目录表示,例如A1,A2,A3,类别目录下面还有些小目录A11,A12,这些小目录就存放具体的文件(文件很小)。数据量大约每秒2-3G,现在要把这些数据压缩到B目录,然后上传到ftp服务器上,大致采用技术:考虑到数据会源源不断的产生,所以使用了定时器quartz,压缩方面使用了commons-io的zip压缩工具,上传则是使用ftpclient,有两个job,一个压缩一个上传,压缩每隔30s执行,上传每隔60s执行,压缩以A11、A12目录为名称,压缩完之后删除原目录。压缩好的包存放在B目录,对B目录的包进行上传。程序运行之后,发现A目录下面有大量的积压,上传还没有什么问题,估计是数据量太大了,请问有没有什么好的方案?? 声明:ITeye文章版权属于作者,受法律保护。没有作者书面许可不得转载。
推荐链接
|
|
返回顶楼 | |
发表时间:2013-11-08
我觉得可以后台跑一个长期任务,不断的压缩,只要发现有新的目录就压缩,而上传任务每一段时间生成一个上传列表,把上传的处理完了,再读重新 生成列表。压缩是个很费CPU和时间的操作,这一步没法节省!
|
|
返回顶楼 | |
发表时间:2013-11-08
首先,你要知道数据写完没。没写完的数据,就算你能读,能压,最后删除还是会失败的。也许这就算你文件挤压的原因?
要对文件锁进行处理和判断。 |
|
返回顶楼 | |
发表时间:2013-11-11
jadedrip 写道 首先,你要知道数据写完没。没写完的数据,就算你能读,能压,最后删除还是会失败的。也许这就算你文件挤压的原因?
要对文件锁进行处理和判断。 的确如楼上所说,以文件做接口的程序,很重要但是经常被忽略的一个问题是,消费端和生产端必须约定好文件何时写完。 |
|
返回顶楼 | |
发表时间:2013-11-16
jadedrip 写道 首先,你要知道数据写完没。没写完的数据,就算你能读,能压,最后删除还是会失败的。也许这就算你文件挤压的原因?
要对文件锁进行处理和判断。 文件锁在linux下是不支持的吧 |
|
返回顶楼 | |