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

于 2024-01-30 16:39:48 发布
阅读量1k 收藏 24
点赞数 28
分类专栏： Redis 文章标签： redis 数据库
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/Grady00/article/details/135936157
版权

文章目录

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作为消息中间件！

拉霍拉卡
关注
  • 28
    点赞
  • 踩
  • 24
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论
专栏目录
Redis发布订阅和实现.NET客户端详解
09-09
因此，对于需要持久化和确认的场景，可能需要考虑其他解决方案，如RabbitMQ或其他消息中间件。 总的来说，Redis的发布订阅功能提供了轻量级的消息传递机制，适合处理实时、低延迟、一对多的消息传递需求。通过结合...
redis发布订阅_动力节点Java学院整理
12-16
总结来说，Redis的发布订阅模式提供了轻量级的实时消息传递机制，通过简单的命令即可实现生产者与消费者的解耦，且不需要持久化连接，适合于低延迟、高并发的实时通信场景。通过灵活的频道订阅和模式匹配，可以适应...
Redis事务、持久化、发布订阅
jx69693678nab的博客
01-02 857
一、Redis事物 1. 概念 　　Redis 事务可以一次执行多个命令， 并且带有以下两个重要的保证： 　　　　事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。 　　　　事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。 　　一个事务从开始到执行会经历以下三个阶段： 　　　　开始事务。 ...
Linux 安装redis,redis发布订阅,持久化
weixin_30287169的博客
02-19 129
安装redis 1.安装redis的方式 -yum (删除这个yum安装的redis，我们只用源码编译安装的) -rpm -源码编译 2.删除原本的redis yum remove redis -y 3.下载redis源码 wget http://download.redis.io/releases/redis-4.0.10.tar.gz 4.解压缩 tar -...
Redis - Redis基础_发布订阅_事务_持久化
你今天真好看呀
03-06 335
文章目录一、Redis发布订阅二、多数据库三、Redis事务示例1： multi & exex示例2：discard放弃队列运行示例3：事务的错误处理示例4：事务的错误处理示例5：事务的watch示例5 ：unwatch四、Redis持久化1. RDB2. AOF五、总结1. 穿透2. 雪崩3. 热点key 一、Redis发布订阅 简介 Redis 发布订阅(pub/sub)是一种消息...
Redis进阶（发布订阅，PipeLine，持久化，内存淘汰）
长沙老码农
02-03 1733
目录 1、发布订阅 1.1 什么是发布订阅 1.2 客户端实例演示 1.3 Java API演示 1.4 Redis发布订阅和rabbitmq的区别 2、批量操作 2.1 普通模式与 PipeLine 模式 2.2 适用场景 2.3 源码解析 2.4 Pipelining的局限性 2.5 事务与 LUA Scripting 3、持久化 3.1 为什么需要持久化 3.2 持久化方式 3.3 文件同步方式 3.4 文件重写（压缩） 3.5 总结 4、内存淘汰 4.1 .
redis - 事物/乐观锁/发布订阅/持久化
ZT
07-06 148
事物/乐观锁 Redis 事务可以一次执行多个命令， 并且带有以下三个重要的保证： 批量操作在发送 EXEC 命令前被放入队列缓存。 收到 EXEC 命令后进入事务执行，事务中任意命令执行失败，其余的命令依然被执行。 在事务执行过程，其他客户端提交的命令请求不会插入到事务执行命令序列中。 一个事务从开始到执行会经历以下三个阶段： 开始事务。 命令入队。 执行事务。 单个 Redis 命令的执行是原子性的，但 Redis 没有在事务上增加任何维持原子性的机制，所以 Redis 事务的执行并不
redis基本类型和使用方法详解
09-08
此外，Redis 还提供了事务（Transaction）、发布订阅（Publish/Subscribe）、持久化、主从复制等高级特性。 总之，Redis 的基本类型和操作提供了灵活的数据存储和处理能力，使其成为许多应用场景的理想选择，如缓存...
redis键值对型数据库知识详解.zip
08-16
四、Redis持久化 1. RDB（Snapshotting）：定期保存当前数据库状态到磁盘，恢复时加载整个文件。 2. AOF（Append Only File）：记录每次写操作，重启时执行日志还原数据。 五、Redis事务 Redis支持事务，用户可以将...
Redis详解.docx
最新发布
09-05
Redis 还提供了一些额外的功能，例如事务（transaction）、发布/订阅（publish/subscribe）模式、持久化（RDB 和 AOF）、复制（replication）以及布隆过滤器（Bloom Filter）等。持久化机制确保即使服务器重启，数据...
redis的发布和订阅，事物，持久化（2）
sssyyyy7的博客
05-09 227
Redis发布和订阅 Redis 发布订阅(pub/sub)是一种消息通信模式： 发送者(pub)发送消息 订阅者(sub)接收消息 Redis 客户端可以订阅任意数量的频道 subscribe c1 c2 c3 订阅c1 c2 c3 publish c1 “hello redis” 向c1频道发布消息 psubscribe c* “c*” #订阅所有发送则是c开头的消息 发送消息...
Redis（3）—— 持久化、发布订阅
qq_44824574的博客
03-28 1335
持久化 Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘中，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化的功能。 1、RDB（Redis DataBase） 在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是Snapshot快照，它恢复时是将快照文 件直接读到内存中。 Redis会单独创建（fork）一个子进程来进程持久化，会先将数据写入到一个临时文件中，待持久化 过程都结束了，再用这个临时文件替换上一次持久化好的文件。整个过程中，主进程是不进行任何IO
Redis之事务、发布订阅与持久化
积跬步，至千里。
07-30 460
Redis事物Redis事物概述Redis事物实例Redis事务命令Redis持久化Redis持久化概述RDB持久化测试AOF持久化AOF与RDB区别 Redis事物概述 Redis事务可以一次执行多个命令 Redis事物的重要保证： 1.事务是一个单独的隔离操作： 事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。 2.事务是一个原子操作： 事务中的命令要么全部被执行，要么全部都不执行。 Redis事物的执行阶段 一个事务从开始到执行会经历以下三
Redis持久化、发布订阅、集群详解
weixin_52859229的博客
04-03 281
Redis的持久化方式之一RDB是通过保存数据库中的键值对来记录数据库的状态。而另一种持久化方式 AOF则是通过保存Redis服务器所执行的写命令来记录数据库状态。AOF以协议文本的方式，将所有对数据库进行写入的命令（及其参数）记录到 AOF 文件，以此达到记录数据库状态的目的。用日志的形式来记录每个操作，将redis执行过的所有的指令都记录下来(读操作不记录)，只许追加文件但不可以写文件，换言之，redis重启的话就根据日志文件的内容将写指令从前到后执行一次，已完成数据文件的。
【redis-基础】数据持久化 事务 发布订阅
alexliu2360的专栏
01-06 1201
1 数据持久化 1.1 RDB方式 1.1.1 配置 // 定时持久化规则 save 900 1 save 300 10 save 60 10000 # 默认值为yes，当启用了RDB且最后一次在后台保存数据失败，Redis是否停止接收数据： # yes代表可以继续写入数据；no代表不会写入成功，通知用户持久化出现错误 stop-writes-on-bgsave-error yes # 持久化的数据是否进行压缩 rdbcompression yes # 存储的快照是否进行CRC64算法的数据校验，如果希望获
Redis持久化以及Redis实现订阅发布
骑着蜗牛行天下
10-29 402
Redis持久化 面试和工作，持久化都是重点！ Redis是内存数据库，如果不将内存中的数据库状态保存到磁盘中，那么一旦服务器进程退出，服务器中的数据库状态也会消失。所以Redis提供了持久化功能！ RDB（Redis DataBase） 什么是RDB： 在主从复制中，rdb就是备用了，从机上面几乎不使用！ 在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。Redis会单独创建( fork ) - -个子进程来进行持久化,会先将数据写入
从零开始的Redis学习 | 3_Redis发布订阅，事务，持久化
庭前云落的博客
09-28 135
这是我之前写的： Jedis...
redis 发布和订阅 持久化 事务 缓存问题
weixin_48811255的博客
02-21 731
redis的发布订阅 使用数据类型lists 原理 可以有多个消费者和订阅者 订阅者：subscribe cla 命令 执行成功后 subscribe :表示成功订阅到响应 第二个元素：提供的频道 第三个参数代表订阅频道的数量 message：这是另一个客户端发出来的发布命令的结果 第二个元素：来源频道的名称 第三个参数：实际消息的内容 发布者:publish cla ‘hello world’(字符间有空格要加上引号，否则会报错) 对应发布频道的内容打不成功会返回频道有几个数据 匹配订阅：psub
Redis持久化详解：快照与AOF
"Redis是一个内存数据库系统，支持两种持久化机制——快照(Snapshotting)和AOF(Append-only file)。快照是默认的持久化方式，通过异步方式将内存中的数据dump到磁盘，可以根据配置在特定条件（如操作次数或时间间隔...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

拉霍拉卡

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

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

余额充值