(进阶篇)Redis6.2.0 集群 主从复制_原理剖析_02

文章目录

          • 一、主从复制流程
            • 1. 主从复制流程图
            • 2. 主从复制日志
          • 二、主从复制信息剖析
            • 2.1. 主节点信息剖析
            • 2.2. 从节点信息剖析
          • 三、关键术语
            • 3.1. 复制功能开启
            • 3.2. 全量复制场景
            • 3.3. 主从复制异步性
            • 3.4. 过期key的处理
            • 3.5. 加速复制

一、主从复制流程
1. 主从复制流程图

在这里插入图片描述
第一条线(全量同步):
①slave从节点发送FULL SYNC全量同步请求命令
②master执行bgsave
③将内存中数据通过copy-on-write方式 写入到磁盘
④将磁盘的数据生成rdb快照
⑤master把rdb快照文件发送给slave从节点
⑥从节点丢弃旧的数据,接收新的rdb快照文件
⑦加载rdb文件
⑧slave复制完成

第二条线(增量同步):
①slave从节点发送FULL SYNC全量同步请求命令
②master执行bgsave
③主节点会往从节点连接缓冲区写一份数据,同时往repl_backlog也写一份数据,所有从节点共享同一份repl_backlog
④slave节点接收缓存区的命令
⑤增量数据同步/复制完成

2. 主从复制日志

master复制日志查看

* Ready to accept connections # 准备就绪等待链接
* Replica 1xxx.xxx.xxx.101:6379 asks for synchronization# 102节点向主节点发起了一个全量resync 的请求
* Full resync requested by replica 1xxx.xxx.xxx.101:6379# 主节点创建缓冲区,
* Replication backlog created, my new replication IDs are 'b1f446c9ea7c0d5e95c8c47f31b000000000000000000000000000'# 通过BGSAVE 将数据写入磁盘,生成rdb快照,发给子节点
* Starting BGSAVE for SYNC with target: disk
* Background saving started by pid 11978
* DB saved on disk# 通过copy-on-write的方式将4m数据写入磁盘
* RDB: 6 MB of memory used by copy-on-write
* Background saving terminated with success# 101 节点的复制结束了 子节点加载rdb快照文件读取数据
* Synchronization with replica 1xxx.xxx.xxx.101:6379 succeeded
* Replica 1xxx.xxx.xxx.102:6379 asks for synchronization
* Full resync requested by replica 1xxx.xxx.xxx.102:6379
* Starting BGSAVE for SYNC with target: disk
* Background saving started by pid 11979
* DB saved on disk
* RDB: 4 MB of memory used by copy-on-write
* Background saving terminated with success
* Synchronization with replica 1xxx.xxx.xxx.102:6379 succeeded
# Disconnecting timedout replica: 1xxx.xxx.xxx.101:6379
# Connection with replica 1xxx.xxx.xxx.101:6379 lost.
# Disconnecting timedout replica: 1xxx.xxx.xxx.102:6379
二、主从复制信息剖析

通过什么可以查看主从节点信息呢?
info replcatipon

