聊聊缓存相关知识

本文详细探讨了缓存中的三大问题——缓存穿透、缓存击穿和缓存雪崩,解释了它们的成因、示例以及应对策略,包括布隆过滤器的应用、互斥锁、热点数据处理和缓存预热、更新与降级等方法。


缓存原理

在这里插入图片描述

缓存穿透

缓存穿透:指用户查询数据,在数据库没有,自然在缓存中也不会有。这样就导致用户查询的时候,在缓存中找不到,每次都要去数据库再查询一遍,然后返回空(相当于进行了两次无用的查询)。这样请求就绕过缓存直接查数据库,这也是经常提的缓存命中率问题。

解决方案

  1. 缓存空值/缺省值
    如果一个查询返回的数据为空(不管是数据不存在,还是系统故障),我们仍然把这个空结果进行缓存,但它的过期时间会很短,最长不超过五分钟。通过这个直接设置的默认值存放到缓存,这样第二次到缓冲中获取就有值了,而不会继续访问数据库。
  2. 布隆过滤器
    快速判断数据是否存在,避免从数据库中查询数据是否存在,减轻数据库压力。
    将所有可能存在的数据哈希到一个足够大的bitmap中,一个一定不存在的数据会被这个bitmap拦截掉,从而避免了对底层存储系统的查询压力。

布隆过滤器
布隆过滤器(Bloom Filter)是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器可以用于检索一个元素是否在一个集合中。

  • 优点:空间效率和查询时间都远远超过一般的算法。
  • 缺点:有一定的误识别率,删除困难。

布隆过滤器原理
布隆过滤器本质上是一个初始值都为 0 的 二进制数组和 N 个哈希函数组成。

当我们想标记某个数据存在时(例如,数据x已被写入数据库),布隆过滤器会通过三个操作完成标记:

  • 首先,使用 N 个哈希函数,分别计算这个数据的哈希值,得到 N 个哈希值。
  • 然后,我们把这 N 个哈希值对 bit 数组的长度取模,得到每个哈希值在数组中的对应位置。
  • 最后,我们把对应位置的 bit 位设置为 1,这就完成了在布隆过滤器中标记数据的操作。

具体了解布隆过滤器可参考文章:谈谈布隆过滤器

缓存击穿

缓存击穿:缓存中没有数据(一般是缓存时间到期),导致并发请求同时先去取缓存数据,没取到数据,所以又同时去数据库取数据,引起数据库压力瞬间增大,造成过大压力。

缓存击穿一般针对的是后一个Key。当缓存在某个时间点过期的时候,恰好在这个时间点对这个Key有大量的并发请求过来,这些请求发现缓存过期一般都会从后端DB加载数据并回设到缓存,这个时候大并发的请求可能会瞬间把后端DB压垮。

解决方案

  1. 使用互斥锁
    单机可以使用synchronized、lock,分布式可以使用lua脚本。
    在并发的多个请求中,只有第一个请求线程能拿到锁并执行数据库查询操作,其他的线程拿不到锁就阻塞等着,等到第一个线程将数据写入缓存后,直接走缓存。
  2. 设置热点数据永不过期
    缓存不设置失效时间,有更新的话,需要更新缓存。

缓存雪崩

缓存雪崩:原有缓存失效,新缓存未到期间所有原本应该访问缓存的请求都去查询数据库了,而对数据库CPU和内存造成巨大压力,严重的会造成数据库宕机。从而形成一系列连锁反应,造成整个系统崩溃。

缓存击穿指并发查同一条数据;缓存雪崩是不同数据都过期了,很多数据都查不到从而查数据库。

解决方案

  1. 不同key设置不同的缓存失效时间(给每个key的失效时间加一个随机值);
    防止同一时间大量数据过期现象发生。
  2. 热点数据永不过期
    不设置失效时间,有更新的话,需要更新缓存。
  3. 缓存失效标记
    给每一个缓存数据增加相应的缓存标记,记录缓存的是否失效,如果缓存标记失效,则更新数据缓存。
  4. 加锁
    避免失效时大量的并发请求同时到数据库。

