[教程] 一文进阶Redis

Redis进阶

过期时间（Expire）

Redis 的过期时间（Expire）功能是一种数据生命周期管理机制，允许为键设置一个过期时间。一旦达到该时间，键会自动被删除。这对于管理缓存数据特别有用，可以自动清理不再需要的数据，从而节省空间。

应用场景

过期时间功能在需要控制数据存储周期的各种应用中都非常有用，尤其是在缓存场景中：

• 缓存数据过期：自动删除过期的缓存数据，以保持数据的新鲜性。
• 会话管理：在会话超时后自动删除会话数据。
• 限时特性控制：用于实现一些限时的功能，例如限时折扣、限时访问等。

注意事项

• 设置过期时间后，键会在指定的时间后自动被删除，无需手动干预。
• 过期时间的精度是秒级或毫秒级，取决于使用的是 EXPIRE 还是 PEXPIRE 命令。
• 过期删除操作是由 Redis 的定时任务异步执行的，因此删除时间可能会稍有延迟。

EXPIRE - 设置键的过期时间（常用）

EXPIRE key seconds
1

–> (integer) 若键存在且过期时间被成功设置，–> 1
若键不存在，–> 0

PEXPIRE - 以毫秒为单位设置键的过期时间（常用）

PEXPIRE key milliseconds
1

–> (integer) 若键存在且过期时间被成功设置，–> 1
若键不存在，–> 0

EXPIREAT - 设置键的过期UNIX时间戳

EXPIREAT key timestamp
1

–> (integer) 若键存在且过期时间被成功设置，–> 1
若键不存在，–> 0

PEXPIREAT - 以毫秒为单位设置键的过期UNIX时间戳

PEXPIREAT key milliseconds-timestamp
1

–> (integer) 若键存在且过期时间被成功设置，–> 1
若键不存在，–> 0

TTL - 查询键的剩余生存时间（秒）（常用）

TTL key
1

–> (integer) 返回键的剩余生存时间（秒）。
若键不存在或没有设置过期时间，–> -1
若键已过期，–> -2

PTTL - 查询键的剩余生存时间（毫秒）（常用）

PTTL key
1

–> (integer) 返回键的剩余生存时间（毫秒）。
若键不存在或没有设置过期时间，–> -1
若键已过期，–> -2

发布订阅模式（Pub/Sub）

Redis 的发布订阅模式（Pub/Sub）是一种消息通信模式，用于在一个或多个订阅者之间发送消息。这种模式由发布者（publisher）向频道（channel）发送消息，订阅者（subscriber）监听这些频道来接收消息。Pub/Sub 模式在需要实现实时消息系统时非常有用，如聊天应用、实时通知系统等。

应用场景

发布订阅模式广泛应用于实时消息传递和事件通知系统，例如：

• 实时消息系统：如在线聊天室、实时数据更新通知等。
• 事件驱动的应用：如在某个事件发生时触发通知或执行操作。
• 订阅服务：用户可以订阅感兴趣的主题或频道，接收相关的消息更新。

注意事项

• Redis 的发布订阅模式不提供持久化功能，如果没有订阅者在线，消息将会丢失。
• 这种模式更适合于轻量级和临时的通信，不建议用于关键数据的传输。

PUBLISH - 发布消息（常用）

PUBLISH channel message
1

–> (integer) 返回接收到消息的订阅者数量。
若无订阅者接收消息，–> 0

SUBSCRIBE - 订阅频道（常用）

SUBSCRIBE channel [channel ...]
1

–> 订阅一个或多个频道。
在订阅后，服务器会实时推送频道中的消息。

UNSUBSCRIBE - 取消订阅（常用）

UNSUBSCRIBE [channel ...]
1

–> 取消一个或多个频道的订阅。
若未指定频道，取消所有订阅。

PSUBSCRIBE - 订阅符合模式的频道

PSUBSCRIBE pattern [pattern ...]
1

–> 订阅符合给定模式的所有频道。
使用通配符匹配模式。

PUNSUBSCRIBE - 取消模式订阅

PUNSUBSCRIBE [pattern ...]
1

–> 取消一个或多个模式的订阅。
若未指定模式，取消所有模式订阅。

PUBSUB - 查看订阅信息

PUBSUB subcommand [argument [argument ...]]
1

–> 获取关于订阅的详细信息。
命令子选项如 CHANNELS、NUMSUB、NUMPAT 提供不同的信息。

消息队列（使用 Stream）

