摘要：，在后續(xù)測試時遇到一個詭異，當文件過大時，任務(wù)腳本上傳到七牛云失敗。當我遇到大文件無法上傳到七牛云時，斷點調(diào)試到這里，發(fā)現(xiàn)返回的是。后來還真被我找到了，七牛云官方提供一個腳本工具。

我們項目有一個文件上傳需求，需要從客戶端上傳到七牛云的對象存儲和自己的應用服務(wù)器上。這里使用七牛云主要是實現(xiàn)下載分發(fā)。應用服務(wù)器需要留一份是因為后續(xù)需要做文件分析（并且是上傳后需要立馬分析出結(jié)果展現(xiàn)給客戶端）。另外，由于是初期項目，暫時沒考慮用獨立服務(wù)器來分析。

服務(wù)器：Centos7
開發(fā)語言：PHP
框架：Laravel
前端上傳組件：百度的WebUploader

準確的說我經(jīng)過了三個階段才真正完美的實現(xiàn)了需求（主要解決上傳速度）。

初期面對需求很容易想到的思路是：客戶端先上傳文件到應用服務(wù)器（因為上傳完成可以及時做分析），然后再上傳到七牛云上。

所以我的解決方案是：前端用webuploader，后端的七牛云文件處理方面使用了Laravel的一個插件:overtrue/flysystem-qiniu (https://github.com/overtrue/f...，該插件的接口很簡潔好用（但是有坑，后面會說到）。

然后為了解決性能問題，我還做了以下工作：
1，使用分片上傳
2，后續(xù)上傳七牛云使用異步的方式（因為文件上傳到其他應用來下載這個文件，中間有許多時間來讓上傳任務(wù)的完成）

這里講下分片上傳的實現(xiàn)思路，客戶端主要是把大文件按一定size進行分片，然后上傳到服務(wù)器，所以會有多個請求，并且每個請求還需帶上關(guān)鍵的信息：當前chunk（從0開始）和chunks（總分片數(shù)）。由于我用的是WebUploader組件，所以客戶端不用自己做什么，只需配置下簡單信息（是否分片及分片大?。?。

服務(wù)端處理邏輯為：
客戶端一個請求過來，分兩種情況：
1，文件總size小于要分片的size，這時候直接處理文件。
2，處理分片情況。

具體邏輯是判斷chunk和chunks，如果相等說明為第一種情況，直接處理上傳，其他走處理分片邏輯。

處理分片的邏輯為：保存當前分片到臨時目錄（按分片命名），然后判斷當所有分片完成時，就合并文件。具體邏輯是判斷 chunk + 1 是否等于chunks。 合并邏輯就是循環(huán)讀取臨時文件，然后寫入到一個新的文件（合并后的），這里可以順便刪除臨時文件。

所遇的坑：
這里處理碎片文件時，當初圖方便使用了Laravel的文件處理接口Storage::append，但是這個接口有個坑就是它自作主張的文件結(jié)尾加入換行符。導致合并后的文件還原不成原始文件。解決辦法是老老實實使用php的fopen、fwrite、fclose這一套。

關(guān)于PHP的異步實現(xiàn)可以參考鳥哥寫的文章：http://www.laruence.com/2008/...

主要方法為：客戶端AJAX、popen函數(shù)、curl、fsocketopen等

不過這篇文章比較老了，局限性也大，現(xiàn)在有了協(xié)程等處理方案（現(xiàn)在Swoole也提供協(xié)程方案了，并且client-server task分發(fā)這種也可以用swoole的），而且往架構(gòu)方面考慮可以使用隊列等（感覺靠譜的還是隊列）。

PS: 我這里前期用的是簡單粗暴的popen，后來使用的是Laravel提供的隊列。

通過上述所說的方案，很容易就實現(xiàn)了一個版本。但是沒高興多久。。，在后續(xù)測試時遇到一個詭異bug，當文件過大時，任務(wù)腳本上傳到七牛云失敗。

這里腳本是寫在Laravel的artisan中的，當我把腳本命令直接在終端調(diào)試時也是沒有任何異常（準確講是看不了任何異常）

。前面我說過七牛這塊SDK用的是overtrue/flysystem-qiniu ，并且為了考慮性能問題用的是他的writeStream接口。

    $disk = Storage::disk("qiniu");
    $stream = fopen($localFileName, "r");
    $disk->writeStream($fileName, $stream);

    if (is_resource($stream)) {
       fclose($stream);
    }

代碼表面上看起來很理想，用的是文件流上傳（怕吃內(nèi)存）。但結(jié)果證明一切只是表面上的。。

當我遇到大文件無法上傳到七牛云時，斷點調(diào)試到$disk->writeStream這里，發(fā)現(xiàn)返回的是false。 繼而調(diào)試到overtrue/flysystem-qiniu這個擴展的源代碼。然后發(fā)現(xiàn)了一個大坑。。

主要是兩個問題：
1，writeStream只是個假的流寫入

具體源碼在擴展的QiniuAdapter.php文件中，這里貼段代碼：

public function writeStream($path, $resource, Config $config)
{
    $contents = "";

    while (!feof($resource)) {
        $contents .= fread($resource, 1024);
    }

    $response = $this->write($path, $contents, $config);

    if (false === $response) {
        return $response;
    }

    return compact("path");
}

注意這里的$contents變量，最終還是等價于一個大文件內(nèi)容的大?。ǚ?wù)器為此變量開辟的內(nèi)存）。并且后續(xù)還要在方法間傳遞。所以這里是假的流！

