fastdfs java客戶端重寫分享

yuqih

基于java客戶端1.24改寫
主要目的：
1.代碼整理的容易理解點，而且更適合spring使用，且放棄了靜態(tài)類加載配置文件的方式
2.使用commoms-pool2做一個簡單的socket連接池
改動及尚未完成的：
1.使用的接口做了一些調(diào)整，比如metadata現(xiàn)在不和文件一起上傳，因為我看官方的包也是先上傳文件在上傳metadata，metadata上傳不成功再刪除上傳的文件
2.取fileinfo的地方?jīng)]有對文件名進(jìn)行解析，直接請求了服務(wù)器，算是沒寫完整

代碼地址svn://svn.code.sf.net/p/fastdfsclient/code
其中代碼tags中1.24是我將官方代碼改成了maven項目
trunk中的是我的代碼，有一個簡單的測試類作為demo

目前注釋缺失比較多，希望大家能看看我的代碼提點意見，如果覺得可以用的話隨便使用

guopeihui

你這個東西和原先的java客戶端有啥區(qū)別呢？

coraldane

checkout出來看了下，使用上比原來余大寫的那個方便多了
不過現(xiàn)在功能還不是很完善，最好多給幾個Test Case
在TestCase上面寫上注釋，主要用于什么用途
還是很感謝樓主的分享和開創(chuàng)精神

coraldane

還有，現(xiàn)在托管的地址是sf的SVN，最好改成github.com托管
這個是比較正規(guī)的開源代碼托管平臺

coraldane

源代碼的包名不要使用thrid.rewrite  使用一個正規(guī)一點的
比如com.github.工程名

guopeihui

你寫的這個客戶端上傳文件的時候必須要些groupname，可以不寫嗎？還有那個groupstate的獲取是不是準(zhǔn)確呢？

yuqih

回復(fù) 6# guopeihui


    groupname可以為null，此時就是系統(tǒng)分配，GroupState, StorageState這個應(yīng)該是準(zhǔn)確的
    其實所有的內(nèi)容我都沒有修改余大原有的邏輯，只是把代碼結(jié)構(gòu)按我使用的喜好調(diào)整了下

guopeihui

其實這個我也看了，我問的意思是可以根據(jù)上傳文件的大小選擇group，前提是GroupState的獲取準(zhǔn)確回復(fù) 7# yuqih


   

yuqih

回復(fù) 8# guopeihui

個人覺得這種需求不應(yīng)該由fastdfs的客戶端來完成，同時注意groupState和storageState即使每次都向服務(wù)器請求拿到的也不是實時信息，好像我看文檔，這些信息是storage節(jié)點定期向tracker節(jié)點推送信息的，默認(rèn)的間隔大概是1分鐘。

同時即使groupState是很準(zhǔn)確的，如果每次上傳都要去獲取信息的話，是很影響上傳的效率的。還有就是fastdfs的適應(yīng)場景是<500M（其實一般就幾十k到幾十M）的小文件，而且這些文件一般不需要修改或追加，很少會出現(xiàn)依靠groupState來判斷的情況，如果特大文件，建議使用hdfs等適合分布式計算的文件服務(wù)器。

至于你說的這種情況，我的做法是在應(yīng)用中定期獲取groupState，比如10分鐘獲取一次，如果groupState中的剩余容量小于某個值，則在可用列表中把這個group去掉。如果storage配置文件中的剩余容量設(shè)置的是30g，那么在groupstate中剩余容量在50g時就可以將這個節(jié)點從可用列表中移除了。


   

blackhorse_lj

回復(fù) 1# yuqih

NB,看著官方寫的源碼 完全是C語言的風(fēng)格，我都快哭啦，自己重構(gòu)了部分代碼，除了核心代碼，外圍代碼又重新封裝了一下，另外我也是用commonPool做的連接池，只是批量上傳圖片經(jīng)常出現(xiàn)各種問題，希望這個代碼能夠解決我的問題，還有那個對socket連接池的配置在哪