Redis 的 Stream 数据类型非常适合用作消息队列。它是一个可持续增长的日志数据结构，可以存储一系列的消息，每个消息都是一个由多个键值对组成的条目。Redis Stream 特别适合于构建事件驱动的应用程序，如消息队列、活动流、实时通知等。

应用场景

Stream 作为消息队列广泛应用于多种场合，例如：

• 任务队列：用于在后台处理任务，例如电子邮件发送、数据处理等。
• 事件流处理：实时记录和处理事件，如用户点击、交易记录等。
• 日志记录：持续记录应用或系统的日志信息。

注意事项

• Redis Stream 提供了消费者组的概念，可以实现多个消费者之间的负载均衡。
• Stream 支持范围查询和阻塞读取，适合实时消息应用。
• Stream 提供了持久化存储，不同于 Pub/Sub，消息不会因为没有消费者在线而丢失。

XADD - 向流添加消息（常用）

XADD key ID field value [field value ...]
1

–> (string) 返回添加消息的ID。
使用 * 作为ID时，Redis 自动生成ID。

XREAD - 从流中读取消息（常用）

XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...]
1

–> 返回指定流中的消息。
如果未指定 COUNT，默认返回所有消息。BLOCK 用于指定阻塞读取的时间。

XGROUP - 管理消费者组（常用）

XGROUP [CREATE key groupname ID | SETID key groupname ID | DESTROY key groupname | DELCONSUMER key groupname consumername]
1

–> 创建、更新或删除消费者组及其消费者。

XACK - 确认消息处理（常用）

XACK key group ID [ID ...]
1

–> (integer) 确认消息已被处理的数量。
用于在消费者组中标记消息为已处理。

XPENDING - 查看待处理消息（常用）

XPENDING key group [start end count] [consumer]
1

–> 查看消费者组中待处理的消息。
可以指定范围和消费者名称。

地理空间（Geospatial）

Redis 的地理空间（Geospatial）功能是一种特殊的数据结构，用于存储和操作地理位置信息。这种数据结构基于有序集合（sorted set），允许你存储地理位置数据（如经度和纬度）并进行复杂的地理空间查询。

应用场景

地理空间功能适用于各种需要地理位置信息的应用场景，例如：

• 位置服务：允许用户查找附近的地点、人或物品。
• 距离计算：计算两点之间的距离，用于配送、旅行规划等。
• 区域查询：查找特定区域内的成员或位置。

注意事项

• 地理空间数据存储在有序集合中，每个元素都与一个地理坐标相关联。
• 查询可以基于半径、成员或者区域来执行。
• Redis 提供的是近似位置数据，对于精度要求非常高的应用场景可能需要额外的处理。

GEOADD - 添加地理空间位置（常用）

GEOADD key longitude latitude member [longitude latitude member ...]
1

–> (integer) 返回添加到地理空间索引的元素数量。
添加位置数据，包括经度、纬度和成员名称。

GEODIST - 计算两个成员之间的距离（常用）

GEODIST key member1 member2 [unit]
1

–> (string) 返回成员之间的距离。
可以指定单位（m、km、mi、ft）。

GEOPOS - 获取成员的地理空间位置（常用）

GEOPOS key member [member ...]
1

–> 返回成员的经纬度坐标。
如果成员不存在，–> (nil)

GEORADIUS 和 GEORADIUSBYMEMBER - 按半径查询（常用）

GEORADIUS key longitude latitude radius unit [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]
1

GEORADIUSBYMEMBER key member radius unit [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]
1

–> 返回符合条件的成员。
可以包含额外的信息，如距离、坐标等。

HyperLogLog（基数估计）

Redis 的 HyperLogLog 是一种概率数据结构，用于高效地执行基数统计，即估算一个集合中唯一元素的数量。HyperLogLog 特别适合处理大数据集，因为它提供了一种空间效率极高的方式来估算唯一元素的数量，例如统计网站的独立访客数。它的优势在于使用极少的内存（约 12 KB）来处理大量数据。

应用场景

HyperLogLog 主要用于大规模数据环境中的基数估算任务，例如：

• 独立访客计数：统计网站或应用中的独立用户数。
• 大数据集的唯一元素计数：在不需要精确计数的场景中，如统计大量数据的不同值。

注意事项

• HyperLogLog 提供的是一个近似值，而不是精确计数。
• 它适用于那些可以接受一定误差的场景。
• 由于其极高的空间效率，它非常适合在内存受限的环境中使用。

PFADD - 向 HyperLogLog 添加元素（常用）

