Redis之旁路缓存

2023-10-10 21:10
文章标签 redis 缓存 旁路

本文主要是介绍Redis之旁路缓存,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

Redis之旁路缓存

Redis作为缓存中间件早已深入人心,但我们有没有想过Redis为什么能作为缓存呢?Redis到底怎样使用缓存呢?本篇文章详细聊聊。

Redis为什么能作为缓存

聊Redis为什么能作为缓存前先需要清楚缓存的作用,我们在很多场景都有接触过缓存就如Redis本身的输入输出缓存、复制缓冲区、复制积压缓存区等等,又如操作系统本身的LLC,page cache缓存等等,这些缓存的主要作用是什么呢?是在一个多层次系统中平衡上下级系统的速度差异。

这里以操作系统为例说明,操作系统的存储结构一般为CPU、内存、磁盘三大块,其中CPU读取速度最快只有几十纳秒,内存读取需要100多纳秒,而磁盘的读取速度是毫秒,这样看可能没有什么对比效果,我们看下下面的单位换算,内存和磁盘的速度差异可是差了数量级的。

1秒 = 1000 毫秒 = 1000000 微秒 = 1000000 纳秒

根据木桶定理,一个木桶装多少水是由木桶的最短板决定,所以在操作系统上如果处理数据,磁盘的读取过慢,CPU将空闲大量的时间,这显然是不合理的,所以引入了缓存的概念。

  • CPU中的末级缓存即LLC用于平衡CPU和内存间的速度差异,避免每次从内存中取数据。

  • 内存中高速缓存页即page cache,用于平衡内存和磁盘中的速度差异,避免每次都从磁盘中取数据。

看到这里就可以得到缓存的一些特征如下

  • 第一在一个多层次系统上缓存一定是一个快速的系统,这样才能平衡层次系统的速度差异。

  • 第二CPU、内存中包含的缓存比它需要平衡的系统小,如LLC就不可能存下内存中的所有数据,所以我们需要有内存淘汰的思想。

到这里缓存的特性就聊完了,那么Redis是否符合呢?显然是可以的

  • Redis运行在内存中而且存在丰富的数据结构以及应用了多路复用IO模型,速度上远超其它数据库,符合第一点速度快的要求。

  • Redis本身自带内存淘汰机制,能根据淘汰规则自动淘汰键值,符合内存淘汰要求。

旁路缓存使用

使用缓存一般的操作都是

  • 读取数据前先从Redis中读取。

  • 如果读取数据在缓存中不存在就需要在数据库中读取。

  • 更新缓存。

那么这些操作是怎么进行的呢?这就和旁路缓存有关,下面详细聊聊。

什么叫旁路缓存

Redis应用于生产上一般是一个独立的程序和业务程序分开,只能被动等待客户端的调用,我们如果在程序中使用还要加入Redis的调用代码,所以我们也将Redis称为旁路缓存,读取缓存和更新缓存都是在业务系统中完成。这和上面提到的操作系统的CPU缓存LLC,内存缓存page cache有本质区别,LLC和page cache从系统初始化就存在系统调用的主路径上,不需要其它业务系统主动调用。

缓存类型

Redis根据请求的类型分为只读缓存和读写缓存,这是针对客户端发送的写请求是否在Redis中修改进行区分。

只读缓存

只读缓存只提升缓存的读性能,当客户端发送一个读请求时Redis从缓存中查找是否存在,如果存在直接返回,不存在就从数据库获取,写入缓存中同时返回客户端,如果是写请求,直接修改数据库数据然后将缓存中的对应键值删除。

这样可以保证数据库中的数据都是最新的,而且数据不会丢失。

读写缓存

读写缓存可以提升读写效率,这与只读缓存不同的是,读写缓存会在Redis中做增删改的操作,Redis中的数据将是最新的一份,这样就能快速的响应客户端,但是数据一直放在内存中显然是不可靠的,如果出现Redis宕机将丢失数据,所以这里又提供了两种写回数据库的策略,同步写回和异步写回。

同步写回表示,当客户端发送一个写请求过来会同时更新缓存和数据库,两者全部更新完毕才会返回,这样会降低处理性能,但能提升可靠性。

异步写回表示,当客户端发送一个写请求过来会先更新缓存,更新完后直接返回客户端,仅当写入后的数据淘汰出内存后才会写入数据库,这样保证了性能,但是可靠性降低了。

如何选择缓存类型

需要根据业务出发,如果是读多写少的场景,那么使用只读缓存就可以解决,而需要给写加速的场景肯定选择读写缓存但使用读写缓存需要注意数据写回策略,需要在数据可靠性和性能两个方面做取舍。

这篇关于Redis之旁路缓存的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/183115

相关文章

零基础学习Redis(10) -- zset类型命令使用

