文章目录
1.主从复制的基本概念
基本概念
Redis 的主从复制（Master-Slave Replication）是一种数据复制机制，允许一个 Redis 服务器（主节点）将数据复制到一个或多个 Redis 服务器（从节点）。这种机制可以用于负载均衡和数据备份。
主从复制的作用
Redis 的主从复制机制主要解决了以下几个单点问题：
- 读写分离
问题：在单一的 Redis 实例中，所有的读写请求都必须通过同一个节点，这可能导致性能瓶颈。
解决方案：通过设置多个从节点，主节点负责处理写请求，而从节点可以处理读请求，从而分散负载，提高系统的并发处理能力。
2.高可用性
问题：如果只有一个 Redis 实例，一旦该实例出现故障，整个服务将不可用。
解决方案：主从复制允许数据在多个节点之间复制。如果主节点出现故障，可以通过其他机制（如 Redis Sentinel 或手动切换）将某个从节点提升为新的主节点(这里使用到了"哨兵机制"，从而实现 高可用性。 - 数据备份
问题：单一节点的数据丢失风险较高，例如由于硬件故障或其他意外情况。
解决方案：从节点可以作为主节点数据的备份，定期同步数据，从而在主节点出现故障时，能够快速恢复数据。 - 负载均衡
问题：单个 Redis 实例处理所有请求，可能导致响应时间变慢和系统性能下降。
解决方案：通过增加从节点，可以将读请求分散到多个从节点上，从而提高系统的整体性能和响应速度。 - 数据一致性
问题：在分布式系统中，数据一致性是一个重要问题。
解决方案：虽然主从复制是异步的，但它提供了一种机制来确保数据在多个节点之间的一致性。即使在某些情况下会有短暂的不一致，从节点会在后续同步中更新数据，最终达到一致性。
redis_22">2.在一个服务器上建立一个主从结构的redis集群
建立主从关系
由于设备的限制,我们采用一台服务器上部署多个redis这样的方式来进行主从复制 的学习.配置复制的方式有以下三种:
- 在配置文件中加入
slaveof{masterHost} {masterPort},随redis启动生效 - 在
redis-server启动命令加入--slaveof {masterHost} {masterPort}生效 - 直接使用redis命令
slaveof {masterHost} {masterPost}生效
注意: 这里能够实现永久性的设置的只有修改配置文件这种方法,其他两种该方法都是临时性的修改
这样,我们通过cp复制命令,建立了两个slave配置文件:
这里我们在配置文件的末尾进行主从关系的建立:
== 注意:由于我们使用的是同一个服务器,所以我们的端口不能一样,在配置文件中也需要对端口号进行修改 ,这里设置了两个从节点,分别占用6380和6381==
然后启动两个从节点的redis:redis-server /etc/redis/slave1.conf,redis-server /etc/redis/slave2.conf
通过ps aux | grep redis来观察是否已经正确启动:
我们发现,此时除了我们默认的6379端口号启动了redis-server以外,6380和6381同时也启动了,此时代表在同一个服务器上启动多个redis-server启动成功
接下来我们验证主从结构关系:
- 进入主节点命令行客户端进行redis交互过程:
在 命令行中输入info replication查询主节点的状态信息
- 发现当前的身份
role是master - 当前连接的从节点的数量为
connected_slaves:2 - 当前节点的相关信息:
slave0和slave1
同理,我们可以观察从节点(以6380端口的redis-server为例)中的相关状态信息:
这里的身份role是slove,同时也记录了相关的主节点的信息,说明主从关系建立成功
断开主从关系
slavof命令不但可以建立关系 ,还可以在从节点执行slaveof no one来断开从节点与主节点之间的主从关系,使用6380节点进行举例:
在命令行客户端中输入slaveof no one命令:
出现ok返回值
接下来再来观察一下当前的复制状态:
我们发现此时的role身份从slave转变为master,说明此时的主从关系已经断开
断开复制的主要流程:
- 断开与主节点的复制关系
- 从节点晋升为主节点
- 从节点断开复制之后并不会抛弃原有的数据,只是无法再获取主节点上的数据变化
redis_66">redis中重要配置
安全性
对于数据比较重要的节点,主节点会通过设置requirepass参数来进行密码验证,这时所有的客户端访问必须使用auth命令实行校验.
只读
默认情况下,从节点使用slave-read-only=yes配置为只读模式.由于复制只能从从主节点到从节点,多于从节点的任何修改主节点都无法感知,修改从节点会造成主从数据不一致.所以建议:线上不要修改从节点的只读模式.
传输延迟
主从节点一般来说不会部署在同一个服务器上,那么在复制的过程中就会存在网络延迟的问题.Redis采用tcp进行传输,那么在tcp的传输机制中,nagle算法,用来解决网络带宽问题(开启nagle算法,主节点会合并较小的tcp数据包,会增加tcp传输的延迟,但节省了网络带宽;关闭nagle算法,主节点产生的命令数据无论大小都会及时的发送给从节点,这样主从之间的延迟就会变小,减少了tcp传输延迟,但是提高了网络带宽)
Redis提供了repl-disable-tcp-nodely参数用来控制是否关闭tcp_nodelay,默认为no,即开启nogle功能.
3.主从关系–拓扑结构
一主一从
一主一从结构式最简单的复制拓扑结构,用于主节点出现宕机时从节点提供故障转移支持.当应用写命令并发量较高且需要持久化时,可以只在从节点上开启AOF,这样保证数据安全性的同时,也避免了持久化对主节点性能的干扰.但是需要注意的是,当主节点关闭持久化功能时,如果主节点宕机要避免主节点的自动重启操作,因为如果主节点进行了重启操作,进而就会进行数据的同步,此时从节点中存储的主节点宕机前的数据会被覆盖掉
一主多从
一主多从结构是的应用端可以利用多个从节点实现读写分离,对于一些读比重比较大的场景,可以把读命令负载均衡到不同的从节点上来分担压力.同时一些耗时的读命令可以指定一台专门的从节点来执行,避免破坏整体的稳定性.对于写并发量较高的场景,多个从节点会导致主节点写命令的多次发送从而加重主节点的负载.
树形主从结构
树形主从结构(分层结构)使得从节点不但可以复制主节点的数据,同时可以作为其他从节点的主节点继续向下层复制.通过引入复制中间层,可以有效降低写操作对于主节点的负载压力,当主节点需要挂载多个从节点时为了避免对主节点的性能干扰,可以采用这种拓扑结构.
