rsync是unix/linux下同步文件的一個高效算法，它能同步更新兩處計算機的文件與目錄，並適當利用查找文件中的不一樣塊以減小數據傳輸。rsync中一項與其餘大部分相似程序或協定中所未見的重要特性是鏡像是隻對有變動的部分進行傳送。rsync可拷貝／顯示目錄屬性，以及拷貝文件，並可選擇性的壓縮以及遞歸拷貝。rsync利用由Andrew Tridgell發明的算法。這裏不介紹其使用方法，只介紹其核心算法。咱們能夠看到，Unix下的東西，一個命令，一個工具都有不少很精妙的東西，怎麼學也學不完，這就是Unix的文化啊。html
原本不想寫這篇文章的，由於原先發現有不少中文blog都說了這個算法，可是看了一下，發現這些中文blog要麼翻譯國外文章翻譯地很是爛，要麼就是介紹這個算法介紹得很亂讓人看不懂，還有錯誤，誤人不淺，因此讓我以爲有必要寫篇rsync算法介紹的文章。（固然，我成文比較倉促，可能會有一些錯誤，請指正）node
問題
首先， 咱們先來想一下rsync要解決的問題，若是咱們要同步的文件只想傳不一樣的部分，咱們就須要對兩邊的文件作diff，可是這兩個問題在兩臺不一樣的機器上，沒法作diff。若是咱們作diff，就要把一個文件傳到另外一臺機器上作diff，但這樣一來，咱們就傳了整個文件，這與咱們只想傳輸不一樣部的初衷相背。linux
因而咱們就要想一個辦法，讓這兩邊的文件見不到面，但還能知道它們間有什麼不一樣。這就出現了rsync的算法。算法
算法
rsync的算法以下：（假設咱們同步源文件名爲fileSrc，同步目的文件叫fileDst）shell
1）分塊Checksum算法。首先，咱們會把fileDst的文件平均切分紅若干個小塊，好比每塊512個字節（最後一塊會小於這個數），而後對每塊計算兩個checksum，數組
- 一個叫rolling checksum，是弱checksum，32位的checksum，其使用的是Mark Adler發明的adler-32算法，
- 另外一個是強checksum，128位的，之前用md4，如今用md5 hash算法。
爲何要這樣？由於若干年前的硬件上跑md4的算法太慢了，因此，咱們須要一個快算法來鑑別文件塊的不一樣，可是弱的adler32算法碰撞機率過高了，因此咱們還要引入強的checksum算法以保證兩文件塊是相同的。也就是說，弱的checksum是用來區別不一樣，而強的是用來確認相同。（checksum的具體公式能夠參看這篇文章）數據結構
2）傳輸算法。同步目標端會把fileDst的一個checksum列表傳給同步源，這個列表裏包括了三個東西，rolling checksum(32bits)，md5 checksume(128bits)，文件塊編號。工具
我估計你猜到了同步源機器拿到了這個列表後，會對fileSrc作一樣的checksum，而後和fileDst的checksum作對比，這樣就知道哪些文件塊改變了。性能
可是，聰明的你必定會有如下兩個疑問：.net
- 若是我fileSrc這邊在文件中間加了一個字符，這樣後面的文件塊都會位移一個字符，這樣就徹底和fileDst這邊的不同了，但理論上來講，我應該只須要傳一個字符就行了。這個怎麼解決？
- 若是這個checksum列表特別長，而個人兩邊的相同的文件塊可能並非同樣的順序，那就須要查找，線性的查找起來應該特別慢吧。這個怎麼解決？
很好，讓咱們來看一下同步源端的算法。
3）checksum查找算法。同步源端拿到fileDst的checksum數組後，會把這個數據存到一個hash table中，用rolling checksum作hash，以便得到O(1)時間複雜度的查找性能。這個hash table是16bits的，因此，hash table的尺寸是2的16次方，對rolling checksum的hash會被散列到0 到 2^16 – 1中的某個整數值。（對於hash table，若是你不清楚，建議回去看大學時的數據結構教科書）
順便說一下，我在網上看到不少文章說，「要對rolling checksum作排序」（好比這篇和這篇），這兩篇文章都引用並翻譯了原做者的這篇文章，可是他們都理解錯了，不是排序，就只是把fileDst的checksum數據，按rolling checksum作存到2^16的hash table中，固然會發生碰撞，把碰撞的作成一個鏈表就行了。這就是原文中所說的第二步——搜索有碰撞的狀況。
4）比對算法。這是最關鍵的算法，細節以下：
4.1）取fileSrc的第一個文件塊（咱們假設的是512個長度），也就是從fileSrc的第1個字節到第512個字節，取出來後作rolling checksum計算。計算好的值到hash表中查。
4.2）若是查到了，說明發如今fileDst中有潛在相同的文件塊，因而就再比較md5的checksum，由於rolling checksume太弱了，可能發生碰撞。因而還要算md5的128bits的checksum，這樣一來，咱們就有 2^-(32+128) = 2^-160的機率發生碰撞，這過小了能夠忽略。若是rolling checksum和md5 checksum都相同，這說明在fileDst中有相同的塊，咱們須要記下這一塊在fileDst下的文件編號。
4.3）若是fileSrc的rolling checksum 沒有在hash table中找到，那就不用算md5 checksum了。表示這一塊中有不一樣的信息。總之，只要rolling checksum 或 md5 checksum 其中有一個在fileDst的checksum hash表中找不到匹配項，那麼就會觸發算法對fileSrc的rolling動做。因而，算法會住後step 1個字節，取fileSrc中字節2-513的文件塊要作checksum，go to (4.1) - 如今你明白什麼叫rolling checksum了吧。
4.4）這樣，咱們就能夠找出fileSrc相鄰兩次匹配中的那些文本字符，這些就是咱們要往同步目標端傳的文件內容了。
圖示
怎麼，你沒看懂？ 好吧，我送佛送上西，畫個示意圖給你看看（對圖中的東西我就再也不解釋了）。
這樣，最終，在同步源這端，咱們的rsync算法可能會獲得下面這個樣子的一個數據數組，圖中，紅色塊表示在目標端已匹配上，不用傳輸（注：我專門在其中顯示了兩塊chunk #5，相信你會懂的），而白色的地方就是須要傳輸的內容（注意：這些白色的塊是不定長的），這樣，同步源這端把這個數組（白色的就是實際內容，紅色的就放一個標號）壓縮傳到目的端，在目的端的rsync會根據這個表從新生成文件，這樣，同步完成。
最後想說一下，對於某些壓縮文件使用rsync傳輸可能會傳得更多，由於被壓縮後的文件可能會很是的不一樣。對此，對於gzip和bzip2這樣的命令，記得開啓 「rsyncalbe」 模式。