Redis持久化以及发布订阅详解

Redis持久化以及发布订阅

Redis配置文件详解

网络

bind 127.0.0.1	#绑定ip
protected-mode yes	#保护模式
port 6379	#端口

通用

daemonize yes	#守护进程运行，默认是no
supervised no	#管理守护进程
pidfile /var/run/redis_6379.pid	#如果以后台方式，守护进程方式运行需要指定一个pid文件
loglevel notice	#日志级别
# Specify the server verbosity level.
# This can be one of:
# debug (a lot of information, useful for development/testing)
# verbose (many rarely useful info, but not a mess like the debug level)
# notice (moderately verbose, what you want in production probably)
# warning (only very important / critical messages are logged)

logfile ""	#日志的文件地址
databases 16	#数据库的数量，默认16
always-show-logo yes	#是否显示logo

快照

持久化，在规定的时间内，执行多少次操作，会持久化到文件(.rdb .aof)，redis是内存数据库，如果没有持久化，那么数据断电丢失

# 如果在900s内有1个key进行了修改，则持久化
save 900 1
# 如果在300s内有10个key进行了修改，则持久化
save 300 10
# 如果在60s内有10000个key进行了修改，则持久化
save 60 10000
#持久化出错是否继续工作
stop-writes-on-bgsave-error yes
#是否压缩rdb文件 需要消耗cpu资源
rdbcompression yes
# 保存rdb文件时是否校验
rdbchecksum yes
# rdb文件保存的文件名
dbfilename dump.rdb
# rdb文件保存的目录
dir ./

Replication主从复制

# 当slave是去和master的连接，或者同步正在进行中
#yes -->会继续相应客户端的请求(默认)
#no -->不会响应
replica-serve-stale-data yes
# 默认所有的slave只读
replica-read-only yes
# 同步策略：磁盘或者socket，默认磁盘(no)
repl-diskless-sync no
# 如果非磁盘同步方式开启，可以配置同步延迟时间，以等待master产生子进程通过socket传输RDB数据给slave。
# 默认值为5秒，设置为0秒则每次传输无延迟。
repl-diskless-sync-delay 5
# 如果选择no，数据传输到salve的延迟将会减少但要使用更多的带宽，默认我们会为低延迟做优化，但高流量情况或主从之间的跳数过多时，可以设置为“yes”
repl-disable-tcp-nodelay no
# 优先级数字小的salve会优先考虑提升为master，所以例如有三个slave优先级分别为10，100，25，sentinel将挑选优先级最小数字为10的slave。
# 0作为一个特殊的优先级，标识这个slave不能作为master，所以一个优先级为0的slave永远不会被# sentinel挑选提升为master。
replica-priority 100

Security安全

# 设置密码，默认不开启
requirepass foobared
# 可以配置也可以通过命令设置
127.0.0.1:6379> ping
PONG
127.0.0.1:6379> config get requirepass	#获取密码
1) "requirepass"
2) ""
127.0.0.1:6379> config set requirepass "123456"	#设置密码
OK
127.0.0.1:6379> config get requirepass
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth "123456"
OK
127.0.0.1:6379> config get requirepass
1) "requirepass"
2) "123456"

限制Client

maxclients 10000	#可连接最大客户端数
maxmemory <bytes>	#redis最大内存容量
#内存达到上限之后的处理策略
# volatile-lru -> 只对设置了过期时间的key进行LRU
# allkeys-lru -> 删除LRU算法的key
# volatile-lfu -> 只对设置了过期时间的key进行LRF
# allkeys-lfu -> 删除LRF算法的key
# volatile-random -> 随机删除即将过期的key(设置了过期时间)
# allkeys-random -> 随机删除key
# volatile-ttl -> 删除即将过期的key
# noeviction -> 永不过期(默认)

maxmemory-policy noeviction	

appendonly 模式 aof配置

appendonly no	#默认不开启，默认rdb持久化
appendfilename "appendonly.aof"	#持久化文件名字
# 有下面几种模式
# everysec-->每秒执行一次sync，可能丢失1s内的数据；
# always-->每次修改都会sync，消耗性能
# no-->不执行sync，依靠操作系统判断
appendfsync everysec	