穿透、击穿、雪崩对比

缓存问题针对数据描述
缓存穿透某个数据某个数据缓存中没有,该数据的并发请求每次都要去数据库查
缓存击穿某个数据某个数据刚好过期,该数据的并发请求全都去数据库查
缓存雪崩不同数据不同数据都刚好过期,并发请求全都去数据库查

缓存预热

缓存预热:系统上线后,将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候,先查询数据库,然后再将数据缓存的问题!用户直接查询事先被预热的缓存数据!

缓存更新

除了缓存服务器自带的缓存失效策略之外(Redis默认的有6中策略可供选择),我们还可以根据具体的业务需求进行自定义的缓存淘汰,常见的策略有两种:

  1. 定时去清理过期的缓存;
  2. 当有用户请求过来时,再判断这个请求所用到的缓存是否过期,过期的话就去底层系统得到新数据并更新缓存。

缓存降级

当访问量剧增、服务出现问题(如响应时间慢或不响应)或非核心服务影响到核心流程的性能时,仍然需要保证服务还是可用的,即使是有损服务。系统可以根据一些关键数据进行自动降级,也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用,即使是有损的。而且有些服务(核心业务)是无法降级的(如加入购物车、结算)。

针对不同的数据采用不同的处理方式:

  • 非核心数据,直接返回预定义信息、空值或者报错;
  • 核心数据,则允许访问缓存,如果缓存缺失,可以读取数据库。
