Redis主从架构、数据同步原理、全量同步、增量同步

文章介绍了Redis主从架构以提高并发能力,详细阐述了数据同步中的全量同步和增量同步原理,包括ReplicationId和offset的角色,并提供了优化主从集群的建议。同时讨论了何时执行全量和增量同步的情况,以及线程并发可能导致的超卖问题。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在这里插入图片描述

大家好,我是哪吒。

专栏导读

2023年再不会Redis,就要被淘汰了

图解Redis,谈谈Redis的持久化,RDB快照与AOF日志

Redis单线程还是多线程?IO多路复用原理

Redis集群的最大槽数为什么是16384个?

Redis缓存穿透、击穿、雪崩到底是个啥?7张图告诉你

Redis分布式锁的实现方式

Redis分布式缓存、秒杀

一、Redis主从架构

单节点Redis的并发能力是有上限的,要进一步提高Redis的并发能力,就需要搭建主从集群,实现读写分离。
在这里插入图片描述

二、数据同步原理

master如何判断slave是不是第一次来同步数据?这里会用到两个很重要的概念:

1、Replication Id:简称replid,是数据集的标记,id一致则说明是同一数据集。每一个master都有唯一的replid,slave则会继承master节点的replid
2、offset:偏移量,随着记录在repl_baklog中的数据增多而逐渐增大。slave完成同步时也会记录当前同步的offset。如果slave的offset小于master的offset,说明slave数据落后于master,需要更新。

因此slave做数据同步,必须向master声明自己的replication id 和offset,master才可以判断到底需要同步哪些数据。

三、全量同步的流程

  1. slave节点请求增量同步;
  2. master节点判断replid,发现不一致,拒绝增量同步;
  3. master将完整内存数据生成RDB,发送RDB到slave;
  4. slave清空本地数据,加载master的RDB;
  5. master将RDB期间的命令记录在repl_baklog,并持续将log中的命令发送给slave;
  6. slave执行接收到的命令,保持与master之间的同步;

三、可以从以下几个方面来优化Redis主从就集群

  1. 在master中配置repl-diskless-sync yes启用无磁盘复制,避免全量同步时的磁盘IO;
  2. Redis单节点上的内存占用不要太大,减少RDB导致的过多磁盘IO;
  3. 适当提高repl_baklog的大小,发现slave宕机时尽快实现故障恢复,尽可能避免全量同步;
  4. 限制一个master上的slave节点数量,如果实在是太多slave,则可以采用主-从-从链式结构,减少master压力

四、全量同步和增量同步区别?

全量同步:master将完整内存数据生成RDB,发送RDB到slave。后续命令则记录在repl_baklog,逐个发送给slave;
增量同步:slave提交自己的offset到master,master获取repl_baklog中从offset之后的命令给slave;

五、什么时候执行全量同步?

slave节点第一次连接master节点时;
slave节点断开时间太久,repl_baklog中的offset已经被覆盖时;

六、什么时候执行增量同步?

slave节点断开又恢复,并且在repl_baklog中能找到offset时。

七、超卖问题

线程交替执行,线程1【查询库存 -> 1】,
在进行库存扣减前,
线程2执行【查询库存 -> 1】,
线程2执行【扣减库存】,产生超卖问题!!!

在这里插入图片描述

在这里插入图片描述

🏆本文收录于,Java基础教程系列

目前已经700+订阅,优快云最强Java专栏,包含全部Java基础知识点、Java8新特性、Java集合、Java多线程、Java代码实例,理论结合实战,实现Java的轻松学习。

🏆哪吒多年工作总结:Java学习路线总结,搬砖工逆袭Java架构师

### Redis 主从复制异步同步机制解释 #### 一、主从复制概述 Redis 的主从复制功能能够显著提升系统的可用性、扩展性和数据冗余性。该特性允许当主节点发生故障时,从节点可接管并持续提供服务;同时支持通过增加从节点来分摊读取请求的压力,优化整体性能表现[^1]。 #### 二、异步同步特点 在Redis主从架构里,默认采用的是**异步复制模式**。这意味着每当客户端向Master(即主库)发起写入指令后,Master会立即将变更应用至本地数据库,并随后将此更新转发给所有的Slave(即从库)。然而,在这个过程中,Master并不会等待确认消息返回就已结束当前事务处理过程[^2]。 这种设计使得即使网络连接不稳定或延迟较高情况下也能保持较高的吞吐率,因为不需要每次操作都阻塞直到所有副本均已完成同步。但是这也意味着如果此时突然遭遇断电或其他意外情况,则可能导致某些未被及时传播的数据丢失风险。 为了应对这种情况下的潜在问题,Redis引入了两种不同的策略来进行更高效的增量恢复: - **全量复制 (SYNC)**:适用于初次建立链接或是遇到严重错误无法继续正常工作的场合。它涉及创建一个新的快照文件(RDB),并通过TCP传输给对方加载。 - **部分重放 (PSYNC)**:作为改进版方案,仅需补发自上次成功通讯以来新增加的内容即可完成修复工作,大大减少了所需时间和带宽消耗[^4]。 ```bash # 配置示例 - 设置为 slave 节点 replicaof master_ip_address port_number ``` 上述配置语句展示了如何在一个 Slave 上指明其 Master 所处的位置以及监听端口号,以便于两者间建立起稳定可靠的通信链路。
评论 9
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

哪 吒

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

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

余额充值