redis进阶笔记

最新推荐文章于 2024-10-01 11:12:34 发布

舒翰

最新推荐文章于 2024-10-01 11:12:34 发布

阅读量102

点赞数

分类专栏： redis java技术栈文章标签： redis 数据库缓存

本文链接：https://blog.csdn.net/qq_43128330/article/details/129105119

版权

java技术栈同时被 2 个专栏收录

6 篇文章 0 订阅

订阅专栏

redis

2 篇文章 0 订阅

订阅专栏

Redis进阶笔记

1、Redis持久化
- 1-1、RDB
- 1-2、AOF(Append Only File)
2、Redis发布订阅
3、主从复制
4、redis缓存穿透和雪崩

1、Redis持久化

Redis是内存数据库，如果不将内存中的数据库的状态保存到磁盘，那么一旦服务器的进程退出，服务器中的数据库状态也会消失，所以Redis提供了持久化

1-1、RDB

在指定的间隔时间内将内存中的数据集快照写入磁盘，恢复将快照读到内存中。
RDB的缺点就是最后一次持久化的数据可能会丢失，默认就是RDB，一般情况下不修改，比AOF更加高效。
RDB保存的文件是dump.rdb
主从复制中，RDB是一个备份

# 60秒内触发五次key值修改，就会进行快照（测试一下）
save 60 5

触发机制

save满足条件的情况下
执行flushall命令
退出redis时
自动备份生成dump.rdb

如何恢复rdb文件？

只需要将rdb文件放在我们的redis启动目录就可以，redis启动的时候会自动检查dump.rdb恢复其中的数据
查看需要存在的文件中
如果该目录下存在dump.rdb文件，启动会自动恢复其中的数据

# 查看我们需要存在的位置
127.0.0.1:6379> config get dir
1) "dir"
2) "/usr/local/redis-7.0.8"

几乎默认的就已经够用了
优点

适合大规模的数据恢复! dump.rdb
对数据完整性的要求不高!
缺点
需要一定的时间间隔进行操作!如果redis意外宕机了，这个最后一次修改数据就没有了。
fork进程的时候，会占用一定的内存空间。

生产坏境的时候会将这个文件进行备份

1-2、AOF(Append Only File)

将我们所有命令都记录下来，history，恢复的时候就把全部的文件再去执行一遍
以日志的形式将每个写操作都记录下来，追加文件但不该写文件，redis启动初期会读取该文重新构造数据，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成的恢复工作。
AOF保存的是appendonly.aof文件

# 默认是不开启的，手动进行配置
appendonly yes

# always 总是保存，everysec 每秒保存
# appendfsync always
appendfsync everysec
# appendfsync no

# 重启的时候是否重写
no-appendfsync-on-rewrite no

# 文件重写规则，文件大于64m， fork一个新的进程来将文件进行重写
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb

文件内容请添加图片描述

如果对文件破坏的话
192:redis-7.0.8 jiangwenhan$ redis-cli
Could not connect to Redis at 127.0.0.1:6379: Connection refused
不能进行正常的连接
如果aof文件有错误，redis是启动不起来的，我们需要修复这个aof文件，redis给我们提供redis-aof-check的工具(文件错误的情况一般是在突然宕机的情况下需要去进行修复)
redis-check-aof --fix appendonlydir/appendonly.aof.1.incr.aof

192:redis-7.0.8 $ redis-check-aof --fix appendonlydir/appendonly.aof.1.incr.aof # 修复文件 
Start checking Old-Style AOF
0x              72: Expected \r\n, got: 6461
AOF analyzed: filename=appendonlydir/appendonly.aof.1.incr.aof, size=126, ok_up_to=23, ok_up_to_line=28, diff=103
This will shrink the AOF appendonlydir/appendonly.aof.1.incr.aof from 126 bytes, with 103 bytes, to 23 bytes
Continue? [y/N]: y
Successfully truncated AOF appendonlydir/appendonly.aof.1.incr.aof

优点