Redis持久化

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

RDB(Redis Database)

什么是RDB

在指定的时间间隔内将内存中的数据集快照写入磁盘，恢复时将快照文件直接读到内存中。

Redis会单独创建(fork)一个子线程来进行持久化，会现将数据写到一个临时文件中，待持久化过程结束后，再用这个文件替换上次持久化好的文件中。整个过程由子线程完成，主进程不进行任何的IO操作，确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是很敏感，那RDB方式比AOF更加高效，RDB的缺点就是最后一次持久化的数据可能会丢失。

RDB保存的是dump.rdb文件

触发机制

1. save的规则满足的情况下，会自动触发rdb规则
2. 执行flushall命令也会触发rdb规则
3. 退出redis，也会产生rdb文件

备份就会自动生成一个dump.rdb文件

如何恢复RDB文件

1. 只需要将RDB文件放在我们redis启动目录就可以，redis启动时会自动检查dump.rdb文件并恢复其中的数据

   #使用config命令查看文件存放位置
   127.0.0.1:6379> config get dir
   1) "dir"
   2) "/usr/local/bin"	#如果在这个目录下就会自动恢复
   
   

优点：

1. 适合大规模数据恢复
2. 如果对数据完整性要求不高

缺点：

1. 需要一定的时间间隔，如果在这个时候意外宕机，这个最后一次修改的数据就会丢失
2. fork进程的时候会占用内存空间

AOF(Append Only File)

将所有命令都记录下来，恢复的时候将命令再执行一遍

什么是AOF

以日志的形式记录每个写操作，将Redis执行过的所有指令记录下来，只追加文件但不改写文件。Redis启动之初会读取该文件重新构建数据，根据日志文件中的内容将指令从前到后执行一遍完成数据的恢复工作

AOF保存的是appendonly.aof文件

Append配置

修改配置之后重启服务

#设置一些值
127.0.0.1:6379> set k1 v1 
OK
127.0.0.1:6379> set k2 v2
OK
127.0.0.1:6379> set k3 v3
OK
127.0.0.1:6379> set k4 v4
OK
# 查看aof文件
[root@VM-4-17-centos bin]# vim appendonly.aof

# shutdown redis服务并破坏aof文件
127.0.0.1:6379> shutdown
not connected> exit
[root@VM-4-17-centos bin]# vim appendonly.aof

# 重新启动服务并连接会报错
[root@VM-4-17-centos bin]# redis-server redisconfig/redis.conf 
26967:C 30 Jan 2024 15:10:39.463 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
26967:C 30 Jan 2024 15:10:39.463 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=26967, just started
26967:C 30 Jan 2024 15:10:39.463 # Configuration loaded
[root@VM-4-17-centos bin]# redis-cli -p 6379
Could not connect to Redis at 127.0.0.1:6379: Connection refused

如果这个aof文件报错这个时候可以使用redis-check-aof命令进行修复

[root@VM-4-17-centos bin]# redis-check-aof --fix appendonly.aof 
0x              8b: Expected prefix '*', got: 'f'
AOF analyzed: size=156, ok_up_to=139, diff=17
This will shrink the AOF from 156 bytes, with 17 bytes, to 139 bytes
Continue? [y/N]: y
Successfully truncated AOF


#修复成功后再看下aof文件

# 再重新启动即可连接
[root@VM-4-17-centos bin]# redis-server redisconfig/redis.conf 
27287:C 30 Jan 2024 15:15:38.539 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
27287:C 30 Jan 2024 15:15:38.539 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=27287, just started
27287:C 30 Jan 2024 15:15:38.539 # Configuration loaded
[root@VM-4-17-centos bin]# redis-cli -p 6379
127.0.0.1:6379> get k1
"v1"

优点：

1. 每一次修改都同步，文件的完整性更好
2. 每秒同步，可能会丢失一秒的数据
3. 从不同步，效率是最高的

缺点：

1. 相对于数据文件来说，aof远远大于rdb，修复的速度也比rdb慢
2. aof运行效率也比rdb慢

持久化总结：

