网站建设 运营,网站怎么更改关键词,网站推广和优化的原因,做音乐网站二十二 Redis
1 Redis 作用 Redis#xff0c;全称Remote Dictionary Server#xff0c;即远程字典服务#xff0c;是一个开源的使用ANSI C语言编写的、支持网络的、基于内存亦可持久化的日志型、Key-Value数据库#xff0c;并提供多种语言的API。它主要用于缓存数据的计算…二十二 Redis
1 Redis 作用 Redis全称Remote Dictionary Server即远程字典服务是一个开源的使用ANSI C语言编写的、支持网络的、基于内存亦可持久化的日志型、Key-Value数据库并提供多种语言的API。它主要用于缓存数据的计算结果、页面内容、数据库查询结果等以提高数据访问速度和响应速度从而提升系统性能和用户体验。 Redis具有多种应用场景包括但不限于 缓存通过缓存热点数据减少数据库查询次数提高访问速度。 消息队列实现异步处理和解耦提高系统的可扩展性和灵活性。 分布式锁作为分布式锁的存储层通过缓存锁信息和锁状态实现分布式锁和并发控制。 计数器通过原子操作实现计数器的自增和自减支持高并发的计数操作可用于实现各种排行榜和统计功能。 Redis支持多种数据类型包括字符串String、哈希Hash、列表List、集合Set和有序集合Sorted Set这使得Redis可以根据不同的场景选择合适的数据类型来实现各种功能。此外Redis还提供持久化服务使得数据在重启或崩溃后不会丢失进一步增强了其作为缓存和数据库使用的可靠性。
2 Redis 的数据类型
1.String字符串这是 Redis 最基本的数据类型一个 key 对应一个 value。Redis 的字符串是二进制安全的这意味着你可以在一个字符串中存储任何数据比如 JPEG 图片或者序列化的对象。2.Hash哈希Redis hash 是一个键值对集合。Redis hash 是一个 string 类型的 field 和 value 的映射表hash 特别适合用于存储对象。3.List列表Redis 列表是简单的字符串列表按照插入顺序排序。你可以添加一个元素到列表的头部左边或者尾部右边。4.Set集合Redis 的集合是 string 类型元素的无序集合。集合成员是唯一的这就意味着集合中不能出现重复的数据。5.Zset有序集合Redis 有序集合和集合一样也是 string 类型元素的集合并且集合成员是唯一的。不同的是每个元素都会关联一个 double 类型的分数。Redis 正是通过分数来为集合中的元素从小到到大进行从小到大的排序。6.Streams流Redis Streams 是 Redis 5.0 版本引入的新数据类型用于实现消息队列系统。Streams 是一个包含零个或多个消息的可持久化、可复制的日志。7.Bitmaps位图虽然位图不是 Redis 的一种独立数据类型但 Redis 提供了位操作命令允许用户将字符串键当作位数组bit array或位图bitmap来处理实现一些高效的位运算操作。8.HyperLogLog超对数日志HyperLogLog 是 Redis 的一种基数统计数据类型它提供了在允许一定误差的情况下使用极少的内存空间来统计大量数据的基数的功能。9.Geospatial地理空间Redis 的地理空间索引用于地理位置信息的查询和计算比如获取某个位置附近的其它位置等。虽然 Redis 支持多种数据类型但每个 key 只能对应一种数据类型。也就是说你不能将一个 key 同时设置为字符串和哈希。此外Redis 的数据类型并不是固定不变的随着版本的更新Redis 可能会引入新的数据类型或改进现有数据类型的功能。3 Redis 如何实现消息队列功能 1.基于 List 实现的队列Redis 的 List 数据结构可以很方便地用来实现队列。List 提供了从头部插入LPUSH和从尾部弹出RPOP或者从尾部插入RPUSH和从头部弹出LPOP元素的原语操作这些操作都是原子性的因此可以很容易地实现一个线程安全的队列。 生产者使用 LPUSH 或 RPUSH 将消息放入队列。 消费者使用 RPOP 或 LPOP 从队列中取出消息。 如果需要处理多个消费者竞争同一个消息的情况可以使用 BLPOP 或 BRPOP 命令这些命令在队列为空时会阻塞直到有消息可用。 2.发布/订阅模型: Pub/SubRedis 的发布/订阅模式允许发送者发布者发送消息到频道而接收者订阅者可以订阅一个或多个频道以接收消息。 发布者使用 PUBLISH 命令将消息发布到指定的频道。 订阅者使用 SUBSCRIBE 命令订阅一个或多个频道并使用 PSUBSCRIBE 命令订阅匹配特定模式的频道。当有消息发布到这些频道时订阅者会收到消息。 需要注意的是发布/订阅模式中的消息是即时发送的如果订阅者当前不在线那么它就不会收到这些消息。因此这种模式更适用于实时通信或事件通知等场景。 3.Redis 5.0 新增的队列: StreamRedis 5.0 引入了 Stream 数据类型它是一个持久化的、可靠的消息队列。Stream 提供了消息的持久化存储并且支持消费者组的概念使得多个消费者可以协作处理消息队列。 生产者使用 XADD 命令将消息添加到 Stream 中。每个消息都有一个唯一的 ID并且可以按照时间顺序排列。 消费者组消费者可以加入一个或多个消费者组并从 Stream 中读取消息。每个消费者组都有一个或多个消费者它们共同处理 Stream 中的消息。 消息确认消费者处理完消息后需要发送一个确认信号XACK 命令以告知 Stream 该消息已经被处理。如果消费者在处理消息时崩溃那么未确认的消息可以被其他消费者重新处理。 Stream 还提供了多种查询和监控功能使得开发者可以更方便地管理和维护消息队列。 基于 List 的实现简单直观适用于简单的队列需求发布/订阅模型适用于实时通信和事件通知等场景而 Stream 则提供了更强大和灵活的消息队列功能适用于复杂的业务场景。
4 Redis 的持久化机制 1.RDB 持久化RDB 持久化方式能够在指定的时间间隔能对你的数据进行快照存储。 在默认情况下 Redis 将数据库快照保存在名字为 dump.rdb 的二进制文件中。 在Redis 运行时 RDB 程序将当前内存中的数据库快照保存到磁盘文件中 在Redis 重启动时 RDB 程序可以通过载入 RDB 文件来还原数据库的状态。
# RDB 自动持久化规则
# 当 900 秒内有至少有 1 个键被改动时自动进行数据集保存操作
save 900 1
# 当 300 秒内有至少有 10 个键被改动时自动进行数据集保存操作
save 300 10
# 当 60 秒内有至少有 10000 个键被改动时自动进行数据集保存操作
save 60 10000RDB 的优点与 AOF 相比在恢复大的数据集的时候RDB 方式会更快一些。与 AOF 相比文件比较小。 RDB 的缺点但有可能会产生长时间的数据丢失。 2.AOF 持久化Redis 在执行命令的时候按照配置的策略定期把命令原本的语句记录一个appendonly.aof 的文件当中,然后通过 fsync 策略,将命令执行后的数据持久化到磁盘中」(不包括读命令)
# AOF 持久化的三种策略
always: 每次有新命令追加到 AOF 文件时就执行一次 fsync 非常慢也非常安全everysec: 每秒 fsync 一次足够快并且在故障时只会丢失 1 秒钟的数据。推荐并且也是默认的措施为每秒 fsync 一次 这种 fsync 策略可以兼顾速度和安全性。no: 从不 fsync 将数据交给操作系统来处理由操作系统来决定什么时候同步数据。更快也更不安全的选择。AOF 的优点AOF 可以[更好的保护数据不丢失]一般 AOF 会以每隔 1 秒通过后台一个线程去执行 fsync 操作如果 Redis 进程挂了最多丢失 1 秒的数据AOF 是将命令直接追加到文件末尾的顺序写写入性能非常高AOF 日志文件的命令通过非常可读的方式进行记录这个非常适合做灾难性的误删除紧急回复如果某人不小心用 flushall 命令清空了所有数据那么可以将日志文件中的 flushall 删除然后进行恢复. AOF 的缺点对于同一份数据源来说一般情况下AOF 文件比 RDB 数据快照要大由于.aof 的每次命令都会写入相对于 RDB 来说需要消耗性能也就更多数据恢复比较慢不适合做冷备 3.混合持久化重启 Redis 时我们很少使用 rdb 来恢复内存状态因为会丢失大量数据。我们通常使用 AOF 日志重写 但是 AOF 重写性能相对 rdb 来说要慢很多这样在 Redis 实例很大的情况下启动需要花费很长的时间。Redis 4.0 为了解决这个问题带来了一个新的持久化选项——混合持久化。 AOF 在进行文件重写(aof 文件里可能有太多没用指令所以 aof 会定期根据内存的最新数据生成 aof 文件)时将重写这一刻之前的内存 rdb 快照文件的内容和增量的 AOF 修改内存数据的命令日志文件存在一起都写入新的 aof 文件新的文件一开始不叫 appendonly.aof等到重写完新的AOF 文件才会进行改名原子的覆盖原有的 AOF 文件完成新旧两个 AOF 文件的替换。
# 混合持久化配置
aof-use-rdb-preamble yes5 Redis 过期键删除策略 对于过期键一般有三种删除策略 定时删除在设置键的过期时间的同时创建一个定时器(timer)让定时器在键的过期时间来临时立即执行对键的删除操作 惰性删除放任键过期不管但是每次从键空间中获取键时都检查取得的键是否过期如果过期的话就删除该键如果没有过期那就返回该键 定期删除每隔一段时间程序就对数据库进行一次检查删除里面的过期键。至于删除多少过期键以及要检查多少个数据库则由算法决定。 三种策略的优缺比较 定时删除策略对内存是最友好的通过使用定时器定时删除策略可以保证过期键会尽可能快地被删除并释放过期键所占用的内存但另一方面定时删除策略的缺点是他对 CPU 是最不友好的在过期键比较多的情况下删除过期键这一行为可能会占用相当一部分 CPU 时间在内存不紧张但是 CPU 时间非常紧张的情况下将 CPU 时间用在删除和当前任务无关的过期键上无疑会对服务器的响应时间和吞吐量造成影响 惰性删除策略对 CPU 时间来说是最友好的程序只会在取出键时才对键进行过期检查这可以保证删除过期键的操作只会在非做不可的情况下进行惰性删除策略的缺点是它对内存是最不友好的如果一个键已经过期而这个键又仍然保留在数据库中那么只要这个过期键不被删除它所占用的内存就不会释放定时删除占用太多 CPU 时间影响服务器的响应时间和吞吐量惰性删除浪费太多内存有内存泄漏的危险。 定期删除策略是前两种策略的一种整合和折中定期删除策略每隔一段时间执行一次删除过期键操作并通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响通过定期删除过期键定期删除策略有效地减少了因为过期键而带来的内存浪费定期删除策略的难点是确定删除操作执行的时长和频率。 Redis 的过期键删除策略Redis 服务器实际使用的是惰性删除和定期删除两种策略。
6 Redis 八种淘汰策略
1.noeviction默认策略当内存不足以容纳新写入数据时新写入操作会报错。这个策略会保证不会删除任何数据但是会拒绝所有的写入请求并返回错误给客户端。 2.volatile-lru针对设置了过期时间的key使用LRULeast Recently Used最近最少使用算法进行淘汰。这意味着最久未使用的key会被优先删除。 3.volatile-lfu同样针对设置了过期时间的key使用LFULeast Frequently Used最不经常使用算法进行淘汰。LFU算法会淘汰那些访问频率最低的key。 4.volatile-ttl这个策略会淘汰那些设置了过期时间且剩余生存时间TTL最短的key。 5.volatile-random随机淘汰设置了过期时间的key。 6.allkeys-lru使用LRU算法淘汰所有key中最近最少使用的那些数据。这个策略不区分key是否设置了过期时间。 7.allkeys-lfu使用LFU算法淘汰所有key中访问频率最低的那些数据。同样这个策略也不区分key是否设置了过期时间。 8.allkeys-random加入键的时候如果过限从所有 key 随机删除
