Redis高级操作

2020-12-22 本文已影响0人攻城老狮

持久化AOF

Redis默认会将持久化的数据保存在 /usr/local/bin 目录下的 dump.rdb 文件内，可以通过以下命令查看

127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/bin"

rdb触发机制

save规则满足的情况下，会自动触发rdb持久化
执行flushall命令，触发rdb持久化
退出redis，会触发rdb持久化

恢复rdb

只要将rdb文件放在redis的启动目录下，redis就可以自动检测并恢复数据

优缺点

优点：
- 适合大规模数据恢复
- 对数据完整性要求不高
缺点：
- 需要一定的时间间隔操作，若redis意外宕机，最后一次修改可能无法得到保存
- fork进程会占用一定的内存空间

持久化AOF

以日志的形式记录写操作，将Redis执行过的指令记录(读指令不记录)，只会追加文件但不可以改写文件。Redis启动后会根据日志内容将写指令从头至尾的执行一遍以完成数据的恢复。
AOF默认关闭，需要手动开启
aof文件操作说明

配置文件中将aof打开

appendonly yes

重启server服务器使配置文件生效，在其中放入一些值

127.0.0.1:6379> set name yorick
OK
127.0.0.1:6379> set age 23
OK
127.0.0.1:6379> set address beijing
OK
127.0.0.1:6379> shutdown
not connected> exit

关闭server服务后，会在目录下生成 appendonly.aof文件，该文件以日志的形式保存了写指令的相关操作

[root@yqj bin]# ls
appendonly.aof  myconfig         redis-check-aof  redis-cli       redis-server
dump.rdb        redis-benchmark  redis-check-rdb  redis-sentinel

删除 dump.rdb 防止实验测试对数据干扰，打开 appendonly.aof 文件，恶意修改文件。会发现无法再次重启redis服务。

此时需要执行redis对aof的检验修复操作

redis-check-aof --fix appendonly.aof

再次重启server服务，发现可以正常获取其他未受干扰的数据

127.0.0.1:6379> keys *
1) "age"
2) "name"

优缺点

优点：
- 每一次修改都同步，数据完整性好
- 每一秒都同步，只会丢失1秒数据
- 从不同步，效率最高
缺点：
- aof文件大小比rdb远远要大，修复速度也慢
- aof运行效率比rdb也慢，故默认使用rdb

发布订阅

发布/订阅模型：发布者，接收者，频道
Redis发布订阅的操作说明

开启一个客户端用于订阅频道

127.0.0.1:6379> subscribe weichat # 订阅频道 weichat
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "weichat"
3) (integer) 1

开启另外一个客户端将消息发布到频道

127.0.0.1:6379> publish weichat "hello world" # 向频道发布消息
(integer) 1

查看客户端方的接收情况

1) "message" # 消息
2) "weichat" # 频道
3) "hello world" # 消息内容

主从复制

主从复制用于读写分离，80%情况下都在进行读操作，可以减轻服务器的压力。
默认情况下，每台Redis服务器均是主节点。一个主节点可以有多个从节点，而一个从节点只能有一个主节点。
主从复制的作用
- 数据冗余
- 故障修复
- 负载均衡
- 高可用（集群）
集群搭建（只需配置从库，不用配置主库）

查看信息

127.0.0.1:6379> info replication
# Replication
role:master # 默认为主库
connected_slaves:0 # 目前没有从机
master_replid:c9924dae7b83755d68ac28f0c11826628396b926
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0

修改3个配置文件，实现一主机二从机的架构

1.修改端口 port 6380
2.修改pid名字 pidfile /var/run/redis_6380.pid
3.修改log文件名字 logfile "6380.log"
4.修改dump.rdb名字 dbfilename dump6380.rdb
5.修改为守护进程 daemonize yes

在客户端手动配置一主机二从机的架构

6380从机配置

127.0.0.1:6380> slaveof 127.0.0.1 6379 # 将6380设为6379的从机
OK
127.0.0.1:6380> info replication
# Replication
role:slave # 从机角色
master_host:127.0.0.1 # 主机host
master_port:6379 # 主机 port
master_link_status:up
master_last_io_seconds_ago:5
master_sync_in_progress:0
slave_repl_offset:0
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:fd0e64a5a450ee131f523ff903158e6921c075d6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:0

6381从机配置

127.0.0.1:6381> slaveof 127.0.0.1 6379 # 将6381设为6379的从机
OK
127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:98
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:fd0e64a5a450ee131f523ff903158e6921c075d6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:98
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:85
repl_backlog_histlen:14

