redis主从复制(Master、Slave)

Redis主从复制详解
最新推荐文章于 2025-09-14 21:34:02 发布
转载 最新推荐文章于 2025-09-14 21:34:02 发布 · 379 阅读 · 0

本文详细介绍了Redis的主从复制机制，包括其概念、应用场景、配置步骤、复制原理及哨兵模式等内容。通过本文，读者可以了解到如何进行读写分离、容灾恢复，并掌握哨兵模式下的自动故障转移。
1、是什么
行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略，自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主。

2、能干嘛
读写分离；
容灾恢复；

3、怎么玩？
配从(库)不配主(库)
从库配置：slaveof 主库IP 主库端口
每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件
info replication（查看当前节点的主从信息，及节点状态等）
修改配置文件细节操作
拷贝多个redis.conf文件
开启daemonize yes
pid文件名字
指定端口
log文件名字
dump.rdb名字
几种实现策略：
一主二仆（可三从、四从、、 ）
Init
一个Master两个Slave
日志查看
主机日志
备机日志
info replication
主从问题演示
1 切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制。从头开始复制
2 从机是否可以写？set可否？从机只读
3 主机shutdown后情况如何？从机是上位还是原地待命。原地待命
4 主机又回来了后，主机新增记录，从机还能否顺利复制？顺利复制
5 其中一台从机down后情况如何？依照原有它能跟上大部队吗？可以
薪火相传
上一个Slave可以是下一个slave的Master，Slave同样可以接收其他slaves的连接和同步请求，那么该slave作为了链条中下一个的master，可以有效减轻master的写压力。
中途变更转向：会清除之前的数据，重新建立拷贝最新的
slaveof 新主库IP 新主库端口
反客为主（SLAVEOF no one）
使当前数据库停止与其他数据库的同步，转成主数据库

4、复制原理
slave启动成功连接到master后会发送一个sync命令；
Master接到命令启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master将传送整个数据文件到slave，以完成一次完全同步；
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中；
增量复制：Master继续将新的所有收集到的修改命令依次传给slave，完成同步；
但是只要是重新连接master,一次完全同步（全量复制）将被自动执行；

