优化系统性能:深入探讨Web层缓存与Redis应用的挑战与对策

Web层缓存对于提高应用性能至关重要,它通过减少重复的数据处理和数据库查询来加快响应时间。例如,如果一个用户请求的数据已经缓存,服务器可以直接从缓存中返回结果,避免了每次请求都进行复杂的计算或数据库查询。这不仅提高了应用的响应速度,还减轻了后端系统的负担。

Redis是一个流行的内存数据结构存储系统,常用于实现高效的缓存层。它支持各种数据结构,如字符串、哈希、列表、集合等,能够迅速存取数据。通过将常用的数据缓存到Redis中,应用可以大幅度降低数据库负担,同时提升用户体验。

缓存问题详解

在本章中,我们将不深入探讨Redis的基本缓存机制,而是专注于如何防范Redis失效可能带来的不必要损失。我们将详细讨论缓存穿透、缓存击穿和缓存雪崩等问题的产生原因及其解决策略。让我们开始深入了解这些内容。

缓存穿透

缓存穿透指的是查询一个根本不存在的数据时,缓存层和存储层都未能命中。这种情况通常出于容错考虑,如果存储层未能找到数据,系统通常不会将其写入缓存层。结果就是每次请求不存在的数据时,系统都需要直接访问存储层进行查询,从而失去了缓存保护后端存储的本质意义。这不仅增加了存储层的负担,也降低了系统的整体性能。

造成缓存穿透的基本原因主要有两个:

  1. 自身业务代码或数据问题:这类问题通常源于业务逻辑的缺陷或数据不一致。例如,如果业务代码未能正确处理某些数据查询,或数据源本身存在缺陷(如数据丢失、数据错误等),可能导致请求的查询始终无法在缓存或存储层找到对应的数据。这种情况下,缓存层无法有效地存储和返回查询结果,从而导致每次请求都需要直接访问存储层。
  2. 恶意攻击或爬虫行为:恶意攻击者或自动化爬虫可能会发起大量的请求,尝试查询大量不存在的数据。由于这些请求不断打击缓存和存储层,造成大量的空命中(即查询结果始终为空),不仅会消耗大量系统资源,还可能导致缓存层和存储层的压力显著增加,从而影响系统的整体性能和稳定性。

解决方案——缓存空对象

解决缓存穿透的有效方案之一是缓存空对象。这种方法涉及在缓存层中存储查询结果为“空”的标记或对象,以表明特定数据不存在。通过这种方式,当后续请求查询相同的数据时,系统可以直接从缓存层获取“空对象”,而不必重新访问存储层。这不仅减少了对存储层的频繁访问,还提高了系统的整体性能和响应速度,从而有效缓解缓存穿透问题。

String get(String key) {
    // 从缓存中获取数据
    String cacheValue = cache.get(key);

    // 缓存命中
    if (cacheValue != null) {
        return cacheValue;
    }

    // 缓存未命中,从存储中获取数据
    String storageValue = storage.get(key);

    // 如果存储中数据为空,则设置缓存并设定过期时间
    if (storageValue == null) {
        cache.set(key, "");  // 存储空对象标记
        cache.expire(key, 60 * 5);  // 设置过期时间(300秒)
    } else {
        // 存储中数据存在,则缓存该数据
        cache.set(key, storageValue);
    }

    return storageValue;
}

解决方案——布隆过滤器

对于恶意攻击中通过请求大量不存在的数据造成的缓存穿透问题,可以使用布隆过滤器来进行初步过滤。布隆过滤器是一种空间效率极高的概率型数据结构,它能有效地判断一个元素是否可能存在于集合中。具体而言,当布隆过滤器表示某个值可能存在时,实际情况可能是该值存在,也可能是布隆过滤器的误判;但当布隆过滤器表示某个值不存在时,则可以肯定该值确实不存在。

image

布隆过滤器是一种高效的概率型数据结构,由一个大型位数组和多个独立的无偏哈希函数组成。无偏哈希函数的特点是能够将输入元素的哈希值均匀地分布到位数组中,减少哈希冲突。添加一个键(key)到布隆过滤器时,首先使用这些哈希函数对键进行哈希运算,每个哈希函数生成一个整数索引值。然后,这些索引值经过对位数组长度的取模运算,确定在位数组中的具体位置。接着,将这些位置的值设置为1,标记该键的存在。