每一次修改都同步，文件的完整性会更加好！
默认每秒同步一次，可能会丢失一秒的数据。
从不同步，效率是最高的！
缺点
相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢！
aof运行效率也要rdb慢，所以我们redis默认的配置就是rdb持久化！

AOF优先，AOF出现问题，找RDB

2、Redis发布订阅

Redis发布订阅（pub/sub）是一种消息通信模式
消息队列（mq，kafka）

第一个：消息发送者。第二个：频道。第三个：消息订阅者

命令	描述
subscribe name	订阅一个频道
publish name msg	发送消息

# 订阅消息
127.0.0.1:6379> subscribe jiangxiaohan # 订阅一个频道
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "jiangxiaohan"
3) (integer) 1
# 监听推送的信息
1) "message"
2) "jiangxiaohan"
3) "redis niubi"

# 发布消息
192:redis-7.0.8 jiangwenhan$ redis-cli # 发布消息到频道
127.0.0.1:6379> publish jiangxiaohan "redis niubi"
(integer) 1

3、主从复制

将一台服务器的数据，复制到其他的服务器中，数据复制是单向的，只能从主节点到从节点。主机负责写，从机负责读。
80%的情况下都在进行读操作，减缓服务器压力，架构中经常使用。
主要作用:

数据冗余：主从复制实现了数据的热备份，是持久化之外的另一种数据冗余的方式。
故障恢复：当主节点出现了故障问题，其他从节点提供服务帮助快速恢复故障问题。
负载均衡：分担服务器的负载（主节点负责写，从节点负责读）
高可用（集群）：高可用基础

单台Redis服务器最大使用内存不能超过20G

3-1、Redis集群环境搭建

只配置从库，不配置主库，默认自己是一个主库。

# 查看当前库的信息
127.0.0.1:6379> info replication
# Replication
role:master # 角色主机
connected_slaves:0 # 没有主机
master_failover_state:no-failover
master_replid:9ce40593880ca7f1a4cc54fa8217af8046db92dd
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

修改配置文件

# 日志名可能会重复(主机)
logfile "6379.log"
dbfilename dump6379.rdb

# 从机
port 6380 # 端口
pidfile /var/run/redis_6380.pid # pid名字
logfile "6380.log"# 日志
dbfilename dump6380.rdb # 备份

3-2、复制原理

将上述内容配置主从配置时三台都是主机，需要配置从机

127.0.0.1:6380> SLAVEOF 127.0.0.1 6379 # 配置从机
OK
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_read_repl_offset:0
slave_repl_offset:0
master_link_down_since_seconds:-1
slave_priority:100
slave_read_only:1
replica_announced:1
connected_slaves:0
master_failover_state:no-failover
master_replid:8b60a84c6b0f29807ead6d5a84c40705d83a9347
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


# 主机
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1
slave0:ip=127.0.0.1,port=6380,state=online,offset=42,lag=1
master_failover_state:no-failover
master_replid:6d08d5ab787ed695dcf463dead32c8e956071430
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:42

真实情况下是在配置文件中配置

replicaof 127.0.0.1 6379

# 可以设置密码验证

主机可以写，从机只能读！主机中所有的信息和数据都会自动被从机保存。
全量复制：从机连接时，主机将发送sync同步命令，一次性同步
增量复制：主机将新的命令给从机

3-3、宕机后手动配置主机

可以使用套娃模式：79->80->81
当79宕机时，80当主机，81为从机
80需要SLAVEOF NO ONE将自己设置为主机
79再上线时就无用了,需要重新配置

3-4、哨兵模式

2.8版本之后，是主从复制的自动版。
哨兵发送命令根据响应判断
为了防止哨兵死去，需要配置多哨兵模式
主观下线：服务器宕机的时候，哨兵1检测这个结果，但是系统不会马上进行failover过程，仅仅是哨兵1主观认为这个服务器不可用。
客观下线：当后面的哨兵也检测到这个主服务器不可用，数量达到一定值时，哨兵之间会进行一个投票，进行故障转移操作，就会通过发布订阅的模式，实现自己监控的从服务器切换主服务器。

测试

配置哨兵

sentinel.conf 哨兵文件