2.1. 主节点信息剖析
[root@bigdata01 bin]# /usr/local/redis/bin/redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> info replication
# Replication
role:master # 角色主节点
connected_slaves:2 #它所连接到的从节点的数量
# 从节点ip地址、 端口、状态:在线 当前从节点读取命令的偏移量 延迟时间:单位:秒
#offset指的是从节点已经复制的命令偏移量是266
# 这里的offset=master_repl_offset说明主从偏移量是一致的
slave0:ip=1xxx.xxx.xxx.101,port=6379,state=online,offset=266,lag=1 #当前连接从01 slave节点信息
slave1:ip=1xxx.xxx.xxx.102,port=6379,state=online,offset=266,lag=1 #当前连接从02 slave节点信息
master_failover_state:no-failover
# 主从的id
master_replid:b1f446c9ea7c0d5e95c8c47f31bb007cea158ce8
# 主从发生变化之后id
master_replid2:0000000000000000000000000000000000000000
# 主节点会把所有的命令转换成子字节。写到队里额里面,最终写入的值就是master_repl_offset
# 主节点已写入的命令偏移量是266
master_repl_offset:266
# 判断是否全量复制的标识
second_repl_offset:-1# 2.8之后 缓冲区
repl_backlog_active:1 # 是否开启缓冲区 1-开启 0-关闭
repl_backlog_size:1048576 # 缓冲区大小 1m,可以调控
repl_backlog_first_byte_offset:1 # 从偏移量为1开始写入
repl_backlog_histlen:266 # 当前缓存冲区长度
127.0.0.1:6379> 
2.2. 从节点信息剖析
[root@bigdata02 ~]# /usr/local/redis/bin/redis-cli -a 123456
Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> info replication
# Replication# 角色
role:slave
# 主节点ip
master_host:1xxx.xxx.xxx.100
# 主节点端口
master_port:6379
# 主节点当前状态
master_link_status:up
# 主从复制最后一次 4秒之前
master_last_io_seconds_ago:4
# 现在主从同步状态 0-未同步 1-正在同步
master_sync_in_progress:0
# 从节点复制的偏移量
slave_repl_offset:3xxx
# 从节点在选举时,成为主节点的权重优先级,这个参数越大,晋升主节点的优先级越高
slave_priority:100
# 从节点只读模式是否开启 1-开启 0-未开启
slave_read_only:1
# 从节点连接从节点数量
connected_slaves:0
master_failover_state:no-failover
# 连接主节点的id
#当前主节点宕机后master_replid会变成一个信心的,master_replid2存储老的主节点master_replid
master_replid:b1f446c9ea7c0d5e95c8c47f31bb007cea158ce8
master_replid2:0000000000000000000000000000000000000000
# 主节点写入的偏移量
master_repl_offset:3xxx
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:3xxx
127.0.0.1:6379> 
三、关键术语
3.1. 复制功能开启

通过什么配置项开启主从之间的复制功能呢?
slaveof
在从节点的配置中添加slaveof,从节点就会识别主节点是谁?跟主节点建立连接,然后开始同步数据。
同步数据就是主从复制。复制的又分为全量复制和增量复制2种概念。

3.2. 全量复制场景

全量复制:从节点把主节点的数据全量复制过来
发生的场景:
1.初始化环境(刚搭建完主从复制集群,初始化主节点数据,从节点全量复制)
2.新增从节点,需要把主节点数据全量复制过来,才能对外提供读服务
3.在redis2.8之前,主节点故障(run_id发生变化),重新选举主节点,从节点为了保证安全性和一致性就会全量复制。
假设如果数据没问题,进行一次全量复制就是多余的。
在2.8之后,多了一个second_repl_offset为了避免主从节点发生变化或者故障转移都要全量复制。就会把主节点的偏移量记录下来,当重新选择举主节点后,就会先判断偏移量,根据偏移量做增复制。
例如:
从节点偏移量2590
主节点偏移量2591
主从节点偏移量相差1
就会只同步1偏移量而不会全量复制了

增量复制:

  • 增量复制是Slave初始化后开始正常工作时,主服务器发生的写操作同步到从服务器的过程。
  • 复制过程是主服务器每执行一个写命令就会向从服务器发送相同的写命令,从服务器接收并执行收到的写命令。
3.3. 主从复制异步性
  • 主从复制对于主从redis服务器是非阻塞的,当从服务器在进行主从复制过程中,主redis仍然可以处理外界的访问请求。
  • 主从复制对于从redis服务器是非阻塞,从redis在进行主从复制过程中也可以接收外界的查询请求,只不过这时候从redis返回以前的数据。

主从复制过程,主节点是非阻塞的,复制的流程中,主节点开启了一个后台子守护进程去做主从复制的,比如,bgsave、生成rdb快照、发送等等。同时,当前服务器的主节点仍然可以对外提供读写服务,这时他的异步性。
从节点也是一样,比如,从节点正在复制主节点的数据,这个sync同步也是异步的,复制的过程中就会有问题。
什么问题呢?
比如,正在复制,这时一个查询请求发过来,就会查询的是老数据,这里面就会有脏读、数据不一致的问题。