PFADD key element [element ...]
1

–> (integer) 如果 HyperLogLog 的内部表示改变了，–> 1
如果没有任何变化，–> 0

PFCOUNT - 计算 HyperLogLog 中的唯一元素数量（常用）

PFCOUNT key [key ...]
1

–> (integer) 返回估算的唯一元素数量。

PFMERGE - 合并多个 HyperLogLog（常用）

PFMERGE destkey sourcekey [sourcekey ...]
1

–> 创建一个新的 HyperLogLog，包含所有提供的 HyperLogLogs 的并集。
–> 返回 OK。

位图（Bitmap）

Redis 的位图（Bitmap）是一种特殊的数据类型，基于字符串类型实现，允许用户操作字符串中的每一位（bit）。位图提供了一种极为节省空间的方法来存储和操作大量的布尔值。这使得位图非常适合于实现大规模的、空间效率极高的标记系统。

应用场景

位图在处理大量布尔值时非常有用，常见的应用场景包括：

• 用户活跃度跟踪：跟踪用户每天的登录情况，每个位表示一天。
• 特征标记：用于标记用户的某些特征或行为，例如是否完成了某项任务。
• 实时计数：如在线用户数、网站点击量等。

注意事项

• 位图非常节省空间，但在处理大偏移量时要小心，因为 Redis 位图的大小会根据最大的偏移量自动增长。
• 位图操作通常非常快，但需要注意，大范围的 BITCOUNT 或 BITPOS 操作可能会消耗较多CPU资源。

SETBIT - 设置或清除位的值（常用）

SETBIT key offset value
1

–> (integer) 在执行操作之前，指定偏移处的位的原始值。
offset 是位的索引，value 是要设置的值（0 或 1）。

GETBIT - 获取位的值（常用）

GETBIT key offset
1

–> (integer) 返回位的值（0 或 1）。
offset 是位的索引。

BITCOUNT - 计算设置为 1 的位的数量（常用）

BITCOUNT key [start end]
1

–> (integer) 返回区间内设置为 1 的位的数量。
可以指定可选的字节范围 start 和 end。

BITOP - 对多个位图进行逻辑运算（常用）

BITOP operation destkey key [key ...]
1

–> (integer) 返回结果位图的长度（以字节为单位）。
支持的运算有 AND、OR、XOR 和 NOT。

BITPOS - 查找第一个设置为指定值的位（常用）

BITPOS key bit [start] [end]
1

–> (integer) 返回第一个设置为指定值（0 或 1）的位的位置。
可以指定可选的字节范围 start 和 end。

BITFIELD - 复杂位操作（Bitmap）

Redis 的 BITFIELD 命令是位图数据类型的扩展，提供了更复杂的操作，允许对字符串的特定部分进行读取、设置和计数等操作。这个命令使得在单个键中有效地存储和管理多种不同的数据片段成为可能，从而在空间效率和性能之间取得平衡。

应用场景

BITFIELD 命令的灵活性使其适用于需要进行更复杂的位操作的场景，特别是在需要处理不同大小的整数字段时，例如：

• 定制的计数器：使用不同大小的整数字段来存储多个计数器。
• 高效存储：将多个标记或状态压缩存储在单个键中。
• 位域映射：映射和操作数据的位域，如权限控制、状态标记等。

注意事项

• BITFIELD 允许对位进行更精细的控制，但这也意味着需要更多地了解数据的存储和表示方式。
• 使用时要考虑到数值溢出的问题，特别是当对数值进行增加或减少操作时。

命令用法

• 设置值（SET）：设置指定偏移量上特定大小的整数。
• 获取值（GET）：获取位于指定偏移量上特定大小的整数。
• 增加值（INCRBY）：在指定偏移量上增加特定大小的整数。
• 溢出控制（OVERFLOW）：指定在数值溢出时的行为。

示例

1. 设置特定位的值：

   BITFIELD mykey SET i5 #100 15
   1

   这会将 mykey 中从第 100 位开始的有符号 5 位整数设置为 15。

2. 获取特定位的值：

   BITFIELD mykey GET u8 #0
   1

   这会返回 mykey 中从第 0 位开始的无符号 8 位整数的值。

3. 增加特定位的值：

   BITFIELD mykey INCRBY i5 #100 1
   1

   这会将 mykey 中从第 100 位开始的有符号 5 位整数增加 1。

4. 处理溢出情况：

   BITFIELD mykey INCRBY i5 #100 1 OVERFLOW SAT
   1

   如果操作导致溢出，这会将值设置为该类型所能表示的最大值。

