概念

Redis是一个基于K-V的存储系统，数据存储在内存中，访问速度快。

适用场景

  • 对数据的高并发的读写
  • 海量数据的读写
  • 对数据的高扩展性

不适用场景

  • 需要事务的支持
  • 处理复杂关系的场景

总结：用不着SQL和用了SQL也不行的情况，考虑使用NoSQL

NoSQL

顾名思义，not only SQL,不仅仅是SQL,泛指非关系型数据库。

  • 不遵循SQL标准
  • 不支持ACID
  • 远超于常用SQL

NoSQL缓存：Redis、MongoDB等

数据类型

  • String
  • Hash
  • List
  • Set
  • ZSet

常用命令

1. 字符串String

  • redis的strin类型的数据结构为简单动态字符串，是可以修改的，采用预分配冗余空间的方式来减少内存的频繁分配。
  • 字符串长度小于1Mde ,扩容都是加倍现有空间，如果超过1M，扩容时只会多扩1M，最大长度为512M
  • set :添加键值对
  • get :根据K获取值
  • setnx :当数据库的K不存在时，才添加到数据库中
  • setxx :当数据库的K存在时，才添加到库中，与setnx相反
  • setex :设置超时秒数
  • setpx :设置超时毫秒数
  • append :将指定的V追加到目前K对应的值后面
  • strlen :返回对应的值得长度
  • incr :对应的值增加1
  • descr :对应的值减少1
  • incrby <步长>:对应的值+步长
  • descby <步长> :对应的值—步长
  • mset :同时设置多个K-V
  • mget :获取多个K对应的V
  • msetnx :同时设置多个K-V,仅当设置的所有K都不存在时，才会生效，否则都不生效
  • expire :设置过期时间
  • ttl :查看过期时间
  • getrange :获取指定范围的值，类似java中的subString()函数，begin和end都包含在内
  • getset :以旧换新，设置新值同时获取旧值

相关命令：String操作API

2. 列表List
单键多值：Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素到列表的头部（左边）或者尾部（右边）。它的底层实际是个双向链表，对两端的操作性能很高，通过索引下标的操作中间的节点性能会较差。

相关命令：List操作API

3. 集合Set

  • Redis的Set是string类型的无序集合。集合成员是唯一的，这就意味着集合中不能出现重复的数据。
  • Redis 中集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。
  • 集合中最大的成员数为 232 - 1 (4294967295,每个集合可存储40多亿个成员)。

相关命令：Set操作API

4. 哈希hash

  • Redis hash 是一个string类型的field和value的映射表，hash特别适合用于存储对象。
  • Redis 中每个 hash 可以存储 232 - 1 键值对（40多亿）。

相关命令：hash操作API

5. 有序集合zset(sorted set)

  • Redis 有序集合和集合一样也是string类型元素的集合,且不允许重复的成员。
  • 不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。
  • 有序集合的成员是唯一的,但分数(score)却可以重复。
  • 集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。 集合中最大的成员数为 232 - 1 (4294967295, 每个集合可存储40多亿个成员)。

相关命令：zset操作API

6. Bitmaps

  • Redis 提供了 Bitmaps 这个 “数据类型” 可以实现对位的操作：
  • Bitmaps 本身不是一种数据类型， 实际上它就是字符串（key-value） ， 但是它可以对字符串的位进行操作。
  • Bitmaps 单独提供了一套命令， 所以在 Redis 中使用 Bitmaps 和使用字符串的方法不太相同。 可以把 Bitmaps 想象成一个以位为单位的数组， 数组的每个单元只能存储 0 和 1， 数组的下标在 Bitmaps 中叫做偏移量。

7. HyperLogLog
Redis 在 2.8.9 版本添加了 HyperLogLog 结构。

  • Redis HyperLogLog 是用来做基数统计的算法，HyperLogLog 的优点是，在输入元素的数量或者体积非常非常大时，计算基数所需的空间总是固定 的、并且是很小的。
  • 在 Redis 里面，每个 HyperLogLog 键只需要花费 12 KB 内存，就可以计算接近 2^64 个不同元素的基 数。这和计算基数时，元素越多耗费内存就越多的集合形成鲜明对比。但是，因为 HyperLogLog 只会根据输入元素来计算基数，而不会储存输入元素本身，所以 HyperLogLog 不能像集合那样，返回输入的各个元素。

