Redis学习笔记2

ruoxiuqaq

已于 2024-08-07 17:21:37 修改

阅读量493

点赞数 22

分类专栏：学习笔记文章标签： redis 学习笔记

于 2024-08-07 09:35:38 首次发布

本文链接：https://blog.csdn.net/ruoxiuqaq/article/details/140971656

版权

学习笔记专栏收录该内容

17 篇文章 0 订阅

订阅专栏

一、Redis的常用场景

基于Redis实现登录

发送登录验证，以手机号为key，value为验证码，保存在redis中
根据手机号寻找用户，若用户存在，创建token为key，用户信息为value，保存在redis中
校验用户登录状态，在用户的浏览器或客户端中存储这个token，每次请求时都会携带token
在后端拦截器中，根据token查询用户状态，若有用户信息，则表示用户已登录

基于Redis实现消息队列

使用list实现

利用redis的list数据结构的leftpush作进队列，rightpop作出列

缺点：缺乏消息确认机制，不支持持久化，不适合高并发，不适合多订阅者

pub/sub模式

缺点：不支持持久化，不能防止重复消费

基于stream实现

实现内容：消息ID的序列化生成，消息遍历，消息的阻塞和非阻塞读取，消息的分组消费，未完成消息的处理，消息队列监控

常用命令：XADD生产消息，XREAD消费消息，XGROUP创建消费者组，XREADGROUP分组消费消息，XPENDING记录未完成消息，XCLAIM消息转移，XDEL坏消息，死信消息，XACK消息确认，XINFO消息监控

二、redis的持久化

RDB

RDB是在指定的时间间隔内生成一个快照，将其保存到磁盘上的一个文件中，这个快照文件包含可redis在生成快照时的所有数据，因此可以完整的恢复redis的数据状态，RDB持久化的方式适合于备份数据或者进行灾难恢复

触发方式：

1、手动触发RDB持久化分别对应save和bgsave命令

SAVE 命令：执行SAVE命令会导致当前Redis服务器进程被阻塞，直到RDB快照过程完成为止。在RDB快照生成期间，Redis服务器无法处理其他请求，因此对于内存较大的实例来说，可能会造成长时间的阻塞。由于阻塞时间较长且影响Redis服务器的正常响应，SAVE命令在实际应用中基本不被采用。
BGSAVE 命令：执行BGSAVE命令会导致Redis进程执行fork操作，创建一个子进程来负责RDB持久化过程。持久化过程由子进程完成，完成后子进程自动结束，而主进程不会被阻塞。因此，阻塞只会发生在fork阶段，通常只会持续很短的时间。由于不会阻塞主进程，BGSAVE命令更为常用。在Redis内部，所有涉及RDB的操作都采用类似BGSAVE的方式，以确保Redis服务器的高性能和稳定性。

2、自动触发

使用 save 配置：通过在 Redis 的配置文件中设置 save 参数，如 "save m n"，表示在 m 秒内数据集发生了 n 次修改时，Redis 会自动触发 RDB 持久化。这样可以根据实际需求设置自动触发持久化的条件，以满足不同的业务需求。
从节点全量复制操作：当从节点进行全量复制操作时，主节点会自动执行 RDB 持久化，并将生成的 RDB 文件内容发送给从节点。这样可以确保从节点在复制完成后拥有与主节点相同的数据快照，保证数据的一致性和完整性。
执行 shutdown 命令关闭 Redis：当执行 shutdown 命令关闭 Redis 服务器时，Redis 会在关闭过程中执行 RDB 持久化操作，将当前数据集保存到硬盘上的 RDB 文件中。这样可以确保在重启时能够使用之前持久化的数据来恢复 Redis 服务器的状态，避免数据丢失和损坏。

优缺点

优点：

紧凑的二进制文件格式：RDB 是 Redis 数据在某个时间点上的紧凑压缩二进制文件格式。这种格式非常适用于备份和全量复制场景。通过定期执行 bgsave 命令生成 RDB 文件，可以将其复制到远程机器或文件系统（如 HDFS），用于灾备和数据恢复。
备份和全量复制：由于 RDB 文件包含了整个数据集的快照，它非常适用于备份和全量复制的场景。管理员可以定期执行 bgsave 命令来生成 RDB 文件，并将其复制到远程机器或者文件系统中，以供灾备和数据恢复之用。
快速的数据恢复速度：与 AOF 持久化方式相比，通过加载 RDB 文件来恢复数据通常更快。这是因为 RDB 文件是一个数据快照，Redis 只需将其加载到内存中，而不需要逐条执行命令回放的过程。
离线生成：RDB 文件的生成过程是离线的，不会对 Redis 实例的性能产生明显的影响。这意味着即使在生成 RDB 文件的过程中，Redis 服务仍然可以继续提供服务，不会中断用户的请求。

缺点：

非实时持久化：RDB 持久化方式无法实现实时持久化或秒级持久化，因为执行 bgsave 命令需要进行 fork 操作来创建子进程。这是一个相对重量级的操作，可能会影响到 Redis 服务器的响应时间，特别是对于大规模数据集和高并发请求的情况下。
兼容性问题：RDB 文件的格式取决于 Redis 版本，并且随着 Redis 版本的演进，可能会出现多个不同的 RDB 文件版本。这可能会导致兼容性问题，尤其是在升级 Redis 版本或者迁移数据时。因此，在进行版本升级或者数据迁移时，需要特别小心确保 RDB 文件的兼容性。
数据丢失风险：由于 RDB 文件是在内存快照的基础上生成的，如果在 bgsave 命令执行期间出现故障或者系统崩溃，可能会导致部分数据丢失。尽管 Redis 会尽量保证数据的一致性和完整性，但仍然存在一定的风险。
增量备份困难：RDB 文件只能提供全量备份，无法实现增量备份。如果需要增量备份，就需要借助其他机制或者技术来实现，增加了管理和维护的复杂度。

