Redis基础教程

关注

原创最新推荐文章于 2026-04-30 09:48:59 发布 699 阅读 AI 写同款· GEO 优化 ›

Basilisk库教程要在仿真中执行模块，其调度由Basilisk的[Process]和[Task]容器控制。BSK[Task]包含一系列模块，这些模块都以相同的更新频率执行。一个[Process]本质上是一个任务组，可以包含多个相关的任务。例如，在多星仿真中，你可以为每颗卫星创建一个[Process]，以便将相关任务和嵌入式模块有序地组织起来。下图展示了一个示例布局，其中bskSat卫星的动力学被添加到与飞行软件（FSW）算法分开的进程中，这些算法在该卫星上执行。在每个进程中，设置了若干任务，这些任务以指定的频率进行评估。阅读详情

今天我们来分享 Redis 相关的知识，文章有点长，一定要看到最后呦！

前言

Redis 在当今的计算机行业，可以说是使用的最为广泛的内存数据库，几乎所有的后端技术面试都会涉及到 Redis 相关的知识，正所谓知己知彼，百战百胜。今天咱们就来盘一盘 Redis，从基础面试题到各种特性、功能，做一次一网打尽式的服务！

什么是 Redis

Redis 是用 C 语言开发的一个开源的高性能键值对（key-value）数据库。通常建议在 Linux 上运行，它通过提供多种键值数据类型来适应不同场景下的存储需求，数据存储在内存中，也可持久化到磁盘中，目前为止 Redis 支持的键值数据类型如下：

字符串类型
散列类型
列表类型
集合类型
有序集合类型

Redis 特色

Redis 是用 C 语言写的开源项目，又由于数据都在内存中，所以读写速度非常快

Redis 所有数据保存在内存中，对数据的更新会异步地保存到磁盘上，这样可以做到断电不丢失数据

Redis 主从复制可以实现高可用和分布式

Redis 数据结构

字符串

String 是 Redis 当中最为基本的数据类型，最大512M，是二进制安全的

Redis 的字符串是动态字符串，是可以修改的，内部结构实现上类似于 Java 的 ArrayList，采用预分配冗余空间的方式来减少内存的频繁分配，内存为当前字符串实际分配的空间，一般要高于实际字符串长度。当字符串长度小于 1M 时，扩容都是加倍现有的空间，如果超过 1M，扩容时一次只会多扩 1M 的空间

使用场景：记录用户页面访问量、缓存基本数据、分布式 Id 生成器

散列

Redis 当中的 Hash 相当于 Java 的 HashMap，无序字典，内部实现是用数组+链表，第一维的数组出现碰撞，则存到链表里面去。Rehash 的时候，为了不阻塞服务，采用的是渐进式的 Rehash，保留2个 Hash，逐渐在指令执行或者定时任务中，将数据从老的 Hash 迁移到新的 Hash

使用场景：购物车、频繁变化的属性

列表

Redis 的列表按照插入顺序排序，相当于 Java 语言里面的 LinkedList，注意它是链表而不是数组。这意味着 list 的插入和删除操作非常快，时间复杂度为 O(1)，但是索引定位很慢，时间复杂度为O(n)。当列表弹出了最后一个元素之后，该数据结构自动被删除，内存被回收

Redis 的列表结构常用来做异步队列使用，将需要延后处理的任务结构体序列化成字符串塞进 Redis 的列表，另一个线程从这个列表中轮询数据进行处理

列表不同进出栈的方式，产生的不同数据结构

LPUSH+LPOP = 栈
LPUSH+RPOP = 队列
LPUSH+ LTRIM = 固定数量的列表
LPUSH +BRPOP = 消息队列

使用场景：异步队列

无序集合

set 相当于 Java 的 HashSet，无序的键值对，不过其值都是NULL，键不可以重复。数据量较少且是整数的时候用有序数组，较大的时候采用散列表

应用场景：标签、社交、随机数

有序集合

zset 可能是 Redis 提供的最为特色的数据结构，它类似于 Java 的 SortedSet 和 HashMap 的结合体，一方面它是一个 set，保证了内部 value 的唯一性，另一方面它可以给每个 value 赋予一个 score，代表这个 value 的排序权重。

