NodeJs實現可續傳的上傳協議(tus resumable upload protocol)

這是一個基於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。

 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沒有太多好感。