AOF

将每次写操作都记录到一个追加日志文件中，这个日志文件记录了redis服务器接收到的所有写命令，可以用来重放这些写操作，从而恢复数据。AOF持久化比RDB更安全，因为它可以提供更精确的恢复点，但相对而言，AOF文件可能会比较大

持久化方式

引入AOF（Append Only File）之后，虽然需要同时写入内存和硬盘，但是AOF机制并没有直接影响到Redis处理请求的速度，它不会直接将数据写入硬盘，而是先写入到内存中的缓冲区。只有在缓冲区中的数据积累到一定程度时，Redis才会将数据一次性地写入硬盘。这样做的好处是减少了频繁写入硬盘的次数，从而反而通过一些优化手段提高了性能。

缓冲区写入： AOF机制会将新的写操作先写入到内存中的缓冲区，而不是立即写入硬盘。这样做的好处是可以快速响应客户端的请求，而不必等待数据写入硬盘完成。
延迟写入： Redis会定期将缓冲区中的数据批量写入硬盘，而不是每次都立即写入。通过积累一定量的数据并一次性地写入硬盘，可以减少硬盘写入的频率，提高性能。
顺序写入优化： AOF机制将新的写操作追加到AOF文件的末尾，这属于顺序写入。与随机写入相比，顺序写入的性能更好，因为硬盘进行顺序读写的速度比随机读写要快得多。这样做可以降低写入硬盘的次数，并进一步提高性能。

工作流程

AOF 的工作流程主要包括命令写入（append）、文件同步（sync）、文件重写（rewrite）、重启加载（load）等步骤：

命令写入（append）：所有的写入命令都会被追加到 AOF 缓冲区中，而不是直接写入到 AOF 文件中。这样可以提高写入操作的性能，因为写入到缓冲区中的数据可以一次性批量写入到磁盘，减少了频繁的磁盘写入操作。
文件同步（sync）：根据配置的同步策略，AOF 缓冲区中的数据会定期或者根据条件触发同步到硬盘上的 AOF 文件中。同步操作可以使用 fsync 或者 fdatasync 等系统调用来保证数据的持久化，以防止数据丢失。
文件重写（rewrite）：随着时间的推移，AOF 文件会变得越来越大。为了减少文件的体积并优化性能，Redis 会定期执行 AOF 文件重写操作。在重写过程中，Redis 会分析内存中的数据并将其转换为命令序列，然后写入到新的 AOF 文件中。新的 AOF 文件通常比原始文件体积更小，并且不包含冗余的命令，从而达到压缩的目的。
重启加载（load）：当 Redis 服务器启动时，可以加载 AOF 文件来进行数据恢复。Redis 会按照 AOF 文件中的命令顺序重新执行命令，从而将数据恢复到最新状态。这种方式确保了数据的持久性，并且在服务重启后可以快速恢复到之前的状态。

三、Redis事务

redis事务与mysql事务不同点

弱化的原子性：Redis的事务并没有像传统数据库中那样的原子性。在Redis中，事务中的命令会依次被执行，但并不会在事务执行过程中进行回滚。如果在事务执行过程中出现了错误，Redis会继续执行后续的命令，而不会回滚到事务开始前的状态。这意味着Redis的事务只能保证命令在事务中的顺序执行，而不能保证整个事务的原子性。
不保证一致性：在Redis中，一致性是指事务运行前和运行后的状态是合理有效的。虽然Redis的事务可以将一系列操作打包执行，但是并不涉及约束或回滚机制来保证数据的一致性。因此，在Redis中，一致性主要体现在事务执行前和执行后的状态是符合预期的，而不会出现中间的非法状态。
不需要隔离性：由于Redis是单线程处理请求的，因此不存在并发执行事务的情况。在Redis中，并没有像传统数据库中那样的隔离级别概念。因为Redis在处理请求时是单线程顺序执行的，所以不需要考虑多个事务之间的隔离性问题。
不需要持久性：Redis的事务是保存在内存中的，并不涉及持久化机制。Redis服务器是否开启持久化与事务本身无关，这完全由redis-server自身的配置决定。因此，即使发生服务器崩溃或重启，事务中的命令也不会被持久化到磁盘上，而是会随着Redis服务器的重启而丢失。

Redis事务的适用场景

原子性操作： Redis事务适用于一系列操作需要作为一个整体执行，且可以容忍部分操作失败的场景。尽管Redis事务不能支持全部回滚，但仍然可以确保一组操作要么全部成功执行，要么全部失败。
批量操作：如果需要一次性执行多个操作，并希望减少网络通信的开销，可以使用Redis事务来打包多个操作。这样可以减少网络延迟，提高性能。
乐观锁控制：在需要乐观锁控制的场景下，可以使用Redis事务来实现乐观锁。通过在事务中对数据进行检查和更新，可以避免并发冲突，确保数据的一致性。
队列操作：当需要对队列进行一系列操作，如入队、出队、查看队列长度等，可以使用Redis事务来确保操作的原子性和一致性。
计数器操作：当需要对计数器进行增减操作，并确保操作的原子性和一致性时，可以使用Redis事务来执行计数器操作。