欢迎各位彦祖与热巴畅游本人专栏与博客
你的三连是我最大的动力
以下图片仅代表专栏特色 [点击箭头指向的专栏名即可闪现]
专栏跑道一
➡️网络空间安全——全栈前沿技术持续深入学习
专栏跑道二
➡️ 24 Network Security -LJS
专栏跑道三
➡️ MYSQL REDIS Advance operation
专栏跑道四
➡️HCIP;H3C-SE;CCIP——LJS[华为、华三、思科高级网络]
专栏跑道五
➡️RHCE-LJS[Linux高端骚操作实战篇]
专栏跑道六
➡️数据结构与算法[考研+实际工作应用+C程序设计]
专栏跑道七
➡️RHCSA-LJS[Linux初级及进阶骚技能]
上节回顾
Redis数据库之Redis 如何高级应用
1.密码防护
- 给 redis 服务器设置密码
- 可以通过 redis 的配置文件设置密码参数,这样客户端连接到 redis 服务就需要密码验证,这样可以让 你的 redis 服务更安全。
S1:查看是否设置了密码验证
127.0.0.1:6379> CONFIG GET requirepass 1) "requirepass" 2) ""
S2:通过以下命令来修改该参数
127.0.0.1:6379> CONFIG SET requirepass "123" OK 127.0.0.1:6379> CONFIG GET requirepass (error) NOAUTH Authentication required.
S3:必须设置密码验证才能进行其他操作:
127.0.0.1:6379> AUTH 123 OK 127.0.0.1:6379> CONFIG GET requirepass 1) "requirepass" 2) "123"
S4:注意:命令设置仅在当前有效,重启服务后失效
127.0.0.1:6379> quit [root@localhost ~]# systemctl restart redis [root@localhost ~]# redis-cli 127.0.0.1:6379> CONFIG GET requirepass 1) "requirepass" 2) ""
S5:如果要永久生效,需要修改配置文件并重启服务
vim /etc/redis.conf requirepass 123456 [root@localhost ~]# systemctl restart redis
1-end——客户端登录
[root@localhost ~]# redis-cli -a 123456 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 127.0.0.1:6379> CONFIG GET requirepass 1) "requirepass" 2) "123456"
也可以交互模式下使用【auth 密码】 命令
[root@localhost ~]# redis-cli 127.0.0.1:6379> AUTH 123456 OK 127.0.0.1:6379> CONFIG GET requirepass 1) "requirepass" 2) "123456" 127.0.0.1:6379> quit
2.数据持久化
2.1简介
- redis为了本身数据的完整和安全性,redis需要经常将内存中的数据同步到磁盘,这个过程称之为 持久化操作。
- 下次再次启动redis服务时,会把磁盘上面保存的数据重新加载到内存里面。
2.2常见的持久化方式
a、基于快照的方式:redis安装一定的周期把内存里面的数据同步到磁盘文件里面 b、基于文件追加:redis会把对redis数据造成更改的命令记录到日志文件里面,然后再一次重启,执 行日志文件里面对redis写的操作,达到数据还原。
2.3基于快照的持久化——以下是系统默认配置
修改配置文件,开启基于快照的选项 save 900 1 #900秒内如果超过1个key被修改,则发起快照保存 save 300 10 #300秒内容如超过10个key被修改,则发起快照保存 save 60 10000 #60秒内容如超过10000个key被修改,则发起快照保存
2.4保持到磁盘上的文件
[root@localhost ~]# egrep "^(dbfilename|dir)" /etc/redis.conf dbfilename dump.rdb # 保持文件名称 dir /var/lib/redis # 保持的路径 [root@localhost ~]# cd /var/lib/redis/ [root@localhost redis]# ls dump.rdb
2.5模拟删除文件,手工保存,重启后查看
[root@localhost redis]# systemctl stop redis [root@localhost redis]# rm -f dump.rdb [root@localhost redis]# systemctl start redis [root@localhost redis]# ls [root@localhost redis]# redis-cli -a 123456 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe.
127.0.0.1:6379> set names tom OK 127.0.0.1:6379> get names "tom" 127.0.0.1:6379> bgsave Background saving started 127.0.0.1:6379> quit
[root@localhost redis]# ls dump.rdb [root@localhost redis]# systemctl restart redis [root@localhost redis]# redis-cli -a 123456 Warning: Using a password with '-a' or '-u' option on the command line interface may not be safe. 127.0.0.1:6379> get names "tom" 127.0.0.1:6379> quit
3.基于文件追加方式持久化——默认没有开启
#appendonly : 基于日志文件追加方式开启持久化 appendonly yes 3 appendfilename "appendonly.aof" # 日志文件
3.1备份文件周期
备份文件周期nash语法表
appendfsync always | 每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用 |
appendfsync everysec | 每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐 |
appendfsync no | 完全依赖os,性能最好,持久化没保证 |
appendfsync always appendfsync everysec appendfsync no
3.2重启测试
[root@localhost ~]# systemctl restart redis [root@localhost ~]# ls /var/lib/redis/ appendonly.aof dump.rdb
4.主从同步
4.1主从复制的作用表
主从复制的作用详解表
数据冗余 | 主从复制实现了数据的热备份 是持久化之外的一种数据冗余方式。 |
故障恢复 | 当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复; 实际上是一种服务的冗余。 |
负载均衡 | 在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务 (即写 Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载; 尤其是在写少读多的场 景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。 |
高可用基石 | 可以用于实现读写分离,主库写、从库读,读写分离不仅可以提高服务器的负载能力 同时可根据需求的变化,改变从库的数量; |
4.2Redis 主从复制过程[重在理解]:
- ➢ Slave 与 master 建立连接,发送 sync 同步命令
- ➢ Master 会启动一个后台进程,将数据库快照保存到文件中,同时 master 主进程会开始收集新的写命 令并缓存。
- ➢ 后台完成保存后,就将此文件发送给 slave
- ➢ Slave 将此文件保存到硬盘上
- 一个master可以拥有多个slave,一个slave又可以拥有多个slave,如此下去,形成了强大的多级服务器集群架构
- 例如,将ip为192.168.1.10的机器作为主服务器,将ip为192.168.1.11的机器作为从服务器
4.2.1设置主服务器的配置
bind 192.168.1.10
4.2.2设置从服务器的配置
bind 192.168.1.11 slaveof 192.168.1.10 6379
注意:在slaveof后面写主机ip,再写端口,而且端口必须写
4.2.3在master上写数据
set hello world
在master和slave分别执行info命令,查看输出信息
4.2.3在slave上读数据
get hello
5.发布订阅【比如说KUN宝们订阅我的专栏】
5.1简介
- 发布者不是计划发送消息给特定的接收者(订阅者),而是发布的消息分到不同的频道,不需要知道什么样的订阅者订阅
- 订阅者对一个或多个频道感兴趣,只需接收感兴趣的消息,不需要知道什么样的发布者发布的
- 发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑
- 客户端发到频道的消息,将会被推送到所有订阅此频道的客户端
- 客户端不需要主动去获取消息,只需要订阅频道,这个频道的内容就会被推送过来
5.2消息的格式
消息类型详解说明表
subscribe | unsubscribe | message |
表示订阅成功 | 表示取消订阅成功 | 表示其它终端发布消息 |
如果第一部分的值为subscribe 则第二部分是频道
第三部分是现在订阅的频道的数量 |
如果第一部分的值为unsubscribe 则第二部分是频道,第三部分是现在订阅的频道的数量 如果为0则表 示当前没有订阅任何频道 当在Pub/Sub以外状态,客户端可以发出任何redis命令 |
如果第一部分的值为message 则第二部分是来源频道的名称 第三部分是消息的内容 |
5.3消息类型与之对应的命令
订阅
SUBSCRIBE 频道名称 [频道名称 ...]
取消订阅[如果不写参数,表示取消所有订阅 ]
UNSUBSCRIBE 频道名称 [频道名称 ...]
发布
PUBLISH 频道 消息
举例:
127.0.0.1:6379> PUBLISH chan1 "hello redis" (integer) 1 127.0.0.1:6379> SUBSCRIBE chan1 Reading messages... (press Ctrl-C to quit) 1) "subscribe" 2) "chan1" 3) (integer) 1 1) "message" 2) "chan1" 3) "hello redis"
6.事务
6.1简介
Redis 事务可以一次执行多个命令, 并且带有以下两个重要的保证:
- 事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。
- 事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
- 事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行。
6.2事务从开始到执行会经历以下三个阶段:
1. 开始事务阶段
- 在这个阶段,可以通过
MULTI
命令开始一个事务,标记接下来要执行的多个命令。 - 此时,命令不会立即执行,而是被放入一个队列中。
举例:
MULTI SET key1 "value1" SET key2 "value2"
在这一阶段,Redis会将 SET key1 "value1"
和 SET key2 "value2"
命令记录下来,但这些命令尚未执行。
2. 事务执行阶段
- 在命令标记阶段之后,用户通过
EXEC
命令提交事务,Redis会按顺序执行所有标记的命令。 - 如果在执行过程中出现任何问题(例如,某个命令无效),其他命令仍会被执行。
举例:
EXEC
此时,Redis会依次执行之前标记的 SET key1 "value1"
和 SET key2 "value2"
命令。
3. 结果处理阶段
执行完事务后,Redis会返回每个命令的结果。这些结果可以用于后续的操作或判断。
举例: 假设上面的事务执行成功,Redis会返回如下结果:
1) OK 2) OK
如果在执行过程中出现错误,Redis会返回错误信息,但已成功执行的命令仍然会返回对应的结果。
6.3事务相关命令详解说明表
事务相关命令详解说明表
DISCARD | 取消事务,放弃执行事务块内的所有命令 |
EXEC | 执行所有事务块内的命令 |
MULTI | 标记一个事务块的开始 |
UNWATCH | 取消WATCH命令对所有key的监视 |
WATCH key [key ...] | 监视一个(或多个) key 如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断 |
7.多数据库
7.1简介
- redis也是有数据库的,默认已经创建好,一共有16个,分别为0,1,2,...15
- redis默认数据操作是在0号数据库上
- 数据库和数据库之间不能共享键值对
切换数据库
select 1 //切换到1号数据库
把键值移到指定数据库
move address 0 //假定当前为1号数据库,将1号数据库address移到0号数据库
清空当前数据库
flushdb
清空服务器所有数据库[慎用]
flushall