小健学 Java-CSDN博客

原创 Kafka 实践中的那些坑：重试、死信队列、反压问题全收录

如果消费失败，Consumer 不提交 offset，Kafka 会不断尝试重新投递同一条消息，直到消费成功或服务挂掉。Kafka 本身不支持延迟消息，可借助定时任务、调度服务（如 Quartz）、或使用中间件如Kafka Delay Queue 实现。在生产环境中使用 Kafka 时，绝不仅仅是 “生产消息 → 消费消息” 这么简单。这是一个非常实用的问题，尤其是在微服务系统中处理消息失败与自动重试时，的组合可以大幅提升健壮性与灵活性。，无需手动创建多个重试 topic，也不必手动编排转发逻辑。

2025-05-05 08:00:00 862

原创 Kafka 与 RabbitMQ、RocketMQ 有何不同？

Kafka 像日志系统，RabbitMQ 像消息代理，RocketMQ 像交易管家 —— 各自擅长领域不同，不能简单替代，只有合适不合适，没有好与不好。RocketMQ 的设计天生支持事务、顺序与高可用，但学习曲线更陡。⭐⭐⭐⭐（需熟悉分区、副本、ISR、Controller）RabbitMQ “路由灵活”，但并不天然支持顺序语义。支持 Java/C++/Python，但 Java 最佳。阿里电商“双11”场景演进而来，强调事务、安全和可控性。高，Spring Kafka / Flink 支持丰富。

2025-05-04 10:00:00 1623

原创 Kafka 中的幂等性与事务机制，能解决消息重复吗

Kafka 的幂等性（Idempotence）和事务（Transactions）机制，正是为了解决这个问题而生。但在电商下单、金融转账等严肃场景中，**“消息重复”或“丢失”**往往是系统灾难的根源。Kafka 本身是**“至少一次”（at-least-once）语义**：消息可以被重复消费，但不会丢。📌 所以，Kafka 可以帮你做到“不重不丢”的前提已经具备，但你仍需参与“最后一公里”的可靠性设计。启用幂等性后，每条消息都需携带 PID 和序号，会增加元数据同步开销，

2025-05-03 07:30:00 1073

原创 Kafka 性能调优指南：Producer与Broker篇

Kafka Producer 是写入性能的起点，优化 Producer 直接影响系统的吞吐与延迟表现。Apache Kafka 作为高吞吐、高可用的消息系统，在大规模生产环境中广泛应用。Kafka Broker 是整个系统的数据中转站，调优 Broker 对整体性能影响深远。默认值较小（16384 字节），在高吞吐场景中可以调大（如 64KB 或更高）往往是保障其稳定运行的核心环节。，建议在实际部署中结合压测与监控，逐步调试参数，达到最优值。，详解调优策略与原理，帮助你在高并发场景中稳定“飙车”。

2025-05-02 01:00:00 1225

原创 Kafka 消费者组机制详解：负载均衡与消费状态管理

在 Kafka 中，消费者组（Consumer Group）是实现高吞吐、横向扩展以及消息可靠消费的核心机制。Kafka 的消费者组不仅实现了消费端的负载均衡，还通过 Offset 管理保证了消息处理的可控性与可靠性。：同一个 Topic 中，每个 Partition 只会被组内某一个消费者独占消费，多个消费者自动分配 Partition，提升并发处理能力。如果消费者宕机或网络异常，Group Coordinator 会感知到心跳（Heartbeat）超时，立刻触发新的再平衡，确保消费过程不中断。

2025-05-01 00:45:00 1111

原创实战：用 Spring Boot 快速构建一个 Kafka 消息系统

初步搭建好系统之后，如果你想真正用 Kafka 支撑起生产级别的业务，还需要掌握更深入的能力。Spring Kafka 也支持 Avro 集成，只需添加依赖，并在配置中指定使用 Avro 序列化器、反序列化器。而 Kafka，以其高吞吐、可扩展、可靠的特性，成为了很多项目的不二之选。Kafka 会根据 key 的 hash 值选择分区，同样 key 的消息一定落到同一个分区，从而保证顺序。这种方式能精准控制 offset 的提交时机，比如确保消息真正处理成功之后再提交，极大提升了系统的可靠性。

2025-04-30 08:00:00 1276

原创 Kafka 消息是如何存储的？深入 Kafka 的底层文件结构