当查询布隆过滤器中某个键(key)是否存在时,操作过程与添加键时类似。首先,使用多个哈希函数对键进行哈希运算,得到多个位置索引。然后,检查这些索引对应的位数组位置。如果所有相关位置的值都是1,那么可以推测该键可能存在;否则,如果有任意一个位置的值为0,则可以确定该键一定不存在。值得注意的是,即使所有相关位置的值均为1,这也仅仅意味着该键“可能”存在,而不能绝对确认,因为这些位置可能已经被其他键置为1。通过调整位数组的大小和哈希函数的数量,可以优化布隆过滤器的性能,达到较好的准确性与效率平衡。

这种方法特别适用于数据命中率不高、数据集相对固定、对实时性要求不高的应用场景,尤其是在数据集较大时,布隆过滤器可以显著减少缓存空间的占用。尽管布隆过滤器的实现可能会增加代码维护的复杂度,但其带来的内存效率和查询速度的优势通常值得投入。

布隆过滤器在这类场景中的有效性得益于其能处理大规模数据集而只占用较少的内存空间。为了实现布隆过滤器,可以使用Redisson,这是一个支持分布式布隆过滤器的Java客户端。要在项目中引入Redisson,可以添加以下依赖项:

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.16.2</version> <!-- 请根据需要选择合适的版本 -->
</dependency>

示例伪代码:

package com.redisson;

import org.redisson.Redisson;
import org.redisson.api.RBloomFilter;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;

public class RedissonBloomFilter {

    public static void main(String[] args) {
        // 配置Redisson客户端,连接到Redis服务器
        Config config = new Config();
        config.useSingleServer().setAddress("redis://localhost:6379");

        // 创建Redisson客户端
        RedissonClient redisson = Redisson.create(config);

        // 获取布隆过滤器实例,名称为 "nameList"
        RBloomFilter<String> bloomFilter = redisson.getBloomFilter("nameList");

        // 初始化布隆过滤器,预计元素数量为100,000,000,误差率为3%
        bloomFilter.tryInit(100_000_000L, 0.03);

        // 将元素 "zhuge" 插入到布隆过滤器中
        bloomFilter.add("xiaoyu");

        // 查询布隆过滤器,检查元素是否存在
        System.out.println("Contains 'huahua': " + bloomFilter.contains("huahua")); // 应为 false
        System.out.println("Contains 'lin': " + bloomFilter.contains("lin")); // 应为 false
        System.out.println("Contains 'xiaoyu': " + bloomFilter.contains("xiaoyu")); // 应为 true

        // 关闭Redisson客户端
        redisson.shutdown();
    }
}

使用布隆过滤器时,首先需要将所有预期的数据元素提前插入布隆过滤器中,以便它能够通过其位数组结构和哈希函数有效地检测元素的存在性。在进行数据插入时,也必须实时更新布隆过滤器,以保证其数据的准确性。

以下是布隆过滤器缓存过滤的伪代码示例,展示了如何在初始化和数据添加过程中操作布隆过滤器:

// 初始化布隆过滤器
RBloomFilter<String> bloomFilter = redisson.getBloomFilter("nameList");

// 设置布隆过滤器的期望元素数量和误差率
bloomFilter.tryInit(100_000_000L, 0.03);

// 将所有数据插入布隆过滤器
void init(List<String> keys) {
    for (String key : keys) {
        bloomFilter.add(key);  
    }
}

// 从缓存中获取数据
String get(String key) {
    // 检查布隆过滤器中是否存在 key
    if (!bloomFilter.contains(key)) {
        return ""; // 如果布隆过滤器中不存在,返回空字符串
    }

    // 从缓存中获取数据
    String cacheValue = cache.get(key);

    // 如果缓存值为空,则从存储中获取
    if (StringUtils.isBlank(cacheValue)) {
        String storageValue = storage.get(key);
        if (storageValue != null) {
            cache.set(key, storageValue); // 存储非空数据到缓存
        } else {
            cache.expire(key, 300); // 设置过期时间为300秒
        }
        return storageValue;
    } else {
        // 缓存值非空,直接返回
        return cacheValue;
    }
}

注意:布隆过滤器不能删除数据,如果要删除得重新初始化数据。

缓存失效(击穿)

