学习笔记-Redis（二）

最新推荐文章于 2024-07-07 17:47:43 发布

Bite.Z

最新推荐文章于 2024-07-07 17:47:43 发布

阅读量195

点赞数

分类专栏： JAVA学习笔记文章标签： redis 学习数据库

本文链接：https://blog.csdn.net/Zk_ZhangK/article/details/125971466

版权

JAVA学习笔记专栏收录该内容

12 篇文章 0 订阅

订阅专栏

上文提到了Redis的相关概述以及其常见的数据类型，这节将介绍Redis的发布和订阅、事务机制、持久化操作

一.Redis的发布和订阅

什么是发布和订阅？

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

发布订阅过程

客户端可以订阅频道：

发送者可以将消息发布给频道，消息再由频道发送给订阅该频道的客户端：

二.Redis的事务机制

与Mysql的事务不同，Redis 事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。其作用是串联多个命令防止别的命令插队。

1.Redis事务流程

Redis 事务中有 Multi、Exec 和 discard 三个指令，在 Redis 中，从输入 Multi 命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入 Exec 后，Redis 会将之前的命令队列中的命令依次执行。而组队的过程中可以通过 discard 来放弃组队。

两种错误情况：

（1）当组队的过程中，某个指令出现了错误，执行时整个的所有队列都会被取消

（2）当执行的过程中，某个指令出现了错误，执行时会只有报错的命令不会被执行，其他指令都会正常执行，不会rollback

2.Redis事务三特性

区别于Mysql事务的四大特性（ACID）,Redis的事务具有一下三大特性：

单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
没有隔离级别的概念：队列中的命令没有提交之前都不会实际被执行，因为事务提交前任何指令都不会被实际执行。
不保证原子性：事务中如果有一条命令执行失败，其后的命令仍然会被执行，没有回滚。

3.LUA脚本

将复杂的或者多步的 redis 操作，写为一个脚本，一次提交给 redis 执行，减少反复连接 redis 的次数，提升性能。
LUA 脚本是类似 redis 事务，有一定的原子性，不会被其他命令插队，可以完成一些 redis 事务性的操作。
但是注意 redis 的 lua 脚本功能，只有在 Redis 2.6 以上的版本才可以使用。
利用 lua 脚本淘汰用户，解决超卖问题，redis 2.6 版本以后，通过 lua 脚本解决争抢问题，实际上是 redis 利用其单线程的特性，用任务队列的方式解决多任务并发问题。

在Redis应用于分布式锁中，要保证加锁解锁的原子性，而解锁操作一般都是用的LUA脚本来执行，保证解锁的原子性。

三.Redis持久化

先前有提到过Redis的特点，虽然Redis是存入内存中的，以提高查询性能，但同时Redis也可以将数据写入磁盘，该过程则叫持久化，这样当系统关闭时，数据也能得以保存。而Redis的持久化有两种方式:RDB（Redis DataBase）和AOF（Append Of File）。

1.RDB

(1)概述

在指定的时间间隔内将内存中的数据集快照写入磁盘，也就是行话讲的 Snapshot 快照，它恢复时是将快照文件直接读到内存里。在Linux系统中引入了“写时复用技术”

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

（2）RDB持久化流程

在指令上有bgsave和save的区别：

save ：save 时只管保存，其它不管，全部阻塞。手动保存，不建议。

bgsave：Redis 会在后台异步进行快照操作，快照同时还可以响应客户端请求。

（3）优缺点

优势

适合大规模的数据恢复
对数据完整性和一致性要求不高更适合使用
节省磁盘空间
恢复速度快

缺点

Fork 的时候，内存中的数据被克隆了一份，大致 2 倍的膨胀性需要考虑。
虽然 Redis 在 fork 时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能。
在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。

2.AOF

（1）概述

以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来 (读操作不记录)， 只许追加文件但不可以改写文件，redis 启动之初会读取该文件重新构建数据，换言之，redis 重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

（2）AOF持久化流程

客户端的请求写命令会被 append 追加到 AOF 缓冲区内；
AOF 缓冲区根据 AOF 持久化策略 [always,everysec,no] 将操作 sync 同步到磁盘的 AOF 文件中；
AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 rewrite 重写，压缩 AOF 文件容量；
Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。

AOF 和 RDB 同时开启，系统默认取 AOF 的数据（数据不会存在丢失）。

（3）优缺点

优点

备份机制更稳健，丢失数据概率更低。
可读的日志文本，通过操作 AOF 稳健，可以处理误操作。（数据恢复）

缺点

比起 RDB 占用更多的磁盘空间。
恢复备份速度要慢。
每次读写都同步的话，有一定的性能压力。
存在个别 Bug，造成恢复失败。

3.总结

用哪个好？
官方推荐两个都启用：

如果对数据不敏感，可以选单独用 RDB。
不建议单独用 AOF，因为可能会出现 Bug。
如果只是做纯内存缓存，可以都不用。

官网建议

RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储。
AOF 持久化方式记录每次对服务器写的操作，当服务器重启的时候会重新执行这些命令来恢复原始的数据，AOF 命令以 redis 协议追加保存每次写的操作到文件末尾。
Redis 还能对 AOF 文件进行后台重写，使得 AOF 文件的体积不至于过大。
只做缓存：如果你只希望你的数据在服务器运行的时候存在，你也可以不使用任何持久化方式。
同时开启两种持久化方式：在这种情况下，当 redis 重启的时候会优先载入 AOF 文件来恢复原始的数据，因为在通常情况下 AOF 文件保存的数据集要比 RDB 文件保存的数据集要完整。

RDB 的数据不实时，同时使用两者时服务器重启也只会找 AOF 文件。那要不要只使用 AOF 呢？

建议不要，因为 RDB 更适合用于备份数据库 (AOF 在不断变化不好备份)，快速重启，而且不会有 AOF 可能潜在的 bug，留着作为一个万一的手段。

性能建议：

因为 RDB 文件只用作后备用途，建议只在 Slave 上持久化 RDB 文件，而且只要 15 分钟备份一次就够了，只保留 save 9001 这条规则。
如果使用 AOF，好处是在最恶劣情况下也只会丢失不超过两秒数据，启动脚本较简单，只 load 自己的 AOF 文件就可以了。
aof 代价：一是带来了持续的 IO，二是 AOF rewrite 的最后，将 rewrite 过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。
只要硬盘许可，应该尽量减少 AOF rewrite 的频率，AOF 重写的基础大小默认值 64M 太小了，可以设到 5G 以上。默认超过原大小 100% 大小时重写可以改到适当的数值。