maddemon · May 30, 2013 06:39
diff --git a/gistfile1.txt b/gistfile1.txt

 Tus协议地址http://www.tus.io/protocols/resumable-upload.html，大家可以看看英文原文介绍，我这里也简单介绍下。
 这是一个基于http的可续传的协议，主要是不同的HttpMethod和相关的自定义header来实现续传功能。
 具体的Method和header介绍：
 1、HEAD
 head请求是获取文件已上传的状态，服务端返回该文件哪些范围已写入，哪些没写入。
 (PS，我刚发现协议已经变了，以前不是offset）
 但是我这个实现和tus也略有不同，我支持一个文件可以多线程同时上传，所以不能完全追寻他的协议。
 客户端接收到的header例子：
 range:bytes=0-9,20-29
 意思表名0-9和20-29这俩个块已被写入，所以续传的时候不需要上传了。
 如果接收到的是 range:bytes=0-1023（假如文件就1024长度，那么说明文件已上传完毕）

 2、POST
 post请求是用于创建文件，header里必须要有声明文件的大小，例如
 content-range:*/1023  这说明文件的大小是1024。

 返回结果：告诉客户端这个文件的地址，好让客户端知道往什么地址PUT数据。例如：
 Location: http://tus.example.org/files/24e533e02ec3bc40c387f1a0e460e216

 3、PUT
 put请求是上传文件用的，如果想实现续传，那么就要把文件拆分为N个小块，按块上传，这样如果断掉，下次可以通过HEAD请求看到哪些块已经上传。

 4、GET
 get请求就是下载文件，这里不必多说了。

 协议大致如此，只是相对于tus原本的协议有所变化（可以多块同时上传，所以并非是顺序上传，在Head请求的返回自然有所变化）。

 协议实现思路：
 客户端分块上传，服务端接收到每个块之后存储到服务端。如何记住哪些块被上传了呢？
 我的实现思路是需要一个metadata的辅助元数据文件来继续这个文件的上传状态、文件大小、文件原名称等等。
 现在是用文件存储的metadata，这只是一个demo，如果是真正使用，我想用数据库更合适一些。

 我走的弯路：
 第一次：
 如何实现块能够写入到目标文件里？这个问题也和以前的同事交流过，当时没有找到解决办法。除非顺序写入然后用append的模式。
 但是客户端上传确实多线程非顺序上传，服务端该如何保证顺序？
 最后的解决办法是把客户端上传的每一个块保存为单个小文件，每次上传完一个块之后判断是不是所有的块上传完毕，如果上传完毕做一次合并。

 判断文件块是否写完，我就要遍历每一个小文件，判断他们是否连续。由于nodejs的文件操作需要异步，所以实现起来需要写各种递归，异常痛苦，大家可以看我的GitHub提交的历史版本，最老的版本里面有很多递归。代码非常丑陋，而且难以维护。

 第二次：
 为了减少递归，我使用global全局缓存，而且限定了文件上传的块的大小必须一样，没上传完一个块，我就把他存储到global缓存里。这样就不需要遍历小文件，减少了很多异步操作，代码清晰了很多。

 第三次:
 小文件合并的方案虽然可行，但毕竟感觉有些愚蠢，如果是特别大的文件，那可以想象合并和遍历都很慢，管理也不方便。所以如果能解决Nodejs的按offset写入stream的问题就可以解决。我又翻了下Nodejs的文档，发现以前使用的都是w和w+的打开方式，这种打开方式会清空文件的内容，而r和r+不会。
 于是我尝试着修改了代码，由于是并发写入，实际上文件写入是不能并发的，所以需要加锁，当块写入的时候判断是否锁住就可以了。
 这一下去掉了好多的代码，代码更加的明亮起来。


 为什么用NodeJS？ 因为这是一个面试题的作业，所以必须用Nodejs。
 我在FileMetadata初始化是依然用的fs.readSync，我以前同事告诉我nodejs不可以使用sync方法，这样会hold住整个进程。这是现实太恐怖了。
 所以我个人觉得nodejs的弊端也很明显，对代码复杂度的增加显而易见。 至于Javascript的非阻塞的先天优势，其他的语言也可以做到。那为什么还用Nodejs呢？而且Javascript的语法比较弱，很多实现都比较困难。我对nodejs没有太多好感。

	Tus协议地址http://www.tus.io/protocols/resumable-upload.html，大家可以看看英文原文介绍，我这里也简单介绍下。
	这是一个基于http的可续传的协议，主要是不同的HttpMethod和相关的自定义header来实现续传功能。
	具体的Method和header介绍：
	1、HEAD
	head请求是获取文件已上传的状态，服务端返回该文件哪些范围已写入，哪些没写入。
	(PS，我刚发现协议已经变了，以前不是offset）
	但是我这个实现和tus也略有不同，我支持一个文件可以多线程同时上传，所以不能完全追寻他的协议。
	客户端接收到的header例子：
	range:bytes=0-9,20-29
	意思表名0-9和20-29这俩个块已被写入，所以续传的时候不需要上传了。
	如果接收到的是 range:bytes=0-1023（假如文件就1024长度，那么说明文件已上传完毕）

	2、POST
	post请求是用于创建文件，header里必须要有声明文件的大小，例如
	content-range:*/1023 这说明文件的大小是1024。

	返回结果：告诉客户端这个文件的地址，好让客户端知道往什么地址PUT数据。例如：
	Location: http://tus.example.org/files/24e533e02ec3bc40c387f1a0e460e216

	3、PUT
	put请求是上传文件用的，如果想实现续传，那么就要把文件拆分为N个小块，按块上传，这样如果断掉，下次可以通过HEAD请求看到哪些块已经上传。

	4、GET
	get请求就是下载文件，这里不必多说了。

	协议大致如此，只是相对于tus原本的协议有所变化（可以多块同时上传，所以并非是顺序上传，在Head请求的返回自然有所变化）。

	协议实现思路：
	客户端分块上传，服务端接收到每个块之后存储到服务端。如何记住哪些块被上传了呢？
	我的实现思路是需要一个metadata的辅助元数据文件来继续这个文件的上传状态、文件大小、文件原名称等等。
	现在是用文件存储的metadata，这只是一个demo，如果是真正使用，我想用数据库更合适一些。

	我走的弯路：
	第一次：
	如何实现块能够写入到目标文件里？这个问题也和以前的同事交流过，当时没有找到解决办法。除非顺序写入然后用append的模式。
	但是客户端上传确实多线程非顺序上传，服务端该如何保证顺序？
	最后的解决办法是把客户端上传的每一个块保存为单个小文件，每次上传完一个块之后判断是不是所有的块上传完毕，如果上传完毕做一次合并。

	判断文件块是否写完，我就要遍历每一个小文件，判断他们是否连续。由于nodejs的文件操作需要异步，所以实现起来需要写各种递归，异常痛苦，大家可以看我的GitHub提交的历史版本，最老的版本里面有很多递归。代码非常丑陋，而且难以维护。

	第二次：
	为了减少递归，我使用global全局缓存，而且限定了文件上传的块的大小必须一样，没上传完一个块，我就把他存储到global缓存里。这样就不需要遍历小文件，减少了很多异步操作，代码清晰了很多。

	第三次:
	小文件合并的方案虽然可行，但毕竟感觉有些愚蠢，如果是特别大的文件，那可以想象合并和遍历都很慢，管理也不方便。所以如果能解决Nodejs的按offset写入stream的问题就可以解决。我又翻了下Nodejs的文档，发现以前使用的都是w和w+的打开方式，这种打开方式会清空文件的内容，而r和r+不会。
	于是我尝试着修改了代码，由于是并发写入，实际上文件写入是不能并发的，所以需要加锁，当块写入的时候判断是否锁住就可以了。
	这一下去掉了好多的代码，代码更加的明亮起来。


	为什么用NodeJS？因为这是一个面试题的作业，所以必须用Nodejs。
	我在FileMetadata初始化是依然用的fs.readSync，我以前同事告诉我nodejs不可以使用sync方法，这样会hold住整个进程。这是现实太恐怖了。
	所以我个人觉得nodejs的弊端也很明显，对代码复杂度的增加显而易见。至于Javascript的非阻塞的先天优势，其他的语言也可以做到。那为什么还用Nodejs呢？而且Javascript的语法比较弱，很多实现都比较困难。我对nodejs没有太多好感。