由于在同一时间大量缓存失效可能会导致大量请求同时穿透缓存,直接访问数据库,这种情况可能会导致数据库瞬间承受过大的压力,甚至可能引发数据库崩溃。

解决方案——随机过期时间

为了缓解这一问题,我们可以采取一种策略:在批量增加缓存时,将这一批数据的缓存过期时间设置为一个时间段内的不同时间。具体来说,可以对每个缓存项设置不同的过期时间,这样可以避免所有缓存项在同一时刻失效,从而减少瞬时请求对数据库的冲击。

以下是具体的示例伪代码:

String get(String key) {
    // 从缓存中获取数据
    String cacheValue = cache.get(key);

    // 如果缓存为空
    if (StringUtils.isBlank(cacheValue)) {
        // 从存储中获取数据
        String storageValue = storage.get(key);
        
        // 如果存储中的数据存在
        if (storageValue != null) {
            cache.set(key, storageValue);
            // 设置一个过期时间(300到600秒之间的随机值)
            int expireTime = 300 + new Random().nextInt(301); // Random range: 300 to 600
            cache.expire(key, expireTime);
        } else {
            // 存储中没有数据时,设置缓存的默认过期时间(300秒)
            cache.expire(key, 300);
        }
        return storageValue;
    } else {
        // 返回缓存中的数据
        return cacheValue;
    }
}

缓存雪崩

缓存雪崩是指在缓存层出现故障或负载过高的情况下,导致大量请求直接涌向后端存储层,从而引发存储层的过载或宕机现象。通常,缓存层的作用是有效地承载和分担请求流量,保护后端存储层免受高并发请求的压力。

然而,当缓存层由于某些原因无法继续提供服务时,比如遇到超大并发的冲击或者缓存设计不当(例如,访问一个极大的缓存项 bigkey 导致缓存性能急剧下降),大量的请求将会转发到存储层。此时,存储层的请求量会急剧增加,可能会导致存储层也发生过载或宕机,从而引发系统级的故障。这种现象被称为“缓存雪崩”。

解决方案

为了有效预防和解决缓存雪崩问题,可以从以下三个方面着手:

  1. 保证缓存层服务的高可用性
    确保缓存层的高可用性是避免缓存雪崩的关键措施。可以使用如 Redis Sentinel 或 Redis Cluster 等工具来实现缓存的高可用性。Redis Sentinel 提供自动故障转移和监控功能,可以在主节点出现问题时自动将从节点提升为新的主节点,从而保持服务的连续性。Redis Cluster 通过数据分片和节点间的复制,进一步提高了系统的可用性和扩展性。这样,即使部分节点发生故障,系统仍能正常运行并继续处理请求。
  2. 依赖隔离组件进行限流、熔断和降级
    利用限流和熔断机制来保护后端服务免受突发请求的冲击,可以有效缓解缓存雪崩带来的压力。例如,使用 Sentinel 或 Hystrix 等限流和熔断组件来实施流量控制和服务降级。针对不同类型的数据,可以采取不同的处理策略:
    • 非核心数据:例如电商平台中的商品属性或用户信息。如果缓存中的这些数据丢失,应用可以直接返回预定义的默认降级信息、空值或错误提示,而不是直接查询后端存储。这种方式可以减少对后端存储的压力,同时为用户提供一些基本的反馈。
    • 核心数据:例如电商平台中的商品库存。对于这些关键数据,仍然可以尝试从缓存中查询,如果缓存缺失,则通过数据库读取。这样即使缓存不可用,核心数据的读取仍可得到保证,避免了因缓存雪崩导致的系统功能丧失。
  3. 提前演练和预案制定
    在项目上线之前,进行充分的演练和测试,模拟缓存层宕机后的应用和后端负载情况,识别潜在问题并制定相应的预案。这包括模拟缓存失效、后端服务过载等情况,观察系统表现,并根据测试结果调整系统配置和策略。通过这些演练,可以发现系统的弱点,并制定相应的应急措施,以应对实际生产环境中的突发情况。这不仅可以提升系统的鲁棒性,还可以确保在缓存雪崩发生时,系统能够迅速恢复正常运行。

通过综合运用这些措施,可以显著降低缓存雪崩带来的风险,提升系统的稳定性和性能。

总结