为了避免每次查找消息都全盘扫描 .log 文件，Kafka 使用 .index 文件加速 offset 查询。它的文件结构又有什么讲究？这种设计让 Kafka 既能按 offset 高速检索，也能高效按时间范围扫描，非常灵活。由于是追加写，因此 Kafka 写入磁盘时几乎不需要磁盘寻址，顺序吞吐率非常高。它不是靠复杂花哨的结构取胜，而是靠对磁盘物理特性的极致利用 —— 简单而高效。每个 Segment 由一组三个文件组成，共同协作，加速消息定位与检索。文件是按需滚动生成的，符合配置的最大大小或时间后切换。

2025-04-29 03:45:00 672

原创 Kafka 是如何保证消息顺序与高可用的？

在众多中间件中，Kafka 凭借其高吞吐、高可用、低延迟等特性，赢得了大量开发者和企业的青睐。如果一个 Consumer 挂了，Kafka 会触发 Rebalance，Partition 会重新分配，可能导致短时间重复消费或延迟。因此，只要 Producer 保证消息写入顺序，Consumer 严格按照 offset 拉取，因此，如果你将所有消息写入同一个 Partition，并使用单线程生产与消费，就能实现强顺序。Kafka 本质是为高吞吐设计的，中等强度的顺序保证是它的优势，而不是全局顺序。

2025-04-28 06:45:00 1191

原创 Kafka 架构详解：Broker、Topic、Partition 有什么讲究？

每个 Topic 可以划分为多个 Partition，不同 Partition 的消息是并行处理的，Producer 和 Consumer 都可以多线程操作不同 Partition。当你明白 Broker 是服务的承载者、Topic 是消息的分类器、Partition 是吞吐的分发器，你就不再会被那些名词绕晕，而是可以自信地做出架构决策。，通过 Topic 来分类管理消息，借助 Partition 实现并发和可扩展性，配合 Producer 和 Consumer 构建起完整的数据流转体系。

2025-04-27 11:00:00 1318

原创深入设计模式之「访问者模式」：让算法与对象解耦

假如“文件系统”不断新增新的元素类型（例如：压缩包、快捷方式），则每一个 Visitor 类都要同步新增 visit() 方法。一个博物馆中有不同类型的展品（如：文物、画作、化石）。是一种行为型设计模式，它让我们可以在不修改对象结构的前提下，为对象结构中的元素添加新的操作。导游就是访问者，各种展品是元素。访问者模式通常需要访问元素的字段/属性，这可能违反封装原则，暴露内部结构。但我们需要对它们执行很多不同的操作（如：展示、统计、导出、权限检查）本质上，它是“把变化的行为从数据结构中抽离出来”的一种方式。

2025-04-26 06:30:00 1070

原创深入设计模式之「模板方法模式」：定义流程框架，稳定主干逻辑

若报表类型不断增加，Excel、PDF、CSV、HTML、Word 等等，会导致继承类暴增，难以管理。是一种行为型设计模式，它在父类中定义算法的整体结构，而将某些具体步骤延迟到子类中去实现。主流程一致，但“冲泡方式”和“加料方式”不同 —— 这就是模板方法模式的典型场景。某电商平台需要根据配置调整“订单处理流程”：先扣库存再发短信，或者反过来。📌 适合用于：数据导出、钩子回调、审批流程、模版解析、任务执行等场景。换句话说，它是一种“规定流程主干、子类填补细节”的模式。子类依赖父类定义流程，继承链可能过长。

2025-04-25 05:15:00 891

原创深入设计模式之「策略模式」：行为封装与选择的利器

在一个国际支付平台中，每个国家 / 支付方式（支付宝、PayPal、微信、信用卡）都有独立计算手续费的策略。✅ 策略模式正是为了解决这类问题而设计：将每种策略抽离成独立类，使其可以互换、动态替换、灵活扩展。这些“出行方式”就是可互换的“策略”，我们可以将它们封装为类，再根据实际情况动态选择最合适的一种。是一种行为型设计模式，它定义了一系列算法，把它们一个个封装起来，并且使它们可以互换。策略模式让算法独立于使用它的客户端而变化，也就是“行为的选择权”交给了客户端。随着业务扩展，策略类数量过多，难以管理。

2025-04-24 07:00:00 613

原创深入设计模式之「状态模式」：行为随状态切换而改变的优雅设计