3.4. 过期key的处理

Slave不睡让key过期,而是等待Master让KEY过期。当Master让KEY过期是,它会合成一个DEL命令并传输到所欲的SLave节点。

3.5. 加速复制

默认情况下,master节点接收SYNC命令后,执行BGSAVE操作,将数据先保存到磁盘,如果磁盘性能差,那么写入磁盘会消耗大量的性能,因此,在redis2.8.18时进行改进,可以设置无需写入磁盘的直接发送RDB快照给slave,加快复制速度。

修改配置:repl_diskless-sync yes (默认no)

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/517829.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

如何抢占云栖大会C位?史上最强强强攻略来了

如何抢占云栖大会C位?史上最强强强攻略来了 原文链接 本文为云栖社区原创内容,未经允许不得转载。

寻找榜样的力量!CSDN【百万人学 AI】评选活动重磅启动

AI 业界历经算法更迭、技术方案升级,有企业攻城略池,占据更多行业山头,有企业中途折戟沉沙。AI 发展浮浮沉沉,但每一年我们都希望审视当下,一窥未来。2020 无疑是特殊的一年,而 AI 在开年的这场”战疫“中表…

重构:改善饿了么交易系统的设计思路

我在2017年5月加入饿了么的交易部门,先后负责搜索、订单、超时、赔付、条约、交付、金额计算以及评价等系统,后期开始做些整体系统升级的工作。 这篇文章成型于交易系统重构一期之后,主要是反思其过程中做决策的思路,我没有使用「…

(进阶篇)Redis6.2.0 集群 主从复制_故障解决_03

文章目录一、 主从数据一致性1. 主多从少2. 主少从多3. 知识点补充二、 数据延迟2.1. 数据延迟因素2.2. 解决方案三、 脏数据3.1. 脏数据产生的场景3.2. 解决方案四、 数据安全性4.1. 场景4.2. 解决方案五、 规避全量复制5.1. 低峰时段5.2. 主节点变更5.3. 增大复制缓冲区六、 …

以“基”取胜:青立方超融合易捷版,助力企业“极简”上云

2020年春天,以云计算、5G、人工智能为代表的“新基建”蔚然成风,不仅助力中国产业智能化、信息化进入加速推进的快车道,促使全产业链迈开高质量发展的新步伐。更是面向长远,构筑数字经济创新发展之基。可以说,没有任何…

从零开始入门 K8s| K8s 的应用编排与管理

一、资源元信息 1. Kubernetes 资源对象 我们知道,Kubernetes 的资源对象组成:主要包括了 Spec、Status 两部分。其中 Spec 部分用来描述期望的状态,Status 部分用来描述观测到的状态。 今天我们将为大家介绍 K8s 的另外一个部分&#xff0c…

创建对象内存分析