Web层缓存显著提高了应用性能,通过减少重复的数据处理和数据库查询来加快响应时间。Redis作为高效的内存数据结构存储系统,在实现缓存层中发挥了重要作用,它支持各种数据结构,能够迅速存取数据,从而减少数据库负担,提升用户体验。

然而,缓存机制也面临挑战,如缓存穿透、缓存击穿和缓存雪崩等问题。缓存穿透通过缓存空对象和布隆过滤器来解决,前者避免了每次查询都访问数据库,后者有效减少了恶意请求的影响。缓存击穿则通过设置随机过期时间来缓解,这样可以避免大量请求同时涌向数据库。对于缓存雪崩,保证缓存层的高可用性、采用限流和熔断机制,以及制定充分的预案是关键。

有效的缓存管理不仅提升了系统性能,还增强了系统的稳定性。了解并解决这些缓存问题,能确保系统在高并发环境下保持高效、稳定的运行。精心设计和实施缓存策略是优化应用性能的基础,持续关注和调整这些策略可以帮助系统应对各种挑战,保持良好的用户体验。


我是努力的小雨,一名 Java 服务端码农,潜心研究着 AI 技术的奥秘。我热爱技术交流与分享,对开源社区充满热情。同时也是一位掘金优秀作者、腾讯云内容共创官、阿里云专家博主、华为云云享专家。

💡 我将不吝分享我在技术道路上的个人探索与经验,希望能为你的学习与成长带来一些启发与帮助。

🌟 欢迎关注努力的小雨!🌟

原创作者: guoxiaoyu 转载于: https://www.cnblogs.com/guoxiaoyu/p/18350801
STM32 CubeMX实战:手把手教你用I2C驱动IST8310磁力计(附完整代码) 本文详细介绍了如何使用STM32 CubeMX和I2C驱动IST8310磁力计,从硬件连接到代码实现的完整流程。重点讲解了I2C通信异常处理、传感器初始化序列优化以及中断驱动数据采集方案,帮助开发者快速搭建可靠的地磁场数据采集系统。 阅读详情

相关推荐

拆解 32 位节点头指针重排:用现代 C++ 手写高性能 Radix Tree 前缀缓存

冷快照的目的是被尽量多的会话共用。一条对话里,从开头到「问这个具体任务的那句 user 消息」之前,全部是稳定的:system prompt、工具定义、检索到的文档、few-shot 示例。第一个 assistant 标记一出现,后面就全是这条会话独有的内容了。切在最靠后那个 user 标记上,等于把这条会话独有的部分整个排除在快照之外。

weixin_45715405的博客 46

优化系统性能:解析Web缓存Redis应用挑战对策

Web缓存Redis作为系统性能优化的重要手段,在提高响应速度和减轻数据库压力方面发挥着重要作用。然而,它们的应用也伴随着一系列挑战。通过合理的缓存策略、内存管理、数据持久化以及高可用性和容错性配置,可以有效应对这些挑战,提升系统性能和稳定性。在未来的系统优化中,我们需要不断探索和实践,以应对日益复杂的业务需求和技术挑战

欢迎你来到我的博客 1038

AFSim 的资源文件目录

AFSim 的资源文件目录压缩,包含地图,3D模型,渲染等内容

Redis 双刃剑:缓存分布式锁的本质区别

很多后端开发者混淆 Redis 缓存分布式锁的用途,二者虽然都基于 Redis 实现,但解决的是完全不同的问题。本文区分缓存用于加速读、分布式锁用于保护并发写;梳理完整工作流程、核心特征、适用场景,展示二者在业务系统中的协作范式,列举开发中高频踩坑误区,帮助开发者建立清晰的选型思路,避免架构误用。

2501_92426010的博客 404

leetcode 146LRU缓存

这道 LRU 题,最值得记的就是下面这些高频点和易错点。负责维护最近使用顺序;访问过的放头部,容量满就删尾部。,哈希表里就会留下一个失效迭代器。这几个基本就是 LRU 的核心。负责 O(1) 找节点,不能只移动链表而不更新。

qq_63176310的博客 186

Claude Prompt缓存怎么验证命中?用前缀、断点和usage做A/B测试