游戏中角色有十几种状态（移动、攻击、防御、中毒、隐身、眩晕、死亡…），每个状态之间又有交叉流转，导致状态类数量激增。若状态切换逻辑被多个模块调用，且没有统一封装状态转移规则，可能造成状态错误（如订单直接从“草稿”跳到“已发货”）。它将与状态相关的行为抽取为独立类，使状态切换更清晰、行为更灵活，避免了大量的条件分支。：将每种状态的行为独立封装，替代条件语句，使状态变化过程更具弹性与可维护性。每个状态拥有独立逻辑，如游戏人物状态（攻击、防御、死亡）将状态分组聚合（如“生存状态组”、“技能状态组”）

2025-04-23 06:00:00 989

原创深入设计模式之「观察者模式」：松耦合事件通知的优雅实现

在证券交易系统中，股价变化通知多个模块（图表、报警器、AI 预测、日志记录等），当观察者达到几十上百个时，系统响应变慢。Vue/React 项目中，未在组件销毁时正确注销监听器，导致观察者无法回收。🧠 如果使用硬编码通知所有响应者，会导致高耦合、难扩展、难测试。公众号无需关心谁订阅、订阅者如何处理，只需“推送”。被观察者，维护观察者列表，状态变化时通知所有观察者。多个观察者收到通知的顺序不固定，易导致状态不一致。具体主题，包含状态逻辑，状态变更后调用通知。观察者，定义响应接口，实现接收通知的行为。

2025-04-22 08:15:00 810

原创深入设计模式之「备忘录模式」：如何优雅地保存与恢复对象状态？

开放世界类游戏（如《赛博朋克2077》）若每分钟自动存档一次，完整记录玩家状态（物品、位置、任务等），极易造成硬盘占用暴涨。当用户在 Photoshop 中频繁调整图片时，若每次都保存整张图片快照，内存消耗迅速增长。是实现“状态快照 + 状态恢复”最经典的方案之一，封装性好、使用灵活。负责人，记录并管理备忘录对象，决定何时保存和恢复状态。原发器，拥有需要保存的状态，负责创建和恢复备忘录。网页记录作为状态备忘录，点击后退即恢复前一个状态。备忘录，存储对象的内部状态，但不暴露给外部。

2025-04-21 08:30:00 1057

原创深入设计模式之「中介者模式」：如何降低对象之间的耦合？

中介者模式是一种非常实用的**“通信调度解耦工具”**，在大型系统中能极大地简化对象间的交互关系。在大型 GUI 界面中，按钮、表单、下拉菜单等频繁交互，所有逻辑都集中在中介者，使其难以维护。多个线程同时与中介者通信（如多设备接入智能家居中心），中介者处理不及时将拖慢整个系统。它提供一个中介者对象，统一协调多个对象之间的通信，避免“网状结构”的耦合。具体同事类，实现具体行为，通过中介者与其他对象通信。拆分多个中介者，每个中介者管理一个“子系统”具体中介者，实现协调逻辑，管理各个同事对象。

2025-04-20 07:30:00 989

原创深入设计模式之「迭代器模式」：如何优雅遍历集合对象？

你只需按“下一台（next）”、“当前频道（current）”、“是否还有下一台（hasNext）”，就可以完成频道遍历。比如要实现“返回上一步”功能，但 Iterator 无 previous() 方法，需用双向迭代器或自己记录索引。多个线程遍历同一个集合，若迭代器未加锁，可能会抛出 ConcurrentModificationException。抽象迭代器，定义 hasNext()、next() 等遍历接口。，无论集合底层是数组还是链表，客户端统一使用迭代器接口即可。

2025-04-19 07:45:00 825

原创深入设计模式之「解释器模式」：如何为“语言”定义文法并进行求值？

在这个模式中，每一个语法规则都对应一个类，构建出一个语法树，解释器通过遍历语法树来解析和执行。当你输入表达式 5 + 3 - 2，我们希望有一个“计算器”能读懂这句话并求值。每一层都是递归，若使用在实时性要求高的场景（如高频交易），效率难以保证。它本质上是将语言规则抽象成对象结构，然后用解释器来执行表达式的求值。若语言语法丰富，每个表达式都要创建一个类，维护成本大。表达式树越深，递归解释越慢，适合简单语法而非复杂语言。非终结符表达式，包含子表达式（如加法、减法）终结符表达式，不能再分解（如数字、变量）

2025-04-18 07:00:00 1157

原创深入设计模式之「命令模式」：如何优雅地将“请求与执行解耦”？

