前言
在Netty應(yīng)用一 大文件傳輸那篇文章和之前的demo（https://gitee.com/bbstone101/pisces.git）能夠傳輸單個(gè)幾G的文件，但是，一旦遇到傳輸?shù)奈募?shù)量多（比如膘格，超過一萬）碉熄，就會(huì)出現(xiàn)服務(wù)器端卡死問題别凤。主要原因是建芙，使用FileRegion模式和ChunkedFile模式傳輸文件旷偿，server端會(huì)主動(dòng)讀取發(fā)送文件到網(wǎng)絡(luò)管道速缆，一旦client端接收和存儲(chǔ)速度跟不上降允，就會(huì)導(dǎo)致server端數(shù)據(jù)堆積，占用服務(wù)器資源艺糜。
本篇基于Netty應(yīng)用一存在的問題和文件備份實(shí)際情況剧董，即，小文件多破停，且文件不過超過1G翅楼，超過10G的更是少。設(shè)計(jì)了pisces2-m基于LengthFieldBasedFrameDecoder自定義文件傳輸協(xié)議真慢，程序由client端來觸發(fā)和控制文件發(fā)送的頻率毅臊，這樣設(shè)計(jì)更切合實(shí)際。
服務(wù)器和客戶端這兩種通信控制模式黑界，與MQ的消息的 推/拉 模式相像：
- Netty應(yīng)用一管嬉，是由服務(wù)器主動(dòng)推送文件數(shù)據(jù)，客戶端接收园爷；
- Netty應(yīng)用二宠蚂，是由客戶端主動(dòng)去服務(wù)器拉取文件信息和文件數(shù)據(jù)。
項(xiàng)目代碼：https://gitee.com/bbstone101/pisces2-m.git
架構(gòu)設(shè)計(jì)
ChunkSlicer: server端將文件切分成一個(gè)個(gè)chunk數(shù)據(jù)塊發(fā)送給client童社。server直接從FileInputStream一個(gè)個(gè)chunk讀取數(shù)據(jù)求厕，然后構(gòu)造響應(yīng)buildRsp發(fā)送給client。
RecvBuffer: client端接收到chunk數(shù)據(jù)后，先緩存起來呀癣，默認(rèn)緩存大忻榔帧：32 * 1024 * 1024 = 32M
請(qǐng)求–響應(yīng)處理流程
通信協(xié)議
請(qǐng)求協(xié)議
協(xié)議定義：
獲取文件列表索引信息和數(shù)據(jù)：
REQ_LIST_INFO：客戶端請(qǐng)求獲取fileNo=0的fli.idx文件信息（文件checksum，chunks數(shù)等）项栏。
REQ_LIST_DATA：客戶端請(qǐng)求獲取fileNo=0的fli.idx文件數(shù)據(jù)浦辨。
REQ_LIST_INFO_ACK：客戶端確認(rèn)已經(jīng)接收fli.idx文件信息。
REQ_LIST_DATA_ACK：客戶端確認(rèn)已經(jīng)接收fli.idx文件chunk的數(shù)據(jù)沼沈。
獲取文件列表索引中文件的信息和數(shù)據(jù)：
REQ_FILE_INFO：客戶端請(qǐng)求獲取fileNo=n的文件信息
REQ_FILE_DATA客戶端請(qǐng)求獲取fileNo=n的文件數(shù)據(jù)流酬。
REQ_FILE_INFO_ACK：客戶端確認(rèn)已經(jīng)接收文件信息。
REQ_FILE_DATA_ACK：客戶端確認(rèn)已經(jīng)接收文件chunk的數(shù)據(jù)列另。
LengthFieldBasedFrameDecoder參數(shù)和說明：
- image.png
請(qǐng)求消息的最大幀長度是1MB芽腾，請(qǐng)求消息大多數(shù)沒有請(qǐng)求體或請(qǐng)求體為空。
響應(yīng)協(xié)議
協(xié)議定義：
- image.png
服務(wù)器響應(yīng)列表索引文件信息和數(shù)據(jù)：
RSP_LIST_INFO：響應(yīng)列表信息（包括chunks和文件checksum）
RSP_LIST_DATA：響應(yīng)列表文件數(shù)據(jù)页衙，chunkNo摊滔，body的checksum，文件數(shù)據(jù)
服務(wù)器響應(yīng)列表索引文件里的文件信息和數(shù)據(jù)：
RSP_FILE_INFO：響應(yīng)文件信息（包括chunks和文件checksum）
RSP_FILE_DATA：響應(yīng)文件數(shù)據(jù)店乐，chunkNo艰躺，body的checksum，文件數(shù)據(jù)
LengthFieldBasedFrameDecoder參數(shù)和說明：
- image.png
響應(yīng)消息最大幀大小是12MB眨八，響應(yīng)消息主要是響應(yīng)文件信息和數(shù)據(jù)腺兴，其中文件數(shù)據(jù)是body主要內(nèi)容，為加快文件從server傳給client踪古，需要適當(dāng)調(diào)整響應(yīng)消息的最大幀大小含长。
后語
目前能夠在局域網(wǎng)正確傳輸30萬左右的文件，但是耗時(shí)也較長伏穆。
可以考慮開多個(gè)client來消費(fèi)fli.idx中的文件列表傳輸任務(wù)來提高文件傳輸效率。
TODO:
1）同時(shí)啟動(dòng)多個(gè)客戶端連服務(wù)器下載（請(qǐng)求）文件
2）客戶端并發(fā)讀取和消費(fèi)fli.idx列表任務(wù)管理器設(shè)計(jì)和開發(fā)
補(bǔ)充：多客戶端與單客戶端性能對(duì)比
更新日期：20220621
- image.png
結(jié)論：
以上測試兩個(gè)版本皆為單服務(wù)端纷纫，其中單客戶端接收40w+文件耗時(shí)枕扫，是同條件下10個(gè)客戶端耗時(shí)的10倍多。
另外辱魁，從初步性能測試結(jié)果看烟瞧，不能確定客戶機(jī)啟動(dòng)10個(gè)客戶端接收數(shù)據(jù)已觸及到客戶機(jī)的磁盤IO或CPU負(fù)載的極限。即染簇，增大客戶端個(gè)數(shù)参滴，還有可能提升性能。