验证Claude Prompt缓存需完整证据链:请求A写入缓存后,请求B需在有效期内复用相同前缀,并在usage中显示缓存读取Token。仅凭cache_read_input_tokens无法证明全Prompt命中。测试时需固定模型、渠道和断点位置,记录三个关键Token字段(creation/read/input)。自动缓存适合尾部追加的对话,显式断点适合"稳定资料+动态问题"场景。注意TTL混用和并发时序问题,测试应控制单变量并保存无敏感数据的结构化记录。最终结论需以API返回的us

AI147AI的博客 387

样式已经更新,用户仍看到旧页面?武汉网站建设中的缓存版本控制

企业网站发布新版样式后,有时开发人员已经确认文件更新,但部分访问人员仍然看到旧页面。这类问题通常不是页面没有发布,而是浏览器缓存、静态资源地址、代理缓存或发布顺序没有形成完整的版本控制。本文从网站建设实际发布流程出发,整理静态资源缓存、文件版本、上线顺序和验证方法。

2601_96141869的博客 326

如何管控企业 AI Agent 成本?哪些云平台可实现模型路由、缓存可观测性?

企业管控AI Agent成本,不能只盯着不同模型的单价对比,也不能等到账单暴涨后,才临时删减Prompt、限制员工使用。AI Agent和普通聊天机器人不一样,会持续多轮推理、读取长期上下文、检索知识库、调用各类工具,根据执行结果不断调整执行方案。一次用户任务,往往会触发多次模型和工具调用,最终成本是由模型选型、Prompt设置、Memory存储、工具数量、Agent循环逻辑、运行基础设施共同决定的。

jikemaoshiyanshi的博客 170

企业自建大模型推理集群,如何依托云上基建提升 GPU 利用率 Token 性价比?—— 聚焦智能路由、PD 分离、缓存复用弹性调度

企业搭建私有化大模型推理服务时,优先选用亚马逊云科技全套云上基础设施组合,可全方位优化算力效率投入产出比,核心架构包含:亚马逊云科技全球基础设施 + 弹性 GPU 资源池 + 智能推理网关 + 高性能推理框架 + 分级 KV Cache + 全链路可观测。规模化大模型推理的核心优化逻辑,并非盲目扩容GPU硬件数量,而是通过精细化调度让每一次模型请求匹配最优集群资源、最大化复用缓存数据、依托流量波动实现算力弹性伸缩。

jikemaoshiyanshi的博客 329

Claude API 成本直降90%:Prompt Caching 提示词缓存 Python 实战

Claude API 引入 Prompt Caching 机制,让重复调用成本直降90%。缓存将输入token拆为三类:缓存写入(1.25倍价格)、缓存读取(0.1倍价格)、普通输入。以1万token系统提示为例,第1次调用$0.0375,后续每次$0.003,100次调用成本$0.33而非$3.00。文章详解自动缓存显式断点两种用法、完整代码示例、四大踩坑记录及适用场景,附cache_control参数实战指南。

patrickstar231的博客 355

SpringBoot 核心原理 + Spring 事务 + 缓存

AOP 面向切面编程,在不修改原有业务代码的前提下,对方法进行增强,抽取通用横切逻辑。事务管理(@Transactional 底就是 AOP 动态代理)接口日志、请求耗时埋点权限校验、接口限流全局异常处理。

weixin_43590392的博客 208

Harmony os 技术实战|拼豆制图29:一次页面重组为何要守住稳定 ID 缓存

编号页同时展示主网格、放大入口、色号表和导出按钮。这四个区域都需要当前完整Pattern。如果每个区域各自按 ID 去仓库重建一次,70×70 图纸会重复创建 4900 个主格子和 256 个预览格子;如果页面直接保存多个Pattern工程选择用作为唯一选择状态,再通过按优先级解析完整对象,并用一组避免同一 ID 重复重建。这条链路表面只有二十多行,实际同时处理内置图案、当前生成图、最近生成记录、仓库结果和兜底项。patterns已经包含完整图纸,解析器却在扫描它之前又调用了一次仓库。

m0_46382645的博客 305

agno v2.9.0发布:身份感知调度、缓存隔离、安全加固组件重建全面升级

例如,一个团队负责人、路由器或者上游 Agent,只需要根据任务去发现并运行 Studio 中已经构建好的 Agent、Team 或 Workflow,但并不应该拥有创建、修改、删除 Studio 组件的权限。如果用户身份没有继续传递到子运行中,那么下游组件保存的状态、读取的上下文或运行结果,就可能无法正确对应到真正的调用用户。问题在于,工具执行名称被调用参数影响后,允许列表、是否需要确认、HITL 审批以及日志记录等机制,可能仍然按照声明时的工具名称进行处理,而实际执行的却是另一个工具。