什么是基数?
比如数据集 {1, 3, 5, 7, 5, 7, 8}， 那么这个数据集的基数集为 {1, 3, 5 ,7, 8}, 基数(不重复元素)为5。 基数估计就是在误差可接受的范围内，快速计算基数。
相关命令：HyperLogLog操作API

Redis 的发布和订阅

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

当给这个频道发布消息后，消息就会发送给订阅的客户端：
image-20210618211401669.png
订阅一个通道：subcribe [channel] [channel]
微信截图_20230224223322.png
向通道发送消息：publish [channel] [message]
微信截图_20230224223410.png
订阅窗口即时收到消息
微信截图_20230224223419.png

Redis 事务、锁机制秒杀

  • Redis 事务定义

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

  • Multi、Exec、discard

Redis 事务中有 Multi、Exec 和 discard 三个指令，在 Redis 中，从输入 Multi 命令开始，输入的命令都会依次进入命令队列中，但不会执行，直到输入 Exec 后，Redis 会将之前的命令队列中的命令依次执行。而组队的过程中可以通过 discard 来放弃组队
image-20210619093306171.png
全部成功的情况：
成功提交.png
命令错误导致事务回滚：
错误命令提交失败.png
运行是的错误，不影响其他指令：
运行的错误不影响.png
事务的错误处理

  • 组队中某个命令出现了报告错误，执行时整个的所有队列都会被取消。

image-20210619094058710.png

  • 如果执行阶段某个命令报出了错误，则只有报错的命令不会被执行，而其他的命令都会执行，不会回滚。

image-20210619094201203.png

数据一致性问题

Redis是通过乐观锁解决数据一致性的问题。

  • watch [key1] [key2]

在执行 multi 之前，先执行 watch key1 [key2]，可以监视一个 (或多个) key ，如果在事务执行之前这个 (或这些) key 被其他命令所改动，那么事务将被打断。

  • unwatch

取消 WATCH 命令对所有 key 的监视。如果在执行 WATCH 命令之后，EXEC 命令或 DISCARD 命令先被执行了的话，那么就不需要再执行 UNWATCH 了。直接上案列：
微信截图_20230224230202.png

Redis 事务三特性

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

Redis 持久化

Redis 提供了 2 个不同形式的持久化方式：

  • RDB（Redis DataBase）redis默认的持久化方式。
  • AOF（Append Of File）

RDB（Redis DataBase）

在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的 Snapshot 快照，它恢复时是将快照文件直接读到内存里。

如何执行备份的

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

fork

Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。
在 Linux 程序中，fork () 会产生一个和父进程完全相同的子进程，但子进程在此后多会 exec 系统调用，出于效率考虑，Linux 中引入了 “写时复制技术”。
一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程
fork.png

dump.rdb 文件

  • 在 redis.conf 中配置文件名称，默认为 dump.rdb。
  • rdb 文件的保存路径，也可以修改。默认为 Redis 启动时命令行所在的目录下 “dir ./”

如何触发 RDB 快照；保持策略

  • 通过redis.conf 配置文件：

image-20210619103558260.png

  • 命令 save VS bgsave

    • save ：save 时只管保存，其它不管，全部阻塞。手动保存，不建议。
    • bgsave：Redis 会在后台异步进行快照操作， 快照同时还可以响应客户端请求。
    • 可以通过 lastsave 命令获取最后一次成功执行快照的时间。
  • flushall 命令
    执行 flushall 命令，也会产生 dump.rdb 文件，但里面是空的，无意义

优点：

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

缺点：

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

如何停止：
动态停止 RDB：redis-cli config set save “”#save 后给空值，表示禁用保存策略。

总结：

rdb总结.png

AOF（Append Of File）

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

AOF 持久化流程

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

aof.png

AOF 默认不开启

可以在 redis.conf 中配置文件名称默认为 appendonly.aof 文件中开启，AOF 文件的保存路径，同 RDB 的路径一致。

AOF 和 RDB 同时开启，redis 听谁的？

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