5、哨兵模式(sentinel)
是什么？
反客为主的自动版。能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库
怎么玩(使用步骤)
调整结构，6379带着80、81；
自定义的/myredis目录下新建sentinel.conf文件，名字绝不能错；
配置哨兵,填写内容
sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1
上面最后一个数字1，表示主机挂掉后salve投票看让谁接替成为主机，得票数多少后成为主机
启动哨兵
redis-sentinel /myredis/sentinel.conf
上述目录依照各自的实际情况配置，可能目录不同
正常主从演示，原有的master挂了，投票新选，重新主从继续开工，
info replication，查查看
问题：如果之前的master重启回来，会不会双master冲突？不会，编程slave
一组sentinel能同时监控多个Master
Redis 主从复制的原理详解
qq_43197840的博客
09-20 2075
当 Sentinel 发现主节点故障时，会通过选举机制，将其中一个从节点提升为新的主节点，并通知其他从节点重新指向新的主节点。如果从节点与主节点断开连接，当从节点恢复连接后，主节点会将自从连接断开后的增量数据发送给从节点，以保持数据的同步。手动故障恢复：在传统的 Redis 主从复制架构中，当主节点故障时，通常需要人工干预，将其中一个从节点提升为主节点，并重新配置其他节点指向新的主节点。增量复制：在全量复制完成后，从节点会通过命令传播机制，接收主节点的实时写操作日志，并应用到自己的数据集中，实现实时同步。
【Redis】Redis 主从复制原理与配置详解：解决单点故障与性能瓶颈的最佳方案
Hsusan的博客
09-05 2049
当从节点正在复制主节点时，如果出现⽹络闪断或者命令丢失等异常情况时，从节点会向主节点要求补发丢失的命令数据，如果主节点的复制积压缓冲区存在数据则直接发送给从节点，这样就可以保持主从节点复制的⼀致性。⼀主⼀从结构是最简单的复制拓扑结构，⽤于主节点出现宕机时从节点提供故障转移⽀持，如图所⽰。复制积压缓冲区是保存在主节点上的⼀个固定⻓度的队列，默认⼤⼩为 1MB，当主节点有连接的从节点（slave）时被创建，这时主节点（master）响应写命令时，不但会把命令发送给从节点，还会写⼊复制积压缓冲区，如图所⽰。
Redis系列-主从复制配置
心灵净土
03-16 9432
redis虽然有着卓越的性能，但我们仍然可以通过master/slave这种简单架构，进行读写分离，进一步挖掘redis的性能，提高系统的可用性。 redis怎么进行主从复制呢？redis复制主要是通过master server持久化的rdb文件实现的。master server 先dump出内存快照文件，然后将rdb文件传给slave server，slave server 根据rdb文件
redis集群（主从复制、高可用、去中心化）
最新发布
2402_83438398的博客
09-14 696
本文介绍了Redis集群的主从复制架构及其配置方法。主要内容包括：1) 主从复制原理，通过读写分离提升吞吐量，实现数据备份和最终一致性；2) 详细配置步骤，包括master和slave节点的环境准备与参数设置；3) 主从切换演示，当master宕机时如何将slave提升为新master。文章通过实验验证了主从数据同步的有效性，并展示了主从角色的临时和永久配置方式。核心在于利用主从架构解决高并发访问问题，同时保证系统的可用性和数据安全性。
【Redis主从架构】Redis哨兵主备切换时数据丢失问题：异步复制，集群脑裂
【程序员不弃】的博客
06-22 1184
9. 【Redis主从架构】Redis哨兵主备切换时数据丢失问题：异步复制，集群脑裂 redis哨兵主备切换两种数据丢失的情况 解决异步复制和脑裂导致的数据丢失 1. 两种导致数据丢失的情况 1.1 异步复制导致数据丢失 因为 master -> slave的复制都是异步的，所以有可能出现master内存中的部分数据来不及复制到slave上，master就宕机了，随后通过哨兵执行主备切换，导致这部分数据丢失。 1.2 脑裂导致的数据丢失 脑裂 脑裂：某个master所在的机器突然脱离了
redis master/slave+sentinel 集群配置
Vv的博客
11-16 3365
架构示意图 如上图所示： 两台服务器分别存在一主一丛，且分别为交叉主从关系，且在服务器上分别有sentinel(哨兵)来监控当前服务器主从情况，通过sentinel进行主从切换，完成failover。 说明： master_16319、slave_26319。 master_16320、slave_26320。 分别对应两组不同的组从，配置文件分别对
Redis主从复制
L1ak的博客
08-17 180
1 sdafas
Redis主从复制和集群配置
08-21
Redis的主从复制机制是一种重要的数据同步方式，它支持一个或多个从数据库(slave)与主数据库(master)之间进行数据同步。其中，主数据库负责处理写操作，并自动将这些写操作同步到所有从数据库；而从数据库通常只用于...
Redis主从复制以及主从复制技术原理.docx
10-14
前者称为主节点(master)，后者称为从节点(slave)，数据的复制是单向的，只能由主节点到从节点。默认情况下，每台 Redis 服务器都是主节点；且一个主节点可以有多个从节点(或没有从节点)，但一个从节点只能有一个主...
日常记录-redis主从复制（master-slave）+ Sentinel 哨兵（高可用）
04-23
redis安装包
黑猴子的家：Redis 一主二仆模式
黑猴子的博客
10-16 320
（1）切入点问题？slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来，那之前的123是否也可以复制？ 从头复制 （2）从机是否可以写？set可否？ 不可写，可以配置成写的，但是没有这么做的 （3）主机shutdown后情况如何？从机是上位还是原地待命？ 一主二仆模式中死等 （4）主机又回来了后，主机新增记录，从机还能否顺利复制？ 一主二仆模式中可以 （5）...
redis(1)-主从复制（一主二仆）
aggie4628的专栏
09-15 192
1.机器编号 2.复制并修改配置文件 3.主从复制的实现与5个特点 1.机器编号 主机名 修改文件server_id redis.conf 文件的目录 文件差异 IP（此处为我本机的IP地址） PC-centos-57-master 100 /usr/local/bin/myredisconfig（一般都在这） 192.168.9.29:6379 PC-win10-slave1 1 D:\Environment...
Redis主从复制原理——一主二仆
DKPT的博客
05-29 378
1.主机不配置，从机使用slaveof声明所属主机。 2.主机如果宕机，重启后自动恢复到之前的转态，不需要再做其他任何修改，再新增加数据，从机可以读到数据。 3.从机如果宕机，再次重启后，再次读数据，读不到。需要使用slaveof再次声明所属主机，声明之后可以再次读取数据。 4.主机可写可读，从机只可以读，不可以写。 5.从机使用slaveof声明所属主机是，会发送sync到主机，获取主机的rdb文件，执行，实现数据同步，以后再增数据，使用增量复制完成同步。如果是宕机后再次声明所属主机，则使用全量复制完成同
Redis主从复制案例（一主二仆）
Mr 敦（A.Dun）Java历险记
10-15 533
文章目录主从复制一主二仆（1）配置三个redis,启动查看运行情况（2）配从(库)不配主(库)(3)宕机情况（i）主机宕机(ii) 从机宕机 主从复制 一主二仆 （1）配置三个redis,启动查看运行情况 新建redis6379.conf，填写以下内容 新建redis6380.conf，填写以下内容 新建redis6381.conf，填写以下内容 slave-priority 10 设置从机的优先级，值越小，优先级越高，用于选举主机时使用。默认100 启动三台redis服务器 查看系统进程，看看三台服
redis主从复制-一主二仆
cdtdt的博客
04-15 662
快速搭建redis主从复制，一主二仆实现方式，redis有密码版本
redis集群搭建学习一主从复制（一主二仆）
lys1695227550的博客
12-23 407
lin环境： 网络环境：桥接搭建 搭建就是解压，进入 make 然后 进入src make install bin是常用命令，etc是配置文件 检查环境，三台都已经搭建ok，并且都能够单机使用redis 1、主从模式 关闭所有redis,下面是关闭一台的截图 master不变 清空所有的redis中的数据 使用info命令查看 可以看出主...
redis学习笔记，Redis的复制(Master/Slave)
qq_28527469的博客
10-21 277
是什么 官网 行话：也就是我们所说的主从复制，主机数据更新后根据配置和策略， 自动同步到备机的master/slaver机制，Master以写为主，Slave以读为主 能干嘛 读写分离 容灾恢复 怎么玩 配从(库)不配主(库) 从库配置：slaveof 主库IP 主库端口 每次与master断开之后，都需要重新连接，除非你配置进redis.conf文件 In...
Redis主从复制 一主二仆 哨兵监控
Bigger-Xu
06-19 1256
准备工作 从官网下载redis,且安装完成（网上有很多教程，不在介绍） 1.将redis.conf文件复制三份，原文件保证不动 2.修改一下属性，三个文件对应修改 redis6379.conf 6379作为主 port 6379 # 开启后台运行 daemonize yes #设置pid进程 pidfile "/var/run/redis6379.pid" #设置log文件 logfile "redis6379.log" #RDB持久化默认是打开，设置一下名字 也可以关闭该功能 sava ""
redis 主从复制模式 Slave 处理读请求（需客户端路由）
06-18
<think>我们正在讨论Redis主从复制模式下Slave节点如何处理读请求，以及客户端如何路由读请求到Slave节点。根据引用[1]和[5]，主从复制模式中，Master节点负责写操作，Slave节点负责读操作，实现读写分离。但是，Redis本身并不提供自动的路由机制，需要客户端或中间件来实现。具体分析：1.Slave节点处理读请求：Slave节点启动后会连接到Master节点同步数据，之后Master的数据变更会异步复制到Slave。因此，Slave节点上的数据可能不是最新的（存在延迟，见引用[2]）。客户端可以直接连接Slave节点执行读命令。2.客户端路由实现方式：a.手动配置：在客户端代码中，显式指定写操作发送到Master节点，读操作发送到Slave节点。例如，在Java中使用Jedis，可以创建两个连接池，分别指向Master和Slave，然后在业务代码中根据操作类型选择连接。b.代理中间件：使用如Twemproxy、Codis等代理，由代理层自动将读请求路由到Slave节点，写请求路由到Master节点。这样客户端只需连接代理，无需关心后端拓扑。c.支持读写分离的客户端库：一些高级的Redis客户端库（如Lettuce）内置了读写分离功能，通过配置主从节点地址，客户端库会自动路由请求。3.注意事项：-数据一致性：由于主从复制是异步的，Slave节点可能存在数据延迟。对于一致性要求高的场景，可能需要强制从Master读（引用[2]提到可以通过外部监控程序检测延迟，或者使用WAIT命令等待同步）。-负载均衡：如果有多个Slave节点，客户端或代理需要实现负载均衡（如轮询、随机等）来分配读请求。4.示例配置（引用[4]提到复制缓冲区配置，这会影响复制性能和延迟，但和客户端路由无关）：在客户端实现读写分离的伪代码示例：```java//伪代码示例：使用两个连接池JedisPoolmasterPool=newJedisPool("master_ip",6379);JedisPoolslavePool=newJedisPool("slave_ip",6379);//写操作使用mastertry(Jedismaster=masterPool.getResource()){master.set("key","value");}//读操作使用slavetry(Jedisslave=slavePool.getResource()){Stringvalue=slave.get("key");}```或者使用Lettuce（支持读写分离）：```javaRedisClientclient=RedisClient.create();StatefulRedisMasterSlaveConnection<String,String>connection=MasterSlave.connect(client,newUtf8StringCodec(),Arrays.asList(newRedisURI("master_ip",6379,30,TimeUnit.SECONDS),newRedisURI("slave1_ip",6379,30,TimeUnit.SECONDS),newRedisURI("slave2_ip",6379,30,TimeUnit.SECONDS)));connection.setReadFrom(ReadFrom.SLAVE);//设置读策略：优先从Slave读//使用连接时，写操作自动发往Master，读操作发往SlaveRedisCommands<String,String>commands=connection.sync();commands.set("key","value");//写操作发往MasterStringvalue=commands.get("key");//读操作发往Slave（根据策略选择一个）```总结：-Slave节点直接处理读请求，但数据可能不是最新。-客户端路由实现方式包括：手动配置、代理中间件、智能客户端库。-需要根据数据一致性要求和系统复杂度选择合适的方案。相关问题：1.Redis主从复制数据延迟如何监控和解决？2.如何配置RedisSentinel以实现自动故障转移和读写分离？3.RedisCluster模式下如何实现读写分离？</think>### Redis 主从复制模式：Slave 读请求处理与客户端路由实现 #### 一、Slave 节点处理读请求的机制 1. **读写分离架构** - **Master**：**独占写权限**（所有写操作必须发送到 Master） - **Slave**：**只读副本**（接收客户端读请求，数据通过异步复制从 Master 同步）[^1][^5] - **数据一致性**：异步复制导致 Slave 数据可能**延迟**（取决于网络带宽和命令阻塞）[^2] 2. **Slave 读请求处理流程** ```mermaid sequenceDiagram Client->>Slave: 发送读请求 (GET key) Slave-->>Slave: 检查本地数据 alt 数据存在且最新 Slave->>Client: 返回数据 else 数据过期或不存在 Slave->>Master: 请求最新数据 Master->>Slave: 发送增量数据 Slave->>Client: 返回更新后数据 end ``` 3. **关键特性** - **无写权限**：Slave 拒绝所有写命令（返回 `READONLY` 错误） - **复制延迟容忍**：业务需能接受**最终一致性**（如商品展示页） - **负载分担**：多个 Slave 可**水平扩展读吞吐量**（理论上限 10万+/秒）[^3] #### 二、客户端路由实现方式 ##### 方式1：手动配置路由（基础方案） ```java // Java 伪代码示例 JedisPool masterPool = new JedisPool("master_ip", 6379); // 写连接池 JedisPool slavePool = new JedisPool("slave_ip", 6379); // 读连接池 public void handleRequest(String key, String value) { if (isWriteOperation()) { try (Jedis master = masterPool.getResource()) { master.set(key, value); // 写操作路由到Master } } else { try (Jedis slave = slavePool.getResource()) { String result = slave.get(key); // 读操作路由到Slave } } } ``` **缺点**：需业务代码显式区分读写，故障转移需手动干预[^4] ##### 方式2：代理中间件（推荐生产使用） - **常用工具**：Twemproxy、Predixy、AWS ElastiCache Proxy - **路由逻辑**： ```mermaid graph LR Client-->Proxy Proxy-->|Write| Master Proxy-->|Read| Slave1 Proxy-->|Read| Slave2 ``` - **配置示例**（Predixy）： ```yaml # predixy.conf ProxyServer: Bind: 0.0.0.0:6379 ClusterServerPool: Master: 192.168.1.10:6379 # Master节点 Slaves: - 192.168.1.11:6379 # Slave节点1 - 192.168.1.12:6379 # Slave节点2 ReadStrategy: RoundRobin # 读负载均衡策略 ``` ##### 方式3：智能客户端库（现代方案） - **支持库**：Lettuce（Java）、redis-py-cluster（Python）、go-redis（Go） - **Lettuce 示例**： ```java List<RedisURI> nodes = Arrays.asList( RedisURI.create("redis://master:6379"), RedisURI.create("redis://slave1:6379"), RedisURI.create("redis://slave2:6379") ); RedisClient client = RedisClient.create(); StatefulRedisMasterSlaveConnection<String, String> connection = MasterSlave.connect(client, StringCodec.UTF8, nodes); connection.setReadFrom(ReadFrom.SLAVE); // 设置读策略：优先Slave RedisCommands<String, String> commands = connection.sync(); commands.set("key", "value"); // 自动路由到Master String value = commands.get("key"); // 自动路由到Slave ``` **优势**：自动感知拓扑变化，支持读写分离策略配置[^5] #### 三、关键优化策略 1. **降低复制延迟** - 增大复制缓冲区：`repl-backlog-size 256mb`（默认1MB）[^4] - 网络优化：主从节点同机房部署，万兆网络 - 监控延迟：使用 `INFO replication` 查看 `slave_repl_offset` 2. **读负载均衡** ```mermaid pie title 读请求分配策略 “轮询(RoundRobin)” ： 45 “权重(Weighted)” ： 30 “就近路由(Geo)” ： 25 ``` 3. **一致性保障** - **强制读Master**：对一致性要求高的操作，客户端显式指定读Master - **WAIT命令**：`WAIT <numreplicas> <timeout>` 等待N个副本同步（牺牲性能）[^2] #### 四、适用场景与限制 | 场景 | 适用性 | 说明 | |---------------------|--------|--------------------------| | 读密集型应用 | ★★★★★ | 电商商品列表、资讯类网站 | | 写后立即读 | ★★☆☆☆ | 需配合WAIT或强制读Master | | 跨地域部署 | ★★★☆☆ | 需考虑网络延迟 | | 强一致性要求 | ★☆☆☆☆ | 建议改用Redis Cluster | > **最佳实践**： > 1. 读请求占比 >80% 时使用主从复制 > 2. 使用代理或智能客户端减少代码侵入 > 3. 监控 `master_link_down_since_seconds` 和 `lag` 指标
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值