它的内部实现用的是一种叫「跳跃列表」的数据结构，之所以「跳跃」，是因为内部的元素可能「身兼数职」

一个元素，同时处于 L0、L1 和 L2 层，可以快速在不同层次之间进行「跳跃」，定位插入点时，先在顶层进行定位，然后下潜到下一级定位，一直下潜到最底层找到合适的位置，将新元素插进去

应用场景：value 为粉丝 ID，score 是关注时间，可以按照关注时间顺序给出粉丝 ID；value 是学生 ID，score 是其分数，可以按照分数排序

Redis 持久化

Redis 提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）

RDB，简而言之，就是在不同的时间点，将 Redis 存储的数据生成快照并存储到磁盘等介质上

AOF，则是换了一个角度来实现持久化，那就是将 Redis 执行过的所有写指令记录下来，在下次 Redis 重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了

其实 RDB 和 AOF 两种方式也可以同时使用，在这种情况下，如果 Redis 重启的话，则会优先采用 AOF 方式来进行数据恢复，这是因为 AOF 方式的数据恢复完整度更高

AOF 有一个配置属性 sync，就是用来同步命令到磁盘的，如果我们对于 Redis 的性能要求不高，则可以在每条写指令时都 sync 一下磁盘，这样即使在突然断电的情况下，也能保证数据的最小丢失率

RDB

RDB 是将 Redis 某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法

Redis 在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的

对于 RDB 方式，Redis 会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何 IO 操作的，这样就确保了 Redis 极高的性能，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效

AOF

AOF，英文是 Append Only File，即只允许追加不允许改写的文件

如前面介绍的，AOF 方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单

默认的 AOF 持久化策略是每秒钟 fsync 一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，Redis 仍然可以保持很好的处理性能，即使 Redis 故障，也只会丢失最近1秒钟的数据

RDB 与 AOF 比较

Redis 主从

Redis 是支持主从同步的，而且也支持一主多从以及多级从结构

主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的 sort 就可以由从服务器来承担

Redis 的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低 Redis 的处理性能

主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能

在主从架构中，从服务器通常被设置为只读模式，这样可以避免从服务器的数据被误修改。但是从服务器仍然可以接受 CONFIG 等指令，所以还是不应该将从服务器直接暴露到不安全的网络环境中

旧版复制功能

Redis 的复制功能分为同步（sync）和命令传播（command propagate）两个操作：

同步操作用于将从服务器的数据库状态更新至主服务器当前所处的数据库状态
命令传播操作则用于在主服务器的数据库状态被修改，导致主从服务器的数据库状态出现不一致时，让主从服务器的数据库重新回到一致状态

同步过程

当客户端向从服务器发送 SLAVEOF 命令，要求从服务器复制主服务器时，从服务器首先需要执行同步操作，也就是将从服务器的数据库状态更新至主服务器当前所处的数据库状态

从服务器对主服务器的同步操作需要通过向主服务器发送 SYNC 命令来完成，以下是 SYNC 命令的执行步骤：

1）从服务器向主服务器发送 SYNC 命令
2）收到 SYNC 命令的主服务器执行 BGSAVE 命令，在后台生成一个 RDB 文件，并使用一个缓冲区记录从现在开始执行的所有写命令
3）当主服务器的 BGSAVE 命令执行完毕时，主服务器会将 BGSAVE 命令生成的 RDB 文件发送给从服务器，从服务器接收并载入这个 RDB 文件，将自己的数据库状态更新至主服务器执行 BGSAVE 命令时的数据库状态
4）主服务器将记录在缓冲区里面的所有写命令发送给从服务器，从服务器执行这些写命令，将自己的数据库状态更新至主服务器数据库当前所处的状态

缺点

这种复制功能，虽然可以很好的完成主备之间的数据同步，但是效率确实非常低的

每次执行 SYNC 命令，主从服务器需要执行以下动作：

1）主服务器需要执行 BGSAVE 命令来生成 RDB 文件，这个生成操作会耗费主服务器大量的 CPU、内存和磁盘 I/O 资源
2）主服务器需要将自己生成的 RDB 文件发送给从服务器，这个发送操作会耗费主从服务器大量的网络资源（带宽和流量），并对主服务器响应命令请求的时间产生影响
3）接收到 RDB 文件的从服务器需要载入主服务器发来的 RDB文件，并且在载入期间，从服务器会因为阻塞而没办法处理命令请求
4）BGSAVE 命令产生的 RDB 文件是主服务器锁包含的所有数据，这是一个全量过程