事务（Transactions）

Redis 的事务功能允许将多个命令打包成一个原子性操作序列。这意味着事务内的所有命令要么全部执行，要么全部不执行。Redis 通过一组命令（MULTI、EXEC、DISCARD 和 WATCH）来实现事务处理。

应用场景

事务在需要确保一系列操作完整性和一致性的场景中非常有用，例如：

• 多步操作：在执行一系列相互依赖的命令时，确保它们要么全部成功，要么全部失败。
• 数据完整性：保证数据状态的一致性，避免部分更新导致的数据不一致问题。

注意事项

• Redis 事务不支持回滚。如果事务中的某个操作失败，事务的其余部分仍将继续执行。
• WATCH 命令可以用于实现乐观锁，它在检测到关键数据在执行事务之前被修改时，会使事务失败。

MULTI - 开始一个事务（常用）

MULTI
1

–> 标记一个事务块的开始。

EXEC - 执行所有事务块内的命令（常用）

EXEC
1

–> 执行所有自 MULTI 后进入队列的命令。

DISCARD - 放弃事务（常用）

DISCARD
1

–> 放弃执行事务块内的所有命令。

WATCH - 监视键变化（常用）

WATCH key [key ...]
1

–> 监视一个或多个键，如果在事务执行之前这些键被修改，那么事务将被中断。

示例：

假设你需要更新两个键 key1 和 key2 的值，并且希望这两个操作要么同时成功，要么都不执行。以下是如何使用 Redis 事务来实现这一点的步骤：

MULTI            # 开始事务
SET key1 value1  # 队列中加入设置 key1 的命令
SET key2 value2  # 队列中加入设置 key2 的命令
EXEC             # 执行所有命令
1
2
3
4

1. 开始事务：
   使用 MULTI 命令开始一个新的事务。这标志着接下来的命令将被作为一个原子单元来处理。

2. 命令入队：
   使用 SET 命令将 key1 设置为 value1，并将 key2 设置为 value2。这些命令在执行 EXEC 前不会立即执行，而是被添加到事务的队列中。

3. 执行事务：
   使用 EXEC 命令来执行事务。当 EXEC 被调用时，事务中的所有命令都会被原子性地执行。如果事务成功，你将看到每个命令的输出结果；如果在执行过程中出现错误，所有命令的执行将会被取消。

在这个过程中，如果需要在执行 EXEC 之前取消事务，可以使用 DISCARD 命令，这会清除事务队列并退出事务模式。

持久化（Persistence）

Redis 的持久化功能是其关键特性之一，它允许将存储在内存中的数据保存到磁盘，确保在服务器重启后数据不会丢失。Redis 提供了两种主要的持久化策略：RDB（Redis Database）快照和 AOF（Append Only File）日志。

应用场景

持久化在以下场景中非常重要：

• 数据备份：定期创建数据快照以备份数据库，用于灾难恢复。
• 数据恢复：在服务器崩溃或重启后恢复数据。
• 系统稳定性：确保系统的稳定运行和数据的完整性。

RDB 持久化

RDB 持久化通过创建整个数据库快照来保存当前数据状态。

• 优点：适用于大规模数据恢复，能快速加载数据。
• 缺点：在两次快照之间的数据可能丢失，不适合需要每个写操作都持久化的场景。

AOF 持久化

AOF 持久化记录每个写操作，并在服务器启动时重放这些操作来重建原始数据。

• 优点：更加可靠，可以确保写操作不丢失。
• 缺点：文件大小可能会很大，且重启恢复速度可能较慢。

注意事项

• 持久化策略选择：根据数据安全性和性能需求选择合适的持久化策略。
• 性能影响：持久化操作可能会影响 Redis 的性能。
• 数据安全：为了确保数据安全，建议同时使用 RDB 和 AOF 持久化。

BGSAVE - 创建 RDB 快照（常用）

BGSAVE
1

–> 异步执行 RDB 快照保存，不阻塞主进程。

SAVE - 同步创建 RDB 快照

SAVE
1

–> 同步执行 RDB 快照保存，期间阻塞所有客户端请求。

AOF 相关配置 - 控制 AOF 行为

• 在配置文件中设置 appendonly yes 开启 AOF 持久化。
• appendfsync 配置项控制 AOF 的同步频率（always、everysec、no）。

主从复制（Replication）

Redis 的主从复制功能允许将一台 Redis 服务器的数据复制到一个或多个从服务器上。这种机制可以用于数据冗余、负载均衡、灾难恢复和数据备份等。