zset是有序集合,内部除了存储元素外,还会存储一个score,存储在zset中的元素会按照score的大小升序排列,不同元素的score可以重复,score相同的元素会按照元素的字典序排列。 1. zset常用命令 1.1 zadd  zadd key [NX | XX] [GT | LT]   [CH] [INCR] score member [score member ...]

缓存雪崩问题

缓存雪崩是缓存中大量key失效后当高并发到来时导致大量请求到数据库,瞬间耗尽数据库资源,导致数据库无法使用。 解决方案: 1、使用锁进行控制 2、对同一类型信息的key设置不同的过期时间 3、缓存预热 1. 什么是缓存雪崩 缓存雪崩是指在短时间内,大量缓存数据同时失效,导致所有请求直接涌向数据库,瞬间增加数据库的负载压力,可能导致数据库性能下降甚至崩溃。这种情况往往发生在缓存中大量 k

Redis中使用布隆过滤器解决缓存穿透问题

一、缓存穿透(失效)问题 缓存穿透是指查询一个一定不存在的数据,由于缓存中没有命中,会去数据库中查询,而数据库中也没有该数据,并且每次查询都不会命中缓存,从而每次请求都直接打到了数据库上,这会给数据库带来巨大压力。 二、布隆过滤器原理 布隆过滤器(Bloom Filter)是一种空间效率很高的随机数据结构,它利用多个不同的哈希函数将一个元素映射到一个位数组中的多个位置,并将这些位置的值置

Lua 脚本在 Redis 中执行时的原子性以及与redis的事务的区别

在 Redis 中,Lua 脚本具有原子性是因为 Redis 保证在执行脚本时,脚本中的所有操作都会被当作一个不可分割的整体。具体来说,Redis 使用单线程的执行模型来处理命令,因此当 Lua 脚本在 Redis 中执行时,不会有其他命令打断脚本的执行过程。脚本中的所有操作都将连续执行,直到脚本执行完成后,Redis 才会继续处理其他客户端的请求。 Lua 脚本在 Redis 中原子性的原因

防止缓存击穿、缓存穿透和缓存雪崩

使用Redis缓存防止缓存击穿、缓存穿透和缓存雪崩 在高并发系统中,缓存击穿、缓存穿透和缓存雪崩是三种常见的缓存问题。本文将介绍如何使用Redis、分布式锁和布隆过滤器有效解决这些问题,并且会通过Java代码详细说明实现的思路和原因。 1. 背景 缓存穿透:指的是大量请求缓存中不存在且数据库中也不存在的数据,导致大量请求直接打到数据库上,形成数据库压力。 缓存击穿:指的是某个热点数据在

laravel框架实现redis分布式集群原理

在app/config/database.php中配置如下: 'redis' => array('cluster' => true,'default' => array('host' => '172.21.107.247','port' => 6379,),'redis1' => array('host' => '172.21.107.248','port' => 6379,),) 其中cl

PHP APC缓存函数使用教程

APC,全称是Alternative PHP Cache,官方翻译叫”可选PHP缓存”。它为我们提供了缓存和优化PHP的中间代码的框架。 APC的缓存分两部分:系统缓存和用户数据缓存。(Linux APC扩展安装) 系统缓存 它是指APC把PHP文件源码的编译结果缓存起来,然后在每次调用时先对比时间标记。如果未过期,则使用缓存的中间代码运行。默认缓存 3600s(一小时)。但是这样仍会浪费大量C

缓存策略使用总结

缓存是提高系统性能的最简单方法之一。相对而言,数据库(or NoSQL数据库)的速度比较慢,而速度却又是致胜的关键。 如果使用得当,缓存可以减少相应时间、减少数据库负载以及节省成本。本文罗列了几种缓存策略,选择正确的一种会有很大的不同。缓存策略取决于数据和数据访问模式。换句话说,数据是如何写和读的。例如: 系统是写多读少的吗?(例如基于时间的日志)数据是否是只写入一次并被读取多次?(例如用户配

Redis的rehash机制

在Redis中,键值对(Key-Value Pair)存储方式是由字典(Dict)保存的,而字典底层是通过哈希表来实现的。通过哈希表中的节点保存字典中的键值对。我们知道当HashMap中由于Hash冲突(负载因子)超过某个阈值时,出于链表性能的考虑,会进行Resize的操作。Redis也一样。 在redis的具体实现中,使用了一种叫做渐进式哈希(rehashing)的机制来提高字典的缩放效率,避

【吊打面试官系列-Redis面试题】说说 Redis 哈希槽的概念?

大家好,我是锋哥。今天分享关于 【说说 Redis 哈希槽的概念?】面试题,希望对大家有帮助; 说说 Redis 哈希槽的概念? Redis 集群没有使用一致性 hash,而是引入了哈希槽的概念,Redis 集群有 16384 个哈希槽,每个 key 通过 CRC16 校验后对 16384 取模来决定放置哪个槽, 集群的每个节点负责一部分 hash 槽。