- 博客(146)
- 资源 (3)
- 收藏
- 关注
RSS订阅原创 提示词注入怎么防？LangChain4j护栏3招
提示词注入之所以难防，是因为它攻击的是"大模型分不清指令和输入谁说了算"这个根本特性，而不是某个代码漏洞。在 AI Service 调用链路的输入端和输出端各装一道必经的安检门，通过 success/failure/fatal/retry/reprompt 五种结果精确控制放行、拦截、改写和重试。三招回顾：第一招，实现用正则拦注入话术，命中就fatal一票否决；第二招，实现用failure拦敏感词和竞品；第三招，用reprompt逼模型重写不符合格式的输出，自动修复而不是直接放弃。三个护栏通过。
2026-11-06 09:09:41
218
原创 Redis持久化怎么选？RDB与AOF一次讲透
Redis 丢数据的根源，几乎都是持久化没配对。三种方式各管一段：RDB 是定时拍照（文件小、恢复快、会丢间隔数据），AOF 是记流水（数据全、文件大、恢复慢），混合持久化是"先拍照再记流水"（两者兼得）。核心配置就三条。配好这三条，最多丢 1 秒数据。别踩这些坑：默认配置不持久化、线上误用save阻塞主线程、AOF 文件损坏不会修、大内存实例fork慢、只开 RDB 扛核心业务、加载来路不明的 RDB 文件。最后给你一份行动清单：上线前用config get确认持久化配置；核心业务开混合持久化；把。
2026-11-06 09:09:14
225
原创 手写MCP Server，让大模型调用Java工具
MCP 解决的是一件事：让"写一次工具，处处可调用"成为现实，而不是为每个 AI 客户端重写一遍胶水代码。Spring AI 2.0 把这件事的复杂度压到了最低——一个@McpTool注解，方法签名自动变 JSON Schema，@Component自动扫描注册，几乎零配置。回顾本文：我们用 Spring Boot 4.1.1 + Spring AI 2.0.1 写了一个订单服务 MCP Server，暴露了查订单、取消订单两个工具和一个配置资源，代码完整可运行，用 MCP Inspector 就能验证。
2026-11-03 11:19:17
172
原创 秒杀接口被刷崩？Sentinel限流熔断三步扛住高并发
限流和熔断是分布式系统对抗「雪崩」的两道基础闸门，Sentinel 用一条责任链把它们做成了开箱即用的能力。限流看入口，熔断看下游。限流配在 Controller/网关挡住洪峰，熔断配在 Service 调用下游的地方，快速失败防止拖垮整条链。blockHandler 和 fallback 各管各的。被规则拦截走 blockHandler，业务异常走 fallback，别混用。规则要持久化，阈值要压测。内存规则重启就丢，生产必须接 Nacos/Redis 做动态数据源；
2026-11-03 11:18:51
413
原创 RAG检索质量怎么评估？3个指标+LLM裁判实战
RAG 系统"效果好不好"，不能靠感觉，必须靠量化评估。评估拆成两层：检索层用数学指标，生成层用 LLM 裁判，两层分开才能精准定位问题出在"没捞到"还是"没用对"。检索层三个指标各有分工：Recall@K 看"该找的找回来多少"，MRR 看"对的排在第几位"，Hit Rate 看"至少捞到一个没有"。三个一起看，漏检、排序、空手而归三种毛病都能暴露出来。生成层用 LLM 当裁判评忠实度——答案有没有照着资料说、有没有编造，这是防止大模型"一本正经地胡说"的最后一道闸。
2026-10-28 14:11:29
184
原创 Spring Boot 镜像瘦身实战：从 450MB 瘦到 180MB
回顾一下这篇文章的核心结论：Spring Boot 镜像大的根因，是用全量 JDK 当基础镜像，把编译器、调试器这些开发工具全打包进了生产环境。而瘦身的本质，就是「让镜像里只留运行时必需的东西」。JRE 换 JDK：直接扔掉开发工具，体积从约 450MB 砍到约 230MB，这是收益最大的一步。多阶段构建：编译环境（Maven + JDK）留在中间阶段，不污染最终镜像。分层 JAR：用把 jar 拆成四层，让依赖层和业务层分开缓存，构建速度从分钟级降到秒级。
2026-10-28 14:11:00
213
原创 Spring AI 语义缓存：重复提问不重复花钱
用户换着说法问同一个问题，每次都要重新付一遍大模型的账。它用 embedding 把"含义"变成可比较的向量，用相似度阈值判断"算不算同一个问题"，命中了就直接返回历史答案，一分钱 token 都不花。依赖用，版本对齐 Spring AI 2.0.1（当前最新 GA）。用建缓存，让它自动声明response等元数据字段——这是避免"缓存永远 miss"的关键。后端必须是 Redis Stack（带 RediSearch 模块）。阈值默认 0.8，按业务调；
2026-10-26 12:27:40
249
原创 Kafka 消息丢失或重复，生产环境这样配置才不翻车
Kafka 丢消息和重复消息，本质是同一个问题的两面：发送时的确认、消费时的提交，这两件事有没有做对。acks=all保证所有同步副本都确认，消息不丢；补上"ISR 可能只剩一个"的漏洞；让生产者重试不写重复数据；手动提交 offset 把"提交"和"业务处理成功"绑在一起；事务则提供多条消息的原子性。Kafka 3.0 之后，acks=all和幂等已经是默认值，你什么都不配，生产者侧就已经是"不丢不重"的底线配置。真正要你动手改的，只有两处——broker 侧的默认还是 1，得手动调成 2；
2026-10-26 12:26:38
149
原创 LangChain4j 流式输出实战：让 AI 回复像打字机一样逐字显示
本文介绍如何使用 LangChain4j 1.x 实现大模型流式输出，解决非流式响应导致的“卡死”体验。通过 StreamingChatModel 与 StreamingChatResponseHandler，实现每生成一个 token 就立即显示，显著降低首字延迟（TTFT），提升用户体验。代码完整可运行，包含 Maven 配置、OpenAI 接入及回调处理，适用于聊天机器人、写作助手等场景。
2026-10-25 18:51:42
333
原创 LangChain4j 多Agent协作实战：一个主控Agent调度多个专家，复杂任务不再一个人硬扛
本文介绍如何用 LangChain4j 1.x 的 AiServices 构建“主控调度+专家分工”的多 Agent 架构，解决单 Agent 职责混杂、Prompt臃肿、错误蔓延的问题。通过将商品、配置、文案等专家封装为独立 Agent，并以工具形式挂载至主控 Agent，实现任务拆解与协同执行。代码完整可运行，支持职责隔离、故障容错与模型按需分配，显著提升企业级复杂任务处理能力。
2026-10-25 18:51:13
308
原创 Spring Boot 项目到底怎么分层？Controller 别再写业务逻辑了
分层是一套依赖规则，不是建几个包就完事。上层依赖下层，单向流动，原则是"谁依赖谁，必须顺着流"。关注点分离是分层的魂：Controller 管 HTTP、Service 管业务、Repository 管数据，各管各的。依赖倒置是分层的骨架：面向接口编程、构造器注入，让业务层不绑死任何实现细节。业务复杂度决定选型：业务简单用三层，复杂用 DDD 四层，领域层把业务规则收敛成心脏，最干净最好测。
2026-10-22 09:01:50
131
原创 LangChain4j RAG查询改写实战：用户问得模糊，怎么让检索也能命中答案
用户问法 ≠ 文档写法，检索不到，回答自然烂。核心思路是用大模型当「翻译官」，检索前先把口语化、模糊的用户提问，改写成规范、信息完整、贴近文档的查询，再拿改写结果去向量库搜。在 LangChain4j 1.x 里，实现路径非常清晰：实现一个，把改写逻辑写在transform方法里，然后通过把它接进检索器，最后交给编排整条链路。改写失败要回退原查询，是必须守住的底线。动手建议：先跑通上面三个示例，用你自己的 FAQ 文档测一轮「改 vs 不改」的命中率对比，用数据决定要不要上线。
2026-10-22 08:59:59
160
原创 Spring Boot生产监控实战：Actuator一眼看穿服务健康
真实项目里，健康检查绝不只查数据库。比如某个关键的下游服务挂了，你的服务也该报不健康。import org/*** 自定义健康检查：模拟检查下游"库存服务"是否可达// 真实项目里这里是 HTTP 调用库存服务探活，或检查连接池 // 这里用一个可配置的开关模拟，方便演示 return Boolean . parseBoolean(System . getProperty("stock.up" , "true"));} }/**
2026-10-12 18:14:07
164
原创 Spring AI 2.0 自校正结构化输出实战：让大模型稳定吐出合格 JSON
这个 record 就是"契约"。Spring AI 会把它转成一个 JSON Schema（一种描述 JSON 结构的规范），塞进给模型的消息里，明确告诉模型：“请按这个结构输出。” 模型看到 Schema 后，输出就倾向于对齐这个格式。这一步解决的是"格式漂移"——从源头让模型知道你要 JSON。原理上相当于先给模型一张标准答卷，让它照着填。先定义一个数据结构。这个 record 就是模型必须对齐的"标准答案"。/*** 期望模型输出的订单信息结构。
2026-10-12 12:38:50
228
原创 Spring Cloud Gateway限流实战 Redis令牌桶算法+熔断降级
限流和熔断是微服务网关保障稳定性的两件核心武器，它们解决的是两个不同的问题：限流在请求进来前"主动防水"，控制进入后端的流量速率；熔断在检测到下游故障后"被动止损"，隔离故障防止雪崩。两者一前一后配合，网关就成了微服务的"安全阀"。Spring Cloud Gateway 用一个过滤器就实现了令牌桶限流，配合 Redis 让多实例共享同一个桶、实现全局准确的限流；再用过滤器接上 Resilience4j 做熔断降级，把故障兜在网关这一层，用户只看到友好的"请稍后再试"。
2026-10-12 12:38:24
207
原创 LangChain4j 1.19 混合检索+重排序实战：RAG 回答精准度翻倍
回到开头的问题：RAG 答非所问，多半不是大模型不行，而是检索环节把对的片段排到了后面。先用"向量按语义 + 关键词按字面"两路检索广撒网，保证不把对的漏掉；再用重排序模型对着用户问题逐条精排，把最相关的那一两条顶到最前面去生成回答。你记住三个关键点就够了：第一，向量检索懂语义不懂专有名词，关键词检索反过来，两者是互补关系不是替代关系；第二，多路结果的合并别比较原始分，用 RRF 这类只看排名的融合算法最省心，LangChain4j 的已经帮你把"多路+重排"封装好了；
2026-10-10 10:21:02
163
原创 为什么加了索引查询还是慢？MySQL索引失效五大场景排查实战
本文用 Spring Boot + MyBatis + MySQL 实战，把索引失效五大场景讲透了，核心记住一句话：索引失效的本质是破坏了索引列的有序性，让 MySQL 无法二分查找，于是退回全表扫描。动手复现三步走：建表（含联合索引）→ 造 20 万条数据 → 逐条跑 EXPLAIN 对比 five 种写法。你只需要这一个文件加几条 SQL，就能亲眼看明白。索引列套函数（YEAR/MONTH 等）→ 改成范围查询隐式类型转换（数字比字符串）→ 类型保持一致前导模糊%xx。
2026-10-10 10:20:18
137
原创 LangChain4j 多LLM切换实战：OpenAI断连秒切Ollama本地模型
我们来收个尾。问题本质：生产环境不能只绑一家大模型，要解决单点故障和成本控制。原理：LangChain4j 用统一所有模型；提供故障自动切换和恢复。实战：给了手动切换和自动降级两套完整可运行代码，含 POM、配置、配置类、启动类。面向接口（）编程，模型随便换；用做主备包装，OpenAI 挂了本地模型自动顶上，业务代码一行都不用改。这套思路不限于 LangChain4j，任何"多 Provider 抽象 + 容错包装"的生产系统都适用。建议你先把 3.4 那段。
2026-10-08 08:54:01
216
原创 Redis 分布式锁从入门到踩坑：手写 SETNX + Lua 到 Redisson 实战对比
分布式锁解决的是"多台机器同一时刻只能有一个执行关键代码"的问题。整个实现围绕三件事展开：加锁要原子、解锁要验明正身、过期时间要合理。从一个问题场景出发（集群扣库存超卖），我们经历了三次升级：原生SET NX EX一行命令加锁，解决了"加锁必须原子"；引入 Lua 脚本解锁，解决了"先比较再删除"的竞态和误删；引入 Redisson 看门狗，解决了"业务没跑完锁就过期"。凡是"先做 A 再做 B"这种分两步的操作，在分布式环境里都要警惕中间被插入，尽量合成一个原子操作。加锁的SET NX EX。
2026-10-08 08:52:57
537
原创 LangChain4j 1.19 Embedding 模型选型与本地向量化实战：别再盲选 OpenAI
本文聚焦RAG中常被忽视的Embedding模型选型问题，解析其原理与实战关键。指出错误选型会导致检索失效、成本飙升，强调“入库与查询必须同模型”这一铁律。基于LangChain4j 1.x，提供OpenAI、通义千问、本地BGE-M3三套可运行代码，实测表明：在中文场景下，本地BGE模型效果媲美甚至超越云端，且具备免费、离线、数据安全优势，是高性价比之选。
2026-10-07 21:29:35
474
原创 Nacos配置中心实战：改了配置不用重启服务，Spring Cloud项目一次搞定
本文基于 Spring Boot 4.0.7 + Spring Cloud 2025.1.3，手把手演示如何用 Nacos 配置中心实现配置热更新。通过命名空间、分组、Data ID 三级定位，将配置从代码中剥离，支持多环境隔离与动态生效。应用启动时拉取配置，运行中通过长轮询监听变更，结合 @RefreshScope 实现秒级更新，无需重启服务。配套完整代码可直接运行，解决生产环境改配置必须发布、重启的痛点，提升运维效率。
2026-10-07 21:28:55
733
原创 Spring AI 2.0 会话记忆实战，让 AI 助手记住每一次对话
大模型无状态导致对话记忆丢失，Spring AI 2.0 通过 ChatMemory 抽象与 Redis 持久化实现多轮对话记忆。文章详解会话管理、接口设计及存储解耦，提供基于 Spring Boot 4.1.1 + Spring AI 2.0.1 的完整可运行示例：内存测试、Redis 持久化、用户隔离会话，并避坑版本依赖问题，助力 AI 助手真正“记住你”。
2026-10-07 21:28:30
385
原创 虚拟线程 Virtual Threads 实战：Java 21 告别线程池阻塞噩梦
虚拟线程是 Java 21 给后端程序员的最大红利，它把高并发的复杂度从"精打细算线程池大小"解放成了"放心跑任务"。这件事的本质：传统线程用一个 1MB 司机占着等 I/O，虚拟线程用几十个司机来回接送几十万乘客，两者写起来都是同步阻塞代码，但内存和并发上限天差地别。你应该记住的关键点虚拟线程 = 写同步代码 + JVM 自动调度，不用改业务逻辑。JDK 21 起正式可用，Spring Boot 4.x 加一行配置即可启用。受益场景是 I/O 密集，不是 CPU 密集。
2026-10-01 07:42:08
177
原创 Spring AI 2.0 多模态实战：让大模型看懂图片识别商品和验证码
本文基于Spring AI 2.0，演示如何用GPT-4o/Claude视觉模型实现图片内容自动解析。通过UserMessage+Media组合，将图片与文本一同输入，实现商品属性提取、订单截图理解等多模态任务。提供四个可运行代码示例，涵盖配置、图像封装、结构化输出全流程，并对比本地OCR方案，阐明多模态模型在语义理解上的优势。框架自动处理编码、MIME识别与请求格式转换，开发者只需关注业务逻辑，大幅降低视觉AI接入门槛。
2026-09-28 11:14:07
351
原创 订单超时自动关闭，RabbitMQ死信队列与延迟队列实战
本文详解电商订单超时自动取消的优雅实现方案：基于RabbitMQ死信队列与延迟消息机制。通过配置队列级TTL和死信交换机，实现15分钟未支付自动关闭订单并释放库存。相比定时轮询和Redis过期回调，该方案性能高、可靠性强、可扩展。文章提供Spring Boot 4.1完整代码，涵盖配置类、消息生产与消费逻辑，手把手实现延迟任务，确保精准、高效落地。
2026-09-28 11:13:45
343
原创 LangChain4j 1.19 组装式 AI 客服实战：让大模型自己查库存、算价格、下订单
让 AI 客服从"话痨"变"办事员"的三板斧是 Tool Calling、结构化输出、会话记忆，而 LangChain4j 的 AiServices 把这三样自动串成一个循环。解决"模型查不到你的实时数据"——用@Tool注册 Java 方法，模型需要数据时自动声明调用，你的代码执行后把结果喂回。结构化输出解决"答案没法进系统"——接口返回类型定义成 record/class，模型按要求填字段，直接反序列化成 Java 对象。会话记忆解决"多轮对话串线"——
2026-09-25 12:59:21
167
原创 MySQL 分库分表实战：单表千万数据卡成狗，这样拆完查询快10倍
分库分表不是银弹，是单表实在扛不动、且查询高频带分片键时才该上的重武器。它的核心就两件事——用路由算法决定数据放哪张表，用聚合逻辑处理跨表查询。选对分片键是地基，忽略它 = 拆完比不拆还慢。动手的顺序建议是：先建 4 张同构表，写个几行的路由工具类，插入和查询都走分片键，跑通"快 10 倍"的效果；然后参考踩坑章节，把主键换成全局唯一、把订单号反查的分片键补齐；等数据量和查询复杂度真的大到需要中间件时，再平滑迁到 ShardingSphere，业务代码基本不用动。
2026-09-17 08:36:12
160
原创 Spring AI 2.0 Tool Calling 组合式 Agent 实战：让大模型学会调用你的方法
本文详解Spring AI 2.0的Tool Calling机制，解决大模型“幻觉”问题：通过注册真实方法（如查天气、算运费、查库存），让模型在回答前先申请调用工具，程序执行后回填结果，实现基于真实数据的智能响应。核心是模型与代码间的双向协作——模型决策调用，程序执行并反馈，形成可组合、可循环的Agent。文章手把手演示如何用Spring Boot 4.1.1 + Spring AI 2.0.1搭建多工具智能客服，全程可复现，代码结构清晰，适合实战落地。
2026-09-15 13:43:06
322
原创 Redis 缓存穿透击穿雪崩三大杀手：一个案例全看懂，附可运行代码
缓存穿透、击穿、雪崩，本质是"Redis 缓存保护数据库"这条防线上的三个漏洞：穿透是不存在的 key 没被缓存，击穿是单个热点 key 过期瞬间没拦住并发，雪崩是大批 key 同时过期或 Redis 整体不可用。缓存空值、互斥锁、过期时间随机化 + 高可用。查一个不存在的数据 → 穿透；查一个存在但缓存刚过期的热点 key → 击穿；一批 key 一起过期或 Redis 挂了 → 雪崩。空值要用特殊标记且短 TTL 随机化（穿透+防空值雪崩）、锁要带过期时间、解锁要 Lua 原子比对（击穿）、
2026-09-14 13:18:13
43
原创 JDK 27 新特性盘点：G1 成默认回收器、对象头瘦身、结构化并发
JDK 27 特性冻结，核心升级为：G1 垃圾回收器默认启用、对象头从 96 位降至 64 位（省内存）、结构化并发进入第 7 预览。无需改代码即可获得性能提升，内存占用降低，GC 更稳定。附可运行验证代码，实测对象头瘦身效果及结构化并发用法，升级收益显著，建议尽早评估。
2026-09-14 09:45:00
625
原创 LangChain4j RAG 分块策略实战：检索质量提升 80% 的 Chunking 调优全解
分块（Chunking）是 RAG 被低估的"第一道工序"，它直接决定向量检索能命中什么，进而决定大模型答得准不准。原理：分块的粒度必须匹配 Embedding 模型的语义上限，chunk 太小缺上下文、太大语义被稀释；overlap 给被切断的语义留缓冲。实践：用纯 JDK 21 + LangChain4j 1.19.0 写了三种分块器的切片对比，以及一个真正"分块 → 向量化 → 检索"的端到端实验，验证了"语义完整的 chunk 检索更准"。落地。
2026-09-11 12:31:15
156
原创 Spring Cloud OpenFeign 超时与重试机制实战：从连接超时到链路雪崩
<think>我们根据要求生成不超过150字的摘要。内容围绕OpenFeign超时与重试的生产故障、原理、配置方法和实战。需简明扼要。</think>OpenFeign 超时与重试配置不当会引发服务雪崩：先理清 LoadBalancer、HTTP Client、Feign 三层超时层级，再区分连接超时（可重试）与读超时（写操作禁止），最后通过 Spring Cloud 2025.1.2 实战配置安全重试，避免重复下单等问题。
2026-09-08 10:04:08
353
原创 LangChain4j 用 Redis 做向量检索 RAG，别再用废弃的旧依赖
<think>我们根据用户要求：根据提供的内容生成≤150字的文章摘要。内容很长，需要提取核心信息。摘要应简洁，包括问题、原因、解决方案和关键坑。注意字数限制。我们需计算摘要字数。中文150字约多少。输出摘要。</think>LangChain4j老版本接Redis的依赖已废弃，网上教程多失效。本文用LangChain4j 1.x最新依赖，手写Redis向量检索RAG：先讲RAG开卷考试类比与向量检索原理，再拆解Redis的HNSW索引及LangChain4j社区版接口，最后给出POM依赖（版本号已验证）与
2026-09-07 15:02:16
347
原创 Spring Boot多环境配置实战 配置文件加载顺序与切换不再翻车
配置来源的优先级和profile 的加载机制。命令行参数 > 环境变量 > 项目外配置文件 > 项目内 profile 配置 > 项目内默认配置。凡是"改了不生效"，先怀疑高优先级来源（环境变量、命令行参数、IDE 配置)把 key 抢占了，而不是怀疑自己写错了。application.yml 存公共配置，application-{env}.yml 存各环境专属配置，用指定激活哪个。生产跑不了开发库，九成是 active 没设对。
2026-09-03 10:20:42
225
原创 LangChain4j 1.x 大模型调用超时重试降级实战：让AI接口稳定不抽风
设对超时：连接超时看"连不连得上"（5～10 秒），读超时看"回不回得来"（60 秒起步）。LLM 生成慢，读超时必须给足。自动重试：用@Retryable配指数退避，只对临时错误（超时、429、5xx）重试，最多 2～3 次，别烧钱。本地降级：用@Recover在 LLM 彻底挂了时兜底，宁可给个不太准的结果，也别让系统白屏。不稳定是 LLM 的常态，你要做的是把"不稳定"关在代码里，而不是让它崩到用户脸上。从今天起，给你的 AI 应用加上超时、重试、降级这三道保险，深夜你就不会被报警电话叫醒了。
2026-08-31 09:30:00
346
原创 JVM JIT即时编译与逃逸分析实战 为什么你的Spring Boot代码忽快忽慢
解释执行＝每单都现场现做现送，慢但接单快。JIT 编译＝把销量最高的几道菜提前做好放保温柜，点单直接出，快。分层编译＝先备好普通食材（C1），再给爆款菜建立中央厨房流水线（C2），越做越熟手。逃逸分析＝判断这道菜是只给门口取餐（不逃逸，可提前做、不打包），还是必须排队打包带走（逃逸，只能正常做）。线上 JVM 应用的性能是"动态"的，不是一启动就满血。JIT 即时编译和逃逸分析，是 JVM 性能里最"看不见摸不着"却又最实用的两块知识。JVM 应用性能是动态的。
2026-08-29 10:15:00
389
原创 我们正在集体降智，只是没人愿意承认
AI 让开发速度翻了三倍，理解力却跌到三分之一。文章从「能力幻觉」切入，拆穿四个真相：来回沟通三天是能力缺口的度量、「写出代码就觉得自己厉害」是最毒的错觉、频繁重构是第一次就没做对、AI 只会做加法不懂架构意图。接受 AI 的变革，但别把脑子交出去——它只会让假装是工程师的人快速现形。有一件事，最近两年我越来越不敢跟人聊：我写代码的速度快了三倍，但我对自己写出来的东西的理解，只有以前的三分之一。我管这叫「用时间换幻觉」。
2026-08-29 09:30:00
148
原创 Spring AI 2.0 结构化输出自纠正实战：让 LLM 返回的 JSON 永远合格
Spring AI 2.0 给接口加了个默认方法。它是连接"自定义转换器"和"两个新开关"的桥梁：你实现它返回 schema（通常代理给 BeanOutputConverter），和就能在你自定义转换器上生效；用默认实现，这俩开关对你就变成空操作。这套设计很妙：它把"解析格式的灵活性"（可以自定义转换器处理代码块等脏格式）和"结构自纠正"（校验+重试）解耦成可以自由组合的两件事。先定义我们想让模型填的那个 Java record。
2026-08-28 09:30:00
200
原创 RocketMQ事务消息实战：下单与积分不一致问题彻底解决
RocketMQ 事务消息解决"本地事务与消息发送不一致"的经典分布式问题。本文先讲清楚问题本质（本地事务与发消息是两个独立操作，无法原子提交），再拆解事务消息的底层原理：半消息、本地事务执行、消息回查三阶段，以及回查次数与间隔等关键参数。然后基于 Spring Boot 4.1.0 + RocketMQ 5.5.0 给出完整的下单加积分实战代码：生产者、TransactionListener、消费者、建表 SQL 全部可复制直接运行。
2026-08-27 09:30:00
163
原创 Spring AI 2.0 接 Milvus 做混合检索：RAG 召回率翻倍的实战方案
向量检索懂语义但抓不住精确信息，关键词检索抓得准但不懂同义改写，两者合并后 RAG 的召回质量明显提升，尤其在客服、产品手册这类"型号 + 描述"混合的知识库场景。实现路径很清晰：Milvus 2.4+ 在同一张表里同时支持向量索引和全文索引，Spring AI 2.0 用+ RRF 算法把两路结果合并排序，你只需要配置好 starter、调一个 API，不用维护第二套检索系统。
2026-08-26 09:30:00
457
SpringBoot整合Quartz实现动态定时任务与灵活调度方案
2025-03-05
超市管理系统
2012-06-11
elasticsearch千亿数据查询速度非常慢
2022-12-02
TA创建的收藏夹 TA关注的收藏夹
TA关注的人