创建对象内存分析 package com.oop.demo03;public class Pet {public String name;public int age;public void shout(){System.out.println("叫了一声");}}/* //一个项目应该这存在一个main方法 public class Application {public static void main(String[] args) …

AliOS Things 维测典型案例分析 —— 内存泄漏

维测典型案例分析1 —— 内存泄漏 在系统运行的过程中,内存泄漏是较为常见但是很难复现的现象,一般的内存泄漏点都是比较隐蔽的,每次几十个字节的泄漏,往往需要压测很久才能复现问题。本节案例分析,我们从一个已经压测…

(进阶篇)Redis6.2.0 集群 哨兵模式_搭建_01

文章目录一、概念架构简述1. Redis Sentinel简述2. Redis Sentinel优点3. Redis Sentinel缺点二、redis 3节点2.1. 101节点配置2.2. 102节点配置2.3. 103节点配置三、哨兵搭建实现3.1. 101节点配置3.2. 102节点配置3.3. 103节点配置3.4. 启动哨兵3.5. sentinel 监控3.6. 哨兵验…

服务器软件大扫盲!

来源 | 沉默王二责编 | Carol头图 | CSDN下载自视觉中国先说一句哈,自从在 B 站开始刷视频后,我就觉得要学的内容实在是太多了。这篇“服务器软件大扫盲”就是我看了羊哥的一期视频后有感而发的,比如说 Web 服务器、HTTP 服务器、应用服务器这…

Flutter浪潮下的音视频研发探索

导读:本文来自 LiveVideoStack 线上分享第三季,第十期阿里巴巴闲鱼事业部无线开发专家陈炉军带来的分享内容,针对闲鱼APP在当下流行的跨平台框架Flutter的大规模实践,介绍其在音视频领域碰到的一些困难以及解决方案。 大家好&…

(进阶篇)Redis6.2.0 集群 哨兵模式_哨兵工作原理_02

文章目录1. 主从复制哨兵架构图2. 定时任务3. 主观下线4. 客观下线5. 仲裁6. 哨兵工作原理1. 主从复制哨兵架构图 2. 定时任务 Sentinel内部有3个定时任务分别是: 每1秒每个Sentinel对其他Sentienl和Redis节点执行 PING 操作(监控)每2秒每个Sentinel通过Master节点…

10年+,阿里沉淀出怎样的搜索引擎?

阿里妹导读:搜索引擎是阿里的10年沉淀,具有很高的技术/业务/商业价值。1688很多场景都借助了搜索中台的能力,基于此,以1688主搜为例介绍搜索全链路知识点,希望对你有所借鉴,有所启发。 一、整体架构 搜索…

年薪15W的程序员因为掌握这个技能,薪资翻倍!

在这个IT系统动辄就是上亿流量的时代,java作为大数据时代应用最广泛的语言,诞生了一批又一批的技术。一些独角兽公司以及腾讯、阿里、百度、网易等知名大厂对java人才的需求量连年升级,优秀程序员能轻松达到30w的水平,但写此同时&…

语雀携手Teambition,玩转项目协作与知识管理

在数字化转型的大浪潮中,大量企业都有项目协作与知识管理诉求。Teambition 是一款优秀的项目协作产品,深受众多企业的青睐。语雀则是来自阿里巴巴的一款新品,是知识管理领域里冉冉升起的新星。今年夏天,语雀携手Teambition&#x…

支付宝小程序“开闸放粮”,亿级流量扶持中小商家!

街边小店也有机会登上支付宝首页推荐位了! 9月17日消息,在支付宝开放日活动中,支付宝宣布向小程序商家开放包括主搜热搜榜、首页腰封、首页惠支付频道、首页生活服务频道、花呗频道、会员频道等六大中心化入口,商家通过引导用户扫…

idea 编译Java heap space 内存溢出

解决方案 根据自身的实际情况设置参数大小,我调整到4096就好使了

避坑!使用 Kubernetes 最易犯的 10 个错误

Kubernetes 作为大规模企业级应用容器编排的首推工具,其为容器化的应用提供部署运行、资源调度、服务发现和动态伸缩等一系列完整功能,本文作者 Marek Bartik 深入分享了 K8s 的避坑宝典,相信会对开发者们大有裨益。作者 | Marek Bartik&…

当 K8s 集群达到万级规模,阿里巴巴如何解决系统各组件性能问题?

本文主要介绍阿里巴巴在大规模生产环境中落地 Kubernetes 的过程中,在集群规模上遇到的典型问题以及对应的解决方案,内容包含对 etcd、kube-apiserver、kube-controller 的若干性能及稳定性增强,这些关键的增强是阿里巴巴内部上万节点的 Kube…

来了!云栖大会都能看到什么?

盼望着 盼望着 一年一度科技盛宴2019杭州云栖大会 来了! 欢迎你 来自远方的开发者们 今天小云为你偷偷潜入会场 带来一大波“谍照” 一起看云栖 在这儿,感受科技带来的巨大惊喜 平头哥放大招! 人工智能整体性突破! 更有三位男神…