应用场景

主从复制在以下场景中非常有用：

• 数据备份：在从服务器上创建数据的副本以备份主服务器上的数据。
• 读取扩展：通过在多个从服务器上读取数据，可以降低主服务器的读取负载。
• 灾难恢复：如果主服务器出现故障，可以从从服务器恢复数据或提升某个从服务器为新的主服务器。

注意事项

• 数据延迟：在高负载情况下，从服务器上的数据可能会稍微滞后于主服务器。
• 内存使用：每个从服务器都需要足够的内存来存储复制的数据。
• 网络带宽：复制数据会占用网络带宽，特别是在进行初始同步时。

主从复制设置

1. 主服务器配置：主服务器无需特殊配置，只需正常运行即可。
2. 从服务器配置：在从服务器上，使用以下命令指定主服务器：

   SLAVEOF host port
   1

   将 host 和 port 替换为主服务器的地址和端口。

示例

假设有一个运行在 IP 地址 192.168.1.100、端口 6379 的主 Redis 服务器，要将其数据复制到从服务器上，从服务器上的配置应该是：

SLAVEOF 192.168.1.100 6379
1

这条命令会使当前服务器成为指定主服务器的从服务器。

INFO REPLICATION - 查看复制信息（常用）

使用 INFO REPLICATION 命令可以查看主从复制的状态，包括从服务器的数量、复制偏移量等信息。

故障转移

Redis Sentinel 或 Redis Cluster 可以用于自动处理故障转移，在主服务器出现故障时自动将从服务器提升为新的主服务器。

通过配置文件配置主从服务器（常用）

要通过配置文件设置 Redis 的主从复制，你需要分别在主服务器和从服务器的 Redis 配置文件中做出相应的修改。
过于复杂，请查阅推荐视频【GeekHour】一小时Redis教程 - P18

验证配置

更改并重启 Redis 服务后，你可以使用 redis-cli 工具检查复制状态。在从服务器上执行以下命令：

redis-cli
info replication
1
2

这将显示复制的状态信息，包括从服务器是否成功连接到主服务器等。

哨兵模式（Sentinel）

Redis Sentinel 是 Redis 的高可用性解决方案。它负责监控所有 Redis 主从服务器，自动进行故障转移，并提供服务发现功能。当主服务器出现故障时，Sentinel 能够自动将其中一个从服务器提升为新的主服务器，并让其余从服务器复制新的主服务器。

应用场景

Redis Sentinel 在以下场景中非常有用：

• 自动故障转移：自动检测主服务器是否故障并进行故障转移。
• 系统监控：监控 Redis 主从服务器的运行状态。
• 服务发现：为客户端提供当前主服务器的地址。

注意事项

• 部署多个 Sentinel 实例：为了确保可靠性，至少需要部署三个 Sentinel 实例。
• 网络可靠性：Sentinel 需要一个可靠的网络环境来监控 Redis 实例。
• 配置一致性：确保所有 Sentinel 实例的配置一致。

Sentinel 配置

在使用 Sentinel 之前，需要对 Sentinel 进行配置。以下是 Sentinel 配置的基本步骤：

1. 创建配置文件：为每个 Sentinel 实例创建一个配置文件，如 sentinel.conf。

2. 配置 Sentinel 监控：在配置文件中指定要监控的主服务器。

   sentinel monitor mymaster 127.0.0.1 6379 2
   1

   这条命令指定 Sentinel 监控名为 mymaster 的主服务器，地址为 127.0.0.1，端口为 6379。数字 2 表示当有两个或更多的 Sentinel 认为主服务器不可用时，才开始故障转移过程。

3. 其他配置选项：

   • 设置主服务器故障判定的超时时间。

     sentinel down-after-milliseconds mymaster 30000
     1

   • 配置故障转移的选项，如选举超时时间等。

4. 启动 Sentinel：
   使用以下命令启动 Sentinel 实例：

   redis-sentinel /path/to/sentinel.conf
   1

故障转移过程

当 Sentinel 检测到主服务器不可用时，它会自动开始故障转移过程：

1. 选举领导 Sentinel。
2. 选举出一个新的主服务器（通常是数据最完整的从服务器）。
3. 配置其他从服务器复制新的主服务器。
4. 更新客户端关于主服务器的信息。

Redis Sentinel 确保了 Redis 环境的高可用性和稳定性，适用于生产环境中对数据可用性要求较高的场景。