qq群推广网站免费秒进,手机网站设计技巧,北京建站公司哪家好都选万维科技,wordpress 简约博客目录
前言
一、Redis概述
1.主要特点
2.Redis优缺点
3.Redis为什么这么快
4.Redis那么快#xff0c;为什么不用它做主数据库#xff0c;只用它做缓存
5.线程模型
5.1单线程架构
5.2多线程IO处理#xff08;Redis 6及以上#xff09;
5.3线程模型的优化
6.作用
…目录
前言
一、Redis概述
1.主要特点
2.Redis优缺点
3.Redis为什么这么快
4.Redis那么快为什么不用它做主数据库只用它做缓存
5.线程模型
5.1单线程架构
5.2多线程IO处理Redis 6及以上
5.3线程模型的优化
6.作用
二、Memcached和Redis区别
1.数据模型和数据类型
2.持久性
3.分布式支持
4.高可用和集群
5.原子性
6.其他特性
7.使用场景
三、为什么用Redis而不用Map/Guava做缓存
1. 分布式环境支持
2. 持久化能力
3. 高级数据结构和操作
4. 缓存淘汰策略
5. 网络访问和可伸缩性
6. 工具和社区支持
四、Redis数据类型
五、SortedSet和List区别
相同点
不同点
六、Redis内存消耗殆尽会怎样
1.内存回收策略驱逐策略
2.达到最大内存限制时的行为
3.防止内存用尽的策略
七、Redis内存优化
1. 合理配置内存回收策略
2. 使用适当的数据类型
3. 避免大键和大值
4.利用小对象压缩编码
5.定期删除不用的键
6.使用SCAN命令替代KEYS命令
7.内存碎片整理
8.使用Redis 6的客户端缓存功能
9. 监控和分析内存使用
10. 适时使用持久化
八、Keys命令存在的问题
1. 性能问题
2. 可伸缩性问题
3. 安全性问题
4.解决方案
九、Redis事务
1. MULTI
2. EXEC
3. DISCARD
4. WATCH
5. UNWATCH
6.Redis事务的特点
十、持久化机制
1.RDB持久化
2.AOF持久化 对于相同数量的数据变更AOF文件的大小通常比RDB文件大。
3.混合使用RDB和AOF
4.RDB和AOF如何选择
4.1RDB持久化
4.2AOF持久化
4.3综合使用RDB和AOF
十一、Redis有哪些部署方案
1.单机部署
2.主从复制
3.哨兵模式
4.集群模式
十二、Redis过期键的删除策略
1. 惰性删除Lazy Expiration
2. 定期删除Periodic Expiration
3. 过期键的内存回收
十三、Redis的内存淘汰策略
十四、Mysql与Redis如何保证数据一致性
1. 缓存穿透策略
2. 延迟双删策略
3. 使用事务或数据库锁慎用
4. 消息队列
5. 读写分离与数据同步
十五、Redis中缓存常见问题有哪些如何解决
1.缓存穿透
2.缓存雪崩
3.缓存击穿
4.综合策略
十六、Redis如何实现消息队列
1.利用列表List实现消息队列
2.利用发布/订阅Pub/Sub实现消息队列
3.利用流Streams实现消息队列
十七、Redis如何实现延时队列
1.利用ZSET有序集合实现延时队列
2.利用LIST和BRPOPLPUSH实现延时队列
3.使用Redis的Keyspace通知实现延时队列
十八、Redis中Pipeline的作用
十九、Redis中的lua脚本有什么作用
1. 原子性操作
2. 减少网络开销
3. 代码复用和逻辑封装
4. 提高性能
5. 服务器端计算
6.示例
7.注意事项
二十、什么是RedLock红锁
1.RedLock算法的工作原理
2.RedLock的优点
注意事项
二十一、Redis大key怎么处理
1.发现大Key
2.分割大Key
3.渐进式删除大Key
4.优化数据结构
5.监控和预警
二十二、Redis常见性能问题和解决方案
1.内存使用过多
2.大key操作导致的延迟
3.错误的数据类型选择
4.网络瓶颈
5.不合理的持久化配置
6.单线程模型导致的CPU瓶颈
二十三、说说为什么Redis过期了为什么内存没释放
1.定期删除
2.为什么内存没立即释放
3.解决方案
二十四、Redis突然变慢有哪些原因
1. 内存满导致的交换Swapping
2.键过期策略
3. 持久化阻塞
4. 大量慢查询
5. 网络瓶颈
6.CPU瓶颈
7. 存在bigKey造成阻塞
8. Redis版本问题
9.总结
二十五、为什么 Redis 集群的最大槽数是 16384 个
1. 平衡性能和灵活性
2. 网络开销和重分布开销
3. CRC16哈希和取模操作
4. 实践中的验证
二十六、Redis存在线程安全的问题吗
二十七、Redis遇到哈希冲突怎么办
1.链地址法Separate Chaining
2.动态扩容
3.总结
二十八、Redis的I/O多路复用
二十九、精简面试提问
1.你们项目Redis用的那种集群方式部署了几个节点redis-Cluster有了解吗说说原理
2.生产环境有遇到过那些Redis的问题
3.redis为什么这么快
4.如何保证Redis和MySQL数据一致性
5.在项目中那些场景用了Redis那种数据类型
6.服务宕机重启后如何恢复数据
7.Redis分布式锁用过吗使用过程中遇到过那些问题还用过那些分布式锁
8.Bitmap、HyperLogLog 如何用于大数据量统计
9.请简述Redis的主要特点和应用场景
10.Redis如何实现持久化有哪些持久化策略
11.Redis的内存淘汰策略有哪些
12.Redis如何处理并发问题
13.Redis的过期键删除策略是怎样的
14.Redis和Memcached有什么区别 前言
Redis是一个开源的、基于内存的高性能键值对数据库支持多种类型的数据结构如字符串strings、列表lists、集合sets、有序集合sorted sets、哈希表hashes、位图bitmaps、超日志hyperloglogs和地理空间索引geospatial indexes。由于它的数据是存放在内存中的这使得Redis能够提供极高的数据读写速度通常能够达到每秒数十万次的读写操作。Redis还支持数据的持久化可以将内存中的数据保存到硬盘中保证数据的安全性。
一、Redis概述
1.主要特点
性能极高Redis能够支持超高的每秒读写操作次数这得益于它的内存存储特性和高效的数据结构设计。丰富的数据类型Redis支持多种数据类型使得它可以用于多种场景如缓存、消息队列、应用程序的会话状态存储等。支持数据持久化Redis提供了两种数据持久化的方式RDB快照存储和AOF追加文件存储可以根据需要选择最合适的持久化策略。特性丰富Redis还支持事务、管道pipelining、发布/订阅pub/sub模式等高级功能。主从复制Redis支持主从复制即自动将数据从一个Redis服务器复制到一个或多个从服务器用于数据备份或读写分离。高可用和分布式通过Redis Sentinel来实现高可用性的监控和故障转移以及通过Redis Cluster来实现数据的自动分片和管理。
2.Redis优缺点
优点
高性能Redis将所有数据存储在内存中访问速度快能够支持高达每秒数十万次的读写操作非常适合需要快速读写访问的场景。丰富的数据类型Redis不仅仅是一个简单的键值对存储系统它支持字符串、列表、集合、有序集合、哈希表等数据类型使得Redis可以很容易地解决各种复杂的应用场景。数据持久化Redis支持RDB和AOF两种持久化方式可以将内存中的数据保存到磁盘中确保数据的安全性。支持事务Redis通过MULTI、EXEC、DISCARD和WATCH命令支持事务可以执行一组命令并保证原子性和一致性。高可用和分布式支持通过Redis Sentinel来实现高可用的架构以及通过Redis Cluster来实现自动分片和数据的分布式存储。发布/订阅消息系统Redis支持发布/订阅模式可以用作消息队列系统进行消息的发布和订阅。简单易用Redis有着简洁高效的设计易于安装和使用同时社区提供了丰富的客户端支持覆盖了几乎所有主流的编程语言。
缺点
数据集大小受限于物理内存由于Redis是基于内存的存储系统其数据集的大小受限于服务器的物理内存大小对于大规模数据处理可能需要较高的成本。持久化可能影响性能虽然Redis提供数据持久化的能力但在某些配置下如使用AOF的每次写入模式持久化操作可能会对性能产生影响。单线程模型限制Redis使用单线程模型来处理命令虽然这简化了设计并有助于客户端以确定的顺序执行命令但也意味着在多核服务器上不能有效利用多核CPU的优势。数据安全和隐私问题由于数据存储在内存中如果服务器被侵入数据可能会被轻易访问。虽然Redis提供了一些安全特性如密码保护和SSL加密但默认配置下这些特性并未启用。内存管理挑战在使用Redis时开发者需要仔细管理内存比如定期删除不用的键使用合适的数据结构等以避免内存膨胀。
3.Redis为什么这么快
完全基于内存Redis是一个内存数据库所有的数据读写操作都是直接对内存进行避免了磁盘IO的延迟。内存的访问速度远远快于任何形式的磁盘存储这是Redis高性能的最基本保证。数据结构简单且高效Redis支持的数据结构非常高效如字符串、列表、集合、哈希表等都是为快速访问和操作而优化的。Redis内部对这些数据结构进行了高度优化使得数据操作尽可能地快速和高效。单线程模型Redis采用单线程模型处理命令避免了多线程的上下文切换和竞争条件这使得Redis在处理每个命令时几乎没有任何性能损耗。虽然是单线程但由于是基于内存操作处理速度极快足以应对大多数高并发场景。非阻塞IORedis使用非阻塞IO模型采用多路复用技术。这意味着Redis服务器可以同时处理多个客户端的请求而不是一次处理一个请求极大提高了网络通信的效率。高效的键值存储模型Redis的键值对存储模型非常简单使得数据的查找和访问非常快速。对于大多数操作Redis能够以常数时间复杂度进行处理即O(1)。优化的持久化策略Redis提供了灵活的数据持久化选项如RDB和AOF可以根据需要进行配置以平衡性能和数据安全性。即使在执行持久化操作时Redis也尽量减少对性能的影响。精心设计的协议Redis协议简洁且易于解析客户端和服务器之间的通信非常高效减少了网络通信的开销。避免复杂的计算Redis设计之初就是为了高速存取数据它避免了复杂的查询和事务处理每个操作都尽可能地简单和快速。 通过这些设计和实现上的优化Redis能够提供极高的性能满足高并发、低延迟的应用场景需求。这也是Redis在缓存、消息队列、实时分析等多种场景中被广泛使用的原因。 4.Redis那么快为什么不用它做主数据库只用它做缓存
Redis虽然以其高性能而闻名特别是在处理大量数据时提供极低的延迟和高吞吐量但将其作为主数据库使用而不仅仅是缓存需要考虑以下几个方面的限制和挑战
内存成本Redis是基于内存的存储系统而内存的成本相比于硬盘等其他存储介质要高得多。随着数据量的增加依赖Redis作为主数据库的成本会迅速增加特别是对于存储大量数据的应用来说这可能是一个显著的成本因素。数据持久性虽然Redis提供了数据持久化的功能如RDB和AOF以保证数据安全但这些机制在发生系统故障时仍然可能面临数据丢失的风险尤其是在极端情况下。对于需要严格数据一致性和完整性保证的应用依赖于内存的数据库可能不是最佳选择。数据安全和隐私问题由于Redis设计为高性能的存储系统其安全特性可能不如专门设计用于持久存储的数据库系统。虽然可以通过配置和使用SSL等手段增强安全性但对于需要高级安全保障的应用可能需要更专业的解决方案。复杂查询的限制Redis虽然支持多种数据结构但它不像关系数据库那样支持SQL查询语言和复杂的查询操作。对于需要执行复杂查询、联结操作或事务处理的应用Redis可能不能满足需求。单线程模型的限制Redis的单线程模型虽然简化了操作并保证了高性能但也意味着在多核处理器上无法充分利用硬件资源。对于计算密集型的场景这可能成为性能的瓶颈。事务处理Redis只支持简单的事务处理对于复杂的事务无能为力比如跨多个键的事务处理。
因此虽然Redis以其出色的性能和灵活的数据结构适用于许多场景如缓存、消息队列、会话存储等但将其作为主数据库使用时上述限制可能会导致它不适合所有应用。通常开发者会结合使用Redis和其他数据库系统如MySQL、PostgreSQL或MongoDB等利用各自的优势以实现更加全面和高效的数据管理和存储解决方案。
5.线程模型
Redis的线程模型是其性能高效的关键因素之一。传统上Redis使用单线程模型来处理客户端的请求但这并不意味着Redis服务器只有一个线程在运行。下面详细解释Redis的线程模型及其如何工作
5.1单线程架构
在Redis 6之前Redis主要使用单个线程来处理所有的命令请求这意味着在任意时刻只有一个命令在被执行。这种设计的优点是避免了多线程编程中常见的并发问题如数据竞争、锁的开销等使得Redis能够以非常高的效率执行操作。
高效的数据结构Redis内部使用高效的数据结构如跳跃表用于有序集合和压缩列表用于小列表和哈希这些结构在单线程模型中表现得非常高效。事件驱动模型Redis使用基于事件的模型通过非阻塞IO和多路复用技术来监听和处理客户端连接这允许单线程高效地处理多个并发连接。
5.2多线程IO处理Redis 6及以上
从Redis 6开始引入了IO多线程模型用于改善网络IO的处理效率。需要注意的是这个多线程模型仅用于网络IO的读写操作而不是命令的执行。命令执行仍然是单线程的保持了Redis操作的原子性和一致性。
IO线程可以配置多个IO线程来并行处理客户端请求的读写操作。这些线程主要负责将命令从网络读取到内存中以及将响应从内存写回到网络不涉及命令的实际执行。主线程尽管引入了IO线程Redis的命令处理逻辑仍然在单个主线程中执行。这意味着数据的读取、写入、操作等都是由单个线程安全地执行避免了并发访问的问题。
5.3线程模型的优化
合理配置IO线程在多核处理器上通过合理配置IO线程的数量可以显著提高Redis处理大量并发连接的能力而不影响命令执行的性能。利用异步操作Redis支持异步操作如异步写入AOF重写和异步删除惰性删除这些操作可以在后台线程中完成减少对主线程处理能力的影响。
Redis的线程模型优化了性能和并发处理能力同时保持了简单和高效的特点。通过将命令执行与网络IO分离Redis能够在保证操作安全性的同时充分利用现代多核CPU的性能提供高吞吐量和低延迟的数据服务。
6.作用
Redis作为一个高性能的键值存储系统因其出色的读写速度和灵活的数据结构被广泛应用于多种场景中。以下是Redis的一些典型应用场景
缓存系统这是Redis最常见的用途之一。利用其高速的读写性能可以将热点数据存储在Redis中减轻后端数据库的压力加快数据的读取速度提高整体的系统响应速度。会话存储Session StoreRedis可以用来存储用户会话信息尤其适用于分布式系统中的会话共享。由于Redis提供持久化功能即使系统重启用户的会话信息也不会丢失。消息队列系统利用Redis的发布/订阅模式可以实现消息队列的功能支持高并发的消息传递。此外利用列表List数据结构也可以实现简单的消息队列。实时分析Redis的高性能读写能力使其非常适合需要实时分析处理的场景如计数器、实时系统监控、实时交易分析等。排行榜/计数器Redis的有序集合Sorted Set数据结构非常适合实现排行榜系统可以快速添加、删除、更新元素并能够实时获取排名信息。地理空间数据处理Redis的地理空间索引Geo功能可以用来存储地理位置信息并进行地理位置查询适合开发地理位置服务如查找附近的人或地点。分布式锁Redis可以实现分布式锁的功能用于多个进程或系统之间的同步访问控制。通过SET命令的NXNot Exists选项可以确保只有一个客户端能够获得锁。数据过期处理Redis支持设置键的生命周期可以用于需要过期处理的场景如临时访问令牌的存储、缓存数据的自动清理等。全页缓存FPC对于静态网页或者页面输出结果不经常变化的场景可以将页面HTML存储在Redis中实现快速的页面加载。轻量级社交网络功能利用Redis的数据结构和操作命令可以实现社交网络中的某些功能如好友关系、共享状态更新、时间线等。
二、Memcached和Redis区别
Memcached和Redis都是高性能的分布式缓存系统广泛用于提升大型动态Web应用的速度减少数据库负载。尽管它们在某些场景下可以互换使用但两者之间还是存在一些关键的区别
1.数据模型和数据类型
Memcached提供一个简单的键值存储解决方案主要支持字符串类型的数据。这意味着它在处理只需要缓存简单数据的场景中非常有效。Redis支持更丰富的数据类型包括字符串Strings、列表Lists、集合Sets、有序集合Sorted Sets、哈希表Hashes、位图Bitmaps、超日志HyperLogLogs和地理空间索引Geospatial Indexes。这种多样性使得Redis能够适用于更复杂的应用场景。
2.持久性
Memcached主要设计为一个纯缓存系统没有提供数据持久化功能一旦缓存服务器重启所有的数据都会丢失。Redis提供多种数据持久化选项如RDB周期性快照和AOFAppend Only File追加写文件。这使得Redis既可以用作缓存系统也可以用作持久化的NoSQL数据库。
3.分布式支持
Memcached需要外部工具或客户端支持来实现分布式缓存环境本身不提供数据分片或集群功能。Redis自Redis 3.0起官方支持集群模式提供数据分片Sharding、自动分区和高可用性等特性。
4.高可用和集群
Memcached虽然可以通过一些客户端库实现简单的高可用方案但Memcached本身不提供内建的高可用或复制特性。Redis支持主从复制Replication、哨兵系统Sentinel和自动分区的集群为构建高可用的分布式缓存环境提供了更多的可能性。
5.原子性
Memcached和Redis都支持原子操作但由于Redis支持更多的数据类型因此Redis在这方面提供了更丰富的原子操作命令。
6.其他特性
Redis还提供了许多Memcached不具备的特性如发布/订阅消息系统、Lua脚本支持、事务以及地理空间支持等。
7.使用场景
Memcached适用于简单的缓存场景特别是当需要快速缓存大量数据时。Redis不仅适用于缓存场景还可以用于需要复杂数据结构和持久化需求的应用比如消息队列、实时分析、地理空间数据处理等。
三、为什么用Redis而不用Map/Guava做缓存
使用Redis而不是map或Guava做缓存通常是出于以下几个考虑
1. 分布式环境支持
Redis是一个独立的服务器进程能够支持多个应用实例共享缓存数据非常适合分布式环境。这意味着无论是扩展应用实例还是实现高可用性Redis都能够提供一致的服务。Map/Guava缓存通常只能在单个JVM实例中使用不适合分布式环境因为每个应用实例都会维护自己的缓存副本这不仅增加了内存消耗也使得缓存数据难以保持一致。
2. 持久化能力
Redis提供了数据持久化的能力可以将内存中的数据保存到硬盘中这对于需要保证数据不会因为进程退出或服务器重启而丢失的场景非常重要。Map/Guava缓存通常只存在于内存中一旦应用重启所有的缓存数据都会丢失。
3. 高级数据结构和操作
Redis提供了丰富的数据结构如列表、集合、有序集合等和相应的操作这些数据结构和操作对于实现复杂的缓存策略和功能非常有用。Map/Guava缓存通常提供较为基本的数据结构和操作可能无法满足某些复杂应用场景的需求。
4. 缓存淘汰策略
Redis内置了多种缓存淘汰策略如LRU最近最少使用、LFU最不经常使用等这些策略可以帮助自动管理缓存空间移除不再需要的缓存项。Map/Guava缓存虽然也提供了一些缓存淘汰策略但相比Redis来说可能不那么灵活或强大。
5. 网络访问和可伸缩性
Redis作为一个网络服务可以被应用程序通过网络访问这使得它可以很容易地水平扩展满足不断增长的数据和访问量。Map/Guava缓存是在应用程序的同一进程内访问不支持网络访问限制了其在大型分布式系统中的可伸缩性。
6. 工具和社区支持
Redis拥有一个活跃的社区和丰富的工具生态提供了大量的客户端库、监控工具和管理工具等。Map/Guava虽然也是广泛使用的Java库但在分布式缓存方面的工具和社区支持可能不如Redis丰富。
四、Redis数据类型
Redis支持多种数据类型使其能够应对不同的数据存储需求。下面是Redis支持的主要数据类型 字符串String 最基本的类型可以存储任何形式的字符串包括文本或二进制数据。 用途广泛如缓存文本、存储各种计数器或共享状态等。 列表List 一个字符串列表按照插入顺序排序。 可以在列表的头部或尾部添加元素实现栈Stack或队列Queue。 适合用于消息队列、文章的评论列表等场景。 集合Set 一个无序且元素唯一的字符串集合。 支持添加、删除、查询操作以及判断某个成员是否存在于集合中。 适用于标签系统、社交网络中的好友关系等。 有序集合Sorted Set 不仅每个元素都是唯一的而且每个元素都会关联一个双精度的分数Redis正是通过分数来为集合中的成员进行从小到大的排序。 支持按照分数范围或成员查询非常适合排行榜、带有优先级的任务队列等。 哈希Hash 类似于程序语言中的哈希表可以存储键值对集合。 键和值都是字符串类型适合存储对象或多个字段的聚合数据如用户的属性信息等。 位图Bitmap 实际上是在字符串类型基础上的一种逻辑表示可以看作是由0和1组成的数组。 通过位操作可以高效地进行计数和标记适用于在线用户统计、特征标记等。 超日志HyperLogLog 一种基于概率的数据结构用于高效地进行基数统计的近似计算如统计独立访客数量。 占用内存非常小无论统计多少元素只需要12KB内存。 地理空间索引Geospatial 可以存储地理位置信息并进行范围查询、距离计算等地理空间相关的操作。 适用于地理位置服务如查找附近的人或地点。
五、SortedSet和List区别
Redis中的Sorted Set有序集合和List列表是两种不同的数据结构它们在使用场景和操作上各有特点。以下是它们的异同点
相同点
动态容器Sorted Set和List都是可以动态增长和缩减的容器不需要事先声明容器大小。存储字符串两者都可以存储字符串作为元素。适用于集合操作它们都可以进行添加、删除和获取元素等基本集合操作。
不同点 排序 Sorted Set元素根据分数score进行自动排序每个元素关联一个双精度的分数Redis正是通过分数来为集合中的成员进行从小到大的排序。这意味着即使你添加元素的顺序改变元素的排列顺序也总是按照分数来确定。 List元素按照插入顺序排序支持在列表的头部或尾部添加元素类似于Java中的LinkedList。列表保持了元素被添加的顺序。 元素唯一性 Sorted Set集合中的每个元素必须是唯一的但分数(score)可以重复。 List允许重复元素即同一个值可以出现多次。 性能 Sorted Set添加、删除、查找操作的复杂度大致为O(logN)N为集合的元素数量这是因为Redis内部使用跳跃表skiplist或其他平衡树结构来实现Sorted Set保证了即使数据量大时操作仍然高效。 List在列表的头部left或尾部right添加、删除操作的复杂度为O(1)但是如果对列表中间的元素进行操作复杂度可能会达到O(N)。 使用场景 Sorted Set适合需要对元素排序的场景如排行榜、带有优先级的任务队列等。 List适合实现队列或栈这样的数据结构如消息队列等。
六、Redis内存消耗殆尽会怎样
当Redis的内存用完时它的行为取决于配置的内存回收策略和最大内存限制。Redis提供了几种内存管理机制来处理内存不足的情况
1.内存回收策略驱逐策略
Redis允许通过maxmemory-policy配置项来设置内存回收策略当内存使用达到maxmemory限制时Redis会根据设置的策略来回收内存。常见的回收策略包括
noeviction不回收任何键对写操作返回错误但允许删除操作和某些特殊情况下的写操作如对现有键的SET操作。allkeys-lru尝试回收最近最少使用Least Recently Used, LRU的键不论键有无过期设置。volatile-lru只从已设置过期时间的键中回收最近最少使用的键。allkeys-random从所有键中随机回收。volatile-random从已设置过期时间的键中随机回收。volatile-ttl回收剩余生存时间Time To Live, TTL最短的键。
2.达到最大内存限制时的行为
写操作受限如果配置了noeviction策略当内存用尽时对于新的写操作Redis会返回错误错误码OOMOut of Memory。这种情况下只有对现有键的某些写操作如覆盖已有键的值才被允许。性能影响即使配置了自动回收策略当频繁达到内存限制并触发回收机制时Redis的性能可能会受到影响因为需要不断地选择并移除键。数据丢失采用回收策略虽然可以继续进行写操作但回收旧数据可能导致数据丢失。
3.防止内存用尽的策略
合理配置根据应用场景合理设置maxmemory值和maxmemory-policy确保系统稳定运行。监控定期监控Redis的内存使用情况及时调整策略或增加资源。数据分片在多个Redis实例间分配数据分散内存压力。使用Redis集群通过搭建Redis集群实现数据的自动分片和负载均衡提高系统的可扩展性和可用性。
七、Redis内存优化
Redis作为内存数据库其性能强依赖于内存的管理和优化。以下是一些Redis内存优化的策略
1. 合理配置内存回收策略
通过maxmemory-policy配置合适的内存回收策略根据实际应用场景选择最合适的策略如volatile-lru、allkeys-lru、volatile-ttl等以优化内存使用。
2. 使用适当的数据类型
合理使用Redis支持的数据类型比如使用哈希Hash类型存储对象来节省空间因为当存储多个字段的小对象时哈希类型比独立的字符串类型更节省内存。
3. 避免大键和大值
尽量避免存储大键key和大值value特别是列表、集合、哈希和有序集合等数据类型大的数据结构会显著增加内存的使用。对于大的列表或集合考虑分片到多个小对象中。
4.利用小对象压缩编码
Redis针对小对象提供了压缩编码如ziplist和intset这可以显著减少内存使用。这些优化通常是自动进行的但了解它们的存在可以帮助我们更好地规划数据结构。
5.定期删除不用的键
使用EXPIRE命令为键设置生存时间TTL让Redis自动删除过期的数据释放内存。
6.使用SCAN命令替代KEYS命令
当需要查找符合特定模式的键时使用SCAN命令代替KEYS命令因为KEYS命令会一次性加载所有匹配的键对内存和CPU资源消耗较大。
7.内存碎片整理
监控内存碎片率通过INFO memory命令查看mem_fragmentation_ratio指标如果内存碎片率过高可以通过重启Redis服务或使用MEMORY PURGE命令在Redis 4.0以上版本可用来减少内存碎片。
8.使用Redis 6的客户端缓存功能
Redis 6引入了客户端缓存能力通过将热点数据缓存在客户端来减轻服务器端的内存压力。
9. 监控和分析内存使用
定期使用INFO memory命令监控内存使用情况使用MEMORY USAGE命令分析特定键的内存使用帮助识别和优化内存使用热点。
10. 适时使用持久化
合理配置RDB和AOF持久化策略虽然主要是为了数据安全但适时的数据持久化和加载也可以帮助管理内存使用特别是在需要重启Redis释放内存碎片时。
八、Keys命令存在的问题
Redis的KEYS命令用于查找所有符合给定模式的键。尽管它在某些场景下非常有用但在生产环境中使用时存在一些显著的问题
1. 性能问题
阻塞性能KEYS命令在执行时会遍历整个数据库的所有键这是一个阻塞操作。在拥有大量键的数据库中这会导致长时间的阻塞期间Redis不能处理其他命令影响Redis服务器的响应性能。CPU资源消耗大规模的键遍历会消耗大量的CPU资源对系统性能产生负面影响特别是在高流量的生产环境中。
2. 可伸缩性问题
随着数据量的增加KEYS命令执行所需的时间和资源消耗将成指数级增长这限制了其在大型数据库中的可用性。
3. 安全性问题
在生产环境中误用KEYS命令可能导致服务暂时不可用影响应用的稳定性和用户体验。
4.解决方案
为了避免这些问题推荐使用以下方法代替KEYS命令
使用SCAN命令SCAN命令是为了替代KEYS命令而设计的。它提供了一种方式来增量地遍历键空间允许你每次只获取部分匹配的键。这样即使在处理大量数据时也不会阻塞服务器因为你可以控制每次扫描返回的结果数量。SCAN命令提供了一个游标每次调用后都会返回一个新游标你可以在下次迭代时使用这个新游标直到游标返回0表示遍历结束。维护索引对于需要频繁查询的键可以考虑在更新数据的同时将这些键的索引存储在特定的数据结构如集合中。这样当你需要查询这些键时可以直接查询索引集合而不是遍历整个键空间。
通过使用SCAN命令或者维护索引可以在不牺牲性能的情况下有效地查询和管理Redis中的键从而避免KEYS命令带来的问题。
九、Redis事务
Redis事务提供了一种将多个命令打包然后按顺序执行的机制确保事务内的命令序列可以连续执行中间不被其他命令请求所打断。Redis的事务通过以下几个关键命令来实现
1. MULTI
标记一个事务块的开始。之后的所有命令都会被加入到队列中并不会立即执行。
2. EXEC
执行所有在MULTI之后加入队列的命令。当执行EXEC时队列中的所有命令会被连续执行期间不会插入其他客户端的命令。
3. DISCARD
取消事务放弃执行所有已经被加入队列的命令。
4. WATCH
监视一个或多个键如果在执行事务之前这些键被其他命令改变了那么事务将被打断。WATCH命令可以用来实现乐观锁。
5. UNWATCH
取消WATCH命令对所有键的监视。
6.Redis事务的特点
原子性Redis的事务虽然保证了事务内的命令序列连续执行但它与传统数据库的事务不同Redis的事务不支持回滚。如果事务队列中的某个命令执行失败后续的命令仍会被执行而不是终止事务。没有隔离级别的概念在Redis事务执行过程中不可能有其他客户端插入命令。乐观锁通过WATCH命令实现乐观锁可以监视一个或多个键如果在事务执行之前这些键的值发生了变化那么事务将不会执行。 #一个Redis事务的简单示例
WATCH mykey
MULTI
INCR mykey
INCR mykey
EXEC 这个事务尝试对键mykey的值进行两次增加。如果在执行事务之前mykey的值被其他客户端改变了那么这个事务将不会执行。 注意 使用事务时需要特别注意监视的键。如果事务执行期间任何一个被监视的键被其他命令所改变那么整个事务都将不会执行。Redis事务不支持回滚一旦事务开始执行即使有命令失败后续的命令也会继续执行。因此在设计事务时需要考虑到这一点确保事务中的每个命令都不会失败。 Redis事务虽然提供了一种执行多个命令的方法但它的机制与传统数据库的事务有所不同使用时需要对其特性和限制有充分的了解。
十、持久化机制
Redis提供了两种主要的数据持久化机制来保证数据的安全性RDBRedis Database和AOFAppend Only File。这两种机制可以单独使用也可以同时使用以达到最佳的数据安全性。下面是对这两种持久化机制的详细介绍
1.RDB持久化
RDB持久化是通过快照snapshotting来实现的它会在特定的时间间隔保存那一刻的数据快照。 优点 使 用RDB进行持久化可以最大化Redis的性能因为Redis在主线程中不需要做任何磁盘I/O操作磁盘I/O由单独的子进程负责这样可以确保性能的最优化。 RDB非常适合用于备份因为每个RDB文件都是数据的完整备份。 RDB是一个非常紧凑compact的文件它保存了Redis在某一时刻的数据。这使得Redis重启的时 候加载RDB文件非常快。 缺点 如 果需要尽可能少地丢失数据比如在Redis崩溃的情况下RDB可能不是最佳选择因为你会丢失最后一次快照之后的所有修改。 在 保存快照的过程中如果数据集很大可能会对系统性能产生影响。
2.AOF持久化
AOF持久化通过记录每个写操作命令来保存数据状态这些命令会被追加到AOF文件的末尾。
优点 A OF可以提供更好的数据安全性通过配置你可以控制数据写入磁盘的频率比如每秒钟同步一次或每次写入都同步。 AOF文件是一个只追加文件即使在写入过程中系统崩溃也不会像RDB那样有文件损坏的风险。 AOF 提供了一种更加丰富的数据恢复策略因为你可以决定从AOF文件的哪个点开始恢复数据。缺点 对于相同数量的数据变更AOF文件的大小通常比RDB文件大。 根据A OF的配置尤其是同步策略AOF可能会比RDB慢因为AOF需要在每次写入时进行磁盘I/O操作。
3.混合使用RDB和AOF
Redis还允许同时使用RDB和AOF结合两者的优点。在这种配置下Redis可以从AOF文件中重建状态以确保操作的完整性同时也可以定期生成RDB快照用于快速重启和数据备份。
4.RDB和AOF如何选择
在选择Redis的RDB和AOF持久化机制时需要根据应用的具体需求来决定。下面是一些考虑因素帮助你做出选择
4.1RDB持久化
优点 性能 RDB可以提供更高的性能。快照操作在子进程中进行对主进程的影响较小。 数据压缩RDB文件是压缩过的二进制文件占用空间较小。 快速恢复使用RDB进行数据恢复比AOF快特别是在处理大数据集时。适用场景 数据备份。 快速恢复需求较高的场景。 对数据完整性要求不是非常高的场景可以容忍几分钟内的数据丢失。缺点 在发 生故障时可能会丢失最后一次快照之后的数据。 数据集非常大时保存快照可能会影响性能。
4.2AOF持久化 优点 数据安全AOF提供了更好的数据安全性可以配置为每秒同步一次或每个命令同步减少数据丢失的风险。 容错性强由于AOF采用追加写的方式即使在追加过程中系统崩溃也不会破坏整个文件且可以通 过redis-check-aof工具修复损坏的AOF文件。适用场景 对数据完整性要求非常高的场景。 可 以接受相对较慢的恢复速度或有能力处理较大的AOF文件。缺点 文件大小AOF文件通常比RDB文件大需要更多的磁盘空间。 恢复速度 AOF恢复速度通常比RDB慢。
4.3综合使用RDB和AOF
对于大多数生产环境推荐同时启用RDB和AOF以结合两者的优点 使用RDB进行快速的灾难恢复。使用AOF保证更高的数据完整性和安全性。
通过合理配置如调整AOF的重写策略和频率以及定期生成RDB快照可以最大限度地提高数据的安全性同时确保系统的性能。
十一、Redis有哪些部署方案
1.单机部署
概述单机部署是最简单的部署方式只涉及到一个Redis服务器实例。 适用场景 开 发和测试环境。 小型应用或负载较低的场景。 作为缓存 系统不涉及数据持久化或数据丢失风险可控的场景。 优点 部 署简单管理方便。 资源消耗相对较低。
缺 点 高 可用性和数据持久化保证较弱。 系统的 扩展性受限。
2.主从复制
概述主从复制模式涉及一个主服务器和一个或多个从服务器。数据更新操作在主服务器上执行然后数据的改动会同步到所有的从服务器。
主从复制的原理
当启 动一个从节点时它会发送一个 PSYNC 命令给主节点如果是从节点初次连接到主节点那么会触发一次全量复制。此时主节点会启动一个后台线程开始生成一份 RDB 快照文件同时还会将从客户端 client 新收到的所有写命令缓存在内存中。RDB 文件生成完毕后 主节点会将RDB文件发送给从节点从节点会先将RDB文件写入本地磁盘然后再从本地磁盘加载到内存中接着主节点会将内存中缓存的写命令发送到从节点从节点同步这些数据如果从节点跟主节点之间网络出现故障连接断开了会自动重连连接之后主节点仅会将部分缺失的 数据同步给从节点。
适用场景
数 据备份。读 写分离提高读操作的扩展性。
优点
数据 有备份提高了数据安全性。支持读 写分离可以通过增加从服务器来提高读操作的并发能力。
缺点 主服务器如果发生故障需要手动切换到从服务器高可用性不如哨兵和集群模式。
3.哨兵模式
概述哨兵Sentinel系统是基于主从复制模式的自动故障转移解决方案。哨兵负责监控所有Redis服务器并在主服务器故障时自动将一个从服务器升级为新的主服务器。
工作原理 每个 Sentinel以每秒钟一次的频率向它所知道的MasterSlave以及其他 Sentinel 实例发送一个 PING命令。如果一个实例距离最后一次有效回复 PING 命令的时间超过指定值 则这个实例会被 Sentine 标记为主观下线。如果一个Master被标记为主观下线则正在监视这个Master的所有 Sentinel 要以每秒一次的频率确认Master是否真正进入主观下线状态。当有足够数量的 Sentinel大于等于配置文件指定值在指定的时间范围内确认Master的确进入了主观下线状态 则Master会被标记为客观下线 。若没有足够数量的 Sentinel 同意 Master 已经下线 Master 的客观下线状态就会被解除。若 Master重新向 Sentinel 的 PING 命令返回有效回复 Master 的主观下线状态就会被移除。哨兵节点会选举出哨兵 leader负责故障转移的工作。哨兵 leader 会推选出某个表现良好的从节点成为新的主节点然后通知其他从节点更新主节点信息 。
适用场景 对高可用性要求较高的生产环境。
优点
实现自 动故障转移和主从切换提高系统的高可用性。支持服务 发现客户端可以查询哨兵获取当前的主服务器地址。
缺点
部署和配 置相对复杂。
4.集群模式
概述Redis集群通过分片Sharding将数据分布在多个Redis节点上每个节点存储不同的数据片段。集群模式支持自动分区、数据复制和故障转移。
工作原理 通过哈希的方式将数据分片每个节点均分存储一定哈希槽(哈希值)区间的数据默认分配了16384 个槽位每份数据分片会存储在多个互为主从的多节点上数据写入先写主节点再同步到从节点(支持配置为阻塞同步)同一分片多个节点间的数据不保持一致性读取数据时当客户端操作的key没有分配在该节点上时redis会返回转向指令指向正确的节点扩容时时 需要需要把旧节点的数据迁移一部分到新节点 在 redis cluster 架构下每个 redis 要放开两个端口号比如一个是 6379另外一个就是 加1w 的端口号比如 16379。 16379 端口号是用来进行节点间通信的也就是 cluster bus 的东西cluster bus 的通信用来进行故障检测、配置更新、故障转移授权。cluster bus 用了另外一种二进制的协议gossip 协议用于节点间进行高效的数据交换占用更少的网络带宽和处理时间。 适用场景
大规模 数据存储和高并发访问。对系统扩展性和 高可用性要求很高的场景。
优点
提 高了数据的可用性和分布式访问的性能。支持线性扩 展可以通过增加更多节点来提升系统容量和性能。
缺点
部署和管 理较为复杂需要处理节点间的数据路由、负载均衡等问题。
总的来说选择哪种部署方案需要根据应用的具体需求、预算以及维护的复杂度等因素综合考虑。对于初学者或小型项目可以从单机部署开始对于需要高可用性和扩展性的生产环境则应考虑使用哨兵系统或集群模式。
十二、Redis过期键的删除策略
Redis处理过期键expired keys的机制主要基于两种策略惰性删除Lazy Expiration和定期删除Periodic Expiration。这两种策略共同确保了内存的有效管理同时避免了单个策略可能带来的性能问题。
1. 惰性删除Lazy Expiration
机制 当客户端尝试访问一个键时Redis会检查该键是否已经过期。如果已经过期Redis会在返回结果之前将其删除确保不会返回过期的数据。优点这种方法可以确保只有被访问的键会被检查和删除避免了不必要的性能开销。缺点如 果过期的键永远不被访问它们将不会被自动删除这可能会导致内存的浪费。
2. 定期删除Periodic Expiration
机制 Redis会定期随机检查一些键如果发现有过期的键就将其删除。这个检查是在Redis的主循环中周期性执行的。优点通过定期删除Redis可以逐渐清理掉过期的键减少内存的浪费。缺点 这种方法不能保证所有的过期键都能被及时删除仍然有可能出现过期键暂时仍占用内存的情况。同时频繁的检查操作可能会消耗一定的计算资源。
3. 过期键的内存回收
主动 清理在Redis进行某些内部操作时比如保存RDB文件或者AOF文件重写时会进行一次全库的过期键扫描以减少持久化文件的大小。配置影 响可以通过调整Redis配置文件中的hz配置项控制后台任务的执行频率包括过期键的检查频率和maxmemory-policy当内存达到限制时决定哪种类型的键会被优先删除来影响过期键处理的行为。
十三、Redis的内存淘汰策略
当Redis用作缓存时经常需要处理内存不足的情况。为了解决这个问题Redis提供了多种内存淘汰策略允许在达到内存上限时自动删除一些键。这些策略可以通过配置maxmemory-policy设置。以下是Redis支持的一些主要内存淘汰策略
Noeviction 不进行任何淘汰当内存使用达到限制时对于写操作会返回错误信息。这是默认策略适用于不允许淘汰任何数据的场景。Allkeys-lru 从所有键中使用LRU最近最少使用算法淘汰数据不论键是否设置了过期时间。Volatile-lru 仅从设置了过期时间的键中使用LRU算法淘汰数据。如果没有足够的过期键可淘汰写操作会返回错误信息。Allkeys-random 从所有键中随机淘汰数据不论键是否设置了过期时间。Volatile-random 仅从设置了过期时间的键中随机淘汰数据。如果没有足够的过期键可淘汰写操作会返回错误信息。Volatile-ttl 从设置了过期时间的键中选择即将过期的键进行淘汰。这种策略会优先淘汰生存时间TTL较短的键。Volatile-lfu (Redis 4.0及以上版本) 从设置了过期时间的键中使用LFU最不经常使用算法淘汰数据。LFU算法会考虑键被访问的频率。Allkeys-lfu (Redis 4.0及以上版本) 从所有键中使用LFU算法淘汰数据不论键是否设置了过期时间
选择合适的淘汰策略
选择哪种内存淘汰策略取决于具体的应用场景
如果希望 缓存尽可能多的数据并且可以接受随机淘汰则可以选择allkeys-random或volatile-random。如果希望保留最近或频繁使用的数据则应该使用allkeys-lru或volatile-lru策略。对于希望 根据访问频率而非最后访问时间来淘汰数据的场景可以使用allkeys-lfu或volatile-lfu策略。
十四、Mysql与Redis如何保证数据一致性
在将MySQL与Redis结合使用时确保数据一致性是一个常见的挑战。MySQL作为关系数据库通常用于持久化存储而Redis作为内存数据库常用于缓存。数据一致性问题主要发生在数据更新时需要同步更新MySQL和Redis中的数据以避免脏读读到旧数据的情况。以下是一些常用的策略来保证MySQL与Redis之间的数据一致性
1. 缓存穿透策略
读操作 流程先查询Redis如果缓存命中则直接返回数据如果缓存未命中则查询MySQL将结果写入Redis并返回给客户端。写操作流 程先更新MySQL更新成功后再删除Redis中对应的键。下一次读请求时由于Redis中没有数据将重新从MySQL加载数据到Redis。
2. 延迟双删策略
为了处理在缓存删除和数据库更新之间可能发生的并发请求可以采用延迟双删策略
写操作流 程
先删 除Redis中的缓存数据。更新MySQL中的数据。延迟一 小段时间例如几百毫秒再次删除Redis中的缓存数据。
延迟的目的是为了处理在这个短暂的时间窗口内可能到达的并发读请求这些请求可能会再次将旧数据加载到缓存中。
3. 使用事务或数据库锁慎用
如果应用场景对数据一致性的要求非常高可以考虑在数据库层面使用事务或锁来确保操作的原子性。例如在更新MySQL数据前获取一个分布式锁直到Redis缓存也更新完成后才释放锁。这种方法虽然可以提高数据一致性但会大大降低系统的性能和吞吐量。
4. 消息队列
在某些场 景下可以通过消息队列来保证MySQL和Redis的数据更新操作的顺序性。操作流程如下
将 数据更新操作封装成消息发送到消息队列。消费 者按顺序消费消息先更新MySQL再更新Redis。
这种方法可以异步地处理数据更新减少直接操作数据库和缓存可能带来的延迟但需要处理消息队列的可靠性和消费顺序问题。
5. 读写分离与数据同步
对于 复杂的系统可以将读写操作分离。写操作直接操作数据库并通过某种机制如定时任务、数据库触发器、日志订阅等异步更新到Redis。这种方式适用于读多写少对实时性要求不高的场景。
十五、Redis中缓存常见问题有哪些如何解决
Redis缓存在提高系统性能、减少数据库压力方面发挥着重要作用但在使用过程中也可能遇到一些常见问题如缓存穿透、缓存雪崩和缓存击穿等。
1.缓存穿透
问题描述缓存穿透是指查询不存在的数据导致请求直接落到数据库上缓存无法命中如果恶意攻击或频繁访问这类不存在的数据将给数据库带来很大压力。
解决策略
空 对象缓存即使数据不存在也将空结果缓存起来并设置较短的过期时间。布隆过滤器在缓存层之前使用布隆过滤器将所有可能存在的数据哈希到一个足够大的位数组中 查询时先通过布隆过滤器判断如果数据绝对不存在则直接返回不再访问数据库。
2.缓存雪崩
问题描述缓存雪崩是指在某一个时间点缓存中大量的或者全部数据都过期失效导致所有的请求都落到数据库上造成瞬时数据库访问压力过大甚至引起数据库崩溃。
解决策略
设置不 同的过期时间为缓存数据设置不同的过期时间避免大量数据同时过期。使用持久化利用Redis的持久化功能即使缓存服务重启也能从磁盘中恢复数据。设置缓存永不过期对于某些热点数据可以设置为永不过期通过程序定期更新缓存内容。
3.缓存击穿
问题描述缓存击穿是指对于某个热点key大量并发访问当这个key在缓存中过期的瞬间持续的大量请求就直接落到数据库上导致数据库瞬时压力骤增。
解决策略
设置热 点数据永不过期对于热点数据可以设置为永不过期通过后台更新缓存来刷新数据。加锁或队 列当缓存失效时不是所有的请求都去数据库加载数据而是用锁或队列的方式保证只有一个请求去数据库取数据并回填到缓存其他请求等待缓存回填后再访问缓存。
4.综合策略
在实践中经常需要结合多种策略来解决缓存相关问题比如对热点数据采用加锁或队列的方式防止缓存击穿对可能不存在的数据采用布隆过滤器预防缓存穿透同时通过设置合理的过期时间和使用Redis持久化功能来防止缓存雪崩。正确的缓存策略和细致的系统设计可以显著提升系统的健壮性和稳定性。
十六、Redis如何实现消息队列
Redis可以利用其内置的数据结构和命令实现简单的消息队列功能主要通过列表List、发布/订阅Pub/Sub机制以及流Streams来实现。
1.利用列表List实现消息队列
Redis的列表数据结构提供了LPUSH/RPUSH命令用于生产消息向列表中添加元素以及BLPOP/BRPOP命令用于消费消息从列表中移除并获取元素。这种方法简单易用适合实现基本的消息队列。 LPUSH myqueue message1
#这条命令将message1添加到名为myqueue的列表头部。 BRPOP myqueue 30
#这条命令从myqueue的尾部移除并获取一个元素如果列表为空则等待最多30秒直到有元素可以移除。 2.利用发布/订阅Pub/Sub实现消息队列
Redis的发布/订阅模式提供了一种消息广播的机制允许发布者向一个频道channel发布消息而所有订阅了该频道的订阅者都能接收到这个消息。这种方式适用于需要消息广播的场景。 PUBLISH mychannel Hello, Redis!
#这条命令向mychannel频道发布消息Hello, Redis!。 SUBSCRIBE mychannel
#这条命令订阅mychannel频道订阅者将接收到通过该频道发布的所有消息。 3.利用流Streams实现消息队列
Redis 5.0 引入了流Streams数据类型提供了更复杂的消息队列功能支持持久化、消费者组Consumer Groups、消息确认等高级特性。Streams是Redis对消息队列和日志数据结构的实现非常适合构建复杂的消息队列和流处理系统。 XADD mystream * field1 value1 field2 value2
#这条命令向名为mystream的流中添加一个包含field1和field2的消息。 XGROUP CREATE mystream mygroup $ MKSTREAM
XREADGROUP GROUP mygroup myconsumer COUNT 1 BLOCK 1000 STREAMS mystream
#第一条命令创建一个名为mygroup的消费者组关联到mystream流。
#第二条命令以阻塞模式从mystream流中读取消息作为消费者组mygroup中的myconsumer消费者。 通过上述三种方式Redis可以灵活地实现消息队列的功能满足不同场景下的需求。选择哪种方式取决于具体的应用场景和对消息队列功能的需求。
十七、Redis如何实现延时队列
1.利用ZSET有序集合实现延时队列
在这种方法中可以利用Redis的有序集合ZSET来实现延时队列。将消息以成员member的形式存储在ZSET中使用消息的执行时间作为分数score。通过定期轮询ZSET取出已到执行时间的消息进行处理。 ZADD mydelayqueue timestamp message
#代表消息的执行时间Unix时间戳message是要延时执行的消息内容。这条命令将消息加入到名为mydelayqueue的有序集合中使用执行时间作为分数。 ZRANGEBYSCORE mydelayqueue 0 current_timestamp WITHSCORES LIMIT 0 1
ZREM mydelayqueue message
#第一条命令获取已到执行时间当前时间戳之前的消息WITHSCORES选项表示同时返回消息的分数即执行时间LIMIT 0 1表示每次只取一个。
#第二条命令从集合中移除已处理的消息。 2.利用LIST和BRPOPLPUSH实现延时队列
这种方法结合使用了列表LIST和BRPOPLPUSH命令。首先将消息存储在一个列表中然后使用BRPOPLPUSH命令将消息从一个列表转移到另一个列表并设置超时时间。如果超时时间到了消息就会被转移这时就可以处理这个消息了。 LPUSH myqueue message
#这条命令将消息message添加到myqueue列表的头部。 BRPOPLPUSH myqueue myprocessingqueue timeout
#这条命令尝试从myqueue列表的尾部移除一个元素并将其推入myprocessingqueue列表的头部如果myqueue为空命令将阻塞直到等待超时或发现新的元素可以移动。是超时时间单位为秒。 3.使用Redis的Keyspace通知实现延时队列
Redis的Keyspace通知功能可以用来实现另一种类型的延时队列。通过为每个消息设置一个具有TTLTime-To-Live的key当key过期时Redis会生成一个过期事件。通过订阅这些事件可以实现延时任务的触发。
首先需要开启Redis的Keyspace通知功能在redis.conf配置文件中设置 notify-keyspace-events Ex SETEX message:message_id delay message content
#这条命令创建一个key例如message:123设置其TTL为秒值为message content。message_id是消息的唯一标识。 需要一个外部的订阅者订阅Redis的过期事件然后根据事件处理消息。
十八、Redis中Pipeline的作用
Redis中的Pipeline管道是一种将多个命令打包然后一次性发送给Redis服务器执行的技术。使用Pipeline可以显著提高Redis操作的效率特别是在需要执行大量独立命令时。它的主要作用和优点包括
减少网络 开销
在没有使用Pipeline的情况下每执行一个Redis命令客户端都需要发送一个请求到服务器然后等待服务器响应。这种“请求-响应”模式在网络延迟较高或需要执行大量操作时会非常低效因为每个命令的执行都会受到网络延迟的影响。使用Pipeline后可以一次性发送多个命令到服务器然后再一次性接收所有命令的执行结果这样可以显著减少网络传输造成的延迟。
提高命令吞吐量
通过Pipeline技术多个命令可以在Redis服务器上连续执行而不需要每执行一个命令就等待客户端的下一个请求这样可以更有效地利用服务器资源提高命令处理的吞吐量。
使用场景
批量插 入或更新数据当需要一次性插入或更新大量数据时使用Pipeline可以减少命令传输时间快速完成数据操作。获取多个键的值如果应用需要一次性获取多个键的值使用Pipeline可以避免多次往返的网络延迟 。
示例
假设需要将多个键值对设置到Redis中不使用Pipeline的方式可能需要这样 SET key1 value1
SET key2 value2
SET key3 value3 每执行一个SET命令都需要等待服务器的响应。而使用Pipeline后这些命令可以打包发送 # 伪代码使用Python的redis客户端
pipe redis.pipeline()
pipe.set(key1, value1)
pipe.set(key2, value2)
pipe.set(key3, value3)
pipe.execute() 注意事项
虽然Pipeline提高了效率但也有一些需要注意的地方
Pi peline会将所有命令的结果存储在内存中直到执行execute()命令。因此如果Pipeline中包含大量命令需要注意内存的使用情况。Pipeli ne不是原子操作Pipeline中的命令仍然是逐个执行的。如果需要原子性操作应该使用Redis的事务MULTI/EXEC命令。
总的来说Pipeline是优化Redis性能的有效手段特别适用于需要大量独立Redis操作的场景
十九、Redis中的lua脚本有什么作用
Redis中的Lua脚本功能是一个强大的特性它允许在Redis服务器上原子性地执行多个命令。这意味着可以把一系列操作写成一个Lua脚本然后作为一个整体执行而不是客户端和Redis服务器之间多次往返通信执行多个命令。
1. 原子性操作
Lua脚本在执行过程中不会被其他命令打断整个脚本作为一个原子操作执行。这对于需要多个步骤完成的操作非常重要确保数据的一致性和完整性无需担心中途发生变化。
2. 减少网络开销
将多个命令封装在一个Lua脚本中执行减少了客户端与Redis服务器之间的网络往返次数提高了效率尤其是在高延迟网络环境中。
3. 代码复用和逻辑封装
Lua脚本支持将复杂的逻辑封装在服务器端客户端只需要调用执行脚本即可。这样可以在不同的应用和客户端之间复用这些逻辑减少了客户端的开发工作量同时也简化了应用逻辑。
4. 提高性能
对于复杂的数据处理逻辑使用Lua脚本可以在Redis服务器内部完成避免了将数据在网络中传输到客户端进行处理的需要从而提高了整体性能。
5. 服务器端计算
Lua脚本使得可以在Redis服务器上直接进行数据处理和计算而不是在客户端进行。这对于数据聚合、过滤或转换等操作特别有用。
6.示例
一个简单的Lua脚本示例实现了原子性地递增键的值并返回新值 local value redis.call(INCR, KEYS[1])
return value 这个脚本使用redis.call函数执行INCR命令递增指定键的值并返回新的值。在客户端只需要发送这个脚本到Redis执行即可例如使用EVAL命令。
7.注意事项
虽然Lua脚本在Redis中非常有用但也需要注意一些事项
性 能影响虽然Lua脚本执行是原子性的但复杂的脚本或大量的数据处理仍可能影响Redis服务器的性能。调试困难相比于客户端代码服务器端的Lua脚本更难调试和测试。安全 性需要确保Lua脚本不会执行恶意操作尤其是在执行用户提供的脚本时。
总体而言Lua脚本为Redis提供了强大的服务器端逻辑处理能力使得数据处理更加灵活和高效。
二十、什么是RedLock红锁
RedLock是一种分布式锁的实现算法由Redis的创造者AntirezSalvatore Sanfilippo提出。这种算法旨在解决在分布式系统中安全地获取锁的问题特别是在基于Redis这种内存数据结构服务器环境下。RedLock提供了一种方法用于在没有中心化锁服务的情况下across多个Redis实例安全地协调锁。
1.RedLock算法的工作原理
RedLock算法的基本思想是使用多个独立的Redis实例来避免单点故障问题算法的步骤如下 获取锁当客户端尝试获取分布式锁时它会向N个Redis实例尝试获取锁在这个过程中客户端会生成一个随机的锁ID通常是一个随机的字符串用于标识这个锁的唯一性。对于每一个Redis实例客户端都会尝试使用相同的key和唯一的锁ID调用SETNX命令或SET命令的一个变体确保原子性例如SET key value NX PX 10000。锁的时间限制在尝试获取锁时客户端会为每个锁设置一个过期时间确保即使发生故障锁也会自动释放避免死锁问题。多数规则客户端需要在大多数N/21的Redis实例上成功获取锁才算成功获取分布式锁。锁的有效时间计算如果客户端在大多数Redis实例上成功获取锁它将计算锁的有效时间即原始有效时间减去获取锁所花费的时间。释放锁当客户端完成其操作后会向所有Redis实例发送释放锁的命令无论它是否在该实例上成功获取了锁。
2.RedLock的优点
容 错性由于RedLock算法在多个Redis实例上操作即使其中一些实例不可用只要满足大多数规则客户端仍然可以安全地获取和释放锁。无中心化RedLock不依赖于单个中心化的锁服务减少了单点故障的风险。 注意事项 性能考虑RedLock算法需要与多个Redis实例通信相比于单个Redis实例的锁可能会有更高的延迟。时间同步RedLock算法的安全性部分依赖于参与的Redis实例之间的时间同步。时钟偏差可能会影响锁的 安全性。
二十一、Redis大key怎么处理
在Redis中大key是指那些存储了大量数据的键如一个包含数百万个元素的列表、集合、哈希表或有序集合。大key在使用过程中会导致多种问题包括但不限于内存使用高、操作延迟增加、阻塞Redis服务器等。因此合理处理大key是优化Redis性能和稳定性的重要一环。以下是处理大key的一些策略
1.发现大Key
在处理大key之前首先需要识别它们。可以使用Redis命令或工具来帮助识别
使 用redis-cli --bigkeys命令快速扫描并报告每种类型的最大key。使用MEMORY USAGE 命令检查特定key的内存占用。使用SCAN命令配合TYPE和HLEN/LLEN/SCARD/ZCARD等命令来迭代查询并检查各个key的大 小。
2.分割大Key
一旦识别出大key可以通过分割的方式来处理。根据key的类型采取不同的分割策略
列表、 集合和有序集合可以将一个大的列表、集合或有序集合分割成多个小的列表、集合或有序集合。例如根据范围如时间段或某些业务逻辑来分割。哈希表 对于大的哈希表可以根据哈希字段的前缀或其他业务逻辑进行分割。
3.渐进式删除大Key
直接删除一个大key可能会导致Redis服务器阻塞影响服务的响应时间。因此推荐使用渐进式删除方法 对于列表、集合、有序集合可以使用LTRIM、SPOP带数量参数、ZREMRANGEBYRANK等命令每次删除一部分元素。对于哈希表可以使用HDEL命令配合HSCAN迭代地删除字段。使用UNLINK命令代替DEL命令删除keyUNLINK命令会在后台异步删除key减少阻塞时间。
4.优化数据结构 评估是否所有数据都需要存储在Redis中对于不经常访问的数据考虑迁移到其他存储系统。使用 更内存高效的数据类型例如利用Redis 5引入的Streams代替某些场景下的列表。
5.监控和预警
设 置监控和预警机制实时监控Redis的内存使用情况和操作延迟及时发现潜在的大key问题。定期 审查和优化数据模型避免未来产生新的大key。
处理大key需要综合考虑数据的使用模式、业务需求和Redis的性能特点采取适当的策略来优化。正确管理大key对于维护Redis实例的高性能和稳定性至关重要。
二十二、Redis常见性能问题和解决方案
Redis作为一个高性能的内存键值数据库其性能问题通常与内存管理、数据结构选择、配置设置以及客户端使用模式有关。下面是一些常见的性能问题及其解决方案
1.内存使用过多
问题描述Redis占用的内存超过了物理内存的大小导致系统使用交换空间从而影响性能。
解决方案
优 化数据结构使用更加内存高效的数据类型例如使用哈希类型存储小对象集合。数据分片将数据分布到多个Redis实例避免单个实例内存使用过多。使用内存淘汰策略通过配置maxmemory-policy来决定当内存达到上限时的数据淘汰策略。定期清理使用EXPIRE设置键的生存时间自动清理不再需要的数据。
2.大key操作导致的延迟
问题描述对包含大量元素的键进行操作如删除一个大列表可能会阻塞Redis导致延迟增加。
解决方案
渐进式 删除对于大key使用渐进式删除策略例如分批次删除元素避免一次性操作导致的长时间阻塞。分割大k ey预先规划避免单个key存储过多的元素如将大列表分割成多个小列表。
3.错误的数据类型选择
问题描述不合理的数据类型选择会导致内存浪费或性能下降。
解决方案
根 据实际使用场景选择合适的数据类型例如利用集合Set而不是列表List存储唯一元素集合。对于频 繁修改的小对象使用哈希Hash类型而非字符串String类型。
4.网络瓶颈
问题描述客户端和Redis服务器之间的大量网络往返导致性能下降。
解决方案 使用Pipeline减少网络往返次数批量执行命令。尽可能在 服务器端处理复杂逻辑比如使用Lua脚本。
5.不合理的持久化配置
问题描述频繁的磁盘同步操作会影响性能特别是在使用AOF持久化并配置为每次写入都同步时。
解决方案 根据数据安全性要求合理配置AOF的同步频率例如改为每秒同步一次。对于 不需要持久化的场景可以关闭AOF或选择合适的RDB快照策略。
6.单线程模型导致的CPU瓶颈
问题描述虽然Redis是基于单线程模型但在处理大量请求或执行复杂命令时CPU可能成为瓶颈。
解决方案
避免 使用复杂的命令特别是那些时间复杂度较高的命令。在可能 的情况下通过增加更多的Redis实例来分担负载使用负载均衡技术分发请求。
二十三、说说为什么Redis过期了为什么内存没释放
当客户端访问一个键时Redis会检查这个键是否已经过期。如果已经过期Redis在这个时间点才会删除这个键。这意味着如果一个已经过期的键没有被访问它就不会被自动删除因此内存不会被立即释放。
1.定期删除
为了减轻仅依赖惰性删除可能导致的内存占用问题Redis还会定期从数据库中随机测试一些键并删除其中已经过期的键。但是这种方法也不保证所有过期的键都会被及时删除。因为定期删除操作只是随机抽查并不会遍历所有的键。
2.为什么内存没立即释放
基于以上两种策略以下是一些原因导致Redis过期键后内存没有立即释放的情况
未 被 访问如果过期的键没有被访问而且恰好没有被定期删除策略检测到这些键就会继续占用内存。定期删除频率定期删除是通过随机抽样的方式进行的这意味着并非所有的键都会被检查特别是在有大量键的数据库中过期键可能在一段时间内不会被检测到。性能考 虑 Redis设计为高性能的内存数据库过多的删除操作尤其是大量键同时过期时可能会对性能产生影响。因此Redis采用这种折衷的策略来平衡内存使用和性能。
3.解决方案
如果过期键未被及时删除导致内存问题可以考虑以下策略
调整 过期策略通过调整maxmemory-policy配置可以设置当内存达到限制时自动删除过期键。手动删除可以通过定期运行脚本使用SCAN命令配合TTL检查键的过期时间手动删除已过期的键。监控和调 整监控Redis的内存使用情况根据需要调整定期删除任务的执行频率。
二十四、Redis突然变慢有哪些原因
Redis突然变慢可能由多种原因引起这些原因可能涉及到Redis配置、硬件资源、客户端行为等多个方面。以下是一些可能导致Redis性能下降的常见原因及其解决方案
1. 内存满导致的交换Swapping
原 因当Redis使用的内存超过物理内存时操作系统会将部分数据交换到磁盘上导致性能下降。解决方案优化内存使用如调整maxmemory配置和淘汰策略减少大key和深度嵌套结构或增加 物理内存。
2.键过期策略
原因 大量键同时过期可能导致Redis在短时间内尝试删除这些键消耗大量CPU资源。解决方 案避免设置大量键同时过期尽可能分散过期时间。
3. 持久化阻塞 原因Redis的RDB快照或AOF重写操作可能导致主线程阻塞。解决 方案调整快照和AOF的配置如使用合理的保存间隔或启用AOF的appendfsync no设置以异步写入磁盘。
4. 大量慢查询 原因执行复杂命令如KEYS、大范围的ZREVRANGEBYSCORE等或处理大key可能导致单个命令执行时间过长。解决方案优化查询命令使用SCAN代替KEYS避免在大数据集上执行复杂命令分割大key 。
5. 网络瓶颈
原 因客户端和Redis服务器之间的网络延迟或带宽限制。解决方 案检查网络配置尽可能在同一局域网内部署客户端和Redis服务器使用Pipeline减少网络往返。
6.CPU瓶颈
原因 Redis服务器CPU资源不足可能由于背景任务如AOF重写、大量并发连接或命令处理导致。解决方案 优化Redis配置减少并发连接数升级服务器硬件。
7. 存在bigKey造成阻塞
原 因使用不合适的数据类型存储数据或数据设计不合理。解决方案根据实际需求选择合适的数据类型合理设计数据模型。
8. Redis版本问题 原因使用的Redis版本中存在已知的性能问题。解 决方案升级到最新的稳定版本。
9.总结
Redis性能问题的诊断和解决通常需要从多个角度出发包括但不限于配置优化、资源调整、查询优化等。使用INFO命令检查Redis状态定位问题源头并根据实际情况采取相应的解决措施。
二十五、为什么 Redis 集群的最大槽数是 16384 个
Redis集群通过分片Sharding来提供数据分布式存储的能力它使用了一种称为哈希槽Hash Slot的技术来实现这一点。在Redis集群中有16384个哈希槽这个数字是固定的。每个键通过对其键名进行CRC16哈希计算然后对16384取模来决定应该分配到哪个哈希槽每个哈希槽指向存储数据的节点。 选择16384个槽的原因涉及到多个方面的考虑
1. 平衡性能和灵活性
16384提供了足够的细粒度使得数据可以在不同的节点间均匀分布同时避免了管理过多槽所带来的复杂性和开销。这个数字是在性能、存储效率和操作复杂度之间的一个折中选择。
2. 网络开销和重分布开销
当需要在节点间迁移槽以实现集群的重新平衡或扩展时使用16384个槽可以限制因槽迁移所需的网络流量和操作开销。如果槽的数量过多即使是小规模的调整也可能会导致大量的数据迁移增加网络压力和迁移时间。
3. CRC16哈希和取模操作
CRC16哈希算法生成的结果是一个16位的哈希值这意味着理论上可以有65536个不同的结果。Redis选择16384作为槽数量是因为它是2的14次幂可以通过简单的取模操作快速计算出一个键应该被分配到哪个槽。这种方法既保证了计算的快速性也足够在集群环境中分散键减少热点。
4. 实践中的验证
Redis的设计者在实践中测试了不同的槽数量最终发现16384是在保证性能和管理上的一个较好平衡点。它足够小使得集群的管理和维护如配置、监控相对简单又足够大能够支持大规模的集群部署满足大多数应用场景的需求。 总之Redis集群选择16384个哈希槽是基于性能、效率和操作简便性的综合考虑。这个设计使得Redis集群能够以较低的管理成本支持高效的数据分布和扩展性。
二十六、Redis存在线程安全的问题吗
Redis服务器本身是线程安全的因为它基于一个单线程模型来处理命令。这意味着在任意时刻只有一个命令在服务器上被执行因此不会存在多个命令同时修改同一个数据造成的数据不一致问题。Redis的这种设计简化了并发控制避免了锁机制带来的复杂性和性能损失同时也确保了高性能和高吞吐率。 然而当我们谈论Redis的线程安全问题时通常是指在客户端操作Redis时的线程安全性。客户端与Redis服务器的交互是否线程安全取决于所使用的Redis客户端库 客户端库的线程安全并非所有的Redis客户端库都是线程安全的。一些客户端库设计为线程安全可以在多个线程中共享和使用同一个连接实例而其他客户端库则可能要求每个线程使用独立的连接实例或者使用适当的线程同步机制来避免并发访问问题。因此开发者在使用Redis客户端库时需要查阅该库的文档了解其线程安全性并根据库的指导使用它。连接池为了在多线程应用中有效地使用Redis许多线程不安全的客户端库提供了连接池功能。连接池允许应用预先创建一定数量的Redis连接并在多个线程间共享这些连接。每个线程需要与Redis交互时从连接池中借用一个连接使用完毕后返回连接池。这样既保证了线程安全又提高了资源利用率和性能。事务和Lua脚 本在需要执行多个操作作为一个原子操作时Redis的事务MULTI/EXEC命令和Lua脚本执行提供了服务器端的“线程安全”机制确保了这些操作序列的原子性和隔离性。
总结而言Redis服务器端是线程安全的因为它本质上是单线程执行命令。客户端操作Redis的线程安全性则取决于所使用的客户端库是否支持线程安全或者是否通过其他机制如连接池来确保线程安全。在多线程环境中使用Redis时开发者需要特别注意这一点。
二十七、Redis遇到哈希冲突怎么办
Redis处理哈希冲突主要依赖于其内部数据结构的设计。Redis使用哈希表作为基础数据结构之一哈希表在处理键值对时会遇到哈希冲突。Redis解决哈希冲突的方法主要是通过链地址法Separate Chaining。
1.链地址法Separate Chaining
当两个或多个键的哈希值相同即它们映射到同一个哈希桶时会产生哈希冲突。Redis通过链地址法来解决这个问题具体做法如下
每个哈希桶不直接存储键值对而是存储了一个指向键值对链表或者是更复杂的数据结构如跳表的指针。如果发生哈希冲突即新的键值对与现有键值对哈希到同一个桶Redis会将这个新的键值对插入到该桶对应的链表的头部或其他位置依据具体实现而定。查找键时Redis会先计算键的哈希值定位到具体的桶然后遍历该桶的链表直到找到该键对应的节 点。
2.动态扩容
随着存储的键值对数量增加哈希表的负载因子即键值对数量与哈希桶数量的比值会增加导致冲突的概率上升进而影响性能。为了维持效率Redis会根据负载因子和其他条件如是否处于读写操作中动态地扩容哈希表
扩容时Redis会增加哈希桶的数量并重新计算每个键的哈希值将键值对重新分布到新的哈希桶中。Redis的哈希表 扩容是渐进式的。为了避免一次性重新哈希所有键值对带来的大量计算Redis会将这个过程分摊到后续的操作中每次操作只迁移部分键值对。
3.总结
Redis通过链地址法有效地解决了哈希冲突问题确保即使多个键哈希到同一个桶也能通过遍历链表的方式准确快速地访问到每个键。同时通过动态扩容机制Redis能够保持哈希表的高效性能即使在存储大量数据的情况下。这些设计使得Redis能够作为一个高性能的键值存储解决方案。
二十八、Redis的I/O多路复用
假设你是一个老师让30个学生解答一道题目然后检查学生做的是否正确你有下面几个选择 第一种选择按顺序逐个检查先检查A然后是B之后是C、D。。。这中间如果有一个学生卡住全班都会被耽误。这种模式就好比你用循环挨个处理socket根本不具有并发能力。第二种选择你创建30个分身每个分身检查一个学生的答案是否正确。这种类似于为每一个用户创建一个进程或者- 线程处理连接。第三种选择你站在讲台上等谁解答完谁举手。这时C、D举手表示他们解答问题完毕你下去依次检 查C、D的答案然后继续回到讲台上等。此时E、A又举手然后去处理E和A。 第一种就是阻塞IO模型第三种就是I/O复用模型。 Redis的IO多路复用机制允许单个线程高效地监视多个网络连接上的IO事件如读写准备就绪。这种机制依赖于操作系统提供的select、poll、epoll在Linux中或kqueue在BSD系统中包括macOS等系统调用。通过这种方式Redis可以在不同的客户端连接间“快速切换”在一个连接上等待IO操作完成的同时处理其他连接上的IO请求。
二十九、精简面试提问
Redis是蛮重要的一个环节所以大家面试的时候也会遇到很多提问Redis的问题以下大概罗列一下关于Redis的面试问题
1.你们项目Redis用的那种集群方式部署了几个节点redis-Cluster有了解吗说说原理
主从、哨兵、Cluster最重要运行机制 各自的优缺点
Redis集群通过分片sharding将数据分散到多个Redis节点上从而实现了数据的水平扩展和高可用性。集群中的每个节点都负责存储一部分数据并且可以通过哈希算法来确定数据应该存储在哪个节点上。此外Redis集群还提供了自动故障转移和负载均衡等功能。
2.生产环境有遇到过那些Redis的问题
雪崩、redis大Key
3.redis为什么这么快
基于内存丰富数据结构多路复用最重要
4.如何保证Redis和MySQL数据一致性
同步、异步双写、延时双删
5.在项目中那些场景用了Redis那种数据类型
场景- 数据类型 - 数据结构 刨底 核心数据结构跳表、压缩表
Redis支持多种数据类型包括String字符串、Hash哈希、List列表、Set集合、Zset有序集合、BitMap位图、HyperLogLog基数统计和Geospatial地理空间等。这些数据类型使得Redis能够灵活地处理各种数据需求。
6.服务宕机重启后如何恢复数据
最好结合项目谈RDB、AOP各自优缺点考虑下恢复数据过程中增量是如何同步的
7.Redis分布式锁用过吗使用过程中遇到过那些问题还用过那些分布式锁
结合Redission底层原理
8.Bitmap、HyperLogLog 如何用于大数据量统计
场景原理
9.请简述Redis的主要特点和应用场景
Redis是一个开源的使用ANSI C语言编写的、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库并提供多种语言的API。它通常被称为数据结构服务器因为值value可以是字符串strings、哈希hashes、列表lists、集合sets、有序集合sorted sets等类型。Redis的主要特点包括高性能、持久化、多种数据结构支持、发布订阅模型、事务支持等。Redis常用于缓存、消息队列、分布式锁等场景。
10.Redis如何实现持久化有哪些持久化策略
Redis提供了两种主要的持久化策略RDB快照和AOF追加写入。RDB通过创建数据的快照来实现持久化而AOF则记录所有对数据库执行的写操作并在重启时重新执行这些操作以恢复数据。此外Redis还提供了混合持久化策略结合了RDB和AOF的优点。
11.Redis的内存淘汰策略有哪些
Redis提供了多种内存淘汰策略用于在内存不足时自动删除一些键以释放空间。这些策略包括volatile-lru从已设置过期时间的键集中挑选最近最少使用的键删除、volatile-ttl根据键的剩余生存时间TTL来决定删除哪些键、volatile-random从已设置过期时间的键集中随机挑选键删除、allkeys-lru从所有键中挑选最近最少使用的键删除、allkeys-random从所有键中随机挑选键删除以及noeviction禁止删除任何键当内存不足时返回错误。
12.Redis如何处理并发问题
Redis本身是一个单线程模型通过非阻塞IO和多路复用技术来处理并发请求。这意味着Redis一次只能处理一个命令但通过高效的事件处理机制它能够快速地处理大量的并发连接和请求。此外Redis还提供了事务支持和Lua脚本执行等功能以在一定程度上满足复杂并发场景的需求。
13.Redis的过期键删除策略是怎样的
Redis使用了三种过期键删除策略定期删除、惰性删除和随机抽查删除。定期删除是在一个设定的时间间隔内程序定期对数据库进行检查删除里面的过期键。惰性删除是当程序尝试访问一个键时Redis会先检查这个键是否已过期如果过期了就立即删除它并返回空值。随机抽查删除是Redis在每次进行数据库定时检查时除了执行定期删除操作外还会随机抽查一些键进行过期检查。
14.Redis和Memcached有什么区别
Redis和Memcached都是常用的内存数据库但它们在多个方面存在差异。例如Redis支持更丰富的数据类型和操作而Memcached主要支持简单的键值对存储。此外Redis支持持久化、事务和Lua脚本等功能而Memcached则主要关注高速缓存。在应用场景上Redis常用于需要复杂数据结构和操作的场景而Memcached则更适合简单的缓存需求。
