安徽省合肥市建设局网站,网站后端开发,wordpress 设置权限,套模板网站建设1.如果你想new一个Quene#xff0c;你有几种方式#xff1f;他们之间的区别是什么#xff1f; 2.Redis 是如何判断数据是否过期的呢#xff1f;
Redis 通过一个叫做过期字典#xff08;可以看作是 hash 表#xff09;来保存数据过期的时间。过期字典的键指向 Redis 数据…1.如果你想new一个Quene你有几种方式他们之间的区别是什么 2.Redis 是如何判断数据是否过期的呢
Redis 通过一个叫做过期字典可以看作是 hash 表来保存数据过期的时间。过期字典的键指向 Redis 数据库中的某个 key(键)过期字典的值是一个 long long 类型的整数这个整数保存了 key 所指向的数据库键的过期时间毫秒精度的 UNIX 时间戳。 过期字典是存储在 redisDb 这个结构里的 typedef struct redisDb {...dict *dict; //数据库键空间,保存着数据库中所有键值对dict *expires // 过期字典,保存着键的过期时间...} redisDb; 3.Redis中常用的过期数据的删除策略就两个重要自己造缓存轮子的时候需要格外考虑的东西 惰性删除 只会在取出 key 的时候才对数据进行过期检查。这样对 CPU 最友好但是可能会造成太多过期 key 没有被删除。 定期删除 每隔一段时间抽取一批 key 执行删除过期 key 操作。并且Redis 底层会通过限制删除操作执行的时长和频率来减少删除操作对 CPU 时间的影响。
定期删除对内存更加友好惰性删除对 CPU 更加友好。两者各有千秋所以 Redis 采用的是 定期删除惰性/懒汉式删除 。 4.Redis 事务支持原子性吗
Redis 事务在运行错误的情况下除了执行过程中出现错误的命令外其他命令都能正常执行。并且Redis 事务是不支持回滚roll back操作的。因此Redis 事务其实是不满足原子性的。 5.什么是缓存穿透
缓存穿透说简单点就是大量请求的 key 是不合理的根本不存在于缓存中也不存在于数据库中 。这就导致这些请求直接到了数据库上根本没有经过缓存这一层对数据库造成了巨大的压力可能直接就被这么多请求弄宕机了。 有哪些解决办法
最基本的就是首先做好参数校验一些不合法的参数请求直接抛出异常信息返回给客户端。比如查询的数据库 id 不能小于 0、传入的邮箱格式不对的时候直接返回错误消息给客户端等等。 缓存无效 key
如果缓存和数据库都查不到某个 key 的数据就写一个到 Redis 中去并设置过期时间具体命令如下 SET key value EX 10086 。这种方式可以解决请求的 key 变化不频繁的情况如果黑客恶意攻击每次构建不同的请求 key会导致 Redis 中缓存大量无效的 key 。很明显这种方案并不能从根本上解决此问题! 布隆过滤器
布隆过滤器是一个非常神奇的数据结构通过它我们可以非常方便地判断一个给定数据是否存在于海量数据中。我们需要的就是判断 key 是否合法有没有感觉布隆过滤器就是我们想要找的那个“人”。
具体是这样做的把所有可能存在的请求的值都存放在布隆过滤器中当用户请求过来先判断用户发来的请求的值是否存在于布隆过滤器中。不存在的话直接返回请求参数错误信息给客户端存在的话才会走下面的流程。
加入布隆过滤器之后的缓存处理流程图如下。 但是需要注意的是布隆过滤器可能会存在误判的情况。总结来说就是 布隆过滤器说某个元素存在小概率会误判。布隆过滤器说某个元素不在那么这个元素一定不在。 6.什么是缓存击穿
缓存击穿中请求的 key 对应的是 热点数据 该数据 存在于数据库中但不存在于缓存中通常是因为缓存中的那份数据已经过期 。这就可能会导致瞬时大量的请求直接打到了数据库上对数据库造成了巨大的压力可能直接就被这么多请求弄宕机了。 举个例子 秒杀进行过程中缓存中的某个秒杀商品的数据突然过期这就导致瞬时大量对该商品的请求直接落到数据库上对数据库造成了巨大的压力。
有哪些解决办法 设置热点数据永不过期或者过期时间比较长。 针对热点数据提前预热将其存入缓存中并设置合理的过期时间比如秒杀场景下的数据在秒杀结束之前不过期。 请求数据库写数据到缓存之前先获取互斥锁保证只有一个请求会落到数据库上减少数据库的压力。
# 缓存穿透和缓存击穿有什么区别
缓存穿透中请求的 key 既不存在于缓存中也不存在于数据库中。
缓存击穿中请求的 key 对应的是 热点数据 该数据 存在于数据库中但不存在于缓存中通常是因为缓存中的那份数据已经过期 。 7.什么是缓存雪崩
我发现缓存雪崩这名字起的有点意思哈哈。
实际上缓存雪崩描述的就是这样一个简单的场景缓存在同一时间大面积的失效导致大量的请求都直接落到了数据库上对数据库造成了巨大的压力。 这就好比雪崩一样摧枯拉朽之势数据库的压力可想而知可能直接就被这么多请求弄宕机了。
另外缓存服务宕机也会导致缓存雪崩现象导致所有的请求都落到了数据库上。 举个例子 数据库中的大量数据在同一时间过期这个时候突然有大量的请求需要访问这些过期的数据。这就导致大量的请求直接落到数据库上对数据库造成了巨大的压力。
# 有哪些解决办法
针对 Redis 服务不可用的情况 采用 Redis 集群避免单机出现问题整个缓存服务都没办法使用。 限流避免同时处理大量的请求。
针对热点缓存失效的情况 设置不同的失效时间比如随机设置缓存的失效时间。 缓存永不失效不太推荐实用性太差。 设置二级缓存。
# 缓存雪崩和缓存击穿有什么区别
缓存雪崩和缓存击穿比较像但缓存雪崩导致的原因是缓存中的大量或者所有数据失效缓存击穿导致的原因主要是某个热点数据不存在与缓存中通常是因为缓存中的那份数据已经过期
8.如果我想实现微信里边的每天步数自动排序的功能Redis中那个数据结构比较合适
Sorted Set 9.Redis持久化机制
Redis 不同于 Memcached 的很重要一点就是Redis 支持持久化而且支持 3 种持久化方式: 快照snapshottingRDB 只追加文件append-only file, AOF RDB 和 AOF 的混合持久化(Redis 4.0 新增)
如何选择 RDB 和 AOF
关于 RDB 和 AOF 的优缺点官网上面也给了比较详细的说明Redis persistenceopen in new window这里结合自己的理解简单总结一下。
RDB 比 AOF 优秀的地方 RDB 文件存储的内容是经过压缩的二进制数据 保存着某个时间点的数据集文件很小适合做数据的备份灾难恢复。AOF 文件存储的是每一次写命令类似于 MySQL 的 binlog 日志通常会比 RDB 文件大很多。当 AOF 变得太大时Redis 能够在后台自动重写 AOF。新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样但体积更小。不过 Redis 7.0 版本之前如果在重写期间有写入命令AOF 可能会使用大量内存重写期间到达的所有写入命令都会写入磁盘两次。 使用 RDB 文件恢复数据直接解析还原数据即可不需要一条一条地执行命令速度非常快。而 AOF 则需要依次执行每个写命令速度非常慢。也就是说与 AOF 相比恢复大数据集的时候RDB 速度更快。
AOF 比 RDB 优秀的地方 RDB 的数据安全性不如 AOF没有办法实时或者秒级持久化数据。生成 RDB 文件的过程是比较繁重的 虽然 BGSAVE 子进程写入 RDB 文件的工作不会阻塞主线程但会对机器的 CPU 资源和内存资源产生影响严重的情况下甚至会直接把 Redis 服务干宕机。AOF 支持秒级数据丢失取决 fsync 策略如果是 everysec最多丢失 1 秒的数据仅仅是追加命令到 AOF 文件操作轻量。 RDB 文件是以特定的二进制格式保存的并且在 Redis 版本演进中有多个版本的 RDB所以存在老版本的 Redis 服务不兼容新版本的 RDB 格式的问题。 AOF 以一种易于理解和解析的格式包含所有操作的日志。你可以轻松地导出 AOF 文件进行分析你也可以直接操作 AOF 文件来解决一些问题。比如如果执行FLUSHALL命令意外地刷新了所有内容后只要 AOF 文件没有被重写删除最新命令并重启即可恢复之前的状态。
综上 Redis 保存的数据丢失一些也没什么影响的话可以选择使用 RDB。 不建议单独使用 AOF因为时不时地创建一个 RDB 快照可以进行数据库备份、更快的重启以及解决 AOF 引擎错误。 如果保存的数据要求安全性比较高的话建议同时开启 RDB 和 AOF 持久化或者开启 RDB 和 AOF 混合持久化。 10.什么是内存碎片?
你可以将内存碎片简单地理解为那些不可用的空闲内存。
举个例子操作系统为你分配了 32 字节的连续内存空间而你存储数据实际只需要使用 24 字节内存空间那这多余出来的 8 字节内存空间如果后续没办法再被分配存储其他数据的话就可以被称为内存碎片。 Redis 内存碎片虽然不会影响 Redis 性能但是会增加内存消耗。
为什么会有 Redis 内存碎片?
Redis 内存碎片产生比较常见的 2 个原因
1、Redis 存储存储数据的时候向操作系统申请的内存空间可能会大于数据实际需要的存储空间。
2、频繁修改 Redis 中的数据也会产生内存碎片。
如何清理 Redis 内存碎片
Redis4.0-RC3 版本以后自带了内存整理可以避免内存碎片率过大的问题。
直接通过 config set 命令将 activedefrag 配置项设置为 yes 即可。 config set activedefrag yes
具体什么时候清理需要通过下面两个参数控制 # 内存碎片占用空间达到 500mb 的时候开始清理config set active-defrag-ignore-bytes 500mb# 内存碎片率大于 1.5 的时候开始清理config set active-defrag-threshold-lower 50
通过 Redis 自动内存碎片清理机制可能会对 Redis 的性能产生影响我们可以通过下面两个参数来减少对 Redis 性能的影响 # 内存碎片清理所占用 CPU 时间的比例不低于 20%config set active-defrag-cycle-min 20# 内存碎片清理所占用 CPU 时间的比例不高于 50%config set active-defrag-cycle-max 50
另外重启节点可以做到内存碎片重新整理。如果你采用的是高可用架构的 Redis 集群的话你可以将碎片率过高的主节点转换为从节点以便进行安全重启。 11.MongoDB 有什么特点 数据记录被存储为文档 MongoDB 中的记录就是一个 BSON 文档它是由键值对组成的数据结构类似于 JSON 对象是 MongoDB 中的基本数据单元。 模式自由 集合的概念类似 MySQL 里的表但它不需要定义任何模式能够用更少的数据对象表现复杂的领域模型对象。 支持多种查询方式 MongoDB 查询 API 支持读写操作 (CRUD)以及数据聚合、文本搜索和地理空间查询。 支持 ACID 事务 NoSQL 数据库通常不支持事务为了可扩展和高性能进行了权衡。不过也有例外MongoDB 就支持事务。与关系型数据库一样MongoDB 事务同样具有 ACID 特性。MongoDB 单文档原生支持原子性也具备事务的特性。MongoDB 4.0 加入了对多文档事务的支持但只支持复制集部署模式下的事务也就是说事务的作用域限制为一个副本集内。MongoDB 4.2 引入了分布式事务增加了对分片集群上多文档事务的支持并合并了对副本集上多文档事务的现有支持。 高效的二进制存储 存储在集合中的文档是以键值对的形式存在的。键用于唯一标识一个文档一般是 ObjectId 类型值是以 BSON 形式存在的。BSON Binary JSON 是在 JSON 基础上加了一些类型及元数据描述的格式。 自带数据压缩功能 存储同样的数据所需的资源更少。 支持 mapreduce 通过分治的方式完成复杂的聚合任务。不过从 MongoDB 5.0 开始map-reduce 已经不被官方推荐使用了替代方案是 聚合管道open in new window。聚合管道提供比 map-reduce 更好的性能和可用性。 支持多种类型的索引 MongoDB 支持多种类型的索引包括单字段索引、复合索引、多键索引、哈希索引、文本索引、 地理位置索引等每种类型的索引有不同的使用场合。 支持 failover 提供自动故障恢复的功能主节点发生故障时自动从从节点中选举出一个新的主节点确保集群的正常使用这对于客户端来说是无感知的。 支持分片集群 MongoDB 支持集群自动切分数据让集群存储更多的数据具备更强的性能。在数据插入和更新时能够自动路由和存储。 支持存储大文件 MongoDB 的单文档存储空间要求不超过 16MB。对于超过 16MB 的大文件MongoDB 提供了 GridFS 来进行存储通过 GridFS可以将大型数据进行分块处理然后将这些切分后的小文档保存在数据库中 12.MongoDB 适合什么应用场景
MongoDB 的优势在于其数据模型和存储引擎的灵活性、架构的可扩展性以及对强大的索引支持。
选用 MongoDB 应该充分考虑 MongoDB 的优势结合实际项目的需求来决定 随着项目的发展使用类 JSON 格式BSON保存数据是否满足项目需求MongoDB 中的记录就是一个 BSON 文档它是由键值对组成的数据结构类似于 JSON 对象是 MongoDB 中的基本数据单元。 是否需要大数据量的存储是否需要快速水平扩展MongoDB 支持分片集群可以很方便地添加更多的节点实例让集群存储更多的数据具备更强的性能。 是否需要更多类型索引来满足更多应用场景MongoDB 支持多种类型的索引包括单字段索引、复合索引、多键索引、哈希索引、文本索引、 地理位置索引等每种类型的索引有不同的使用场合。 13. MongoDB 支持哪些存储引擎
与 MySQL 一样MongoDB 采用的也是 插件式的存储引擎架构 支持不同类型的存储引擎不同的存储引擎解决不同场景的问题。在创建数据库或集合时可以指定存储引擎。 插件式的存储引擎架构可以实现 Server 层和存储引擎层的解耦可以支持多种存储引擎如MySQL既可以支持B-Tree结构的InnoDB存储引擎还可以支持LSM结构的RocksDB存储引擎。 现在主要有下面这两种存储引擎 WiredTiger 存储引擎 自 MongoDB 3.2 以后默认的存储引擎为 WiredTiger 存储引擎open in new window 。非常适合大多数工作负载建议用于新部署。WiredTiger 提供文档级并发模型、检查点和数据压缩后文会介绍到等功能。 In-Memory 存储引擎 In-Memory 存储引擎open in new window在 MongoDB Enterprise 中可用。它不是将文档存储在磁盘上而是将它们保留在内存中以获得更可预测的数据延迟。