<think>嗯,用户再次询问了Sentinel的作用原理,但这次特别提到要结合面试场景,并且引用了四段材料。用户之前已经得到过详细的技术原理解释,这次需求更聚焦于"面试中如何讨论这个话题"。翻看历史记录,上次我详细拆解了流量控制和熔断降级两大机制,还附带了工作流程图。这次需要转换角度——用户可能正在准备分布式系统的面试,那些秒杀项目[^1]、Redis原理[^2]和幂等性设计[^3]的引用就是线索。ta应该希望把Sentinel的知识点组织成面试应答素材。注意到用户引用的材料里有个有趣细节:秒杀项目用Redis缓存做预减库存[^1],这其实和Sentinel的流量控制理念相通。可以把这个作为实际案例融入回答,既体现原理理解又能展示业务场景结合能力。另外幂等性保证方案[^3]虽然属于消息队列领域,但Sentinel的熔断恢复机制其实面临类似挑战——比如半开状态下的重复请求处理。规划这样组织内容:先简述核心功能避免重复,然后重点构建"面试话术",把工作原理拆解成可口头表达的模块。技术细节保留但要用面试语言包装,比如提到QPS限流时关联秒杀案例[^1],讲熔断器状态机时对比RedisSentinel机制[^2]。最后那些面试反问特别重要——用户引用4关于职业规划[^4]让我意识到ta可能在准备晋升或跳槽。要设计些有深度的问题帮ta反客为主,比如让面试官解释误报处理方案,既能展示思考深度又能套取信息。啊,差点忘记LateX格式要求。那个熔断器状态转换的数学表示需要单独成行,工作流图示要用$$...$$包装。引用标注统一用方括号避免混淆。</think> 以下将结合Sentinel核心原理与面试考点,通过结构化的方式解析其工作机制,并附面试常见问题及回答技巧: --- ### **一、Sentinel核心作用原理** #### 1. **流量控制(Flow Control)** - **核心目标**:通过限制QPS或并发线程数保护系统不被突发流量压垮 - **实现机制**: - 拦截资源请求(如API接口、方法调用) - 实时计算指标:$$ QPS = \frac{\text{单位时间请求量}}{\Delta t} $$ - **规则触发**: - QPS超阈值 → 立即拒绝请求(抛出`BlockException`) - 并发线程数超限 → 阻塞新请求(类似线程池满策略) - **实际应用**:秒杀场景预减库存(基于Redis计数器限流)[^1] #### 2. **熔断降级(Circuit Breaking)** - **核心目标**:快速失败避免故障蔓延,提升系统韧性 - **熔断器状态机**: ``` $$ \begin{array}{c} \text{关闭(Closed)} \\ \downarrow \text{(错误率/慢调用超阈值)} \\ \text{打开(Open)} \\ \downarrow \text{(等待超时时间)} \\ \text{半开(Half-Open)} \\ \end{array} \begin{cases} \text{成功} \rightarrow \text{关闭} \\ \text{失败} \rightarrow \text{打开} \end{cases} $$ ``` - **关键规则**: - **慢调用比例**:响应时间 > 阈值且比例超标(如50%) - **异常比例**:错误率超过设定阈值(如60%) - **异常数**:窗口周期内异常次数超限 #### 3. **工作流程** ```mermaid graph LR A[请求进入] --> B{Sentinel拦截资源} B -->|规则检查| C[流量控制] B -->|规则检查| D[熔断降级] C -->|QPS/线程数达标| E[放行请求] C -->|超限| F[抛出BlockException] D -->|服务正常| E D -->|熔断触发| F F --> G[执行降级逻辑] ``` --- ### **二、面试高频问题与回答要点** #### 1. **Sentinel如何实现流量控制?** - **回答结构**: - 原理:基于滑动窗口统计指标(QPS/线程数) + 规则引擎 - 策略:直接拒绝/Warm Up/匀速排队(漏桶算法) - **举例**:秒杀系统用Redis预减库存实现限流[^1] #### 2. **熔断降级与Hystrix的区别?** | **维度** | Sentinel | Hystrix | |----------------|-----------------------------------|--------------------------| | 隔离策略 | 信号量/线程池 | 线程池 | | 熔断触发条件 | 支持慢调用/异常比例/异常数多维指标 | 仅异常比例 | | 实时监控 | 支持控制台实时查看 | 依赖Dashboard | | 规则动态配置 | 支持热更新 | 需重启生效 | #### 3. **如何保证熔断恢复的准确性?** - **关键点**: 1. **半开状态试探机制**:定时放行少量请求测试服务恢复情况 2. **灰度放行策略**:逐步增加流量避免二次雪崩 3. **异常标记**:使用`Tracer.trace(ex)`统计业务异常(非BlockException)[^3] #### 4. **Sentinel规则如何持久化?** - **方案对比**: - **原始模式**:规则存在内存,重启失效 - **Pull模式**:客户端定时拉取配置中心(如Nacos) - **Push模式**:配置中心主动推送(推荐,保证实时性) --- ### **三、实战案例:秒杀场景应用** ```java @SentinelResource( value = "seckillService", blockHandler = "handleBlock", // 限流降级方法 fallback = "handleFallback" // 业务异常降级 ) public void seckill(String skuId) { // 1. Redis预减库存(原子操作DECR) Long stock = redisTemplate.opsForValue().decrement("stock:" + skuId); if (stock < 0) { throw new RuntimeException("库存不足"); } // 2. 发送MQ创建订单(保证最终一致性) } ``` - **保护策略**: - 流量控制:限制QPS=5000(超出返回"活动火爆") - 熔断降级:当订单服务错误率>40%时熔断10秒 --- ### **四、面试追问方向** 1. **系统自适应保护** - 原理:基于Load(系统负载)/CPU使用率动态调整入口流量 - 公式:$$ \text{允许QPS} = \min(\text{预设阈值}, \frac{\text{系统容量}}{\text{当前负载}}) $$ 2. **热点参数限流** - 场景:针对高频参数(如商品ID)独立统计 - 实现:`ParamFlowRule` + LRU统计结构 3. **集群流控** - 问题:单机限流无法应对集群不均匀流量 - 方案:Token Server统一分配令牌 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值