1. RDB持久化方式能够在指定的时间间隔内对数据进行快照存储

2. AOF持久化方式记录每次对服务器的写的操作，当服务器重启时会重新执行aof文件中记录的命令来进行数据恢复，Redis还能对AOF文件进行后台重写(可以在配置文件中进行修改)，保证单个的aof文件不至于过大

3. 只做缓存，如果只希望数据在服务器运行时存在，可以不使用任何的持久化方式

4. 同时开启两种持久化方式

   • 在这种情况下，当Redis重启的时候会优先加载AOF文件来恢复原始的数据，因为在通常情况下AOF文件保存的数据相对较完整
   • RDB的数据不实时，同时使用两者时服务重启也只会找AOF文件，但是RDB文件更适用备份数据库

5. 性能建议

   • 因为RDB文件只用作后背用途，建议只在slave上持久化RDB文件，只保留配置文件中的(save 900 1)这条即可
   • 如果开启AOF，好处是在最恶劣的情况下也只不过丢失不超过两秒的数据，启动脚本较简单只load自己的aof文件即可，代价是带来持续的IO；还有就是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件所带来的阻塞是不可避免的，应该尽量减少AOF rewrite的频率
   • 如果不开启AOF，仅靠Master-Slave Replication实现高可用性也可以，可以减少一大笔IO，也减少rewrite带来的系统波动，代价是如果Master/Slave同时挂掉，会丢失十几分钟的数据，启动脚本也要比较两个Master/Slave中的RDB文件，载入较新的那个

Redis发布订阅

Redis发布订阅(pub/sub)是一种消息通信模式：发送者(pub)发送消息，订阅者(sub)接收消息，Redis客户端可以订阅任意数量的频道。

下图展示了频道 channel1 ， 以及订阅这个频道的三个客户端 —— client2 、 client5 和 client1 之间的关系：

当有新消息通过 PUBLISH 命令发送给频道 channel1 时， 这个消息就会被发送给订阅它的三个客户端：

命令

这些命令被广泛用于通信应用，比如网络聊天室和实时广播，实时提醒等等。

测试

# 订阅一个channel，会持续等待管道的消息
127.0.0.1:6379> SUBSCRIBE test
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "test"
3) (integer) 1
1) "message"
2) "test"

# 另起一个客户端 并发布消息
127.0.0.1:6379> PUBLISH test "this is a message"
(integer) 1

原理

Redis是使用C实现的，通过PUBLISH、SUBSCRIBE、PSUBSCRIBE等命令实现发布订阅功能。

通过SUBSCRIBE订阅后，redis-server里维护了一个字典，字典的键就是一个channel，值则是一个链表，链表保存了所有订阅这个channel的客户端，SUBSCRIBE命令的关键就是将客户端添加到给定的channel订阅链表中。

通过PUBLISH命令向订阅者发布消息，redis-server会使用给定的频道作为键，在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发送给所有的订阅者。

Pub/Sub从字面上理解就是发布(publish)和订阅(subscribe)，在redis中，你可以设定对某一个key进行消息的发布和消息的订阅，当一个key值上进行了消息发布后，所有的订阅它的客户端都会收到相应的消息，这一功能最明显的使用场景就是实时消息系统，比如即时聊天、群聊等功能。

rver里维护了一个字典，字典的键就是一个channel，值则是一个链表，链表保存了所有订阅这个channel的客户端，SUBSCRIBE命令的关键就是将客户端添加到给定的channel订阅链表中。

通过PUBLISH命令向订阅者发布消息，redis-server会使用给定的频道作为键，在它所维护的channel字典中查找记录了订阅这个频道的所有客户端的链表，遍历这个链表，将消息发送给所有的订阅者。

Pub/Sub从字面上理解就是发布(publish)和订阅(subscribe)，在redis中，你可以设定对某一个key进行消息的发布和消息的订阅，当一个key值上进行了消息发布后，所有的订阅它的客户端都会收到相应的消息，这一功能最明显的使用场景就是实时消息系统，比如即时聊天、群聊等功能。

如果是复杂系统，建议使用MQ作为消息中间件！