外贸一站式推广服务,电子商务网站建设收获,网站建设 科目,郑州app开发公司定制外包Redis进阶
过期时间#xff08;Expire#xff09;
Redis 的过期时间#xff08;Expire#xff09;功能是一种数据生命周期管理机制#xff0c;允许为键设置一个过期时间。一旦达到该时间#xff0c;键会自动被删除。这对于管理缓存数据特别有用#xff0c;可以自动清理…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 模式在需要实现实时消息系统时非常有用如聊天应用、实时通知系统等。
应用场景
发布订阅模式广泛应用于实时消息传递和事件通知系统例如
实时消息系统如在线聊天室、实时数据更新通知等。事件驱动的应用如在某个事件发生时触发通知或执行操作。订阅服务用户可以订阅感兴趣的主题或频道接收相关的消息更新。
注意事项
Redis 的发布订阅模式不提供持久化功能如果没有订阅者在线消息将会丢失。这种模式更适合于轻量级和临时的通信不建议用于关键数据的传输。
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 特别适合于构建事件驱动的应用程序如消息队列、活动流、实时通知等。
应用场景
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允许你存储地理位置数据如经度和纬度并进行复杂的地理空间查询。
应用场景
地理空间功能适用于各种需要地理位置信息的应用场景例如
位置服务允许用户查找附近的地点、人或物品。距离计算计算两点之间的距离用于配送、旅行规划等。区域查询查找特定区域内的成员或位置。
注意事项
地理空间数据存储在有序集合中每个元素都与一个地理坐标相关联。查询可以基于半径、成员或者区域来执行。Redis 提供的是近似位置数据对于精度要求非常高的应用场景可能需要额外的处理。
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 主要用于大规模数据环境中的基数估算任务例如
独立访客计数统计网站或应用中的独立用户数。大数据集的唯一元素计数在不需要精确计数的场景中如统计大量数据的不同值。
注意事项
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 命令的灵活性使其适用于需要进行更复杂的位操作的场景特别是在需要处理不同大小的整数字段时例如
定制的计数器使用不同大小的整数字段来存储多个计数器。高效存储将多个标记或状态压缩存储在单个键中。位域映射映射和操作数据的位域如权限控制、状态标记等。
注意事项
BITFIELD 允许对位进行更精细的控制但这也意味着需要更多地了解数据的存储和表示方式。使用时要考虑到数值溢出的问题特别是当对数值进行增加或减少操作时。
命令用法
设置值SET设置指定偏移量上特定大小的整数。获取值GET获取位于指定偏移量上特定大小的整数。增加值INCRBY在指定偏移量上增加特定大小的整数。溢出控制OVERFLOW指定在数值溢出时的行为。
示例 设置特定位的值 BITFIELD mykey SET i5 #100 15这会将 mykey 中从第 100 位开始的有符号 5 位整数设置为 15。 获取特定位的值 BITFIELD mykey GET u8 #0这会返回 mykey 中从第 0 位开始的无符号 8 位整数的值。 增加特定位的值 BITFIELD mykey INCRBY i5 #100 1这会将 mykey 中从第 100 位开始的有符号 5 位整数增加 1。 处理溢出情况 BITFIELD mykey INCRBY i5 #100 1 OVERFLOW SAT如果操作导致溢出这会将值设置为该类型所能表示的最大值。
事务Transactions
Redis 的事务功能允许将多个命令打包成一个原子性操作序列。这意味着事务内的所有命令要么全部执行要么全部不执行。Redis 通过一组命令MULTI、EXEC、DISCARD 和 WATCH来实现事务处理。
应用场景
事务在需要确保一系列操作完整性和一致性的场景中非常有用例如
多步操作在执行一系列相互依赖的命令时确保它们要么全部成功要么全部失败。数据完整性保证数据状态的一致性避免部分更新导致的数据不一致问题。
注意事项
Redis 事务不支持回滚。如果事务中的某个操作失败事务的其余部分仍将继续执行。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 # 执行所有命令开始事务 使用 MULTI 命令开始一个新的事务。这标志着接下来的命令将被作为一个原子单元来处理。 命令入队 使用 SET 命令将 key1 设置为 value1并将 key2 设置为 value2。这些命令在执行 EXEC 前不会立即执行而是被添加到事务的队列中。 执行事务 使用 EXEC 命令来执行事务。当 EXEC 被调用时事务中的所有命令都会被原子性地执行。如果事务成功你将看到每个命令的输出结果如果在执行过程中出现错误所有命令的执行将会被取消。
在这个过程中如果需要在执行 EXEC 之前取消事务可以使用 DISCARD 命令这会清除事务队列并退出事务模式。
持久化Persistence
Redis 的持久化功能是其关键特性之一它允许将存储在内存中的数据保存到磁盘确保在服务器重启后数据不会丢失。Redis 提供了两种主要的持久化策略RDBRedis Database快照和 AOFAppend Only File日志。
应用场景
持久化在以下场景中非常重要
数据备份定期创建数据快照以备份数据库用于灾难恢复。数据恢复在服务器崩溃或重启后恢复数据。系统稳定性确保系统的稳定运行和数据的完整性。
RDB 持久化
RDB 持久化通过创建整个数据库快照来保存当前数据状态。
优点适用于大规模数据恢复能快速加载数据。缺点在两次快照之间的数据可能丢失不适合需要每个写操作都持久化的场景。
AOF 持久化
AOF 持久化记录每个写操作并在服务器启动时重放这些操作来重建原始数据。
优点更加可靠可以确保写操作不丢失。缺点文件大小可能会很大且重启恢复速度可能较慢。
注意事项
持久化策略选择根据数据安全性和性能需求选择合适的持久化策略。性能影响持久化操作可能会影响 Redis 的性能。数据安全为了确保数据安全建议同时使用 RDB 和 AOF 持久化。
BGSAVE - 创建 RDB 快照常用
BGSAVE– 异步执行 RDB 快照保存不阻塞主进程。
SAVE - 同步创建 RDB 快照
SAVE– 同步执行 RDB 快照保存期间阻塞所有客户端请求。
AOF 相关配置 - 控制 AOF 行为
在配置文件中设置 appendonly yes 开启 AOF 持久化。appendfsync 配置项控制 AOF 的同步频率always、everysec、no。
主从复制Replication
Redis 的主从复制功能允许将一台 Redis 服务器的数据复制到一个或多个从服务器上。这种机制可以用于数据冗余、负载均衡、灾难恢复和数据备份等。
应用场景
主从复制在以下场景中非常有用
数据备份在从服务器上创建数据的副本以备份主服务器上的数据。读取扩展通过在多个从服务器上读取数据可以降低主服务器的读取负载。灾难恢复如果主服务器出现故障可以从从服务器恢复数据或提升某个从服务器为新的主服务器。
注意事项
数据延迟在高负载情况下从服务器上的数据可能会稍微滞后于主服务器。内存使用每个从服务器都需要足够的内存来存储复制的数据。网络带宽复制数据会占用网络带宽特别是在进行初始同步时。
主从复制设置
主服务器配置主服务器无需特殊配置只需正常运行即可。从服务器配置在从服务器上使用以下命令指定主服务器SLAVEOF host port将 host 和 port 替换为主服务器的地址和端口。
示例
假设有一个运行在 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 在以下场景中非常有用
自动故障转移自动检测主服务器是否故障并进行故障转移。系统监控监控 Redis 主从服务器的运行状态。服务发现为客户端提供当前主服务器的地址。
注意事项
部署多个 Sentinel 实例为了确保可靠性至少需要部署三个 Sentinel 实例。网络可靠性Sentinel 需要一个可靠的网络环境来监控 Redis 实例。配置一致性确保所有 Sentinel 实例的配置一致。
Sentinel 配置
在使用 Sentinel 之前需要对 Sentinel 进行配置。以下是 Sentinel 配置的基本步骤 创建配置文件为每个 Sentinel 实例创建一个配置文件如 sentinel.conf。 配置 Sentinel 监控在配置文件中指定要监控的主服务器。 sentinel monitor mymaster 127.0.0.1 6379 2这条命令指定 Sentinel 监控名为 mymaster 的主服务器地址为 127.0.0.1端口为 6379。数字 2 表示当有两个或更多的 Sentinel 认为主服务器不可用时才开始故障转移过程。 其他配置选项 设置主服务器故障判定的超时时间。sentinel down-after-milliseconds mymaster 30000配置故障转移的选项如选举超时时间等。 启动 Sentinel 使用以下命令启动 Sentinel 实例 redis-sentinel /path/to/sentinel.conf故障转移过程
当 Sentinel 检测到主服务器不可用时它会自动开始故障转移过程
选举领导 Sentinel。选举出一个新的主服务器通常是数据最完整的从服务器。配置其他从服务器复制新的主服务器。更新客户端关于主服务器的信息。
Redis Sentinel 确保了 Redis 环境的高可用性和稳定性适用于生产环境中对数据可用性要求较高的场景。