因为 SYNC 命令是一个如此耗费资源的操作，所以 Redis 有必要保证在真正有需要时才执行 SYNC 命令

新版复制功能

为了解决旧版本复制功能的低效问题，Redis 从2.8版本开始，使用 PSYNC 命令代替 SYNC 命令来执行复制时的同步操作

PSYNC 命令具有完整重同步（full resynchronization）和部分重同步（partial resynchronization）两种模式：

完整重同步用于处理初次复制情况：完整重同步的执行步骤SYN命令的执行步骤基本一样，它们都是通过让主服务器创建并发RD文件，以及向从服务器发送保存在缓冲区里面的写命令来进行同步
部分重同步则用于处理断线后重复制情况：当从服务器在断线后重新连接主服务器时，如果条件允许，主服务器可以将主从服务器连接断开期间执行的写命令发送给从服务器，从服务器只要接收并执行这些写命令，就可以将数据库更新至主服务器当前所处的状态

PSYNC 命令的部分重同步模式解决了旧版复制功能在处理断线后重复制时出现的低效情况，即采用增量同步的形式，大大节省了服务器资源

哨兵与集群

Redis Sentinal 主要用于高可用，在 master 宕机时会自动将 slave 提升为 master，继续提供服务

Redis Cluster 则侧重于扩展性，在单个 Redis 内存不足时，使用 Cluster 进行分片存储

Redis Sentinal

Sentinel（哨岗、哨兵）是 Redis 的高可用性（high availability）解决方案：由一个或多个 Sentinel 实例组成的 Sentinel 系统可以监视任意多个主服务器，以及这些主服务器属下的所有从服务器，并在被监视的主服务器进入下线状态时，自动将下线主服务器属下的某个从服务器升级为新的主服务器，然后由新的主服务器代替已下线的主服务器继续处理命令请求

初始状态下，Server1 为主服务器，其余为从服务器

假设这时，主服务器 Server1 进入下线状态，那么从服务器 Server2、Server3、Server4 对主服务器的复制操作将被中止，并且 Sentinel 系统会察觉到 Server1 已下线

当 Server1 的下线时长超过用户设定的下线时长上限时，Sentinel 系统就会对 Server1 执行故障转移操作：

首先，Sentinel 系统会挑选 Server1 属下的其中一个从服务器，并将这个被选中的从服务器升级为新的主服务器
之后，Sentinel 系统会向 Server1 属下的所有从服务器发送新的复制指令，让它们成为新的主服务器的从服务器，当所有从服务器都开始复制新的主服务器时，故障转移操作执行完毕
另外，Sentinel 还会继续监视已下线的 Server1，并在它重新上线时，将它设置为新的主服务器的从服务器

选取新主

老主恢复，降为从服务器

Redis Cluster

Redis 集群是 Redis 提供的分布式数据库方案，集群通过分片（sharding）来进行数据共享，并提供复制和故障转移功能

Redis Cluser 采用虚拟槽分区，所有的键根据哈希函数映射到0~16383整数槽内，计算公式：slot=CRC16（key）&16383

每一个节点负责维护一部分槽以及槽所映射的键值数据

Redis 虚拟槽分区解耦了数据与节点之间的关系，简化了节点扩容和收缩的难度

当然 Redis 集群也有很多功能上的限制

1）key 批量操作支持有限。如 mset、mget，目前只支持具有相同 slot 值的 key 执行批量操作。对于映射为不同 slot 值的 key 由于执行 mget、mget 等操作可能存在于多个节点上因此不被支持
2）key 事务操作支持有限。同理只支持多 key 在同一节点上的事务操作，当多个 key 分布在不同的节点上时无法使用事务功能
3）key 作为数据分区的最小粒度，因此不能将一个大的键值对象如 hash、list 等映射到不同的节点
4）不支持多数据库空间。单机下的 Redis 可以支持16个数据库，集群模式下只能使用一个数据库空间，即db0
5）复制结构只支持一层，从节点只能复制主节点，不支持嵌套树状复制结构