Redis(开发与运维):35---复制之（复制的建立/断开/切换主节点、安全性/只读/传输延迟、复制拓扑）

• 关于复制的设计与实现，还可以参阅：
  • https://blog.csdn.net/qq_41453285/article/details/103332763
  • https://blog.csdn.net/qq_41453285/article/details/103332968
  • https://blog.csdn.net/qq_41453285/article/details/103333183
  • https://blog.csdn.net/qq_41453285/article/details/103333985
  • https://blog.csdn.net/qq_41453285/article/details/103334300
• 在分布式系统中为了解决单点问题，通常会把数据复制多个副本部署到其他机器，满足故障恢复和负载均衡等需求。Redis也是如此，它为我们提供了复制功能，实现了相同数据的多个Redis副本
• 复制功能是高可用Redis 的基础，后面文章介绍的哨兵和集群都是在复制的基础上实现高可用的。复制也是Redis日常运维的常见维护点。因此深刻理解复制的工作原理与使用技巧对我们日常开发运维非常有帮助

一、复制的建立

• 参与复制的Redis实例划分为主节点（master）和从节点（slave）。默认情况下，Redis都是主节点
• 每个从节点只能有一个主节点，而主节点可以同时具有多个从节点
• 复制的数据流是单向的，只能由主节点复制到从节点
• 配置复制的方式有以下三种：
  • ①在配置文件中加入slaveof {masterHost} {masterPort}随Redis启动生效
  • ②在redis-server启动命令后加入--slaveof {masterHost} {masterPort}生效
  • ③直接使用命令：slaveof {masterHost} {masterPort}生效
• slaveof本身是异步命令：执行slaveof命令时，节点只保存主节点信息后返回，后续复制流程在节点内部异步执行（具体见下一篇文章“复制原理”的介绍）

演示案例

• 在本地启动两个redis服务端实例，一个为127.0.0.1:6379，另一个为127.0.0.1:6380。并且各自使用redis-cli去连接

• 现在我们想让127.0.0.1:6380（从节点）去复制127.0.0.1:6379（主节点），那么可以在127.0.0.1:6380端输入下面的命令

slaveof 127.0.0.1 6379

 

• 现在主节点（左侧）新建一个字符串键值对，然后从服务（右侧）也可以查看到该键值对

• 从运行结果中看到复制已经工作了，针对主节点6379的任何修改都可以同步到从节点6380中

info replication命令

• 主从节点复制成功建立后，可以使用info replication命令查看复制相关状态
• 例如，主节点和从节点的状态如下所示：

二、复制的断开

• slaveof命令不但可以建立复制，还可以在从节点执行slaveof no one来断开与主节点复制关系
• 断开复制主要流程：
  • ①断开与主节点复制关系
  • ②从节点晋升为主节点
• 从节点断开复制后并不会抛弃原有数据，只是无法再获取主节点上的数据变化

演示案例

• 接着上面的演示案例，我们让6380断开对6379的复制

slaveof no one

 

• 断开之后，6380的内容依然存在

• 现在对6379进行操作，6380不会受到任何影响了

三、切换复制节点

• 通过slaveof命令还可以实现切主操作，所谓切主是指把当前从节点对主节点的复制切换到另一个主节点
• 在一个已经建立复制的从节点上执行slaveof {newMasterIp} {newMasterPort}命令即可
• 切主操作流程如下：
  • 断开与旧主节点复制关系
  • 与新主节点建立复制关系
  • 删除从节点当前所有数据
  • 对新主节点进行复制操作
• 运维提示：切主后从节点会清空之前所有的数据，线上人工操作时小心slaveof在错误的节点上执行或者指向错误的主节点

演示案例

• 接着上面的演示案例，我们再次建立6380对6379的复制

slaveof 127.0.0.1 6379

 

• 现在我们重新开启一个新redis服务端实例，端口为6381

• 现在我们切换6380所复制的主节点，让其从复制6379变为复制6381

slaveof 127.0.0.1 6381

• 切换之后，6380原先的内容都会消息，内容变为6381服务器内的内容

四、安全性（requirepass参数）

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

五、只读

• 默认情况下，从节点使用slave-read-only=yes配置为只读模式

• 由于复制只能主节点到从节点，对于从节点的任何修改主节点都无法感知，修改从节点会造成主从数据不一致。因此建议线上不要修改从节点的只读模式

六、传输延迟（repl-disable-tcp-nodelay参数）

• 主从节点一般部署在不同机器上，复制时的网络延迟就成为需要考虑的问题
• Redis为我们提供了repl-disable-tcp-nodelay参数用于控制是否关闭TCP_NODELAY。默认关闭

• repl-disable-tcp-nodelay参数说明如下：
  • 当关闭时，主节点产生的命令数据无论大小都会及时地发送给从节点，这样主从之间延迟会变小，但增加了网络带宽的消耗。适用于主从之间的网络环境良好的场景，如同机架或同机房部署
  • 当开启时，主节点会合并较小的TCP数据包从而节省带宽。默认发送时间间隔取决于Linux的内核，一般默认为40毫秒。这种配置节省了带宽但增大主从之间的延迟。适用于主从网络环境复杂或带宽紧张的场景，如跨机房部署
• 运维提示：部署主从节点时需要考虑网络延迟、带宽使用率、防灾级别等因素。如要求低延迟时，建议同机架或同机房部署并关闭repl-disable-tcp-nodelay；如果考虑高容灾性，可以同城跨机房部署并开启repl-disable-tcp-nodelay

七、复制拓扑

• Redis的复制拓扑结构可以支持单层或多层复制关系，根据拓扑复杂性可以分为以下三种：一主一从、一主多从、树状主从结构

一主一从结构

• 一主一从结构是最简单的复制拓扑结构，用于主节点出现宕机时从节点提供故障转移支持（如下图所示，B复制A）

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

一主多从结构

• 一主多从结构（又称为星形拓扑结构）使得应用端可以利用多个从节点实现读写分离（如下图所示，B、C、D、E复制A）

• 应用场景与优点：
  • 对于读占比较大的场景，可以把读命令发送到从节点来分担主节点压力
  • 同时在日常开发中如果需要执行一些比较耗时的读命令，如：keys、sort等，可以在其中一台从节点上执行，防止慢查询对主节点造成阻塞从而影响线上服务的稳定性
• 可能存在的缺陷：对于写并发量较高的场景，多个从节点会导致主节点写命令的多次发送从而过度消耗网络带宽，同时也加 重了主节点的负载影响服务稳定性

树状主从结构

• 树状主从结构（又称为树状拓扑结构）使得从节点不但可以复制主节点数据，同时可以作为其他从节点的主节点继续向下层复制。通过引入复制中 间层，可以有效降低主节点负载和需要传送给从节点的数据量
• 如下图所示：B和C复制A，D和E复制B，数据实现了一层一层的向下复制

• 当主节点需要挂载多个从节点时为了避免对主节点的性能干扰，可以采用树状主从结构降低主节点压力