目录
一、类型
一、RDB模式
默认持久化
dump.rdb 数据库启动时读取
触发条件当redis进程退出会宕机/redis程序崩溃
二、AOF模式
默认关闭
appendonly.aof 默认进程启动时读取
开启
appendonly yes
可以与RDB同时使用
二、配置文件及操作
仍然在 vim /etc/redis.conf中
save存储机制的描述
15分钟内改变一条
5分钟内改变了十条
1分钟内改变了一万条
会存储

当出现错误时停止书写

是否允许压缩

存储数据时放入哪个文件中

存储路径

查看

登录

查看是空的

创建并保存

开启个新的终端查看

vim进入

一、 以上就是RDB的模式(把数据值存下来,默认打开)
二、AOF
默认是关闭的

把它打开

三种数据同步模式
追加同步采用always
每秒同步一次
不同步

没有同步成功时是否进行重新
![]()
更改配置文件重新启动服务

切换 输入命令监视
tail - f appendonly.aof 是监视文件

现在里面没东西为空


回到新建终端验证
意思是select是0 set是lisi 值是123.com

* 代表两个*之间有多少个$
$后面的数字代表 下方有多少个字符
当创建lisi1的时候,在验证发现只有lisi从4变成了5

退出重启服务并验证

开启appendonly.aof 时则不读取dump.rdb
当这么创建

则这一行的空白行

加完内容在删除 可以删除
三、Redis 主从复制
一、概念
是指将一台Redis服务器的数据,复制到其他的Redis服务器。前者称为主节点(Master),后者称为从节点(Slave);数据的复制是单向的,只能由主节点到从节点。
二、作用
数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
高可用:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。
三、缺点
故障恢复无法自动化;
写操作无法负载均衡;
存储能力受到单机的限制。
四、流程
第一步:若启动一个Slave机器进程,则它会向Master机器发送一个“sync command”命令,请求同步连接。
第二步:无论是第一次连接还是重新连接,Master机器都会启动一个后台进程,将数据快照保存到数据文件中(执行rdb操作),同时Master还会记录修改数据的所有命令并缓存在数据文件中。
第三步:后台进程完成缓存操作之后,Maste机器就会向Slave机器发送数据文件,Slave端机器将数据文件保存到硬盘上,然后将其加载到内存中,接着Master机器就会将修改数据的所有操作一并发送给Slave端机器。若Slave出现故障导致宕机,则恢复正常后会自动重新连接。
第四步:Master机器收到Slave端机器的连接后,将其完整的数据文件发送给Slave端机器,如果Mater同时收到多个Slave发来的同步请求,则Master会在后台启动一个进程以保存数据文件,然后将其发送给所有的Slave端机器,确保所有的Slave端机器都正常。
五、主从服务搭建

进入配置文件、按内容整改

改完6379在改6380号
![]()
改完后重启
主配置完成

这是作为谁的从

查看监听端口
杀掉进程
重新监听端口显示为空则成功杀掉进程
Redis服务器将使用路径为/opt/redis_6380.conf的配置文件进行启动。这将启动Redis服务器,并根据该配置文件的设置进行操作。
再次验证

主从配置完成
六、哨兵模式
一、概念
是一个分布式系统,用于对主从结构中的每台服务器进行监控,当出现故障时通过投票机制选择新的 Master 并将所有 Slave 连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。
依托于主从模式
二、作用
监控:哨兵会不断地检查主节点和从节点是否运作正常。
自动故障转移:当主节点不能正常工作时,哨兵会开始自动故障转移操作,它会将失效主节点的其中一个从节点升级为新的主节点,并让其他从节点改为复制新的主节点。
通知(提醒):哨兵可以将故障转移的结果发送给客户端。
三、缺点
写操作无法负载均衡
存储能力受到单机的限制
哨兵无法对从节点进行自动故障转移,在读写分离场景下,从节点故障会导致读服务不可用,需要对从节点做额外的监控、切换操作。
四、搭建
搭建更改的配置

七、验证
停止master后,slave会通过选举产生新的master
哨兵配置文件会自动修改监听的master节点地址为新的master节点地址
八、搭建并验证的模拟操作实验
一、查看配置文件

监听端口前方多个2

将此处改为主机ip

"sentinel monitor mymaster 192.168.115.4 6379 2" 是一个 Redis Sentinel 命令的示例。
这条命令的意思是,告诉 Redis Sentinel 监控名为 "mymaster" 的 Redis 主服务器,该主服务器的 IP 地址是 "192.168.115.4",端口号是 "6379"。数字 "2" 指定了至少 2 个 Sentinel 实例需要同意认为该主服务器不可用时才能执行故障转移操作。
Redis Sentinel 是一个用于监控和自动故障转移 Redis 主从服务器的系统。该命令用于向 Sentinel 添加一个监控主服务器的配置。一旦主服务器不可用,Sentinel 会触发故障转移并选举新的主服务器。
二、查看并复制,有几个从 要复制几个

三、进入配置文件

将此处内容改为对应的端口号

哨兵配置文件中添加一行内容 (放入后台启动)

进入主配置文件和哨兵配置文件注释掉密码(也可以不设置密码,但是在生产环境下是存在密码的)


四、修改后在启动

输入 netstat -anptu | grep redis 查看监听端口是否成功启动

五、杀掉所有的进程


查看

六、启动所有的进程

七、启动后测试主从复制,查看是否正常(开启第二个终端页面)

验证主从没有问题
八、启动哨兵,查看状态

九、进入第三个终端 查看日志


再次启动6380和6381的哨兵
端口号已成功启用
再次查看日志 cat sentinel.log

显示结果翻译

十、杀掉6379的进程
![]()
Kill 80381

十一、再次验证是否成功
cat sentinel.log

结果的含义为
哨兵验证成功
129

被折叠的 条评论
为什么被折叠?