福大大架构师每日一题 489

深入理解 HTTP 缓存:强缓存协商缓存完全指南(含流程图实战排查)

场景推荐响应头HTML 页面带指纹的静态资源登录态/隐私数据敏感但允许浏览器私有缓存接口(动态数据)通常no-store或短max-age强缓存不发请求,协商缓存发小请求(可能 304)优先于Expires;ETag优先于no-cache= 每次验证,no-store= 禁止缓存(区别必考)浏览器找缓存:Service Worker → Memory → Disk → 网络静态资源 = 强缓存 + 内容哈希指纹;HTML = 协商缓存缓存配置看起来是一行响应头的事,但。

2401_84182005的博客 279

[特殊字符]《电商API成本优化圣经:云内调用+配额守卫+缓存,月费从¥3000降到¥200》(附Python源码)

¥0.02/百次×(10,000-80,000免额)=¥0。¥0.05/百次×(10,000-50,000免额)=¥0。¥0.20/百次×10,000×30=¥600。¥0.15/百次×10,000×30=¥450。¥0.10/百次×10,000×30=¥300。¥0.10/百次×10,000×30=¥300。¥0.18/百次×10,000×30=¥540。¥0.018/百次×10,000×30=¥54。¥0.01/百次×10,000×30=¥30。2人×¥15k=¥30k/月。

yuweide19761218的博客 210

Redis 缓存三大经典问题深度解析:穿透、击穿、雪崩的原理实战解决方案

在高并发系统中,Redis 几乎是标配的缓存中间件。合理使用缓存可以大幅降低数据库压力、提升接口响应速度。但如果缓存使用不当,反而会引发严重的线上事故——缓存穿透、缓存击穿、缓存雪崩,这三个问题被称为 Redis 缓存的"三大杀手"。很多开发者在日常工作中用过 Redis,但对这三个问题的理解停留在"背八股文"的面,一旦在生产环境中遇到,往往手足无措。这篇文章从原理出发,结合实际代码(基于 Spring Boot + Redis),把三大问题的成因、危害、解决方案讲透,帮你建立完整的缓存防护体系。

xixiaoyunya的博客 335

linux7.2-CAS-llc缓存感知

Cache Aware Scheduling(CAS,缓存感知调度):它解决什么硬件问题、老调度器为什么瞎、7.2 里到底改了哪几处、收益边界在哪、以及怎么开。以前低端多核时代,一个 socket 内所有核共享同一片 L3,调度器把任务扔到哪个核差别不大。但现在服务器端和高端桌面是这样:于是“末级缓存域(LLC domain)”成了一个比 NUMA 节点更细、比核心更粗的关键边界:老 CFS/EEVDF 负载均衡只认“这个核闲不闲、NUMA 归谁、SMT 兄弟是谁”,不认 LLC 边界,所以同进程的多线程可

baidu_38316985的博客 325

数据开放服务 Redis 缓存架构设计:从腹稿到落地方案

以「数据开放服务平台」为背景,完整呈现一套 Redis 缓存架构设计:缓存定位、多级缓存、击穿/穿透/雪崩三大问题解决方案、Key 设计淘汰策略,可直接作为方案文档骨架。

mihuyang的博客 214

AI Agent 技能分享|MCP Server 查询慢怎么办:连接池、超时、缓存熔断

摘要:优化MCP Server查询性能的实用方案 针对MCP Server查询变慢的问题,本文提出了一套完整的优化方案,重点解决线上环境中的并发查询挑战。文章首先分析了查询慢的多个环节(连接池等待、SQL执行、数据传输等),建议通过trace_id分项记录耗时指标定位瓶颈。核心优化措施包括:合理配置SQLAlchemy连接池参数(大小、超时、回收机制);设置多级超时控制(连接等待、SQL执行、总时间预算);限制结果集行数和字节数;采用游标分页替代OFFSET分页;设计租户隔离的缓存策略并防止缓存击穿。特别强

二等碗 458
上一篇: 利用Spring Boot实现微服务的认证与授权
weixin_41324802
博客等级 码龄6年 23粉丝 · 0原创
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值