Rsync使用的Rsync演算法来使本地和远程两个主机之间的文件达到同步，这个算法只传送两个文件的不同部分，而不是每次都整份传送，因此速度相当快。 核心算法 假定在名为和的两台计算机之间同步相似的文件A与B，其中对文件A拥有访问权，对文件B拥有访问权
Rsync使用所谓的“Rsync演算法”来使本地和远程两个主机之间的文件达到同步，这个算法只传送两个文件的不同部分，而不是每次都整份传送，因此速度相当快。
算法核心部分：
假定在名为α和β的两台计算机之间同步相似的文件A与B，其中α对文件A拥有访问权，β对文件B拥有访问权。并且假定主机α与β之间的网络带宽很小。那么rsync算法将通过下面的五个步骤来完成：
1.β将文件B分割成一组不重叠的固定大小为S字节的数据块。最后一块可能会比S 小。
2.β对每一个分割好的数据块执行两种校验：一种是32位的滚动弱校验，另一种是128位的MD4强校验。
3.β将这些校验结果发给α。
4.α通过搜索文件A的所有大小为S的数据块(偏移量可以任选，不一定非要是S的倍数)，来寻找与文件B的某一块有着相同的弱校验码和强校验码的数据块。这项工作可以借助滚动校验的特性很快完成。
5.α发给β一串指令来生成文件A在β上的备份。这里的每一条指令要么是对文件B经拥有某一个数据块而不须重传的证明，要么是一个数据块，这个数据块肯定是没有与文件B的任何一个数据块匹配上的。
Rsync的优点如下：
1.可以镜像保存整个目录树和文件系统；
2.可以很容易做到保持原来文件的权限、时间、软硬链接等；
3.无须特殊权限即可安装；
4.优化的流程，文件传输效率高；
5.可以使用rcp、ssh等方式来传输文件，当然也可以通过直接的socket连接；
6.支持匿名传输。
基本语法
- rsync [OPTION] [USER@]HOST:SRC DEST
- 使用远程 shell（如 ssh, rsh）实现将远程机器的内容拷贝到本地机器。 SRC 地址路径中以单个冒号 ":" 进行分隔。
- rsync [OPTION] SRC [USER@]HOST:DEST
- 使用远程 shell（如 rsh、ssh）实现本地机器的内容拷贝到远程机器。 DEST 地址路径中以单个冒号 ":" 进行分隔。
- rsync [OPTION] [USER@]HOST::SRC DEST 或
- rsync [OPTION] rsync://[USER@]HOST[:PORT]/SRC [DEST]
- 从远程 rsync 服务器中拷贝文件到本地机。 SRC 地址路径中以双冒号 "::" 进行分隔。
- rsync [OPTION] SRC [USER@]HOST::DEST 或
- rsync [OPTION] SRC rsync://[USER@]HOST[:PORT]/DEST
- 从本地机器拷贝文件到远程 rsync 服务器中。 DEST 地址路径中以双冒号 "::" 进行分隔。
如果 rsync 命令中只指定 SRC 参数而不指定 DEST 参数，则意为显示源文件列表而非进行同步拷贝。 rsync 有许多功能选项，常用的选项如下：
rsync 常用参数
选项
描述
-a, –archive
归档模式，保持所有文件属性，等同于 -rlptgoD
-v, –verbose
详细信息输出
-r, –recursive
对子目录进行递归处理
-R, –relative
使用相对路径信息
-b, –backup
创建备份
-z, –compress
对备份的文件在传输时进行压缩处理
–delete
用于同步目录，从 DEST 中将 SRC 不存在的文件进行删除
–progress
显示备份过程
rsync模式
rsync [OPTION]… SRC [SRC]… [USER@]HOST:DEST
rsync [OPTION]… [USER@]HOST:SRC DEST
rsync [OPTION]… SRC [SRC]… DEST
rsync [OPTION]… [USER@]HOST::SRC [DEST]
rsync [OPTION]… SRC [SRC]… [USER@]HOST::DEST
rsync [OPTION]… rsync://[USER@]HOST[:PORT]/SRC [DEST]
rsync有六种不同的工作模式：
拷贝本地文件；当SRC和DES路径信息都不包含有单个冒号":"分隔符时就启动这种工作模式。
使用一个远程shell程序（如rsh、ssh）来实现将本地机器的内容拷贝到远程机器。当DST路径地址包含单个冒号":"分隔符时启动该模式。
使用一个远程shell程序（如rsh、ssh）来实现将远程机器的内容拷贝到本地机器。当SRC地址路径包含单个冒号":"分隔符时启动该模式。
从远程rsync服务器中拷贝文件到本地机。当SRC路径信息包含"::"分隔符时启动该模式。
从本地机器拷贝文件到远程rsync服务器中。当DST路径信息包含"::"分隔符时启动该模式。
列远程机的文件列表。这类似于rsync传输，不过只要在命令中省略掉本地机信息即可。
使用实例：
- 查看服务端文件及列表
- 保持客户端与服务端的数据同步
- # rsync -avz ibmuser@9.186.110.53::www/ /backup1/
使用后台服务方式将服务端 www 模块下的内容备份到本地 /backup1 目录中，备份时保留原有权限、属性、属主及符号连接等，并使用压缩方式加快数据传输。
- # rsync – avz ibmuser@9.186.110.53:/var/www/html /backup2/
使用 ssh 方式将远程的 /var/www/html 目录备份到本地 /backup2/ 目录下
- # rsync -avz –delete ibmuser@9.186.110.53::www/ /backup3/
将远程 www 模块备份到本地 /backup3/ 目录中，同时进行同步目录，删除本地目录中多余的文件。
当服务端的数据出现问题时，需要通过客户端的数据对服务端进行恢复，只要客户端有服务端的写入权限，即可通过调换 rsync 命令的 SRC、DEST 参数进行恢复。
来源
版权声明：可以任意转载，但转载时必须标明原作者charlee、原始链接http://tech.idv2.com/2008/07/11/memcached-002/以及本声明。
下面是《memcached全面剖析》的第二部分。
发表日：2008/7/9
作者：前坂徹(Toru Maesaka)
原文链接：http://gihyo.jp/dev/feature/01/memcached/0002
我是mixi株式会社研究开发组的前坂徹。 上次的文章介绍了memcached是分布式的高速缓存服务器。本次将介绍memcached的内部构造的实现方式，以及内存的管理方式。另外，memcached的内部构造导致的弱点也将加以说明。
Slab Allocation机制：整理内存以便重复使用
最近的memcached默认情况下采用了名为Slab Allocator的机制分配、管理内存。在该机制出现以前，内存的分配是通过对所有记录简单地进行malloc和free来进行的。但是，这种方式会导致内存碎片，加重操作系统内存管理器的负担，最坏的情况下，会导致操作系统比memcached进程本身还慢。Slab Allocator就是为解决该问题而诞生的。
下面来看看Slab Allocator的原理。下面是memcached文档中的slab allocator的目标：
the primary goal of the slabs subsystem in memcached was to eliminate memory fragmentation issues totally by using fixed-size memory chunks coming from a few predetermined size classes.
也就是说，Slab Allocator的基本原理是按照预先规定的大小，将分配的内存分割成特定长度的块，以完全解决内存碎片问题。
Slab Allocation的原理相当简单。 将分配的内存分割成各种尺寸的块（chunk），并把尺寸相同的块分成组（chunk的集合）（图1）。
图1 Slab Allocation的构造图
而且，slab allocator还有重复使用已分配的内存的目的。也就是说，分配到的内存不会释放，而是重复利用。
Slab Allocation的主要术语
Page
分配给Slab的内存空间，默认是1MB。分配给Slab之后根据slab的大小切分成chunk。
Chunk
用于缓存记录的内存空间。
Slab Class
特定大小的chunk的组。
在Slab中缓存记录的原理
下面说明memcached如何针对客户端发送的数据选择slab并缓存到chunk中。
memcached根据收到的数据的大小，选择最适合数据大小的slab（图2）。 memcached中保存着slab内空闲chunk的列表，根据该列表选择chunk，然后将数据缓存于其中。
图2 选择存储记录的组的方法
实际上，Slab Allocator也是有利也有弊。下面介绍一下它的缺点。
Slab Allocator的缺点
Slab Allocator解决了当初的内存碎片问题，但新的机制也给memcached带来了新的问题。
这个问题就是，由于分配的是特定长度的内存，因此无法有效利用分配的内存。例如，将100字节的数据缓存到128字节的chunk中，剩余的28字节就浪费了（图3）。
图3 chunk空间的使用
对于该问题目前还没有完美的解决方案，但在文档中记载了比较有效的解决方案。
The most efficient way to reduce the waste is to use a list of size classes that closely matches (if that’s at all possible) common sizes of objects that the clients of this particular installation of memcached are likely to store.
就是说，如果预先知道客户端发送的数据的公用大小，或者仅缓存大小相同的数据的情况下，只要使用适合数据大小的组的列表，就可以减少浪费。
但是很遗憾，现在还不能进行任何调优，只能期待以后的版本了。但是，我们可以调节slab class的大小的差别。接下来说明growth factor选项。
使用Growth Factor进行调优
memcached在启动时指定 Growth Factor因子（通过-f选项），就可以在某种程度上控制slab之间的差异。默认值为1.25。但是，在该选项出现之前，这个因子曾经固定为2，称为“powers of 2”策略。
让我们用以前的设置，以verbose模式启动memcached试试看：
$ memcached -f 2 -vv
下面是启动后的verbose输出：
slab class 1: chunk size 128 perslab 8192
slab class 2: chunk size 256 perslab 4096
slab class 3: chunk size 512 perslab 2048
slab class 4: chunk size 1024 perslab 1024
slab class 5: chunk size 2048 perslab 512
slab class 6: chunk size 4096 perslab 256
slab class 7: chunk size 8192 perslab 128
slab class 8: chunk size 16384 perslab 64
slab class 9: chunk size 32768 perslab 32
slab class 10: chunk size 65536 perslab 16
slab class 11: chunk size 131072 perslab 8
slab class 12: chunk size 262144 perslab 4
slab class 13: chunk size 524288 perslab 2
可见，从128字节的组开始，组的大小依次增大为原来的2倍。这样设置的问题是，slab之间的差别比较大，有些情况下就相当浪费内存。因此，为尽量减少内存浪费，两年前追加了growth factor这个选项。
来看看现在的默认设置（f=1.25）时的输出（篇幅所限，这里只写到第10组）：
slab class 1: chunk size 88 perslab 11915
slab class 2: chunk size 112 perslab 9362
slab class 3: chunk size 144 perslab 7281
slab class 4: chunk size 184 perslab 5698
slab class 5: chunk size 232 perslab 4519
slab class 6: chunk size 296 perslab 3542
slab class 7: chunk size 376 perslab 2788
slab class 8: chunk size 472 perslab 2221
slab class 9: chunk size 592 perslab 1771
slab class 10: chunk size 744 perslab 1409
可见，组间差距比因子为2时小得多，更适合缓存几百字节的记录。从上面的输出结果来看，可能会觉得有些计算误差，这些误差是为了保持字节数的对齐而故意设置的。
将memcached引入产品，或是直接使用默认值进行部署时，最好是重新计算一下数据的预期平均长度，调整growth factor，以获得最恰当的设置。内存是珍贵的资源，浪费就太可惜了。
接下来介绍一下如何使用memcached的stats命令查看slabs的利用率等各种各样的信息。
查看memcached的内部状态
memcached有个名为stats的命令，使用它可以获得各种各样的信息。执行命令的方法很多，用telnet最为简单：
$ telnet 主机名 端口号
连接到memcached之后，输入stats再按回车，即可获得包括资源利用率在内的各种信息。此外，输入”stats slabs”或”stats items”还可以获得关于缓存记录的信息。结束程序请输入quit。
这些命令的详细信息可以参考memcached软件包内的protocol.txt文档。
$ telnet localhost 11211
Trying ::1...
Connected to localhost.
Escape character is '^]'.
stats
STAT pid 481
STAT uptime 16574
STAT time 1213687612
STAT version 1.2.5
STAT pointer_size 32
STAT rusage_user 0.102297
STAT rusage_system 0.214317
STAT curr_items 0
STAT total_items 0
STAT bytes 0
STAT curr_connections 6
STAT total_connections 8
STAT connection_structures 7
STAT cmd_get 0
STAT cmd_set 0
STAT get_hits 0
STAT get_misses 0
STAT evictions 0
STAT bytes_read 20
STAT bytes_written 465
STAT limit_maxbytes 67108864
STAT threads 4
END
quit
另外，如果安装了libmemcached这个面向C/C++语言的客户端库，就会安装 memstat 这个命令。使用方法很简单，可以用更少的步骤获得与telnet相同的信息，还能一次性从多台服务器获得信息。
$ memstat --servers=server1,server2,server3,...
libmemcached可以从下面的地址获得：
查看slabs的使用状况
使用memcached的创造着Brad写的名为memcached-tool的Perl脚本，可以方便地获得slab的使用情况（它将memcached的返回值整理成容易阅读的格式）。可以从下面的地址获得脚本：
使用方法也极其简单：
$ memcached-tool 主机名:端口 选项
查看slabs使用状况时无需指定选项，因此用下面的命令即可：
$ memcached-tool 主机名:端口
获得的信息如下所示：
# Item_Size Max_age 1MB_pages Count Full?
1 104 B 1394292 s 1215 12249628 yes
2 136 B 1456795 s 52 400919 yes
3 176 B 1339587 s 33 196567 yes
4 224 B 1360926 s 109 510221 yes
5 280 B 1570071 s 49 183452 yes
6 352 B 1592051 s 77 229197 yes
7 440 B 1517732 s 66 157183 yes
8 552 B 1460821 s 62 117697 yes
9 696 B 1521917 s 143 215308 yes
10 872 B 1695035 s 205 246162 yes
11 1.1 kB 1681650 s 233 221968 yes
12 1.3 kB 1603363 s 241 183621 yes
13 1.7 kB 1634218 s 94 57197 yes
14 2.1 kB 1695038 s 75 36488 yes
15 2.6 kB 1747075 s 65 25203 yes
16 3.3 kB 1760661 s 78 24167 yes
各列的含义为：
| 列 |
含义 |
| # |
slab class编号 |
| Item_Size |
Chunk大小 |
| Max_age |
LRU内最旧的记录的生存时间 |
| 1MB_pages |
分配给Slab的页数 |
| Count |
Slab内的记录数 |
| Full? |
Slab内是否含有空闲chunk |
从这个脚本获得的信息对于调优非常方便，强烈推荐使用。
内存存储的总结
本次简单说明了memcached的缓存机制和调优方法。希望读者能理解memcached的内存管理原理及其优缺点。
下次将继续说明LRU和Expire等原理，以及memcached的最新发展方向—— 可扩充体系（pluggable architecher））。
1、复制进程
Mysql的复制（replication）是一个异步的复制，从一个Mysql instace（称之为Master）复制到另一个Mysql instance（称之Slave）。实现整个复制操作主要由三个进程完成的，其中两个进程在Slave（Sql进程和IO进程），另外一个进程在 Master（IO进程）上。
要实施复制，首先必须打开Master端的binary log（bin-log）功能，否则无法实现。因为整个复制过程实际上就是Slave从Master端获取该日志然后再在自己身上完全顺序的执行日志中所记录的各种操作。
复制的基本过程如下：
1)、Slave上面的IO进程连接上Master，并请求从指定日志文件的指定位置（或者从最开始的日志）之后的日志内容；
2)、Master接收到来自Slave的IO进程的请求后，通过负责复制的IO进程根据请求信息读取制定日志指定位置之后的日志信息，返回给Slave 的IO进程。返回信息中除了日志所包含的信息之外，还包括本次返回的信息已经到Master端的bin-log文件的名称以及bin-log的位置；
3)、Slave的IO进程接收到信息后，将接收到的日志内容依次添加到Slave端的relay-log文件的最末端，并将读取到的Master端的 bin-log的文件名和位置记录到master-info文件中，以便在下一次读取的时候能够清楚的高速Master“我需要从某个bin-log的哪 个位置开始往后的日志内容，请发给我”；
4)、Slave的Sql进程检测到relay-log中新增加了内容后，会马上解析relay-log的内容成为在Master端真实执行时候的那些可执行的内容，并在自身执行。
实际上在老版本的Mysql的复制实现在Slave端并不是两个进程完成的，而是由一个进程完成。但是后来发现这样做存在较大的风险和性能问题，主要如下：
首先，一个进程就使复制bin-log日志和解析日志并在自身执行的过程成为一个串行的过程，性能受到了一定的限制，异步复制的延迟也会比较长。
另外，Slave端从Master端获取bin-log过来之后，需要接着解析日志内容，然后在自身执行。在这个过程中，Master端可能又产生了大量 变化并声称了大量的日志。如果在这个阶段Master端的存储出现了无法修复的错误，那么在这个阶段所产生的所有变更都将永远无法找回。如果在Slave 端的压力比较大的时候，这个过程的时间可能会比较长。
所以，后面版本的Mysql为了解决这个风险并提高复制的性能，将Slave端的复制改为两个进程来完成。提出这个改进方案的人是Yahoo!的一位工程 师“Jeremy Zawodny”。这样既解决了性能问题，又缩短了异步的延时时间，同时也减少了可能存在的数据丢失量。当然，即使是换成了现在这样两个线程处理以后，同 样也还是存在slave数据延时以及数据丢失的可能性的，毕竟这个复制是异步的。只要数据的更改不是在一个事物中，这些问题都是会存在的。如果要完全避免 这些问题，就只能用mysql的cluster来解决了。不过mysql的cluster是内存数据库的解决方案，需要将所有数据都load到内存中，这 样就对内存的要求就非常大了，对于一般的应用来说可实施性不是太大。
2、复制实现级别
Mysql的复制可以是基于一条语句（Statement level），也可以是基于一条记录（Row level），可以在Mysql的配置参数中设定这个复制级别，不同复制级别的设置会影响到Master端的bin-log记录成不同的形式。
Row Level：日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改。
优点：在row level模式下，bin-log中可以不记录执行的sql语句的上下文相关的信息，仅仅只需要记录那一条记录被修改了，修改成什么样了。所以row level的日志内容会非常清楚的记录下每一行数据修改的细节，非常容易理解。而且不会出现某些特定情况下的存储过程，或function，以及 trigger的调用和触发无法被正确复制的问题。
缺点：row level下，所有的执行的语句当记录到日志中的时候，都将以每行记录的修改来记录，这样可能会产生大量的日志内容，比如有这样一条update语 句：update product set owner_member_id = ‘b’ where owner_member_id = ‘a’，执行之后，日志中记录的不是这条update语句所对应额事件（mysql以事件的形式来记录bin-log日志），而是这条语句所更新的每一条 记录的变化情况，这样就记录成很多条记录被更新的很多个事件。自然，bin-log日志的量就会很大。尤其是当执行alter table之类的语句的时候，产生的日志量是惊人的。因为Mysql对于alter table之类的表结构变更语句的处理方式是整个表的每一条记录都需要变动，实际上就是重建了整个表。那么该表的每一条记录都会被记录到日志中。
Statement Level:每一条会修改数据的sql都会记录到 master的bin-log中。slave在复制的时候sql进程会解析成和原来master端执行过的相同的sql来再次执行。
优点：statement level下的优点首先就是解决了row level下的缺点，不需要记录每一行数据的变化，减少bin-log日志量，节约IO，提高性能。因为他只需要记录在Master上所执行的语句的细节，以及执行语句时候的上下文的信息。
缺点：由于他是记录的执行语句，所以，为了让这些语句在slave端也能正确执行，那么他还必须记录每条语句在执行的时候的一些相关信息，也就是上下文信 息，以保证所有语句在slave端杯执行的时候能够得到和在master端执行时候相同的结果。另外就是，由于Mysql现在发展比较快，很多的新功能不 断的加入，使mysql得复制遇到了不小的挑战，自然复制的时候涉及到越复杂的内容，bug也就越容易出现。在statement level下，目前已经发现的就有不少情况会造成mysql的复制出现问题，主要是修改数据的时候使用了某些特定的函数或者功能的时候会出现，比 如：sleep()函数在有些版本中就不能真确复制，在存储过程中使用了last_insert_id()函数，可能会使slave和master上得到 不一致的id等等。由于row level是基于每一行来记录的变化，所以不会出现类似的问题。
从官方文档中看到，之前的Mysql一直都只有基于statement的复制模式，直到5.1.5版本的Mysql才开始支持row level的复制。从5.0开始，Mysql的复制已经解决了大量老版本中出现的无法正确复制的问题。但是由于存储过程的出现，给Mysql的复制又带来 了更大的新挑战。另外，看到官方文档说，从5.1.8版本开始，Mysql提供了除Statement Level和Row Level之外的第三种复制模式：Mixed，实际上就是前两种模式的结合。在Mixed模式下，Mysql会根据执行的每一条具体的sql语句来区分对 待记录的日志形式，也就是在Statement和Row之间选择一种。新版本中的Statment level还是和以前一样，仅仅记录执行的语句。而新版本的Mysql中队row level模式也被做了优化，并不是所有的修改都会以row level来记录，像遇到表结构变更的时候就会以statement模式来记录，如果sql语句确实就是update或者delete等修改数据的语句， 那么还是会记录所有行的变更。
3、复制常用架构
Mysql复制环境90%以上都是一个Master带一个或者多个Slave的架构模式，主要用于读压力比较大的应用的数据库端廉价扩展解决方案。因为只 要master和slave的压力不是太大（尤其是slave端压力）的话，异步复制的延时一般都很少很少。尤其是自slave端的复制方式改成两个进程 处理之后，更是减小了slave端的延时。而带来的效益是，对于数据实时性要求不是特别的敏感度的应用，只需要通过廉价的pc server来扩展slave的数量，将读压力分散到多台slave的机器上面，即可解决数据库端的读压力瓶颈。这在很大程度上解决了目前很多中小型网站 的数据库压力瓶颈问题，甚至有些大型网站也在使用类似方案解决数据库瓶颈。
一个Master带多个slave的架构实施非常简单，多个slave和单个slave的实施并没有太大区别。在Master端并不care有多少个 slave连上了master端，只要有slave进程通过了连接认证，向他请求binlog信息，他就会按照连接上来的io进程的要求，读取自己的 binlog信息，返回给slave的IO进程。对于slave的配置细节，在Mysql的官方文档上面已经说的很清楚了，甚至介绍了多种实现slave 的配置方法。
Mysql不支持一个Slave instance从属于多个Master的架构。就是说，一个slave instance只能接受一个master的同步源，听说有patch可以改进这样的功能，但没有实践过。Mysql AB之所以不实现这样的功能，主要是考虑到冲突解决的问题。
Mysql也可以搭建成dual master模式，也就是说两个Mysql instance互为对方的Master，也同时为对方的Slave。不过一般这种架构也是只有一端提供服务，避免冲突问题。因为即使在两边执行的修改有 先后顺序，由于复制的异步实现机制，同样会导致即使在晚做的修改也可能会被早做的修改所覆盖，就像如下情形：
时间点 Mysql A Mysql B
1 更新x表y记录为10
2 更新x表y记录为20
3 获取到A日志并应用，更新x表的y记录为10（不符合期望）
4 获取B日志更新x表y记录为20（符合期望）
这样，不仅在B库上面的数据不是用户所期望的结果，A和B两边的数据也出现了不一致的情况。除非能将写操作根据某种条件固定分开在A和B两端，保证不会交叉写入，才能够避免上面的问题。
原文首发： Sky.Jian 朝阳的天空
原文链接：MySQL Replication(复制)基本原理
