目录
一 redis的拓扑结构
(1)什么是拓扑
(2)⼀主⼀从结构
(3)⼀主多从结构
(4)树形主从结构
(5)三种拓扑结构的优缺点,以及适用场景
二 redis的复制原理
(1)复制过程
(2)数据同步psync
replicationid/replid (复制id)(标注同步的数据来自哪里:数据来源)
offset (偏移量)(标注同步的进度)
replication id 和 offset 共同描述了一个数据集合
一 redis的拓扑结构
(1)什么是拓扑
答案:说白了就是若干个结点之间,按照啥样的方式来进行组织连接
Redis 的复制拓扑结构可以⽀持单层或多层复制关系，根据拓扑复杂性可以分为以下三种：⼀主⼀ 从、⼀主多从、树状主从结构。
(2)⼀主⼀从结构
⼀主⼀从结构是最简单的复制拓扑结构，⽤于主节点出现宕机时从节点提供故障转移⽀持，如图 所⽰。当应⽤写命令并发量较⾼且需要持久化时，可以只在从节点上开启AOF，这样既可以保证数据 安全性同时也避免了持久化对主节点的性能⼲扰。但需要注意的是，当主节点关闭持久化功能时，如 果主节点宕机要避免⾃动重启操作。
(3)⼀主多从结构
⼀主多从结构（星形结构）使得应⽤端可以利⽤多个从节点实现读写分离，如图5-3所⽰。对于 读⽐重较⼤的场景，可以把读命令负载均衡到不同的从节点上来分担压⼒。同时⼀些耗时的读命令可 以指定⼀台专⻔的从节点执⾏，避免破坏整体的稳定性。对于写并发量较⾼的场景，多个从节点会导 致主节点写命令的多次发送从⽽加重主节点的负载。
(4)树形主从结构
树形主从结构（分层结构）使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主 节点继续向下层复制。通过引⼊复制中间层，可以有效降低住系欸按负载和需要传送给从节点的数据 量，如图所⽰。数据写⼊节点A之后会同步给B和C节点，B节点进⼀步把数据同步给D和E节 点。当主节点需要挂载等多个从节点时为了避免对主节点的性能⼲扰，可以采⽤这种拓扑结构。
(5)三种拓扑结构的优缺点,以及适用场景
一主一从:就像一个初创公司,只有你和老板两个人,老板给你同步数据,你只负责读数据,老板要负责写数据和读数据
一主多从:就像发展中的公司人员多了一些,但是还在老板管理范围之内,老板亲自给每位员工同步数据,这就会造成一个问题,同步数据是通过网络通信,成本比较高,10个员工同步10次,1w个员工同步1w次,消耗太大了扛不住,会给主节点带来严重负担,甚至崩溃
树形主从结构:就像比较完善的公司,有了不同的部门,老板只需要把数据同步给各部门负责人,再由每个负责人同步给更下边的员工即可,只是叶子结点上的员工得到同步数据的延时也增加了
二 redis的复制原理
(1)复制过程
如图所⽰，下⾯详细介绍建⽴复制的完整流程。从图中可以看出复制过程⼤致分为6个过程：
主从节点建⽴复制流程图
1）保存主节点（master）的信息。
开始配置主从同步关系之后，从节点只保存主节点的地址信息，此时建⽴复制流程还没有开始，在从节点6380执⾏inforeplication可以看到如下信息：
1. master_host: 127.0.0.1
2. master_port: 6379
3. master_link_status: down
#从统计信息可以看出，主节点的ip和port被保存下来，但是主节点的连接状态（master_link_status）是下线状态。2）从节点（slave）内部通过每秒运⾏的定时任务维护复制相关逻辑，当定时任务发现存在新的主节点后，会尝试与主节点建⽴基于TCP的⽹络连接。如果从节点⽆法建⽴连接，定时任务会⽆限重试直到连接成功或者⽤⼾停⽌主从复制。3）发送ping命令。连接建⽴成功之后，从节点通过ping命令确认主节点在应⽤层上是⼯作良好的。如果ping命令的结果pong回复超时，从节点会断开TCP连接，等待定时任务下次重新建⽴连接。4）权限验证。如果主节点设置了requirepass参数，则需要密码验证，从节点通过配置masterauth参数来设置密码。如果验证失败，则从节点的复制将会停⽌。5）同步数据集。对于⾸次建⽴复制的场景，主节点会把当前持有的所有数据全部发送给从节点，这步操作基本是耗时最⻓的，所以⼜划分称两种情况：全量同步和部分同步，下⼀节重点介绍。6）命令持续复制。当从节点复制了主节点的所有数据之后，针对之后的修改命令，主节点会持续的把命令发送给从节点，从节点执⾏修改命令，保证主从数据的⼀致性。
(2)数据同步psync
Redis 使⽤psync命令完成主从数据同步，同步过程分为：全量复制和部分复制。
- 全量复制：⼀般⽤于初次复制场景，Redis早期⽀持的复制功能只有全量复制，它会把主节点全部 数据⼀次性发送给从节点，当数据量较⼤时，会对主从节点和⽹络造成很⼤的开销。
- 部分复制：⽤于处理在主从复制中因⽹络闪断等原因造成的数据丢失场景，当从节点再次连上主节 点后，如果条件允许，主节点会补发数据给从节点。因为补发的数据远⼩于全量数据，可以有效避 免全量复制的过⾼开销。
PSYNC的语法格式
PSYNC replicationid offset- 如果replicationid 设为?并且offset设为-1 此时就是在尝试进⾏全量复制.
- 如果replicationid offset 设为了具体的数值,则是尝试进⾏部分复制.
replicationid/replid (复制id)(标注同步的数据来自哪里:数据来源)
板书如下:
主节点的复制id.主节点重新启动,或者从节点晋级成主节点,都会⽣成⼀个replicationid.(同⼀个节 点,每次重启,⽣成的replicationid也会变化). 从节点在和主节点建⽴连接之后,就会获取到主节点的replicationid.
通过 info replication 即可看到replicationid
127.0.0.1:6379> info replication #Replication role:master connected_slaves:0 master_replid:1da596acecf5a34b4b2aae45bd35be785691ae69 master_replid2:0000000000000000000000000000000000000000 master_repl_offset:0 second_repl_offset:-1 repl_backlog_active:0 repl_backlog_size:1048576 repl_backlog_first_byte_offset:0 repl_backlog_histlen:0关于master_replid和master_replid2
每个节点需要记录两组master_replid.这个设定解决的问题场景是这样的:
⽐如当前有两个节点A和B,A为master,B为slave.
此时B就会记录A的master_replid.
如果⽹络出现抖动,B以为A挂了,B⾃⼰就会成为主节点.于是B给⾃⼰分配了新master_replid. 此时就会使⽤master_replid2来保存之前A的master_replid.
- 后续如果⽹络恢复了,B就可以根据master_replid2找回之前的主节点.
- 后续如果⽹络没有恢复,B就按照新的master_replid⾃成⼀派,继续处理后续的数据.
offset (偏移量)(标注同步的进度)
板书如下
参与复制的主从节点都会维护⾃⾝复制偏移量。主节点（master）在处理完写⼊命令后，会把命令的 字节⻓度做累加记录，统计信息在inforeplication中的master_repl_offset指标中。
127.0.0.1:6379> info replication # Replication role:master ... master_repl_offset:1055130从节点（slave）每秒钟上报⾃⾝的复制偏移量给主节点，因此主节点也会保存从节点的复制偏移量， 统计指标如下：
127.0.0.1:6379> info replication connected_slaves:1 slave0:ip=127.0.0.1,port=6380,state=online,offset=1055214,lag=1 ...从节点在接受到主节点发送的命令后，也会累加记录⾃⾝的偏移量。统计信息在inforeplication中的 slave_repl_offset 指标中：
127.0.0.1:6380> info replication # Replication role:slave ... slave_repl_offset:1055214复制偏移量的维护如图所⽰。通过对⽐主从节点的复制偏移量，可以判断主从节点数据是否⼀致。
replication id 和 offset 共同描述了一个数据集合