而“遥控器”不关心电视是如何开机的，它只是发出“开”的命令。命令模式是“解耦请求与执行”的强大工具，特别适用于GUI按钮事件、任务队列、撤销重做等场景。一个系统中有几十个按钮，每个按钮都要创建一个 XXXCommand 类，会导致类数量快速增长。将“请求封装为对象”，从而让我们可以将请求的发送者与接收者解耦，使得命令可以。，执行者只负责调用，而不关心命令的具体实现。调用者（请求发送者），负责调用命令对象的方法。可以将多个命令封装为复合命令，支持宏操作。命令对象封装了具体逻辑，灵活更换命令。

2025-04-17 07:30:00 964

原创深入设计模式之「责任链模式」：如何构建“灵活可扩展”的请求处理机制？

它非常适合处理流程复杂、处理器需要解耦的业务场景，如审批流、校验链、拦截器等。这条审批链就是责任链的典型例子。审批链设计为：员工 -> 主管 -> 副经理 -> 经理 -> 总经理 -> CEO。一个请求可以被多个处理器中的某一个处理（如审批流、拦截器）抽象处理器，定义处理请求的接口及设置下一个处理器的方法。具体处理器，判断能否处理请求，不能则转交给下一个处理器。每个处理器只关心“自己能否处理”，不关心链的全貌。若链尾未做“兜底处理”，请求可能直接被“吞掉”。请求发送者，只需设置处理器链，不关心谁来处理。

2025-04-16 07:00:00 897

原创深入设计模式之「代理模式」：如何为对象添加“防火墙”？

✅ 使用代理模式，可以在不改变目标对象的前提下，为其提供“保护层”，增强系统的可控性与可扩展性。代理类，持有 RealSubject 的引用，控制访问并添加附加行为。动态代理需要反射，性能较差。延迟加载，只有真正需要时才创建目标对象（如图片/视频预览）明星专注唱歌，访问全由代理处理，这就是典型的代理模式。某个对象创建成本高，调用耗资源，不希望用户直接访问。代理位于本地，目标对象在远程服务器（如 RMI）代理模式通过“控制访问”的方式，为原始对象提供。抽象主题，定义目标对象和代理对象的共同接口。

2025-04-15 05:30:00 750

原创深入设计模式之「享元模式」：如何实现海量对象的内存优化？

通过缓存共享对象池，有效减少对象数量，是提升性能、节省内存的利器。，在游戏引擎、图形渲染、地图标注、文档编辑器等场景中广泛应用。享元对象只保留内部状态，外部状态由使用者传入，从而实现共享。，不可维护可变状态，否则线程安全/数据一致性无法保证。一个类可能有多个享元实例（可共享），依赖外部状态。减少重复对象创建，尤其适用于海量相似对象的系统。具体享元，实现内部状态并支持外部状态的传入。客户端，通过工厂获取共享对象并传入外部状态。，通过缓存池共享，从而大幅减少内存使用。对象状态需拆分、管理共享池、控制外部状态。

2025-04-14 07:30:00 1195

原创深入设计模式之「外观模式」：如何为复杂子系统提供统一入口？

客户端无需了解灯光/窗帘/投影仪等子系统的顺序与操作细节，只需调用 startMovieMode()，系统自动完成所有操作。客户端，仅通过 Facade 接口调用，无需了解子系统的复杂实现。改变子系统实现不会影响客户端，只需调整 Facade 即可。如果客户端只依赖 Facade，无法使用子系统的高级功能。外观模式通过引入一个统一接口，隐藏多个子系统的复杂性，子系统类，提供实际的业务功能，但不直接暴露给客户端。打交道，背后细节由 Facade 统一协调，外观类，对外提供统一接口，内部协调多个子系统。

2025-04-13 08:30:00 1005

原创深入设计模式之「装饰器模式」：如何在不修改原类的前提下，灵活扩展对象功能？

相比继承的“编译时增强”，装饰器提供的是“运行时增强” —— 将一个对象“包装”进一个装饰器类中，实现功能的扩展、叠加、修改。装饰器模式是一种强大的结构型模式，适合在不改变原有代码的前提下，为对象添加“可插拔”的功能。装饰器和被装饰者实现同一接口，装饰器内部持有被装饰者引用，并调用其方法。⚠️ 装饰器适合功能“独立、可插拔”的场景，避免为了架构而架构。外观上相似，目的不同（代理是控制访问，装饰是增强功能）具体装饰器，实现附加功能，再调用被包装对象的方法。✅ 装饰器模式通过“组合 + 包装”，实现功能。

