web断点续传和秒传的逻辑思路

前端的思路大体已经了解了：分片

1. 用户选择文件，监听到文件内容变化后，拿到文件，通过FLASH或者H5对文件内容进行流读取，然后计算MD5值

2. 计算出MD5后，通过异步请求后端，查找该MD5是否已经存在，如果存在，相当于该文件已经存在了，此时就可以调过文件的上传过程，实现秒传；

当然，有可能是续传：那么此时，可以通过MD5确定到这个文件是哪个文件，同时，该文件已经上传成功的分片序号（或者标识），返回前端，由前端对分片序号（标识）进行校验，已经成功上传的分片则跳过；

3.如果MD5不存在，则是属于新文件，需要重头开始传，前端对文件进行分片，大小2M-5M，小于200M用2M，以上用5M

4.将文件分片后，通过校验，将没有上传通过的分片，通过异步，将内容提交给后台

5.后台接受到分片后，通过MD5值确定文件，通过分片内容及序号（标识）确定在文件中的位置，然后对分片进行拼接或扩容

6.由于是异步长传，可能分片的顺序并不是顺序提交的，所以需要可以对分片内容进行缓存，如果文件共10个分片，现在已经传递了3个分片，到第四个分片，此时判断提交的分片是不是第四个，如果是则拼接，拼接后，在缓存中查找是否有第五个分片，如果有，则继续拼接，以此类推；如果不是则缓存；如果拼接完成后继续更新数据库，防止传输中断，方面下次继续查找；

分片拼接的第二种方式：扩容，如果传递的是第二个，则把第一个空间留出来，等上传第一个的时候，再拼接上；这样会比较好点，不会耗内存；

上传完成后，更新数据库的标识，文件完整；

7.当分片全部上传完成后，文件则上传完毕，由于是hadoop服务器的存在，那么之前的操作 都是在项目中进行的，也就是说如果文件没有上传完成，则全部留在本地的临时文件夹中；

数据库表结构：

id : 主键ID

MD5 ： 文件的MD5值，

attachmentId : 附件ID，用来查找其他的属性，比如pdfpath或者高清或者一些其他的等等。

filePath : 文件的路径（可能是在hadoop服务器，也可能在本地的临时文件中，有可能上传完了，也有可能没成功）

iscomplete : 文件是否完整，在文件完成后更新

chrunklist : 已经成功的分片列表，通过查找，返回前端校验使用

实现方式：

1. 通过HTML5的API实现,额 这个有兴趣可以研究下，搞一搞

2. 别人家的东西，webuploader，百度的，对百度好感还是不错的

参考网址：

ps: 以下均为webuploader的参考文章，方便以后查找

断点续传和秒传参考： https://github.com/fex-team/webuploader/issues/142

github : https://github.com/fex-team/webuploader/tree/research/experiment

API : http://fex.baidu.com/webuploader/doc/index.html

逻辑讲解：　http://bbs.csdn.net/topics/391906102

webuploader issue : https://github.com/fex-team/webuploader/issues