redis基础五(主从复制&哨兵模式)

最新推荐文章于 2024-11-13 16:06:44 发布

11爱学习的程序员11

最新推荐文章于 2024-11-13 16:06:44 发布

阅读量206

点赞数

分类专栏： redis 文章标签： redis

本文链接：https://blog.youkuaiyun.com/zhang1314fudao/article/details/103544055

版权

redis 专栏收录该内容

8 篇文章

订阅专栏

本文详细介绍了Redis的主从复制机制，包括复制原理、角色查看、配置及优缺点。此外，还探讨了哨兵模式，阐述了哨兵配置、启动以及其在故障转移中的作用和优缺点。主从复制适用于读写分离，但存在数据丢失风险和手动故障恢复等问题。哨兵模式则提供了自动监控和故障恢复，提高了系统的可用性和健壮性。

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

1、主从复制

Master/Slave 机制：master机器负责“写”，Salve机器负责备份和读，也就是常说的读写分离。

1.1 原理

复制原理：Slave启动成功连接到Master后会发送一个sync命令，Master接到命令启动后台的存盘进程，同时手机所有接受到的用于修改数据集命令。在后台进程执行完毕之后，Master将传送整个数据文件到slave，以完成一次完全同步。

全量复制：slave服务在接受到数据库文件数据后，将其存盘并加载到内存中；

增量复制：master继续将新的所有收集到的修改命令依次传给slave，完成同步；

但是只要重新连接master，一次完全同步(全量复制)将被自动执行。

1.2 查看redis服务的角色

默认情况下每个redis服务都是master的角色，可以登录客户端输入：

Info replication 查看该redis服务的角色。

1.3 master到slave 角色

方法一、手动输入命令

1)、启动redis服务；

2)、启动客户端；

3)、在客户端输入： slaveof masterIp masterPort

缺点：redis服务再次重启后，不在作为salve角色，而是采用默认的master角色；

方法二、修改配置文件

Redis再次重启后还是salve角色。

1:master 服务器的ip和端口；

2： master服务器如果有密码的话，这里输入它的密码；

1.4 一主多备

举例说明啊，1个主机 A ，2个slave机器 B和C；

Master服务器是redis启动默认的，我们要把redis的服务B和C变为Slave角色，可通过上面介绍的命令或配置文件模式实现。

说明：

主机Master是可以写的，而从机Slave是不允许进行写操作的；
从机slave也可以继续作为其他机器的mater，也就是说，A是master，B的master是A，C的master可以是B，但是B还是Slave角色，不能写数据；
当主机master挂了的时候，从机slave和slave默认还是不会变为master的，master A重启后自动变为slave B和C的master；
就是slave挂了，如果是通过命令使一个服务变为slave，那么重启服务后这个redis服务将不在是slave，而是默认的master；如果是通过修改配置文件的话，那么重启redis服务后还是slave的角色；

1.5 主从模式的优缺点

优点：

1、同一个Master可以同步多个Slaves。

2、Slave同样可以接受其它Slaves的连接和同步请求，这样可以有效的分载Master的同步压力。因此我们可以将Redis的Replication架构视为图结构。

3、Master Server是以非阻塞的方式为Slaves提供服务。所以在Master-Slave同步期间，客户端仍然可以提交查询或修改请求。

4、Slave Server同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis则返回同步之前的数据为了分载Master的读操作压力，Slave服务器可以为客户端提供只读操作的服务，写服务仍然必须由Master来完成。即便如此，系统的伸缩性还是得到了很大的提高。

5、Master可以将数据保存操作交给Slaves完成，从而避免了在Master中要有独立的进程来完成此操作。

6、支持主从复制，主机会自动将数据同步到从机，可以进行读写分离。

缺点：

1、Redis不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的IP才能恢复。

2、主机宕机，宕机前有部分数据未能及时同步到从机，切换IP后还会引入数据不一致的问题，降低了系统的可用性。

3、Redis的主从复制采用全量复制，复制过程中主机会fork出一个子进程对内存做一份快照，并将子进程的内存快照保存为文件发送给从机，这一过程需要确保主机有足够多的空余内存。若快照文件较大，对集群的服务能力会产生较大的影响，而且复制过程是在从机新加入集群或者从机和主机网络断开重连时都会进行，也就是网络波动都会造成主机和从机间的一次全量的数据复制，这对实际的系统运营造成了不小的麻烦。

4、Redis较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。为避免这一问题，运维人员在系统上线时必须确保有足够的空间，这对资源造成了很大的浪费。

其实redis的主从模式很简单，在实际的生产环境中是很少使用的，我也不建议在实际的生产环境中使用主从模式来提供系统的高可用性，之所以不建议使用都是由它的缺点造成的，在数据量非常大的情况，或者对系统的高可用性要求很高的情况下，主从模式也是不稳定的。