2025-04-12 07:30:00 765

原创深入设计模式之「组合模式」：如何优雅地处理树形结构对象？

客户端无需关心是文件还是文件夹，只需要调用 show()，容器节点会自动递归其子节点完成行为。如果某些节点只能读、不能写，统一接口无法表达不同角色权限，需额外机制处理（如权限控制层）。组合模式是处理树形层级结构的利器，它让我们用统一的方式处理对象和组合结构，显著提升了系统的。⚠️ 文件本不应包含子节点，但接口中有 add() 方法，被迫实现空逻辑，违反单一职责。这意味着，无论你处理的是一个对象，还是一组对象的组合，容器节点，持有子节点列表，递归地执行子节点的行为。无论是单个文件，还是整个文件夹组合，

2025-04-11 10:00:00 1213

原创深入设计模式之「桥接模式」：如何让系统灵活应对“两个维度的变化”？

只有一个产品维度（比如一个图形库），仅有一个 RenderEngine。✅ 桥接模式通过“组合代替继承”，将这些变化维度拆开，结构更清晰、扩展更灵活。本质上，桥接模式是两个维度的组合：一个负责抽象行为，一个负责实现细节。桥接模式将遥控器类型与电视品牌解耦，让它们可以任意组合，无需类爆炸。相比直接继承，多了一个接口和多个组合类，新手阅读理解成本略高。，通过“桥接”连接，使得这两个维度可以灵活组合、解耦演进。拆分后，需要同时管理抽象层和实现层，代码数量增多。的强大工具，它用组合方式代替继承，提升了系统的。

2025-04-10 10:00:00 862

原创深入设计模式之「适配器模式」：如何让“插头不兼容”的系统顺畅协作？

假设你原本的系统接口是 Target，但你现在想接入某个 SDK（它只有 specificRequest() 方法），无法直接使用。它优雅地隔离了“调用者”和“被调用者”之间的差异，避免侵入式修改，有效提升系统兼容性和灵活性。但请注意，适配器滥用会让系统结构臃肿、逻辑分散，因此适当封装、统一命名、归档适配器十分重要。出国旅行时，你的手机充电器是扁头插头 🇨🇳，但酒店插座是圆孔 🇪🇺，怎么办？若接口种类多，适配器数量可能爆炸，代码维护成本升高。希望在不破坏现有代码的基础上，兼容新旧接口。

2025-04-09 10:00:00 1090

原创深入设计模式之「原型模式」：如何高效复制对象？

🔁 它通过复制而不是重新 new，提升了系统性能、提升了构建效率，但也必须注意。在游戏中，每次创建玩家角色时，如果都从头设置所有技能、装备、等级，非常低效。如需Java面试题资料，可关注公众号：小健学Java，回复“面试”即可获得！🚫 在数据结构不稳定、对象小而轻、构造可变时，应优先使用建造者或工厂。这时候，与其每次都“从零构造”，不如先准备一个“原型对象”，通过。方式二（原型模式）：复印去年的年报模板，改个数据，一分钟完成。方式一（传统构造）：从空白页开始写，每次都要调格式、调结构。

2025-04-08 10:00:00 772

原创深入设计模式之「建造者模式」：解决构造复杂对象的痛点

在高频场景中构建对象，例如 JSON 解析构造 UserProfile，对象多、字段小，用建造者反而拖慢速度。建造者模式：就像你点一个套餐，服务员一步步问你：要不要汤？普通构造函数：就像你去餐厅点菜，一口气说出所有菜名，错一个都麻烦。大量批量构建小对象时，建造者中间对象反复创建，影响 GC 压力。某些字段若必须初始化，建造者也需要手动校验，否则容易遗漏。构造参数过多，位置易错，字段混淆，阅读性差，维护代价高。建造者模式最适合“对象参数众多，构建步骤复杂”的场景。构建复杂对象，参数种类多且结构不稳定。

2025-04-07 12:00:00 942

原创深入设计模式之「工厂模式」：什么是工厂模式？该如何使用？

