コア原則：
プロジェクトのコアは、ファイルブロックをアップロードすることです。フロントと協力のハイレベルへの後端部には、双方は、我々は次のような問題を解決するためのプロジェクトに焦点を当てるの完全な大容量ファイルのセグメントに順番に、より良いデータを必要とすることに合意しました。
* どのように断片化。
* ファイルを合成する方法。
* 当初からのスライス中断。
プログラマの本質は、車輪を再作成するために私を余儀なくされたものの、ポイントは、私たちの仕事を容易にするために、強力なJSライブラリを使用して、市場での大きなファイルの車輪をブロックすることができた方法。しかし、関係のだけでなく、作業時間ので、私はあきらめることができます。最後に、私は希望のフロントエンドを達成するためにBaiduのWebUploaderを選択しました。
どれだけ近いか、終了する前に、まず私たちはブロックが属するファイルを区別しないか、問題を解決しなければなりません。初めに、私はユニークなUUIDを生成するためのフロントエンドを使用していたことは、各スライス要求に置く記号文書を、行います。しかし、その後、ときに私はブロックとファイルの関係を維持するためにMD5を使用、第二のパスを放棄します。
マージファイルの問題のサーバー、およびレコードのブロッキングが、この点で業界は、実際に良い解決策を与えています。サンダーを参照すると、あなたはそれぞれのダウンロード時間は、二つのファイル、ファイル本体が存在するであろうことがわかります、別のファイルは、一時ファイル、バイト位置を対応する各ブロックの一時ファイルが格納状態です。
これらは、要求数とサイズを持参する前端と後端との密接な接触をする必要があり、ファイルの断片化への固定サイズの必要性のフロントエンド、および断片化されています。成功した送信要求をサーバによれば、背景の前端部に達した後にのみ要求データスライス番号する必要があり、（セグメントのサイズは固定され、同じ）の開始位置を計算し、リードセグメントデータファイル、書き込みされた各ブロックのサイズをスライスファイルに。
開発を容易にするために、私はサービスのビジネス・ロジックは、初期化、ブロック処理などでアップロードされたファイルに分け、以下の終了します。
サーバー側のビジネスロジックモジュールは、以下の
機能解析：
フォルダ生成モジュール
フォルダは、サーバスキャンコードによってアップロードされた後、次のようです
アップロード・ブロックは、論理ブロックを処理する最も簡単なロジックであるべきで、UP6ファイルは、各ブロックと識別データブロックを有し、識別インデックスファイルブロックサイズ、オフセット、ファイルを含みますプロセスは非常に便利です後MD5、ファイルブロックMD5（オープンが必要）やその他の情報は、サーバーは、情報を受け取ることができます。例えば、ブロックデータが分散ストレージシステムに格納されています
分块上传可以说是我们整个项目的基础，像断点续传、暂停这些都是需要用到分块。
分块这块相对来说比较简单。前端是采用了webuploader，分块等基础功能已经封装起来，使用方便。
借助webUpload提供给我们的文件API,前端就显得异常简单。
前台HTML模板
分则必合。把大文件分片了，但是分片了就没有原本文件功能，所以我们要把分片合成为原本的文件。我们只需要把分片按原本位置写入到文件中去。因为前面原理那一部我们已经讲到了，我们知道分块大小和分块序号，我就可以知道该分块在文件中的起始位置。所以这里使用RandomAccessFile是明智的，RandomAccessFile能在文件里面前后移动。但是在andomAccessFile的绝大多数功能，已经被JDK1.4的NIO的“内存映射文件(memory-mapped files)”取代了。我在该项目中分别写了使用RandomAccessFile与MappedByteBuffer来合成文件。分别对应的方法是uploadFileRandomAccessFile和uploadFileByMappedByteBuffer。两个方法代码如下。
秒传功能
服务端逻辑
秒传功能，相信大家都体现过了，网盘上传的时候，发现上传的文件秒传了。其实原理稍微有研究过的同学应该知道，其实就是检验文件MD5，记录下上传到系统的文件的MD5,在一个文件上传前先获取文件内容MD5值或者部分取值MD5，然后在匹配系统上的数据。
Breakpoint-http实现秒传原理，客户端选择文件之后，点击上传的时候触发获取文件MD5值，获取MD5后调用系统一个接口（/index/checkFileMd5），查询该MD5是否已经存在（我在该项目中用redis来存储数据，用文件MD5值来作key，value是文件存储的地址。）接口返回检查状态，然后再进行下一步的操作。相信大家看代码就能明白了。
嗯，前端的MD5取值也是用了webuploader自带的功能，这还是个不错的工具。
控件计算完文件MD5后会触发md5_complete事件，并传值md5，开发者只需要处理这个事件即可，
断点续传
up6已经自动对断点续传进行了处理，不需要开发都再进行单独的处理。
在f_post.jsp中接收这些参数，并进行处理，开发者只需要关注业务逻辑，不需要关注其它的方面。
断点续传，就是在文件上传的过程中发生了中断，人为因素（暂停）或者不可抗力（断网或者网络差）导致了文件上传到一半失败了。然后在环境恢复的时候，重新上传该文件，而不至于是从新开始上传的。
前面也已经讲过，断点续传的功能是基于分块上传来实现的，把一个大文件分成很多个小块，服务端能够把每个上传成功的分块都落地下来，客户端在上传文件开始时调用接口快速验证，条件选择跳过某个分块。
实现原理，就是在每个文件上传前，就获取到文件MD5取值，在上传文件前调用接口（/index/checkFileMd5，没错也是秒传的检验接口）如果获取的文件状态是未完成，则返回所有的还没上传的分块的编号，然后前端进行条件筛算出哪些没上传的分块，然后进行上传。
当接收到文件块后就可以直接写入到服务器的文件中
这是文件块上传的效果
这是文件夹上传完后的效果
这是文件夹上传完后在服务端的存储结构
