Redis主从复制

文章目录

  1. 1. Redis主从复制
    1. 1.1. 作用
    2. 1.2. 搭建前的准备
    3. 1.3. 主从节点关系
    4. 1.4. 查看复制信息 info replication
    5. 1.5. 建立复制
      1. 1.5.1. 动态配置
      2. 1.5.2. 配置文件配置
      3. 1.5.3. 操作
    6. 1.6. 断开复制
    7. 1.7. 切主
      1. 1.7.1. 执行流程
      2. 1.7.2. 提示
    8. 1.8. 安全性
    9. 1.9. 只读
    10. 1.10. 传输延迟
      1. 1.10.1. 提示
    11. 1.11. 一主一从
    12. 1.12. 一主多从
    13. 1.13. 树状主从结构

Redis主从复制

  • 本章介绍Redis的一个强大功能–主从复制。一台master主机可以拥有多台slave从机。而一台slave从机又可以拥有多个slave从机。如此下去,形成强大的多级服务器集群架构(高扩展)。可以避免Redis单点故障,实现容灾恢复效果(高可用)。读写分离的架构,满足读多写少的并发应用场景。

作用

  • 主从复制,读写分离,容灾恢复。一台主机负责写入数据,多台从机负责备份数据。在高并发的场景下,即便是主机挂了,可以用从机代替主机继续工作,避免单点故障导致系统性能问题。读写分离,让读多写少的应用性能更佳。

搭建前的准备

  • 因为服务器有限,因此我们只能在一台服务器上模拟操作,实际工作中都是在不同的机器上
  • cd /etc : 进入etc目录
  • cp redis.conf redis6380.conf : 复制一份redis的配置文件
  • cp redis.conf redis6381.conf : 复制一份redis的配置文件
  • 修改新建的配置文件中的内容,只需要三份配置文件中的前四项不同即可
    • port : 端口号
    • pidfile : pid的文件名
    • logfile : 日志的文件名
    • dbfilename : 修改持久化的文件名称
    • daemonize : 设置为守护线程启动,yes
  • redis-server redis.conf : 启动端口为6379的redis
  • redis-server redis6380.conf : 启动端口为6380的redis
  • redis-server redis6381.conf : 启动端口为6381的redis
  • redis-cli -h 127.0.0.1 -p 6379 : 连接端口为6379的redis
  • redis-cli -h 127.0.0.1 -p 6380 : 连接端口为6380的redis
  • redis-cli -h 127.0.0.1 -p 6381 : 连接端口为6381的redis

主从节点关系

  • 一个主节点可以有多个从节点,但是一个从节点(slaver)只能有一个主节点(master)

查看复制信息 info replication

  • 初始状态没有建立复制的时候,使用info replication,输出以下信息
# Replication
role:master      # 角色,默认是主节点
connected_slaves:0    
master_repl_offset:37617   # 自身复制偏移量
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:17378
  • 建立主从复制之后,从节点复制信息如下
role:slave     # 角色为从节点
master_host:127.0.0.1    # 主节点ip地址
master_port:6381     # 端口
master_link_status:up    # 是否已经连接上 up表示连接上,down表示没有连接
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:37688
slave_priority:100
slave_read_only:1       # 从节点设置只读,不能写
connected_slaves:0
master_repl_offset:0
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:2
repl_backlog_histlen:17378

建立复制

动态配置

  • 直接在redis中敲命令设置主从节点,一旦重启之后会恢复原型
  • slaveof ip port : 建立复制,在哪个redis中执行这条语句,那么哪个redis就作为从节点
    • slaveof 127.0.0.1 6381 : 6381端口开启的redis作为主节点

配置文件配置

  • 我们可以在配置文件中配置,大概在配置文件中的210行左右,有一个# slaveof <masterip> <masterport>,我们可以在这个地方配置slaveof 127.0.0.1 6381
  • 一旦配置完成之后,redis启动将会建立主从复制

操作

  • 建立了主从关系之后,将会自动执行全量复制,即是主节点中的内容将会更新到从节点中
  • 从节点此时只能执行只读命令,比如get key,不能执行set ke偶们y value
  • 主节点的操作会同步更新到从节点中,比如在主节点中执行set name 陈加兵,那么在从节点中就会出现name这个key

断开复制

  • slaveof no one : 断开复制
  • 在从节点中执行slaveof no one,那么将会断开和主节点的关系,此时的从节点将会成为主节点,可以使用info replication查看
  • 断开主从复制关系并不会抛弃原有的数据,只是不会接收主节点的数据变化而已

切主

  • 通过slaveof命令还可以实现切主操作,所谓切主是指把当前从节点对主节点的复制切换到另一个主节点。执行slaveof{newMasterIp}{newMasterPort}命令即可,例如把6380节从原来的复制6379节点变为复制6381节点

执行流程

  1. 断开与旧主节点复制关系。
  2. 与新主节点建立复制关系。
  3. 删除从节点当前所有数据。
  4. 对新主节点进行复制操作。

提示

  • 切主后从节点会清空之前所有的数据,线上人工操作时小心slaveof在错误的节点上执行或者指向错误的主节点。

