如何实现文件增量同步——算法

如何实现文件增量同步——算法

问题:

如何增量同步文件,例如一个文本文件有10M,分别存放在A,B两个地方,现在两个文件是完全一样的,但是我马上要在A上对这个文件进行修改,B如何实现自动和A上的文件保持一致,并且网络的传输量最少。

应用场景:

这样的使用场景太多,这里随便列举几个

1.A机器为线上运营的机器,现在需要一台备份的机器B,当A发生宕机的时候,或者硬盘损坏等各种认为非人为原因导致数据不可用时,可以很快从B恢复

2.SVN这样的应用场景,不需要每次修改都向服务器发送并替换掉一个文件,而是只发送被修改的部分

3.手机客户端对一个文本修改,如果那个文本有2M,难道我每次更新都需要上传整个文件吗?每次2M,傻子才用!

等等....

解决方案:

.分而治之

计算机最重要的基本算法思路就是分而治之,在我们眼里,一个文件不是一个文件,而 是一堆存储块,每个存储块可能20Byte大小,至于这个值具体多大,你可以自己设定,这里的20Byte仅提供参考。通过这样的方法,一个文件被分成了 很多个块,我们只需要比对块是否相同就可以得出哪个部分做了相应修改。

.快速校验

刚上面提到如何比对文件,当然这里肯定不会把文件的每个块上传去比对,那样做就没 有意义了。快速比对这不禁让我想起了哈希规则,哈希表可以通过O(1)的复杂度查找某个key,为什么?  因为它通过计算hash值来初步验证key,一个key的hash值是唯一的。但是仅仅验证hash值是不可靠的,因为hash值有可能会冲突,所以在 验证完hash值后,我们在进行key的比较来确定要找的值...

通过哈希的思路,我们可以使用类似的方法来实现文件增量同步,把每一个存储块,通过MD5计算其值,然后传递MD5值到服务器,让服务器比对MD5来确定有没有被修改,如若MD5值不相等,则判定这个文件块有被修改过

为什么是MD5?

1)能够将任意长度的字符串转换为128位定长字符串(MD5 16)

2)MD5能够保证绝大部分情况下不同的值hash之后其hash值不一样,哈希冲突比较少

这样就可以了吗?

No,MD5的生成需要占用比较长的CPU时间,所以我们需要寻找一种更简洁的校验方式,这里选用Alder32 是一个比较通用的解决方案

Alder32有两个优点:

1、计算非常快,比MD5快多了,成本小;

2、当我们有了从0-k长度的校验和后,计算出1-k或者2-k等其他校验和非常方便,只要少量运算即可。(k可以理解为上面的20Byte)

当然,它的缺点也很明显,就是碰撞率比MD5高多了,所以,我们客户端需要同时计算出Alder32校验和与MD5值,传给服务器,而服务器,为了节省CPU时间,第一步只生成Alder32进行校验,当值相等时,在进行MD5校验,这样服务器就节省了很大的开支。

Alder32算法实现:

A = 1 + D1 + D2 + ... + Dn (mod 65521)
 B = (1 + D1) + (1 + D1 + D2) + ... + (1 + D1 + D2 + ... + Dn) (mod 65521)
   = n×D1 + (n−1)×D2 + (n−2)×D3 + ... + Dn + n (mod 65521)

Adler-32(D) = B × 65536 + A

C实现版本

const int MOD_ADLER = 65521;
 
unsigned long adler32(unsigned char *data, int len) /* where data is the location of the data in physical memory and 
                                                       len is the length of the data in bytes */
{
    unsigned long a = 1, b = 0;
    int index;
 
    /* Process each byte of the data in order */
    for (index = 0; index < len; ++index)
    {
        a = (a + data[index]) % MOD_ADLER;
        b = (b + a) % MOD_ADLER;
    }
 
    return (b << 16) | a;
}

三.实现更改

因为已经找出来了文件不同的地方,所以只需要按需上传更改的部分到服务器,然后服务器做更改就可以了。

实例分析:

理论概述完毕,来点小例子子

客户端文件内容是:

taohuiissoman

而服务器的文件内容是:

itaohuiamsoman

首先,客户端开始分块并计算出MD5和Alder32值。

如上图,像taoh是一块,对taoh分别计算出MD5和alder32值。以此类推,最后一个n字母不足4位保留。于是,客户端把计算出的MD5和alder32按顺序发出,最后发出字符n。

服务器收到后,先把自己保存的File.2的内容按4字节划分。

划分出itao、huia、msom、an,当然,这些串的Alder32值肯定无法从File.1里划分出的:taoh、uiis、soma、n找出相同的。于是向后移一个字节,从t开始继续按4字节划分。

从taoh上找到了alder32相同的块,接着再比较MD5值,也相同!于是记下来,跳过taoh这4个字符,看uiam,又找不到File.1上相同的块了。继续向后跳1个字节从i开始看。还是没有找到Alder32相同,继续向后移,以此类推。

到了soma,又找到相同的块了。

重复上面的步骤,直到File.2文件结束。

通过这个简单的例子,可以设想一下其他任何的增删查改功能 

时间: 2024-10-08 21:16:57

如何实现文件增量同步——算法的相关文章

