这篇文章主要介绍了Redis复制原理的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让小编带着大家一起了解一下。
本文主要介绍Redis复制机制
Redis实例分为主节点（master）和从节点（slave），默认情况下都是主节点。每一个从节点只能有一个主节点，但是每一个主节点可以有多个从节点（注意数量，多个从节点会导致主节点写命令多次发送从而过度消耗网络带宽，可用树状结构降低主节点负载）。复制是单向的，只能从主节点复制到从节点。配置复制的方式由以下3种：
在redis-slave.conf配置文件中加入slaveof {masterHost} {masterPort}
在redis-server启动命令后加入 --slaveof {masterHost} {masterPort}
启动后直接使用命令slaveof {masterHost} {masterPort}
综上，Redis支持在启动之前配置，也支持运行中动态配置。
我们用动态配置的方法来配置，先起一个端口为6379的Redis实例，作为主节点：
redis-server /usr/local/Cellar/redis/4.0.9/.bottle/etc/redis.conf
再起一个端口为6380的Redis实例，作为6379的从节点：
redis-server /usr/local/Cellar/redis/4.0.9/.bottle/etc/redis-slave.conf
用客户端连到从节点，使用slaveof命令，slaveof配置都是在从节点发起的。
127.0.0.1:6380> slaveof 127.0.0.1 6379
OK
从节点日志：
75585:S 06 May 16:27:50.389 * Connecting to MASTER 127.0.0.1:6379
75585:S 06 May 16:27:50.389 * MASTER <-> SLAVE sync started
75585:S 06 May 16:27:50.390 * Non blocking connect for SYNC fired the event.
75585:S 06 May 16:27:50.390 * Master replied to PING, replication can continue...
75585:S 06 May 16:27:50.390 * Trying a partial resynchronization (request 47770067272eb8101489fe7c00c8e838125c3aa3:1).
75585:S 06 May 16:27:50.392 * Full resync from master: e91e683b1e13332f97ecb9fa90ecdace460ab4ca:0
75585:S 06 May 16:27:50.392 * Discarding previously cached master state.
75585:S 06 May 16:27:50.491 * MASTER <-> SLAVE sync: receiving 215 bytes from master
75585:S 06 May 16:27:50.492 * MASTER <-> SLAVE sync: Flushing old data
75585:S 06 May 16:27:50.492 * MASTER <-> SLAVE sync: Loading DB in memory
75585:S 06 May 16:27:50.492 * MASTER <-> SLAVE sync: Finished with success
主节点日志：
75553:M 06 May 16:27:50.391 * Slave 127.0.0.1:6380 asks for synchronization
75553:M 06 May 16:27:50.391 * Partial resynchronization not accepted: Replication ID mismatch (Slave asked for '47770067272eb8101489fe7c00c8e838125c3aa3', my replication IDs are '160af1c75f86edc50186e3e4a4dc6ecb5e3fa586' and '0000000000000000000000000000000000000000')
75553:M 06 May 16:27:50.391 * Starting BGSAVE for SYNC with target: disk
75553:M 06 May 16:27:50.391 * Background saving started by pid 75675
75675:C 06 May 16:27:50.395 * DB saved on disk
75553:M 06 May 16:27:50.490 * Background saving terminated with success
75553:M 06 May 16:27:50.491 * Synchronization with slave 127.0.0.1:6380 succeeded
可以看到，第一次建立复制关系的时候，主节点和从节点进行了一次全量复制，见图：
当完成复制的建立之后，接下来主节点会持续的把写命令发送给从节点，保证主从数据一致。
在主实例上添加新的key：
127.0.0.1:6379> set Lin 112131
OK
在从实例查看刚刚添加的key：
127.0.0.1:6380> get Lin
"112131"
由于复制只能从主节点到从节点，对于从节点的数据修改主节点无法感知，为了避免主从实例之间的数据不一致。从节点默认配置为只读模式：
slave-read-only yes
我们先讲3个比较关键的参数：master_replid、master_repl_offset和slave_repl_offset。我们分别在master6379和slave6380上执行info replication
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1093,lag=1
master_replid:e91e683b1e13332f97ecb9fa90ecdace460ab4ca
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1093
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1093
127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:9
master_sync_in_progress:0
slave_repl_offset:1107
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:e91e683b1e13332f97ecb9fa90ecdace460ab4ca
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1107
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1107
master_replid是master启动时生成的随机字符串，用来标识主实例
master_repl_offset是复制流中的一个偏移量，master处理完写入命令后，会把命令的字节长度做累加记录，统计在该字段。该字段也是实现部分复制的关键字段。
slave_repl_offset同样也是一个偏移量，从节点收到主节点发送的命令后，累加自身的偏移量，通过比较主从节点的复制偏移量可以判断主从节点数据是否一致。
当从实例连接到主实例时，从实例会发送master_replid和master_repl_offset（标识与主实例同步的最后一个快照）请求部分复制。如果主实例接收部分复制的话则从最后一个偏移量开始增量进行部分复制，否则将进行全量复制。如图：
Redis在2.8之前使用sync命令完成主从数据同步，Redis在2.8及以上使用psync命令完成主从数据同步，同步过程分为：全量复制和部分复制
全量复制是Redis最早支持的复制方式，也是主从第一次建立复制的时候必须经历的。它会把主节点全部数据一次性发送给从节点，当数据量较大的时候，会对主从节点和网络造成很大开销。主节点执行bgsave保存RDB文件，然后将这个文件发送给从节点，从节点收到RDB文件后，会先将内存中的所有数据清除，然后再将RDB文件中的数据导入。
主实例在复制过程中是完全异步的，因此不会阻塞主节点的请求。在这一期间内主节点的所有写入命令数据都保存在从客户端缓冲区（slave client buffer）内，在从节点加载完RDB文件后，主节点会将这个缓冲区的内容发送给从节点。
从客户端缓冲区默认大小限制为：
client-output-buffer-limit slave 256mb 64mb 60
意思是如果60秒内缓冲区消耗持续大于64MB或者直接超过256MB时，主节点将直接关闭复制客户端连接，造成全量同步失败。
在高版本的Redis实现中，master_replid和offset存储在RDB文件中。当从实例在复制过程中，因网络闪断等原因造成的数据丢失场景，Redis能够从rdb文件中重新加载master_replid和offset，从而使部分重新同步成为可能。因为补发的数据远小于全量数据，所以可以有效的避免全量复制带来的负载和消耗。
之前说过，从节点连接主节点之后，会使用master_replid和master_repl_offset请求主节点，首先判断master_replid是否和自己的master_replid一致，然后检查请求中的master_repl_offset是否能从缓冲区（replication backlog）中获取，如果偏移量在backlog范围内，那么可以进行部分复制。如果在断开连接期间主节点收到的写入命令的数量超过了backlog缓冲区的容量，那么会进行全量复制。默认情况下backlog为1MB。
感谢你能够认真阅读完这篇文章，希望小编分享的“Redis复制原理的示例分析”这篇文章对大家有帮助，同时也希望大家多多支持亿速云，关注亿速云行业资讯频道，更多相关知识等着你来学习!
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。