6379主机信息

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:2 # 有2个从机
slave0:ip=127.0.0.1,port=6380,state=online,offset=182,lag=0
slave1:ip=127.0.0.1,port=6381,state=online,offset=182,lag=0
master_replid:fd0e64a5a450ee131f523ff903158e6921c075d6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:182
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:182

测试正常主从交互，其中主机负责写操作，从机负责读操作

127.0.0.1:6379> set name yorick
OK

127.0.0.1:6380> get name
"yorick"

127.0.0.1:6381> get name
"yorick"

测试主机宕机的情况

主机宕机后从机的状态信息

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:down # 主机宕机
master_last_io_seconds_ago:-1
master_sync_in_progress:0
slave_repl_offset:548
master_link_down_since_seconds:9
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:fd0e64a5a450ee131f523ff903158e6921c075d6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:548
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:548

主机重新上线

1.从机的状态变为up状态
2.可以正常接收主机的写信息
3.从机会在主机上线后，做全量复制。当主机此时的rdb做了清空操作，则导致从机也会同步到清空的rdb

从机宕机

主机此时会剔除掉从机节点

27.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=394,lag=0
master_replid:62a549d678800656506801c644cf8d1745d13b33
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:394
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:394

从机重新上线，若是之前在命令中手动配置的话，会又变为master节点，需要再次手动配置为6379的从机节点。之后会从主机节点进行全量复制的操作，同步数据信息。

测试三个节点形成串行架构，A -- B -- C ，其中 A为主机，B C为从机。此时，若主机A宕机，将B手动配置为主机的情形。

A节点信息

127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=1038,lag=0
master_replid:62a549d678800656506801c644cf8d1745d13b33
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:1038
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:1038

B节点信息

127.0.0.1:6380> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6379
master_link_status:up
master_last_io_seconds_ago:8
master_sync_in_progress:0
slave_repl_offset:996
slave_priority:100
slave_read_only:1
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=996,lag=0
master_replid:62a549d678800656506801c644cf8d1745d13b33
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:996
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:677
repl_backlog_histlen:320

C节点信息

127.0.0.1:6381> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6380
master_link_status:up
master_last_io_seconds_ago:1
master_sync_in_progress:0
slave_repl_offset:996
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:62a549d678800656506801c644cf8d1745d13b33
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:996
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:996

A节点宕机，让B节点变为主节点

127.0.0.1:6380> slaveof no one
OK
127.0.0.1:6380> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6381,state=online,offset=1248,lag=1
master_replid:790fe401bebe59340a2d205afbfb1979a04dab8d
master_replid2:62a549d678800656506801c644cf8d1745d13b33
master_repl_offset:1248
second_repl_offset:1235
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:677
repl_backlog_histlen:572

此时，C从机会根据B节点的数据变化而同步数据

哨兵模式

利用哨兵模式实现对一主机二从机的架构进行监控，有宕机发生时可以实现自动选举新的主机节点

编写哨兵的配置文件 sentinel.conf

# sentinel monitor 自定义名称 host port 票数 
sentinel monitor myredis 127.0.0.1 6379 1

启动哨兵，监控

redis-sentinel myconfig/sentinel.conf

测试使主节点宕机

哨兵监控到主节点宕机，选举6381为主节点

17063:X 18 Dec 2020 08:45:54.116 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6381
17063:X 18 Dec 2020 08:45:54.116 * +slave slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381
17063:X 18 Dec 2020 08:46:24.170 # +sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ myredis 127.0.0.1 6381

此时若恢复原来的节点，则会将该节点变为新主节点的从节点

127.0.0.1:6379> info replication
# Replication
role:slave
master_host:127.0.0.1
master_port:6381
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0
slave_repl_offset:18536
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:adf8c515dc36f5834f3a1f4b49076e62a4046de6
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:18536
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:14470
repl_backlog_histlen:4067

哨兵模式的优缺点

优点：
- 哨兵集群基于主从复制模式，所有的主从配置优点，哨兵全部继承
- 主从可以实现切换，故障转移，系统的可用性提升
- 哨兵模式是主从模式的升级，手动到自动更健壮
缺点：
- Redis不易进行在线扩容，集群容量达到上线后扩容较为麻烦
- 实现哨兵模式的配置较为复杂

参考地址：https://www.bilibili.com/video/BV1S54y1R7SB

Redis高级操作

持久化AOF

持久化AOF

发布订阅

主从复制

哨兵模式

猜你喜欢

热点阅读