AOF 启动、修复、恢复

  • AOF 的备份机制和性能虽然和 RDB 不同，但是备份和恢复的操作同 RDB 一样，都是拷贝备份文件，需要恢复时再拷贝到 Redis 工作目录下，启动系统即加载。

  • 正常恢复

    • 修改默认的 appendonly no，改为 yes。
    • 将有数据的 aof 文件复制一份保存到对应目录 (查看目录：config get dir)。
    • 恢复：重启 redis 然后重新加载。

  • 异常恢复

    • 修改默认的 appendonly no，改为 yes。
    • 如遇到 AOF 文件损坏，通过 /usr/local/bin/ redis-check-aof–fix appendonly.aof 进行恢复。
    • 备份被写坏的 AOF 文件。
    • 恢复：重启 redis，然后重新加载。

AOF 同步频率设置

  • appendfsync always：始终同步，每次 Redis 的写入都会立刻记入日志；性能较差但数据完整性比较好。
  • appendfsync everysec：每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。
  • appendfsync no：redis 不主动进行同步，把同步时机交给操作系统。

Rewrite 压缩

Rewrite 压缩是什么

AOF 采用文件追加方式，文件会越来越大为避免出现此种情况，新增了重写机制，当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集，可以使用命令 bgrewriteaof。

重写原理，如何实现重写

AOF 文件持续增长而过大时，会 fork 出一条新进程来将文件重写 (也是先写临时文件最后再 rename)，redis4.0 版本后的重写，是指把 rdb 的快照，以二进制的形式附在新的 aof 头部，作为已有的历史数据，替换掉原来的流水账操作。

no-appendfsync-on-rewrite：

  • 如果 no-appendfsync-on-rewrite=yes ，不写入aof文件只写入缓存，用户请求不会阻塞，但是在这段时间如果宕机会丢失这段时间的缓存数据。（降低数据安全性，提高性能）
  • 如果no-appendfsync-on-rewrite=no，还是会把数据往磁盘里刷，但是遇到重写操作，可能会发生阻塞。（数据安全，但是性能降低）

触发机制，何时重写

Redis 会记录上次重写时的 AOF 大小，默认配置是当 AOF 文件大小是上次 rewrite 后大小的一倍且文件大于 64M 时触发。
重写虽然可以节约大量磁盘空间，减少恢复时间。但是每次重写还是有一定的负担的，因此设定 Redis 要满足一定条件才会进行重写。

  • auto-aof-rewrite-percentage：设置重写的基准值，文件达到 100% 时开始重写（文件是原来重写后文件的 2
    倍时触发）。
  • auto-aof-rewrite-min-size：设置重写的基准值，最小文件 64MB。达到这个值开始重写。
  • 系统载入时或者上次重写完毕时，Redis 会记录此时 AOF 大小，设为 base_size,
  • 如果 Redis 的 AOF 当前大小 >= base_size +base_size*100% (默认) 且当前大小 >=64mb
    (默认) 的情况下，Redis 会对 AOF 进行重写。
  • 例如：文件达到 70MB 开始重写，降到 50MB，下次什么时候开始重写？100MB

重写流程

  1. bgrewriteaof 触发重写，判断是否当前有 bgsave 或 bgrewriteaof在运行，如果有，则等待该命令结束后再继续执行；
  2. 主进程 fork 出子进程执行重写操作，保证主进程不会阻塞；
  3. 子进程遍历 redis 内存中数据到临时文件，客户端的写请求同时写入 aof_buf 缓冲区和 aof_rewrite_buf重写缓冲区，保证原 AOF 文件完整以及新 AOF 文件生成期间的新的数据修改动作不会丢失；
  4. 子进程写完新的 AOF 文件后，向主进程发信号，父进程更新统计信息。主进程把 aof_rewrite_buf 中的数据写入到新的 AOF文件；
  5. 使用新的 AOF 文件覆盖旧的 AOF 文件，完成 AOF 重写。

aof重写.png

优点：

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

缺点：

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

总结

aof总结.png

选择哪种备份方式

官方推荐两个都启用：

  • 如果对数据不敏感，可以选单独用 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% 大小时重写可以改到适当的数值。

Redis 主从复制

最后修改：2023 年 02 月 28 日
© 允许规范转载
如果觉得我的文章对你有用，请随意赞赏