2，接口對調(diào)試不友好

還有在write方法中，屏蔽了$error，只返回false，這樣不便于我們查問題，最終我是斷點打印這個$error才知道報的錯誤是：“invalid multipart format: multipart: message too large”，這個應該是七牛那邊真正返回的，但這么重要的信息被這個擴展屏蔽了。

知道了一期方案的具體問題所在，我就一直在思考（那個擴展就不提了。。我現(xiàn)在懷疑它的存在意義。。），甚至在想也許一開始整個思路就錯了（通過SDK上傳文件的方案）。后來還真被我找到了，七牛云官方提供一個腳本工具：Qshell（https://github.com/qiniu/qshell）。這個是命令行運行腳本，具體操作看文檔就可以了。放到我的項目也是集成到七牛的任務(wù)腳本中。

后來測試可以了，整個流程可以跑通。

但是無意中發(fā)現(xiàn)二期的重要問題，這個上傳走的是服務(wù)器的上行帶寬！而我們平常付費買的帶寬就是買的上行帶寬！（下行是一般是免費的）。這還怎么搞！由于我們上傳業(yè)務(wù)是商戶端使用的，平時使用頻次也不會太少，這會導致在上傳時影響前端網(wǎng)站的訪問速度。

這里具體講下服務(wù)器帶寬問題（網(wǎng)上查詢后整理的）：

首先對服務(wù)器帶寬方向的描述一般是用上行和下行，上傳和下載是指動作。

上行是指從服務(wù)器流出的帶寬，如果是在其他機器下載服務(wù)器上的文件，用的主要是服務(wù)器的上行帶寬（這里說下我們平時的網(wǎng)頁瀏覽，其實也是不同客戶端從服務(wù)器下數(shù)據(jù), html文件、css等然后渲染，所以網(wǎng)頁瀏覽占用的也是上行帶寬）。

下行是指流入到服務(wù)器的帶寬，如果是在其他機器上傳文件到服務(wù)器，比如用FTP上傳文件，用的主要是服務(wù)器的下行帶寬（服務(wù)器上下載文件用的也是下行帶寬）。

現(xiàn)在的云提供商比如阿里云不限制的是下行帶寬，大部分服務(wù)器的使用環(huán)境，都是上行帶寬用的多，下行帶寬用的少。

通過對帶寬的理解，再回到我們項目的上傳實現(xiàn)思路，可以看到一開始就錯了（不該用應用服務(wù)器作為中轉(zhuǎn)）！

當初為了節(jié)省時間，直接跳過官方文檔，而使用第三方擴展。 現(xiàn)在看來，不得不又回到官方文檔了。

通過把七牛的文檔過一遍，發(fā)現(xiàn)是有方案可以避開那個占用服務(wù)器上行帶寬的問題的。

主體思路是要避開應用服務(wù)器上行帶寬的使用，因為上行帶寬很寶貴，盡量使用下行帶寬（免費、速度很快！阿里的大概60M多每秒）。

具體實現(xiàn)是通過七牛的表單上傳方案直接把客戶端的文件先上傳到七牛（這一步根本不關(guān)應用服務(wù)器什么事，所以避開了，而且直接上傳到七牛的速度非?？?，基本只取決于用戶端的網(wǎng)速，而且對于一般需求，七牛提供了對于到我們應用服務(wù)器的回調(diào)方法）。然后由于我們應用服務(wù)器也需要文件，所以方案是直接在我們應用服務(wù)器直接下載七牛的文件（這里可以同步阻塞住，前端做個等待效果解決用戶體驗問題）。因為前面說到流入到服務(wù)器占用的是下行帶寬。所以這里速度也會非?？欤ǘ沂敲赓M的^_^）。

這種方案基本是完美的了。

首先是對個人的反省，前期調(diào)研不充足，但是項目初期有點緊，這里也說明投入時間的重要性。

其次關(guān)于項目經(jīng)驗：上傳第三方云存儲，千萬不要使用應用服務(wù)器做中轉(zhuǎn)！可以直接上傳到第三方云服務(wù)器，如果有后續(xù)處理邏輯的，可以使用他們的回調(diào)接口。