ap4249e0w_个人页

个人头像照片 ap4249e0w
0
2
0

个人介绍

暂无个人介绍

擅长的技术

获得更多能力
通用技术能力:

暂时未有相关通用技术能力~

云产品技术能力:

暂时未有相关云产品技术能力~

阿里云技能认证

详细说明
  • 提交了问题 2012-11-07

    严重问题:无法确保文件完整性

暂无更多信息
正在加载, 请稍后...
暂无更多信息
  • 提交了问题 2012-11-07

    严重问题:无法确保文件完整性

  • 回答了问题 2012-11-07

    严重问题:无法确保文件完整性

    Re严重问题:无法确保文件完整性 事实上我们在一个繁忙的产品环境上就遇到了这个问题,给我们带来了不小的损失。 ------------------------- 回3楼wood23的帖子 引用第3楼wood23于2012-11-08 14:32发表的 回1楼ap4249e0w的帖子 : OSS已经返回了400或者根本没有返回200,这个时候这个object是可能会不完整的。建议在上传的时候判断返回码是否为200,并在上传文件的时候自定义header例如x-oss-meta-md5, 用来下载的时候建议文件的完整性。 1. 我的上传和下载是异步进行的,并且在无法互相通讯的不同服务器上 2. 上传的时候自定义的header必须等到下载方下载完成才能校验,无法实现在下载前确认完整性的需求 3. 官方提供的PHP SDK中设置header的函数有bug ------------------------- Re严重问题:无法确保文件完整性 引用第6楼sanbo于2012-11-09 19:55发表的  : 楼主,对于传统文件系统,写文件写到一半异常退出,操作系统也会留一个不完整的文件在磁盘上。 对于多个客户端同时写同一个Object的情况,最后的Object会写成什么样子是无法预知的。我们目前建议用户在自己的逻辑端避免这种并发写的问题(因为传统的文件系统也不支持对同一个文件的并发写)。 目前我们推荐的标准解决方案是: 1. 生成一个UUID作为Object的名称,然后客户端把数据写入这个Object; ....... 我抱怨的不是并发写,也不是写到一半异常退出,而是A客户端写入操作的过程中B客户端应该有办法知道这不是一个完整的文件而避免去读取它,或者让B无法读取到任何文件。请不要拿传统文件系统做比较,传统文件系统也提供了系统级别的文件句柄和共享锁。即使并发写,云存储也应当有合理的反馈信息(例如写锁定和锁定超时)。云存储中这种需求非常常见,阿里云存储需要的是改进而不是为错误辩解。你推荐的所谓标准解决方案要求你们的客户做了额外的事情。或许能解决问题但是这是不负责任的。期待你们下一版本的写一致模型。
    踩0 评论0
正在加载, 请稍后...
滑动查看更多
正在加载, 请稍后...
暂无更多信息