Redis进阶
过期时间(Expire)
Redis 的过期时间(Expire)功能是一种数据生命周期管理机制,允许为键设置一个过期时间。一旦达到该时间,键会自动被删除。这对于管理缓存数据特别有用,可以自动清理不再需要的数据,从而节省空间。
应用场景
过期时间功能在需要控制数据存储周期的各种应用中都非常有用,尤其是在缓存场景中:
注意事项
- 设置过期时间后,键会在指定的时间后自动被删除,无需手动干预。
- 过期时间的精度是秒级或毫秒级,取决于使用的是
EXPIRE
还是PEXPIRE
命令。 - 过期删除操作是由 Redis 的定时任务异步执行的,因此删除时间可能会稍有延迟。
EXPIRE – 设置键的过期时间(常用)
EXPIRE key seconds
–> (integer) 若键存在且过期时间被成功设置,–> 1
若键不存在,–> 0
PEXPIRE – 以毫秒为单位设置键的过期时间(常用)
PEXPIRE key milliseconds
–> (integer) 若键存在且过期时间被成功设置,–> 1
若键不存在,–> 0
EXPIREAT – 设置键的过期UNIX时间戳
EXPIREAT key timestamp
–> (integer) 若键存在且过期时间被成功设置,–> 1
若键不存在,–> 0
PEXPIREAT – 以毫秒为单位设置键的过期UNIX时间戳
PEXPIREAT key milliseconds-timestamp
–> (integer) 若键存在且过期时间被成功设置,–> 1
若键不存在,–> 0
TTL – 查询键的剩余生存时间(秒)(常用)
TTL key
–> (integer) 返回键的剩余生存时间(秒)。
若键不存在或没有设置过期时间,–> -1
若键已过期,–> -2
PTTL – 查询键的剩余生存时间(毫秒)(常用)
PTTL key
–> (integer) 返回键的剩余生存时间(毫秒)。
若键不存在或没有设置过期时间,–> -1
若键已过期,–> -2
发布订阅模式(Pub/Sub)
Redis 的发布订阅模式(Pub/Sub)是一种消息通信模式,用于在一个或多个订阅者之间发送消息。这种模式由发布者(publisher)向频道(channel)发送消息,订阅者(subscriber)监听这些频道来接收消息。Pub/Sub 模式在需要实现实时消息系统时非常有用,如聊天应用、实时通知系统等。
应用场景
注意事项
PUBLISH – 发布消息(常用)
PUBLISH channel message
–> (integer) 返回接收到消息的订阅者数量。
若无订阅者接收消息,–> 0
SUBSCRIBE – 订阅频道(常用)
SUBSCRIBE channel [channel ...]
–> 订阅一个或多个频道。
在订阅后,服务器会实时推送频道中的消息。
UNSUBSCRIBE – 取消订阅(常用)
UNSUBSCRIBE [channel ...]
–> 取消一个或多个频道的订阅。
若未指定频道,取消所有订阅。
PSUBSCRIBE – 订阅符合模式的频道
PSUBSCRIBE pattern [pattern ...]
PUNSUBSCRIBE – 取消模式订阅
PUNSUBSCRIBE [pattern ...]
–> 取消一个或多个模式的订阅。
若未指定模式,取消所有模式订阅。
PUBSUB – 查看订阅信息
PUBSUB subcommand [argument [argument ...]]
–> 获取关于订阅的详细信息。
命令子选项如 CHANNELS、NUMSUB、NUMPAT 提供不同的信息。
消息队列(使用 Stream)
Redis 的 Stream 数据类型非常适合用作消息队列。它是一个可持续增长的日志数据结构,可以存储一系列的消息,每个消息都是一个由多个键值对组成的条目。Redis Stream 特别适合于构建事件驱动的应用程序,如消息队列、活动流、实时通知等。
应用场景
注意事项
- Redis Stream 提供了消费者组的概念,可以实现多个消费者之间的负载均衡。
- Stream 支持范围查询和阻塞读取,适合实时消息应用。
- Stream 提供了持久化存储,不同于 Pub/Sub,消息不会因为没有消费者在线而丢失。
XADD – 向流添加消息(常用)
XADD key ID field value [field value ...]
–> (string) 返回添加消息的ID。
使用 *
作为ID时,Redis 自动生成ID。
XREAD – 从流中读取消息(常用)
XREAD [COUNT count] [BLOCK milliseconds] STREAMS key [key ...] ID [ID ...]
–> 返回指定流中的消息。
如果未指定 COUNT
,默认返回所有消息。BLOCK
用于指定阻塞读取的时间。
XGROUP – 管理消费者组(常用)
XGROUP [CREATE key groupname ID | SETID key groupname ID | DESTROY key groupname | DELCONSUMER key groupname consumername]
XACK – 确认消息处理(常用)
XACK key group ID [ID ...]
–> (integer) 确认消息已被处理的数量。
用于在消费者组中标记消息为已处理。
XPENDING – 查看待处理消息(常用)
XPENDING key group [start end count] [consumer]
–> 查看消费者组中待处理的消息。
可以指定范围和消费者名称。
地理空间(Geospatial)
Redis 的地理空间(Geospatial)功能是一种特殊的数据结构,用于存储和操作地理位置信息。这种数据结构基于有序集合(sorted set),允许你存储地理位置数据(如经度和纬度)并进行复杂的地理空间查询。
应用场景
注意事项
GEOADD – 添加地理空间位置(常用)
GEOADD key longitude latitude member [longitude latitude member ...]
–> (integer) 返回添加到地理空间索引的元素数量。
添加位置数据,包括经度、纬度和成员名称。
GEODIST – 计算两个成员之间的距离(常用)
GEODIST key member1 member2 [unit]
–> (string) 返回成员之间的距离。
可以指定单位(m、km、mi、ft)。
GEOPOS – 获取成员的地理空间位置(常用)
GEOPOS key member [member ...]
–> 返回成员的经纬度坐标。
如果成员不存在,–> (nil)
GEORADIUS 和 GEORADIUSBYMEMBER – 按半径查询(常用)
GEORADIUS key longitude latitude radius unit [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]
GEORADIUSBYMEMBER key member radius unit [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count] [ASC|DESC] [STORE key] [STOREDIST key]
–> 返回符合条件的成员。
可以包含额外的信息,如距离、坐标等。
HyperLogLog(基数估计)
Redis 的 HyperLogLog 是一种概率数据结构,用于高效地执行基数统计,即估算一个集合中唯一元素的数量。HyperLogLog 特别适合处理大数据集,因为它提供了一种空间效率极高的方式来估算唯一元素的数量,例如统计网站的独立访客数。它的优势在于使用极少的内存(约 12 KB)来处理大量数据。
应用场景
HyperLogLog 主要用于大规模数据环境中的基数估算任务,例如:
注意事项
PFADD – 向 HyperLogLog 添加元素(常用)
PFADD key element [element ...]
–> (integer) 如果 HyperLogLog 的内部表示改变了,–> 1
如果没有任何变化,–> 0
PFCOUNT – 计算 HyperLogLog 中的唯一元素数量(常用)
PFCOUNT key [key ...]
–> (integer) 返回估算的唯一元素数量。
PFMERGE – 合并多个 HyperLogLog(常用)
PFMERGE destkey sourcekey [sourcekey ...]
–> 创建一个新的 HyperLogLog,包含所有提供的 HyperLogLogs 的并集。
–> 返回 OK。
位图(Bitmap)
Redis 的位图(Bitmap)是一种特殊的数据类型,基于字符串类型实现,允许用户操作字符串中的每一位(bit)。位图提供了一种极为节省空间的方法来存储和操作大量的布尔值。这使得位图非常适合于实现大规模的、空间效率极高的标记系统。
应用场景
位图在处理大量布尔值时非常有用,常见的应用场景包括:
注意事项
- 位图非常节省空间,但在处理大偏移量时要小心,因为 Redis 位图的大小会根据最大的偏移量自动增长。
- 位图操作通常非常快,但需要注意,大范围的
BITCOUNT
或BITPOS
操作可能会消耗较多CPU资源。
SETBIT – 设置或清除位的值(常用)
SETBIT key offset value
–> (integer) 在执行操作之前,指定偏移处的位的原始值。
offset
是位的索引,value
是要设置的值(0 或 1)。
GETBIT – 获取位的值(常用)
GETBIT key offset
–> (integer) 返回位的值(0 或 1)。
offset
是位的索引。
BITCOUNT – 计算设置为 1 的位的数量(常用)
BITCOUNT key [start end]
–> (integer) 返回区间内设置为 1 的位的数量。
可以指定可选的字节范围 start
和 end
。
BITOP – 对多个位图进行逻辑运算(常用)
BITOP operation destkey key [key ...]
–> (integer) 返回结果位图的长度(以字节为单位)。
支持的运算有 AND、OR、XOR 和 NOT。
BITPOS – 查找第一个设置为指定值的位(常用)
BITPOS key bit [start] [end]
–> (integer) 返回第一个设置为指定值(0 或 1)的位的位置。
可以指定可选的字节范围 start
和 end
。
BITFIELD – 复杂位操作(Bitmap)
Redis 的 BITFIELD
命令是位图数据类型的扩展,提供了更复杂的操作,允许对字符串的特定部分进行读取、设置和计数等操作。这个命令使得在单个键中有效地存储和管理多种不同的数据片段成为可能,从而在空间效率和性能之间取得平衡。
应用场景
BITFIELD
命令的灵活性使其适用于需要进行更复杂的位操作的场景,特别是在需要处理不同大小的整数字段时,例如:
注意事项
命令用法
- 设置值(SET):设置指定偏移量上特定大小的整数。
- 获取值(GET):获取位于指定偏移量上特定大小的整数。
- 增加值(INCRBY):在指定偏移量上增加特定大小的整数。
- 溢出控制(OVERFLOW):指定在数值溢出时的行为。
示例
-
设置特定位的值:
BITFIELD mykey SET i5 #100 15
-
获取特定位的值:
BITFIELD mykey GET u8 #0
-
增加特定位的值:
BITFIELD mykey INCRBY i5 #100 1
-
处理溢出情况:
BITFIELD mykey INCRBY i5 #100 1 OVERFLOW SAT
如果操作导致溢出,这会将值设置为该类型所能表示的最大值。
事务(Transactions)
Redis 的事务功能允许将多个命令打包成一个原子性操作序列。这意味着事务内的所有命令要么全部执行,要么全部不执行。Redis 通过一组命令(MULTI
、EXEC
、DISCARD
和 WATCH
)来实现事务处理。
应用场景
事务在需要确保一系列操作完整性和一致性的场景中非常有用,例如:
注意事项
MULTI – 开始一个事务(常用)
MULTI
–> 标记一个事务块的开始。
EXEC – 执行所有事务块内的命令(常用)
EXEC
–> 执行所有自 MULTI
后进入队列的命令。
DISCARD – 放弃事务(常用)
DISCARD
–> 放弃执行事务块内的所有命令。
WATCH – 监视键变化(常用)
WATCH key [key ...]
–> 监视一个或多个键,如果在事务执行之前这些键被修改,那么事务将被中断。
示例:
假设你需要更新两个键 key1
和 key2
的值,并且希望这两个操作要么同时成功,要么都不执行。以下是如何使用 Redis 事务来实现这一点的步骤:
MULTI # 开始事务
SET key1 value1 # 队列中加入设置 key1 的命令
SET key2 value2 # 队列中加入设置 key2 的命令
EXEC # 执行所有命令
-
命令入队:
使用SET
命令将key1
设置为value1
,并将key2
设置为value2
。这些命令在执行EXEC
前不会立即执行,而是被添加到事务的队列中。 -
执行事务:
使用EXEC
命令来执行事务。当EXEC
被调用时,事务中的所有命令都会被原子性地执行。如果事务成功,你将看到每个命令的输出结果;如果在执行过程中出现错误,所有命令的执行将会被取消。
在这个过程中,如果需要在执行 EXEC
之前取消事务,可以使用 DISCARD
命令,这会清除事务队列并退出事务模式。
持久化(Persistence)
Redis 的持久化功能是其关键特性之一,它允许将存储在内存中的数据保存到磁盘,确保在服务器重启后数据不会丢失。Redis 提供了两种主要的持久化策略:RDB(Redis Database)快照和 AOF(Append Only File)日志。
应用场景
持久化在以下场景中非常重要:
RDB 持久化
AOF 持久化
AOF 持久化记录每个写操作,并在服务器启动时重放这些操作来重建原始数据。
注意事项
BGSAVE – 创建 RDB 快照(常用)
BGSAVE
SAVE – 同步创建 RDB 快照
SAVE
AOF 相关配置 – 控制 AOF 行为
主从复制(Replication)
Redis 的主从复制功能允许将一台 Redis 服务器的数据复制到一个或多个从服务器上。这种机制可以用于数据冗余、负载均衡、灾难恢复和数据备份等。
应用场景
主从复制在以下场景中非常有用:
- 数据备份:在从服务器上创建数据的副本以备份主服务器上的数据。
- 读取扩展:通过在多个从服务器上读取数据,可以降低主服务器的读取负载。
- 灾难恢复:如果主服务器出现故障,可以从从服务器恢复数据或提升某个从服务器为新的主服务器。
注意事项
主从复制设置
示例
假设有一个运行在 IP 地址 192.168.1.100
、端口 6379
的主 Redis 服务器,要将其数据复制到从服务器上,从服务器上的配置应该是:
SLAVEOF 192.168.1.100 6379
INFO REPLICATION – 查看复制信息(常用)
使用 INFO REPLICATION
命令可以查看主从复制的状态,包括从服务器的数量、复制偏移量等信息。
故障转移
Redis Sentinel 或 Redis Cluster 可以用于自动处理故障转移,在主服务器出现故障时自动将从服务器提升为新的主服务器。
通过配置文件配置主从服务器(常用)
要通过配置文件设置 Redis 的主从复制,你需要分别在主服务器和从服务器的 Redis 配置文件中做出相应的修改。
过于复杂,请查阅推荐视频【GeekHour】一小时Redis教程 – P18
验证配置
更改并重启 Redis 服务后,你可以使用 redis-cli
工具检查复制状态。在从服务器上执行以下命令:
redis-cli
info replication
这将显示复制的状态信息,包括从服务器是否成功连接到主服务器等。
哨兵模式(Sentinel)
Redis Sentinel 是 Redis 的高可用性解决方案。它负责监控所有 Redis 主从服务器,自动进行故障转移,并提供服务发现功能。当主服务器出现故障时,Sentinel 能够自动将其中一个从服务器提升为新的主服务器,并让其余从服务器复制新的主服务器。
应用场景
Redis Sentinel 在以下场景中非常有用:
注意事项
- 部署多个 Sentinel 实例:为了确保可靠性,至少需要部署三个 Sentinel 实例。
- 网络可靠性:Sentinel 需要一个可靠的网络环境来监控 Redis 实例。
- 配置一致性:确保所有 Sentinel 实例的配置一致。
Sentinel 配置
在使用 Sentinel 之前,需要对 Sentinel 进行配置。以下是 Sentinel 配置的基本步骤:
-
配置 Sentinel 监控:在配置文件中指定要监控的主服务器。
sentinel monitor mymaster 127.0.0.1 6379 2
这条命令指定 Sentinel 监控名为
mymaster
的主服务器,地址为127.0.0.1
,端口为6379
。数字2
表示当有两个或更多的 Sentinel 认为主服务器不可用时,才开始故障转移过程。 -
其他配置选项:
-
启动 Sentinel:
使用以下命令启动 Sentinel 实例:redis-sentinel /path/to/sentinel.conf
故障转移过程
当 Sentinel 检测到主服务器不可用时,它会自动开始故障转移过程:
- 选举领导 Sentinel。
- 选举出一个新的主服务器(通常是数据最完整的从服务器)。
- 配置其他从服务器复制新的主服务器。
- 更新客户端关于主服务器的信息。
Redis Sentinel 确保了 Redis 环境的高可用性和稳定性,适用于生产环境中对数据可用性要求较高的场景。
原文地址:https://blog.csdn.net/gulugulu1103/article/details/134701360
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。
如若转载,请注明出处:http://www.7code.cn/show_12229.html
如若内容造成侵权/违法违规/事实不符,请联系代码007邮箱:suwngjj01@126.com进行投诉反馈,一经查实,立即删除!