安全性

  • 对于数据比较重要的节点,主节点会通过设置requirepass参数进行密码验证,这时所有的客户端访问必须使用auth命令实行校验。从节点与主节点的复制连接是通过一个特殊标识的客户端来完成,因此需要配置从节点的masterauth参数与主节点密码保持一致,这样从节点才可以正确地连接到主节点并发起复制流程。

只读

  • 默认情况下,从节点使用slave-read-only=yes配置为只读模式。由于复制只能从主节点到从节点,对于从节点的任何修改主节点都无法感知,修改从节点会造成主从数据不一致。因此建议线上不要修改从节点的只读模式。

传输延迟

  • 主从节点一般部署在不同机器上,复制时的网络延迟就成为需要考虑的问题,Redis为我们提供了repl-disable-tcp-nodelay参数用于控制是否关闭TCP_NODELAY,默认关闭,说明如下:
    • 当关闭时,主节点产生的命令数据无论大小都会及时地发送给从节点,这样主从之间延迟会变小,但增加了网络带宽的消耗。适用于主从之间的网络环境良好的场景,如同机架或同机房部署。
    • 当开启时,主节点会合并较小的TCP数据包从而节省带宽。默认发送时间间隔取决于Linux的内核,一般默认为40毫秒。这种配置节省了带宽但增大主从之间的延迟。适用于主从网络环境复杂或带宽紧张的场景,如跨机房部署。

提示

  • 部署主从节点时需要考虑网络延迟、带宽使用率、防灾级别等因素,如要求低延迟时,建议同机架或同机房部署并关闭repl-disable-tcp-nodelay;如果考虑高容灾性,可以同城跨机房部署并开启repl-disable-tcp-nodelay

一主一从

  • 一主一从结构是最简单的复制拓扑结构,用于主节点出现宕机时从节点提供故障转移支持。当应用写命令并发量较高且需要持久化时,可以只在从节点上开启AOF,这样既保证数据安全性同时也避免了持久化对主节点的性能干扰。但需要注意的是,当主节点关闭持久化功能时,如果主节点脱机要避免自动重启操作。因为主节点之前没有开启持久化功能自动重启后数据集为空,这时从节点如果继续复制主节点会导致从节点数据也被清空的情况,丧失了持久化的意义。安全的做法是在从节点上执行slaveof no one断开与主节点的复制关系,再重启主节点从而避免这一问题。

一主多从

  • 一主多从结构(又称为星形拓扑结构)使得应用端可以利用多个从节点实现读写分离。对于读占比较大的场景,可以把读命令发送到从节点来分担主节点压力。同时在日常开发中如果需要执行一些比较耗时的读命令,如:keys、sort等,可以在其中一台从节点上执行,防止慢查询对主节点造成阻塞从而影响线上服务的稳定性。对于写并发量较高的场景,多个从节点会导致主节点写命令的多次发送从而过度消耗网络带宽,同时也加 重了主节点的负载影响服务稳定性。

树状主从结构

  • 树状主从结构(又称为树状拓扑结构)使得从节点不但可以复制主节点数据,同时可以作为其他从节点的主节点继续向下层复制。通过引入复制中间层,可以有效降低主节点负载和需要传送给从节点的数据量。数据写入节点A后会同步到B和C节点,B节点再把数据同步到D和E节点,数据实现了一层一层的向下复制。当主节点需要挂载多个从节点时为了避免对主节点的性能干扰,可以采用树状主从结构降低主节点压力。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • Zookeeper入门

    爱撒谎的男孩
  • Zookeeper实现分布式锁

    爱撒谎的男孩
  • 二叉树

    爱撒谎的男孩
  • ignite TCP发现原理

    节点顺序 - 每个节点的内部属性(对于TcpDiscoverySpi,它只是一个统一增加的数字)。

    lilihongjava
  • 《Redis设计与实现》读书笔记(二十八) ——Redis集群节点结构与槽分配

    《Redis设计与实现》读书笔记(二十八) ——Redis集群节点结构与槽分配 (原创内容,转载请注明来源,谢谢) 一、概述 redis集群是...

    用户1327360
  • 数据结构:树与二叉树

    一颗高度为h,并含有2^h-1个节点的二叉树称为满二叉树,即树中的每一层都含有最多的节点。

    HLee
  • 《Redis设计与实现》读书笔记(三十) ——Redis集群节点复制与故障转移

    《Redis设计与实现》读书笔记(三十) ——Redis集群节点复制与故障转移 (原创内容,转载请注明来源,谢谢) 1、概述 redis集群的...

    用户1327360
  • 红黑树算法

    前情提要 红黑树是AVL树里最流行的变种,有些资料甚至说自从红黑树出来以后,AVL树就被放到博物馆里了。红黑树是否真的有那么优秀,我们一看究竟。红黑树遵循以下...

    机器学习算法工程师
  • 多叉树 & B树 & B+树 & B*树

    二叉树虽然操作效率比较高,但是如果数据一多,就会有好多好多的节点,需要进行好多次的I/O操作,构建出来的二叉树就会很高很高,也会降低操作速度。

    贪挽懒月
  • 像管理 Pod 一样管理 Node | TKE 节点池全面上线

    晏子怡,腾讯云产品经理,目前负责TKE集群、网络及调度模块。 从 K8s 的声明式设计理念谈起 Pod 模板 K8s 最优雅精妙的一个设计理念在于声明式  A...

    腾讯云原生

扫码关注云+社区

领取腾讯云代金券