# sentinel monitor 监控名称 host port [主机挂了，slave投票看让谁接任主机]
sentinel monitor myredis 127.0.0.1 6379 1

启动哨兵

redis-sentinel kconf/sentinel.conf 
8498:X 19 Feb 2023 01:32:03.013 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
8498:X 19 Feb 2023 01:32:03.013 # Redis version=7.0.8, bits=64, commit=00000000, modified=0, pid=8498, just started
8498:X 19 Feb 2023 01:32:03.013 # Configuration loaded
8498:X 19 Feb 2023 01:32:03.014 * Increased maximum number of open files to 10032 (it was originally set to 256).
8498:X 19 Feb 2023 01:32:03.014 * monotonic clock: POSIX clock_gettime
                _._                                                  
           _.-``__ ''-._                                             
      _.-``    `.  `_.  ''-._           Redis 7.0.8 (00000000/0) 64 bit
  .-`` .-```.  ```\/    _.,_ ''-._                                  
 (    '      ,       .-`  | `,    )     Running in sentinel mode
 |`-._`-...-` __...-.``-._|'` _.-'|     Port: 26379
 |    `-._   `._    /     _.-'    |     PID: 8498
  `-._    `-._  `-./  _.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |           https://redis.io       
  `-._    `-._`-.__.-'_.-'    _.-'                                   
 |`-._`-._    `-.__.-'    _.-'_.-'|                                  
 |    `-._`-._        _.-'_.-'    |                                  
  `-._    `-._`-.__.-'_.-'    _.-'                                   
      `-._    `-.__.-'    _.-'                                       
          `-._        _.-'                                           
              `-.__.-'                                               

8498:X 19 Feb 2023 01:32:03.015 # WARNING: The TCP backlog setting of 511 cannot be enforced because kern.ipc.somaxconn is set to the lower value of 128.
8498:X 19 Feb 2023 01:32:03.024 * Sentinel new configuration saved on disk
8498:X 19 Feb 2023 01:32:03.024 # Sentinel ID is c7c5ae1f5cca2b13b6684450b6eebfc9e524df1f
8498:X 19 Feb 2023 01:32:03.024 # +monitor master myredis 127.0.0.1 6379 quorum 1
8498:X 19 Feb 2023 01:32:03.027 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
8498:X 19 Feb 2023 01:32:03.031 * Sentinel new configuration saved on disk

master节点断开了，会从从机选择当主机
主机回来了，只能当从机

优点

哨兵集群，基于主从复制模式，所有的主从配置的优点它都有。
主从可以切换，故障可以转移，系统的可用性就会更好
哨兵模式就是主从模式的升级，手动到自动
缺点
Redis不好在线扩容，集群容量一旦到达上限，在线扩容就十分麻烦
实现哨兵模式的配置其实很麻烦，里面有很多选择.

# 端口，哨兵集群还要配置每个哨兵集群的端口
port 26379
# 哨兵的sentinel的工作目录
dir /tmp
# 主机的配置
sentinel monitor myredis 127.0.0.1 6379 1

# 主机密码
sentinel auth-pass myredis MySUPER--secret-0123passwOrd

# 指定多少秒主节点主观下线，默认30秒
sentinel down-after-milliseconds mymaster 30000

4、redis缓存穿透和雪崩

穿透（查不到）

秒杀场景，缓存中没数据，直接大量请求数据库，导致数据库压力过大。
解决：布隆过滤器->是一种数据结构，对所有可能查询的参数以hash形式存储，在控制层先进行校验，不符合条件的丢弃，避免了对底层存储查询的压力。
设置空对象：有可能会出现双写不一致问题

雪崩（查太多了）

击穿是雪崩的一个特例，击穿是当一个key非常热点，在这个缓存失效的一瞬间，直接请求数据库，导致数据库压力过大。
解决：1、缓存设置永久。2、加分布式锁
雪崩，在某一瞬间集体失效或者服务器宕机。例如双十二时，集体失效。
解决：1、多增加redis服务器 2、限流降级 3、数据预热 4、设置随机失效时间