redis高级应用【密码防护、数据持久化、主从同步、哨兵模式、事务】【暂未完成(半成品)】

redis高级应用【密码防护、数据持久化、主从同步、哨兵模式、事务】

1、密码防护

给 redis 服务器设置密码

可以通过 redis 的配置文件设置密码参数,这样客户端连接到 redis 服务就需要密码验证,这样可以让你的 redis 服务更安全。
查看是否设置了密码验证:

127.0.0.1:6379> CONFIG GET requirepass
1) "requirepass"
2) ""

通过以下命令来修改该参数

127.0.0.1:6379> CONFIG SET requirepass "123"
OK
127.0.0.1:6379> CONFIG GET requirepass
(error) NOAUTH Authentication required.

设置密码验证后必须验证才能进行其他操作:

127.0.0.1:6379> AUTH 123
OK
127.0.0.1:6379> CONFIG GET requirepass
1) "requirepass"
2) "123"

注意:命令设置仅在当前有效,重启服务后失效。

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) ""

要永久生效,需要修改配置文件并重启服务。

vim /etc/redis.conf

requirepass 123456 
[root@localhost ~]# systemctl restart redis

3、客户端登录

[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、数据持久化

1、简介
redis为了本身数据的完整和安全性,redis需要经常将内存中的数据同步到磁盘,这个过程称之为持久化操作。下次再次启动redis服务时,会把磁盘上面保存的数据重新加载到内存里面。

    常见的持久化方式:
    a、基于快照的方式:redis按照一定的周期把内存里面的数据同步到磁盘文件里面
    b、基于文件追加:redis会把对redis数据造成更改的命令记录到日志文件里面,然后再一次重启,执行日志文件里面对redis写的操作,达到数据还原。

2、基于快照的持久化
修改配置文件,开启基于快照的选项
save 900 1 #900秒内如果超过1个key被修改,则发起快照保存
save 300 10 #300秒内容如超过10个key被修改,则发起快照保存
save 60 10000 #60秒内容如超过10000个key被修改,则发起快照保存
#以上是系统默认配置

保持到磁盘上的文件

[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

模拟删除文件,手工保存,重启后查看

[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 

appendfilename "appendonly.aof" # 日志文件

备份文件周期

# appendfsync always
appendfsync everysec
# appendfsync no

appendfsync always //每次收到写命令就立即强制写入磁盘,最慢的,但是保证完全的持久化,不推荐使用

appendfsync everysec //每秒钟强制写入磁盘一次,在性能和持久化方面做了很好的折中,推荐

appendfsync no //完全依赖os,性能最好,持久化没保证

重启测试

[root@localhost ~]# systemctl restart redis
[root@localhost ~]# ls /var/lib/redis/
appendonly.aof  dump.rdb

3、主从同步

主从复制的作用

1. 数据冗余:主从复制实现了数据的热备份,是持久化之外的一种数据冗余方式。
2. 故障恢复:当主节点出现问题时,可以由从节点提供服务,实现快速的故障恢复;实际上是一种服务的冗余。
3. 负载均衡:在主从复制的基础上,配合读写分离,可以由主节点提供写服务,由从节点提供读服务(即写Redis数据时应用连接主节点,读Redis数据时应用连接从节点),分担服务器负载;尤其是在写少读多的场景下,通过多个从节点分担读负载,可以大大提高Redis服务器的并发量。
4. 读写分离:可以用于实现读写分离,主库写、从库读,读写分离不仅可以提高服务器的负载能力,同时可根据需求的变化,改变从库的数量;
5. 高可用基石:除了上述作用以外,主从复制还是哨兵和集群能够实施的基础,因此说主从复制是Redis高可用的基础。

Redis 主从复制过程:
➢ Slave 与 master 建立连接,发送 sync 同步命令
➢ Master 会启动一个后台进程,将数据库快照保存到文件中,同时 master 主进程会开始收集新的写命令并缓存。
➢ 后台完成保存后,就将此文件发送给 slave
➢ Slave 将此文件保存到硬盘上

  • 一个master可以拥有多个slave,一个slave又可以拥有多个slave,如此下去,形成了强大的多级服务器集群架构
  • 比如,将ip为192.168.1.10的机器作为主服务器,将ip为192.168.1.11的机器作为从服务器
  • 设置主服务器的配置
bind 192.168.1.10
  • 设置从服务器的配置
  • 注意:在slaveof后面写主机ip,再写端口,而且端口必须写
bind 192.168.1.11
slaveof 192.168.1.10 6379
  • 在master和slave分别执行info命令,查看输出信息:info replication
  • 在master上写数据
set hello world
  • 在slave上读数据
get hello

4、哨兵模式

高可用方案:

1、cluster 集群

2、sentinel 哨兵

高可用 Sentinel 哨兵

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-E4KeIvXZ-1654621540427)(素材\NoSQL\sentinel哨兵模式.jpg)]

​ Sentinel 哨兵是 redis 官方提供的高可用方案,可以用它来监控多个 Redis 服务实例的运行情况。Redis Sentinel 是一个运行在特殊模式下的 Redis 服务器。Redis Sentinel 是在多个Sentinel 进程环境下互相协作工作的。

Sentinel 系统有三个主要任务:
1.监控:Sentinel 不断的检查主服务和从服务器是否按照预期正常工作。
2.提醒:被监控的 Redis 出现问题时,Sentinel 会通知管理员或其他应用程序。
3.自动故障转移:监控的主 Redis 不能正常工作,Sentinel 会开始进行故障迁移操作。将一个从服务器升级新的主服务器。 让其他从服务器挂到新的主服务器。同时向客户端提供新的主服务器地址

高可用 Sentinel 哨兵配置
哨兵作为对redis实例的监控,通过选举算法保证哨兵的鲁棒性和高可用,所以哨兵至少要部署3台,符合半数原则,需要5或者7,超过一半,不包含一半存活的时候,才能够选举出leader,才能进行主从的切换功能。
redis服务,至少需要存活一台,才能保证服务正常运行sentinel ,选择新 master 的原则是最近可用且数据最新且优先级最高且活跃最久
哨兵高可用测试:分别连接对应的redis服务端,手动停止哨兵,停止主reids服务,看主从是否切换成功。
三哨兵情况:redis实例挂掉两台,剩下一台能够成为主,自动切换

哨兵系统的搭建过程,有几点需要注意:
(1)哨兵系统中的主从节点,与普通的主从节点并没有什么区别,故障发现和转移是由哨兵来控制和完成的。
(2)哨兵节点本质上是redis节点。
(3)每个哨兵节点,只需要配置监控主节点,便可以自动发现其他的哨兵节点和从节点。
(4)在哨兵节点启动和故障转移阶段,各个节点的配置文件会被重写(config rewrite)。
(5)一个哨兵可以只监控了一个主节点;实际上,一个哨兵可以监控多个主节点,通过配置多条sentinel monitor即可实现。

参考配置文件

#是否为守护进程
daemonize yes

pidfile "/var/run/redis/redis-sentinel.pid"
logfile "/var/log/redis/redis-sentinel.log"
bind 127.0.0.1
port 26379

#工作目录
dir "/var/lib/redis"

#声明该哨兵的主库是mymaster,主库的ip和端口分别为127.0.0.1和6379
#最后一个2的含义是,在哨兵发生领导选举时,该哨兵需要获得2票才能成为leader
sentinel monitor mymaster 127.0.0.1 6379 2

#在mymaster宕机30秒后进行主观下线
sentinel down-after-milliseconds mymaster 30000
#指定在发生failover故障转移时最多可以有1个slave同时对新的master进行同步
sentinel parallel-syncs mymaster 1

#设置故障转移超时时间为180秒
#这个参数的意义比较复杂,详细可以参考官方的注释说明
sentinel failover-timeout mymaster 180000

#发现两个从节点
sentinel known-slave mymaster 127.0.0.1 6380
sentinel known-slave mymaster 127.0.0.1 6381

#epoch实现类似版本号的功能
sentinel current-epoch 0	

5、发布订阅

- 发布者不是计划发送消息给特定的接收者(订阅者),而是发布的消息分到不同的频道,不需要知道什么样的订阅者订阅
- 订阅者对一个或多个频道感兴趣,只需接收感兴趣的消息,不需要知道什么样的发布者发布的
- 发布者和订阅者的解耦合可以带来更大的扩展性和更加动态的网络拓扑
- 客户端发到频道的消息,将会被推送到所有订阅此频道的客户端
- 客户端不需要主动去获取消息,只需要订阅频道,这个频道的内容就会被推送过来

消息的格式

- 推送消息的格式包含三部分
- part1:消息类型,包含三种类型
  - subscribe,表示订阅成功
  - unsubscribe,表示取消订阅成功
  - message,表示其它终端发布消息
- 如果第一部分的值为subscribe,则第二部分是频道,第三部分是现在订阅的频道的数量
- 如果第一部分的值为unsubscribe,则第二部分是频道,第三部分是现在订阅的频道的数量,如果为0则表示当前没有订阅任何频道,当在Pub/Sub以外状态,客户端可以发出任何redis命令
- 如果第一部分的值为message,则第二部分是来源频道的名称,第三部分是消息的内容

命令

  • 订阅
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、事务

Redis 事务可以一次执行多个命令, 并且带有以下两个重要的保证:
▪ 事务是一个单独的隔离操作:事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中,不会被其他客户端发送来的命令请求所打断。
▪ 事务是一个原子操作:事务中的命令要么全部被执行,要么全部都不执行。

一个事务从开始到执行会经历以下三个阶段:

​ ▪ 开始事务。multi

​ ▪ 命令入队。

​ ▪ 执行事务。

序号命令及描述
1DISCARD 取消事务,放弃执行事务块内的所有命令。
2EXEC 执行所有事务块内的命令。
3MULTI 标记一个事务块的开始。
4UNWATCH 取消 WATCH 命令对所有 key 的监视。
5WATCH key [key …] 监视一个(或多个) key ,如果在事务执行之前这个(或这些) key 被其他命令所改动,那么事务将被打断。

7、多数据库

​ redis也是有数据库的,默认已经创建好,一共有16个,分别为0,1,2,…15
​ redis默认数据操作是在0号数据库上。
​ 数据库和数据库之间不能共享键值对。

切换数据库 
 select 1    //切换到1号数据库
 
把键值移到指定数据库
 move address 0 //假定当前为1号数据库,将1号数据库address移到0号数据库
 
清空当前数据库:flushdb
清空服务器所有数据库:flushall

注意:清空数据库慎用!!!

  • 2
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值