我們最近推出了一款新產(chǎn)品预柒，今天有用戶反饋一款新產(chǎn)品人臉無識別問題。比較奇怪痊剖，因為我們很多產(chǎn)品都使用了人臉識別技術(shù)告丢，此前從未出過類似問題枪蘑。
比較巧合的是這款新產(chǎn)品所在服務器沒有掛載物理磁盤损谦，而是采用我們自研的云磁盤技術(shù)岖免，將上傳圖片實時存儲到其它節(jié)點。
排查代碼后確認使用云磁盤技術(shù)后照捡，圖片不具有本地路徑導致識別失敗颅湘。
下圖是我們目前圖片識別流程，具體流程口述如下：
- 圖片本地路徑和回調(diào)方法首先被包裝成識別任務栗精；
- 將識別任務發(fā)往任務隊列闯参；
- 識別線程不斷從識別任務隊列獲取新的任務；
- 獲取到新的任務悲立，讀取本地路徑對應的文件流并轉(zhuǎn)成 BASE64鹿寨；
- 將 BASE64 發(fā)往百度人臉識別接口，獲取識別結(jié)果薪夕；
- 調(diào)用回調(diào)方法脚草。
其實就是生產(chǎn)者（單）和消費者（多）模式，效率比較高原献，但不支持優(yōu)先級調(diào)整馏慨。
我和同事各提出一種解決辦法，我基于效率考慮提出了第一種解決辦法姑隅，他出于可擴展性考慮提出第二種方法写隶。
第一種解決方法
本節(jié)點將圖片緩存到內(nèi)存，然后才發(fā)往遠程節(jié)點讲仰。如果將這片內(nèi)存包裝 Java 的 byte[] 然后包裝成識別任務慕趴，發(fā)往隊列。
這樣一來，識別程序需要作相應改動秩贰，以便支持將 byte[] 數(shù)據(jù)轉(zhuǎn)成 BASE64霹俺。
優(yōu)點：無需發(fā)起網(wǎng)絡請求，識別任務周轉(zhuǎn)率高
缺點：識別任務長時間占用內(nèi)存使得內(nèi)存利用率低毒费；識別程序與文件類型高度耦合丙唧；請求數(shù)過多時內(nèi)存線性增長
第二種解決方法
云磁盤技術(shù)采用 FileId 來標識每一個文件（無論是本地還是遠程）識別任務包裝 FileId，識別程序調(diào)用云磁盤接口來獲取數(shù)據(jù)流觅玻。
這樣一來想际，通過云磁盤來屏蔽底層文件位置差異，實現(xiàn)識別程序與文件位置解耦溪厘。
優(yōu)點：內(nèi)存資源利用率高胡本，按需讀取畸悬；通過 FileId侧甫，將文件位置與識別程序解耦，便于后期擴展（將識別程序解構(gòu)成獨立服務）蹋宦。
缺點：遠程文件需要發(fā)起網(wǎng)絡請求披粟，可能產(chǎn)生延遲影響后續(xù)任務周轉(zhuǎn)率
由于出發(fā)角度不同，可以看出兩種解決方法必須做出相應的權(quán)衡取舍冷冗，而且巧合是兩者恰好是對方的對立面守屉。最終基于擴展性考慮，決定使用第二種解決方法蒿辙。
