利用seaweedfs支持多文件合并上传

        在日常文件处理这一块，我们经常会有大文件处理的需求，这个文件有可能有100M以上，甚至更高。针对这种情况，如果直接上传到seaweedfs上面，受制于网络，服务器情况，单个文件过大，稳定性就会大打折扣。在查看了seaweedfs之后，Large-File-Handling(https://github.com/chrislusf/seaweedfs/wiki/Large-File-Handling).仔细阅读之后，大概意思就是。seaweedfs的高可用是建立在处理小文件的前提下，因为文件会加载到seaweedfs的内存之中。在文件拆分这一块，内置是提供了filer这个服务来处理，它会自动处理这个问题。以过分析，我果断放弃，就像我对DB的理解一样，把数据存储搞定就行了。中间件就专注做好本职内的事情。所以我转向了另外一种解决办法，改为由客户端自行处理。我们可以根据实际情况，调整单个包的大小，最好控制在10M以内，当然做成可配置是更好。然后把每个文件的信息整理成一个json对象，并命名为Manifest，告诉seaweedfs，这个大文件是由1，2，3。。。。这几个文件合并而成。详情请参考https://github.com/chrislusf/seaweedfs/blob/master/weed/operation/chunked_file.go#L24

因为是go写的，大家看着可能有点不太习惯。我整理了java的模板，如下：

文件明细:ChunkInfo

                 fid:产生的唯一文件编码(7,169aba906a)一定是带逗号，具体这个编码的规则，大家去查看我之前写的https://www.jianshu.com/p/32239852d984。访问文件地址，http://127.0.0.1:9081/7/169aba906a/test1.zip

                offset:文件读取的起始位置，如果是第一个文件就是0，如果是下一个文件，这个值就是上一个文件的结束位置

                 size:当前文件大小，以字节为单位

批量文件集合:ChunkManifest

                  name:新的文件名称

                  mine:文件类型，可以参考httpclient

                 size:合并之后的总文件大小，其实就是所有拆分文件的总合

                  chunks:上面ChunkInfo的集合

现在给一个实际的对象，大家看起来会更有感触：{

  "name" : "allin.zip",

  "mine" : "zip",

  "size" : 127646446,

  "chunks" : [ {

    "fid" : "7/169aba906a",

    "offset" : 0,

    "size" : 52428800

  }, {

    "fid" : "4/177d5cadcc",

    "offset" : 52428801,

    "size" : 52428800

  }, {

    "fid" : "3/18f0e181ff",

    "offset" : 104857601,

    "size" : 22788846

  } ]

}

这个对象整好之后，通过httpclient，走一般的seaweedfs文件上传流程，拿到ID，再把这个对象发送出去，成功之后就可以通过新的ID来访问这个合并之后的文件了。