我們的乙個方案是基於檔案做多端資料同步，見另外一篇部落格：基於檔案的資料同步方案
其中的核心是如何正確、高效地同步檔案，一開始我們使用了國產的libsync庫：libsync
基本的流程是：有檔案a和b，現在想把檔案a「變成」檔案b，先對檔案a做chunk；然後用chunk和檔案b對比，得到delta；最後用檔案a和delta做sync操作，a就變成了b的複製。但是實際測試之後發現，在某些場景下，合併得到的檔案和原始檔案的md5不一致，說明在過程中，檔案已經損壞了
看源**，沒有找到原因。於是直接改用另乙個更有名的庫，librsync，位址在：librsync。編譯之後會得到2個東西，乙個是可執行命令列rdiff，另乙個是靜態鏈結庫librsync.a，如果需要動態鏈結庫比如.so或.dylib，可能需要自己改一下makefile
經過測試，剛才合併出錯的2個檔案，用rdiff命令執行signature -> delta -> patch之後，md5完全一致，說明新的庫本身是ok的，沒有遇到老庫的bug。那麼接下來還需要做2件事：
2、將librsync庫整合到server**裡
呼叫的**也很簡單，因為在客戶端只需要delta，我就只包裝了乙個函式：
-(int) deltawithsignature:(nsstring*)signaturepath newfilepath:(nsstring*)newfilepath deltapath:(nsstring*)deltapath
if ((result = rs_build_hash_table(sumset)) != rs_done)
result = rs_delta_file(sumset, new_file, delta_file, &stats);
rs_free_sumset(sumset);
rs_file_close(delta_file);
rs_file_close(new_file);
rs_file_close(sig_file);
return result;
}
官方自帶的makefile只能打出靜態鏈結庫，如果要打出所需的.so檔案，還需要自己改一下makefile。而且我們這個服務是用node寫的，就算得到了.so，還是需要用ffi再重新包裝一下，才能在node裡面呼叫，同樣很費事
所以最後我是在環境裡編譯好了rdiff命令列，然後**裡直接呼叫，省去了封裝ffi的麻煩。由於是非同步呼叫，效能也沒有太大的問題，不過不太好的就是呼叫過程中的精細控制不好實現，另外集群部署的時候也會麻煩一點
var cmd = "rdiff patch " + localrdbpath + " " + uploadpath + " " + syncpath;
console.log(cmd);
exec(cmd, {}, function (err, stdout, stderr) );
hbase學習筆記 regiion拆分 合併
region中儲存的是大量的rowkey資料 當region中的資料條數過多的時候,直接影響查詢效率.當region過大的時候.hbase會拆分region 這也是hbase的乙個優點 hbase的region split策略一共有以下幾種 當region大小大於某個閾值 hbase.hregion...
用例公共部分合併
每個測試類都有setup 和teardown 方法，而且兩個方法內容都是一樣的，用於列印開始與結束提示語句，是否可以合併在一起呢？class math def init self,a,b self.a int a self.b int b defadd self return self.a self...
XML拆分合併列值學習整理
原帖 http blog.csdn.net htl258 archive 2009 04 26 4127043.aspx 建立測試資料 if object id tb is not null drop table tb go create table tb id int identity prima...