你开发一个跨平台桌面应用（支持 Windows / Mac / Linux），使用抽象工厂创建不同风格控件，但 UI 突然要求“新增滑动条组件”，结果每个产品族都要实现一套 Slider 系列，实现成本大幅上升。你在写一个图形渲染引擎，每种图形（Circle、Square、Triangle）都用一个 Factory 实现，结果光工厂类就有 20 个，新人很难理清结构。当系统需要引入更多“产品”时，直接 new 的方式必须修改原有逻辑，而工厂模式允许你通过新增类实现扩展，

2025-04-06 10:00:00 997

原创深入设计模式之「单例模式」：什么是单例？怎么写才优雅？

由于是高并发环境，两个线程同时判断 instance == null，结果各自都 new 出一个实例，日志写入出现错乱。假设你在开发一个大型系统，定义了 ConfigManager 使用单例加载配置文件，结果由于饿汉式写法，它在系统启动时即加载文件，哪怕后续根本没使用这个模块，浪费了 500MB 的内存。在一个高频使用的工具类中，比如缓存服务 CacheManager，单例访问非常频繁。结果你加了同步，导致并发性能急剧下降，吞吐量下降 30%。最终你以为日志是集中记录，其实是分开写的，分析出了大问题。

2025-04-05 10:00:00 1204

原创一文带你了解JDK中的虚拟线程

虚拟线程的引入为 Java 的并发编程带来了新的可能性，极大地提升了高并发应用的开发效率和系统性能。通过理解其实现原理和优势，开发者可以更好地利用这一特性，构建高效、可扩展的 Java 应用程序。

2025-04-04 10:00:00 1207

原创一致性协议Raft与Kafka中的KRaft

KRaft 模式通过引入 Raft 共识算法，简化了 Kafka 的架构，减少了对外部依赖的需求。通过事件驱动和单线程处理机制，控制器能够高效地管理集群的元数据和状态变更。同时，引入 Timeline 数据结构，确保了在领导者切换时内存状态的一致性和可靠性。这种设计提高了 Kafka 集群的一致性和高可用性，适应了更大规模的集群管理需求。开源一个纯AI生成的健身记录App，如需源码，可关注公众号：小健学Java，回复“健身”即可获得！

2025-04-03 12:00:00 959

原创 Redis高级特性：深入剖析内存管理

内存碎片是指由于内存分配和释放不均衡，导致系统中的可用内存无法被有效利用的现象。在 Redis 中，由于数据结构的动态变化、不同数据类型的存储方式以及底层内存分配器的特性，都会导致内存碎片的产生。外部碎片（External Fragmentation）：Redis 释放的内存块大小不一，导致无法高效地重新分配。内部碎片（Internal Fragmentation）：Redis 分配的内存块大于实际数据所需的空间，造成浪费。Redis 作为一个基于内存的数据库，需要有效地管理和回收内存，以保证高效运行。

2025-04-02 08:00:00 1874

原创 Redis与MySQL数据一致性方案详解

Redis与MySQL数据一致性是指在同时使用这两种数据库时，确保两者存储的同一份数据在逻辑上保持同步，避免出现数据差异的问题，Redis 作为缓存层，MySQL 作为存储层，如何保证两者数据一致性是一个重要的问题。Cache Aside 方案是最经典的缓存策略，适用于读多写少的场景。高并发场景下，多个线程可能同时更新数据库和缓存，引发顺序错乱（如先删缓存后更新DB时，其他线程可能在DB更新前读取旧值并重新写入缓存）。如果缓存未命中，Redis 会自动从 MySQL 加载数据，并写入缓存，随后返回数据。

2025-04-01 08:00:00 1421

原创 Redis分布式锁原理解析与实战代码

Redis分布式锁的实现方案，提供库存超卖实战示例代码

2025-03-31 07:30:00 1096

原创 Redis 常见问题解析：缓存穿透、缓存击穿、缓存雪崩与缓存抖动

假设一个高并发的电商平台，秒杀商品的库存信息频繁更新，每次更新都会使缓存失效，导致所有请求短时间内都去查询数据库并重新构建缓存。当缓存数据过期后，在短时间内大量请求直接落到数据库，导致数据库负载急剧上升，甚至可能宕机。如果数据库查询后发现数据不存在，我们可以将 NULL 结果写入缓存，并设置较短的过期时间（如 5 分钟），防止频繁查询同一不可用数据。假设一个电商系统中，用户查询商品详情时，系统首先会去 Redis 缓存查询，若缓存未命中，则查询数据库。，导致所有请求直达数据库，可能导致数据库崩溃。

2025-03-30 10:00:00 954

空空如也

空空如也