應(yīng)項(xiàng)目需求，需要將上傳至Fastdfs的圖片，搭建一個圖片素材庫（類似于百度圖片）。但是在項(xiàng)目構(gòu)建初期，數(shù)據(jù)量不是很大，也并沒有設(shè)想到要做這一塊的功能，圖片上傳fastdfs后，也就沒有將圖片寬高，大小，存下來。在需求下發(fā)下來后，著手考慮如何針對場景在現(xiàn)有基礎(chǔ)上做一些補(bǔ)充或者叫修復(fù)。首先需要新增三個字段，width,height,size。然后對庫中已有的千萬圖片數(shù)據(jù)，做數(shù)據(jù)修復(fù)。
開始構(gòu)想，做一個定時處理任務(wù)跑批，一次獲取1w條數(shù)據(jù)，然后在此次任務(wù)中，將獲取到的1w條數(shù)據(jù)分片，一個分片中1000條數(shù)據(jù)，然后分10個線程并發(fā)處理。處理完后，一次性更新入庫(大數(shù)據(jù)庫，1w條數(shù)據(jù)還是可以支持的)?；蛘咭粋€分片中100條數(shù)據(jù)，分100個線程。針對線程數(shù)這塊，特地查到windows服務(wù)器下最多可支持好幾千甚至更多個線程，當(dāng)然這些也跟CPU，操作系統(tǒng)等有關(guān)系，但對于我們跑批的這一點(diǎn)線程，還是沒問題的。
期間遇到些問題，操作FastDfs的是使用了一個封裝好的工具包org.csource.fastdfs-client-java 版本5.0.4，調(diào)用了其封裝好的下載接口，StorageClient.download_file1(file_id);但是報錯，主要錯誤如下：? java.io.IOException: recv cmd: 10 is not correct, expect cmd: 100
經(jīng)查，發(fā)現(xiàn)，F(xiàn)astDfs 在多線程環(huán)境下上傳，下載圖片的時候，同時使用一個StorageClient操作文件，會報這個錯誤，網(wǎng)絡(luò)建議有兩種解決方案：
1. 對StorageClient對象加鎖
2. 每次下載或上傳文件時，重新new一個StorageClient
第一種方案的話，鑒于多線程處理方式下，對象加鎖，那顯然不合適，
第二種方案，每一次上傳，下載時都去開辟一個鏈接，幾千萬的數(shù)據(jù)量，頻繁的開關(guān)，是否會給線上的圖片服務(wù)器造成壓力，是未知的，保險起見，換了一種方式：
?通過HttpURLConnection 讀取流的方式下載，這種方式，顯然是避開了頻繁創(chuàng)建StorageClient，并且，通過HttpURLConnection請求Fastdfs的ngnix代理路徑，也會適當(dāng)?shù)慕档蛦我籗torage訪問壓力。項(xiàng)目比較趕，所以，暫時先用該方式修復(fù)，至于Fastdfs頻繁創(chuàng)建StorageClient是否會有效率或者其他影響，需要深入了解一下。
期間還遇到了一些圖片下載解析的問題，這個問題，是JDK由于版本迭代產(chǎn)生的一些隱式異常，是在ImageIO.read() 還有 像此處的java.awt.image.ColorConvertOp.filter() 的一些顯式異常。
這個異常暫時先忽略掉了，因?yàn)榭赡苁怯捎谝恍v史的jpeg圖片導(dǎo)致，后期再看如何修復(fù)，可能會需要使用到類似于ImageMagic的圖片處理工具等等了。
雖然弄完了，程序一切正常，但是，還是不夠快，10000數(shù)據(jù)量差不多10分鐘，那些秒級百萬數(shù)據(jù)處理到底是怎么樣做到的呢，行吧，自己需要學(xué)的還有很多了。
最后，還是將數(shù)據(jù)分成了多個時間段，在檢索上進(jìn)行分片，然后部署了多個處理任務(wù)，并行處理。
學(xué)無止盡，在每一次處理解決問題中，才能感受到成長。