记一次rsync增量同步远程服务器文件

rsync remote shell 增量方式同步数据 rsync同步文件有两种方式,一种是daemon的方式(rsync daemon)另一种方式是通过远程shell方式(rsync remote shell). 两种方式的区别 daemon方式,这种方式通过TCP方式连接远程rsync daemon,需要使用配置文件,并启用daemon进程. rsync [OPTION] user@host::src dest rsync [OPTION] src user@host::dest remot

rsync+inotify节点间文件实时同步

说明: 操作系统:CentOS 7.2 server服务器(代码.数据检入)server: SLB-1:10.171.63.120 client服务器(数据检出.主动推送)client:WWW:10.163.0.233 目的:把client服务器上/www/web目录实时同步到server服务器的/www/web下 ============================================================ 具体操作: 第一部分:在server--SLB-1_10.1

文件夹同步/备份软件推荐 (SyncToy/FreeFileSync/Compare Advance/GoodSync/Allway Sync/Compare Advance)

关于文件同步的文章,已经很多次出现在异次元上了,因为它们很多都能实实在在提高工作便利性.比方说有我们熟悉的云端同步软件 Dropbox.金山快盘,以及曾经还介绍过可本地使用的 Allway Sync 以及 GoodSync等等. 虽然说已经介绍过了这么多同类型的软件,但在一番深思熟虑之后还是决定再介绍几款本地文件夹同步备份软件,我相信,虽然他们大体上是类似的,但是还是各自有自己的特色,而屏幕前的你,则可根据自己的需求选择更加合适自己的…… Microsoft SyncToy SyncToy 是由

rsync+inotify 实现服务器文件实时同步

rsync+inotify 实现服务器文件实时同步 操作系统:CentOS 6.X 源服务器:192.168.80.132 目标服务器:192.168.80.128 目的:把源服务器上/data/app目录实时同步到目标服务器的/data/app下 具体操作: 第一部分:在目标服务器192.168.80.128上操作 一.在目标服务器安装Rsync服务端 1.关闭SELINUX vi /etc/selinux/config #SELINUX=enforcing #SELINUXTYPE=targ

谈谈文件增量同步算法:RSYNC和CDC

谈谈文件增量同步算法:RSYNC和CDC 分类: 数据同步 增量备份 版权声明:本文为博主原创文章,未经博主允许不得转载. 最近在研究文件的增量同步问题,着重研究了文件差异编码部分,因为这个其实是文件同步的核心.目前应用最广泛的当然是linux下的RSYNC算法,但是这个算法本身存在缺陷,就是当两个文件完全无关时,差异编码的效率非常低,几乎难以接受! 带着这个问题,我研究了CDC(Content-Defined Chunking)算法,发现CDC算法恰好解决了这个问题:当两个文件的差异非常大时,

rsync+inotify 实现服务器之间目录文件实时同步(转)

软件简介: 1.rsync 与传统的 cp. tar 备份方式相比,rsync 具有安全性高.备份迅速.支持增量备份等优点,通过 rsync 可 以解决对实时性要求不高的数据备份需求,例如定期的备份文件服务器数据到远端服务器,对本地磁盘定 期做数据镜像等. 随着应用系统规模的不断扩大,对数据的安全性和可靠性也提出的更好的要求,rsync 在高端业务系统中 也逐渐暴露出了很多不足,首先,rsync 同步数据时,需要扫描所有文件后进行比对,进行差量传输.如 果文件数量达到了百万甚至千万量级,扫描所有

网站文件的同步

一个网站,除了有数据库,还有很多别的文件,比如用户上传的图片,你的网站代码之类,光有数据库而没有这些文件你的网站也没法跑起来. 和数据库比起来,网站文件要大得多,而且文件数目也多得多,要做到实时同步必须考虑"增量文件同步",一般传统的方法是使用  inotify + rsync 写脚本来操作. 我们这里采用  Sersync (https://code.google.com/p/sersync/) 来做网站数据同步  . 配置 Slave 上的 WWW 同步 采用 Rsync 做数据同

rsync+inotify+ssh远程实时增量同步

一.准备工作 -主服务器: Rsync,发起端 Inotify Ssh IP:192.168.10.128 -备份服务器 ssh,备份端 IP:192.168.10.129 二.部署过程 1.备份端建立上传用户,并设置权限 -创建用户 [[email protected] ~]# useradd rput [[email protected] ~]# passwd rput -为同步目录设置访问权限 [[email protected] ~]# chown -R rput:rput/var/ww

文件增量备份工具

增量备份是指在一次全备份或上一次增量备份后,以后每次的备份只需备份与前一次相比增加或者被修改的部分.这就意味着,第一次增量备份的对象是进行全备后所产生的增加和修改的文件;第二次增量备份的对象是进行第一次增量备份后所产生的增加和修改的文件,如此类推. 增量备份由于没有重复的备份数据,因此备份的数据量不大,备份所需的时间短,所需的数据存储空间小,再加上云存储的价格优势,将进一步降低整体成本投入.而且云端数据备份还可以省去备份硬件损坏造成的难以恢复的问题. 下面介绍几款常见的文件增量备份软件: 1.多