Redis：主从复制

最新推荐文章于 2024-11-28 22:47:18 发布

_李白_

最新推荐文章于 2024-11-28 22:47:18 发布

阅读量506

点赞数

CC 4.0 BY-SA版权

分类专栏： redis 文章标签： redis

本文链接：https://blog.csdn.net/weixin_40179091/article/details/115594704

redis 专栏收录该内容

14 篇文章

订阅专栏

1、主从复制的概念

redis为了实现高可用（比如解决单点故障的问题），会把数据复制多个副本部署到其他节点上，通过复制，实现Redis的高可用性，实现对数据的冗余备份，保证数据和服务的可靠性。比如：

如何配置的：

配置⽂件：在从服务器的配置⽂件中加⼊：slaveof
启动命令： redis-server启动命令后加⼊ --slaveof
客户端命令： Redis服务器启动后，直接通过客户端执⾏命令：slaveof ，则该Redis实例成为从节点。

主从复制信息显示如下图：

主节点有从节点前后的变化：

某个节点成为从节点之后的变化：

主从复制的作⽤

数据冗余：主从复制实现了数据的热备份，是持久化之外的⼀种数据冗余⽅式。
故障恢复：当主节点出现问题时，可以由从节点提供服务，实现快速的故障恢复；实际上是⼀种服务的冗余。
负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（即写Redis数据时应⽤连接主节点，读Redis数据时应⽤连接从节点），分担服务器负载；尤其是在写少读多的场景下，通过多个从节点分担读负载，可以⼤⼤提⾼Redis服务器的并发量。
读写分离：可以⽤于实现读写分离，主库写、从库读，读写分离不仅可以提⾼服务器的负载能⼒，同时可根据需求的变化，改变从库的数量；
⾼可⽤基⽯：除了上述作⽤以外，主从复制还是哨兵和集群能够实施的基础，因此说主从复制是Redis⾼可⽤的基础。

2、主从复制的机制

Redis的主从复制功能除了⽀持⼀个Master节点对应多个Slave节点的同时进⾏复制外，还⽀持Slave节点向其它多个Slave节点进⾏复制。这样就使得架构师能够灵活组织业务缓存数据的传播，例如使⽤多个Slave作为数据读取服务的同时，专⻔使⽤⼀个Slave节点为流式分析⼯具服务。Redis的主从复制功能分为两种数据同步模式进⾏：全量数据同步和增量数据同步。

2.1、全量同步

上图简要说明了Redis中Master节点到Slave节点的全量数据同步过程。当Slave节点给定的replication id和Master的replication id不⼀致时，或者Slave给定的上⼀次增量同步的offset的位置在Master的环形内存中(replication backlog)⽆法定位时（就是从节点欠缺数据过多），Master就会对Slave发起全量同步操作。这时⽆论您是否在Master打开了RDB快照功能，它和Slave节点的每⼀次全量同步操作过程都会更新/创建Master上的RDB⽂件。在Slave连接到Master，并完成第⼀次全量数据同步后，接下来Master到Slave的数据同步过程⼀般就是增量同步形式了（也称为部分同步）。增量同步过程不再主要依赖RDB⽂件，

Master会将新产⽣的数据变化操作存放在replication backlog这个内存缓存区，这个内存区域是⼀个环形缓冲区，也就是说是⼀个FIFO的队列。

2.2、增量同步

master作为⼀个普通的client连⼊slave，将所有写操作转发给slave，没有特殊的同步协议。具体过程如下：

为什么在Master上新增的数据除了根据Master节点上RDB或者AOF的设置进⾏⽇志⽂件更新外，还会同时将数据变化写⼊⼀个环形内存结构（replication backlog），并以后者为依据进⾏Slave节点的增量更新呢？主要原因有以下⼏个：

由于⽹络环境的不稳定，⽹络抖动/延迟都可能造成Slave和Master暂时断开连接，这种情况要远远多于新的Slave连接到Master的情况。如果以上所有情况都使⽤全量更新，就会⼤⼤增加Master的负载压⼒——写RDB⽂件是有⼤量I/O过程的，虽然Linux Page Cahe特性会减少性能消耗。
另外在数据量达到⼀定规模的情况下，使⽤全量更新进⾏和Slave的第⼀次同步是⼀个不得已的选择 ——因为要尽快减少Slave节点和Master节点的数据差异。所以只能占⽤Master节点的资源和⽹络带宽资源。
使⽤内存记录数据增量操作，可以有效减少Master节点在这⽅⾯付出的I/O代价。⽽做成环形内存的原因，是为了保证在满⾜数据记录需求的情况下尽可能减少内存的占⽤量。这个环形内存的⼤⼩，可以通过repl-backlog-size参数进⾏设置。

Slave重连后会向Master发送之前接收到的Master replication id信息和上⼀次完成部分同步的offset的位置信息。如果Master能够确定这个replication id和⾃⼰的replication id(有两个)⼀致且能够在环形内存中找到这个offset的位置，Master就会发送从offset的位置开始向Slave发送增量数据。那么连接正常的各个Slave节点如何接受新数据呢？连接正常的Slave节点将会在Master节点将数据写⼊环形内存后，主动接收到来⾃Master的数据复制信息。

这里就有⼀个问题了，我们的replication backlog的size设置为多⼤合适？ redis为replication backlog设置的默认⼤⼩为1M（repl-backlog-size），但是这个值是可以调整的，如果主服务器需要执行大量的写命令，⼜或者主从服务器之间断线后重连的时间⽐较⻓，那么这个大小也许并不合适。如果replication backlog的大小设置不恰当，那么PSYNC命令的复制同步模式就不能正常发挥作⽤，因此，正确估算和设置replication backlog的size⾮常重要。可以参考下面的值：

reconnect_time_second * write_size_per_second*2

reconnect_time_second : 重连时间，以秒未单位

write_size_per_second : 每秒写⼊的命令大小