- 博客(189)
- 收藏
- 关注
RSS订阅
原创 我的技术博客创作回顾：从一个异常开始的1460天
本文作者回顾了自己成为技术博主1460天的历程，从最初解决一个NumberFormatException开始，逐步沉淀出围绕互联网医院项目的真实技术实践。内容涵盖分布式事务、腾讯IM对接、密码学应用、AI分诊助手、运维踩坑、Redis与MySQL优化等系列文章，均源于一线开发中的真实问题。写作以“案例驱动”“系列化输出”“小白友好”为特点，强调技术服务于业务，且在记录中实现自我深化。文章不仅帮助他人避坑，更推动自身成长，未来将持续深耕AI医疗、虚拟线程与架构经验系统化整理。
2026-09-17 23:45:34
424
原创 测试环境 K8s 502 故障复盘：被 ClusterIP 表象误导，最终定位 kube-proxy 规则缺失
互联网医院系统测试环境突发502故障、No route to host (Host unreachable)，影响cms、doctor等服务。排查发现kube-proxy未能为service-titan-zuul生成iptables/IPVS转发规则，导致ClusterIP成为网络黑洞。Nginx日志显示upstream连接失败，表现为"无路由到主机"和"连接超时"。最终通过全量重启kube-proxy恢复服务。该问题暴露出K8s网络组件稳定性风险，建议加强监控并建立自动化恢复机制。
2026-08-13 23:33:20
470
原创 AI医疗分诊与健康咨询助手agent开发——（0）项目背景与概要
本文作者基于互联网医院项目中的挂号流程痛点、儿时就医困惑记忆以及对Agent技术的好奇，决定开发一个AI医疗分诊与健康咨询助手。该项目定位为学习型AIAgent应用，通过多轮追问、急症拦截、科室推荐等功能模拟分诊流程，所有输出均带免责声明，严格规避医疗红线。技术栈采用Java+Spring生态，结合本地模型Ollama和向量数据库pgvector，通过8个分工明确的Agent实现流程编排。项目将分10个阶段迭代开发，每阶段确保可演示验证，并配套9篇系列文章记录开发过程。作者强调该项目的核心目标是探索Java
2026-06-07 23:35:44
350
原创 Java AI Agent 开发中的 RAG 实现方案及小白入门指南
本文介绍了RAG（检索增强生成）技术的核心原理与应用实践。RAG通过"先检索后生成"的方式解决大模型幻觉问题，包含文档解析、向量化存储、语义检索和提示词生成四个关键步骤。文章对比了Java生态三大RAG框架：SpringAI适合SpringBoot项目、LangChain4j功能全面灵活、SpringAIAlibaba专为阿里云生态优化。同时讲解了向量数据库选择策略和入门学习路线，指出文档切块、Embedding模型配置等常见技术难点，并给出优化建议。
2026-05-17 16:59:28
959
原创 （一）OpenClaw大龙虾-云端服务器部署-对接飞书-保姆级教程
OpenClaw云端linux服务器部署教程、windows、mac部署同理，步骤基本没差别
2026-03-06 22:15:47
3608
原创 Spring AI Alibaba 个人学习笔记
摘要： Spring AI Alibaba是基于Spring AI构建的开源项目，旨在为Java开发者提供便捷的AI应用开发框架。它深度集成了阿里云百炼大模型服务和通义系列模型，提供高层次API抽象、云原生集成方案和企业级AI生态支持。相比Python生态的AI工具，SAA解决了Java开发者面临的工具缺乏问题，继承了Spring AI的核心能力并扩展了模型、向量存储等功能。SAA与Spring AI、LangChain4J相比，在Spring Boot集成、阿里云生态适配等方面具有优势。
2026-02-03 21:26:59
628
原创 应用集成平台-系统之间的桥梁-思路分享
集成平台作为系统间的"前台服务员"，提供三种核心场景：1）页面重定向（带安全跳转机制）；2）HTTP API调用（后台数据获取）3）消息广播（群发通知）。平台采用严格的安全机制，包括Token认证、SM4加密、防重复请求等技术保障。文中分步骤说明了各场景的调用流程，包括必要的接口、参数准备和加密要求，并提供了常见错误解决方案。最后强调必须遵守的安全规则，如Token使用规范、数据加密要求等。集成平台通过统一入口和安全认证机制，实现了系统间安全高效通信
2025-12-16 23:43:50
788
原创 Gateway网关层灰度方案—xx互联网医院系统灰度发布设计与思路详解
本文介绍了一种基于Spring Cloud微服务架构的灰度发布方案，该方案已在某地区互联网医院系统中成功应用。系统采用网关层+负载均衡器的设计思路，通过请求头驱动流量路由，实现灵活可控的灰度发布。核心架构包含配置管理层、网关层、负载均衡层和业务服务层，支持多维度灰度判断、上下文透传和安全降级机制。该方案具有轻量级集成、无侵入式设计等特点，有效满足了医疗行业对系统稳定性的严格要求。
2025-07-27 21:34:49
1330
2
原创 企业级 Java 应用灰度发布设计方案与实践全解析
摘要：灰度发布作为互联网产品迭代的关键技术，通过渐进式部署实现风险可控、快速验证和平稳过渡。文章系统剖析了6种主流实现方案：代码硬编码、配置中心、网关层、服务网格、Kubernetes Ingress和Java Agent，对比了各方案的技术复杂度、业务侵入性和适用场景。针对中大型系统，推荐采用配置中心或网关层方案实现灰度规则与业务解耦；云原生环境建议结合服务网格或K8s Inress；遗留系统可采用Java Agent改造。
2025-06-25 22:58:03
1707
原创 Spring Plugin框架应用实践：医院多租户客户端动态路由方案解析
本文以医院多租户系统为例，探讨了基于SpringPlugin框架实现动态业务路由的解决方案。通过策略模式设计插件接口，结合PluginRegistry实现策略自注册和动态匹配，有效解决了SaaS系统中客户需求差异化的痛点。文章详细解析了核心实现机制，包括插件定义、策略枚举、动态路由控制等关键技术点，并总结了配置驱动扩展的设计优势。该方案已在三甲医院落地验证，具有核心模块零修改、策略间完全隔离、支持热部署等特点，为类似场景提供了可复用的架构范式。
2025-06-05 16:07:21
1134
原创 Redis延时队列在订单超时未报到场景的应用分享
Redis 延时队列是一种特殊的队列，它允许元素在指定的时间后才被消费。在 Redis 中，通常可以使用有序集合（Sorted Set）或 Redisson 提供的延迟队列来实现。有序集合的分数可以用来表示元素的过期时间，通过不断轮询有序集合，当分数小于当前时间时，就将元素取出消费。而 Redisson 则提供了更方便的 API 来实现延时队列，它内部封装了很多复杂的操作，让开发者可以更简单地使用。
2025-03-29 10:46:30
1215
原创 关于java对接微信公众号（对接百度AI实现图片文字识别，对接聚合数据实现笑话、谜语大全，成语接龙等功能）
关于java对接微信公众号（对接百度AI实现图片文字识别，对接聚合数据实现笑话、谜语大全，成语接龙等功能）：只是自己学习使用，所以有点不规范，请见谅。本文直接附上源码与效果图，具体操作步骤请参考另一篇文章：http://t.csdnimg.cn/PQu25
2024-04-26 17:51:37
1015
2
原创 关于JAVA如何对接海康威视（iSecure Center综合安防管理平台）门禁和摄像头视频取流
根据自己的需求灵活选用对接方式。我们客户购买了海康的综合安防管理平台，经与海康交流过后，我这里选择直接通过调用海康的综合安防管理平台的Open Api进行对接这篇文章只包含java如何对接海康威视，不涉及前端具体技术需求：对接海康威视的视频与门禁。（1）大屏可视化，实现视频的取流，摄像头监控实时预览。（2）获取摄像头监控点与门禁设备的状态，是否运行正常（3）获取门禁设备的事件，用户进出情况记录。大致对接流程：注册登录后，在场景方案中选择基础对接，先了解接口安全认证规则，确保必要参数客户/海康已经提供，
2024-04-25 13:30:35
15365
3
原创 DDD（领域驱动设计）篇二：DDD 和三层架构到底差在哪？
本文对比了三层架构与DDD分层架构在系统设计上的差异，指出核心区别不在于层数，而在于业务逻辑的合理归属。三层架构中，服务层混杂业务规则、远程调用、锁与缓存等多重职责，导致变更成本高；而DDD通过应用层（领班）、领域层（厨师）、基础设施层（设备）的分离，实现职责解耦。以订单模块为例，DDD将状态流转交由状态机管理，规则由Handler处理，锁通过适配器隔离，使代码更清晰、可维护性更强。文章强调：复杂状态流转、规则频繁变动或多团队共用场景应采用DDD，否则过度设计。关键在于先厘清业务边界，而非简单“搬代码”。
2026-10-26 22:59:24
11
原创 DDD（领域驱动设计）篇一：DDD 到底在解决什么问题？
本文以一个常见订单状态异常问题切入，揭示传统三层架构下业务规则分散、难以维护的痛点。引出DDD（领域驱动设计）的核心目标：让代码结构匹配业务结构，解决规则散落、改漏、理解成本高等问题。通过三大核心思想——统一语言（用业务术语命名）、充血模型（规则内聚于对象）、限界上下文（划分清晰业务边界），展示如何实现规则不丢失、不重复、易维护。最后指出，DDD适用于复杂业务场景与多团队协作的中台系统，而非简单增删查改。建议开发者自查现有模块，思考规则是否可重构。
2026-10-26 17:51:20
204
原创 一次线上锁风暴复盘：号源表大范围 DELETE 的隐患与分批删除改造
本文复盘医院号源刷新中因大DELETE导致系统雪崩的故障：原代码使用this.调用致@Transactional失效，单条无LIMIT删除锁住数千行，引发大量LockWaitTimeout。深层问题在于“细粒度行锁”仍可死锁，且长事务阻塞写入。改造方案为：通过代理调用启用事务、分批（每批500行）删除并独立提交，配合幂等兜底，将长锁拆成短锁，显著降低锁竞争与死锁风险，最终实现高可用。核心经验：避免this.调用、分批处理、幂等兜底，是处理历史数据清理的通用解法。
2026-10-24 16:43:11
270
原创 记一次线上事故：一个“不起眼“的线程池配置-无界队列，如何拖垮整个微服务系统
自建HIS接口故障引发系统瘫痪，根源在于ThreadUtil.newExecutor(3)实为无界线程池：仅设核心线程3个，最大线程数达21亿，队列满后无限创建线程。故障期间，60秒超时任务堆积，17+线程并发刷新号源，导致数据库行锁竞争激烈，锁等待超时50秒，触发Lock wait timeout exceeded。多个服务因数据库阻塞而线程耗尽，最终网关502/504刷屏，系统全面崩溃。本质是线程池配置误用与数据库未隔离的连锁反应。
2026-10-20 23:53:51
348
原创 Java 线程池核心参数，以及无界队列如何把服务拖垮：从 OOM 到 Tomcat 线程耗尽
线程池在压测环境下易暴露问题：流量突增或下游变慢时，任务堆积导致内存飙升，服务“假死”。根源常在参数配置，尤其无界队列（如默认LinkedBlockingQueue）会无限积压任务，使线程数无法扩容，最终引发OOM。核心误区是误以为任务多就扩线程，实则先排队、队满才扩。生产环境应使用有界队列、合理设置线程数与拒绝策略，避免Executors.newFixedThreadPool等默认创建方式。自定义线程名便于排查，CallerRunsPolicy可实现回压削峰。
2026-10-20 23:35:57
302
原创 《通过SeaTunnel 把 MySQL 的数据搬进 Doris》番外篇：容量、切分与速度——Doris 能扛多少，比 MySQL 快多少
本文为SeaTunnel+Doris+MySQL-CDC数据同步的实战笔记，核心结论：MySQL瓶颈在数据量（单表超2000万行性能骤降），Doris瓶颈在元数据规模（tablet数超100万致FE内存溢出）。Doris优势显著：分析查询快5-10倍，复杂JOIN快8倍以上，源于列存、分区裁剪与分桶并行。建表关键：分区按时间（如create_time）+动态管理，分区列必须入主键；分桶数按“单桶1~10GB”计算，避免过度切分。建议：表量超5000万行必分区，日志类表按天动态分区，小表不分区。一句话总结：分
2026-10-17 18:05:31
516
原创 SeaTunnel + Doris + MySQL-CDC 数据同步故障排查个人笔记
SeaTunnel 2.3.7 单机集群同步 MySQL CDC 至 Doris 时，因 VARCHAR(2048) 字段单位混淆（字符数 vs 字节数）导致病历文本超限，引发 too many filtered rows 错误。修复方案为将长文本字段改为 STRING 并确认 schema change 完成。同时因重复提交作业导致并发冲突与 checkpoint 超时（180秒过短），经多次重试后通过统一配置 checkpoint.timeout=3600000 并清理旧任务，最终成功闭环。
2026-10-17 17:46:03
343
原创 《通过SeaTunnel 把 MySQL 的数据搬进 Doris》小白学习系列
本文系统阐述了将医疗业务库MySQL数据同步至Doris分析库的全流程。针对MySQL不适宜处理大规模报表查询的问题，提出通过CDC+SeaTunnel实现全量+增量实时同步，利用Doris列存与MPP架构优势实现秒级聚合分析。全文以28张表为例，详解动机、技术选型（Doris、SeaTunnel Zeta引擎）、环境准备、配置实战与运维验证，最终构建一条低延迟、高可靠的数据管道，实现业务与分析解耦，保障线上稳定的同时提升数据分析效率。
2026-10-17 17:31:12
574
原创 定时任务从外部调度搬回本地 @Scheduled：一次连接池被打满的复盘与选型思考
打个比方：你雇了个闹钟助理，他不住你家，在隔壁楼办公室。到点了给你打个电话喊你干活。放到代码里：有一个独立部署的分布式调度中心（XXL-JOB、SchedulerX、Elastic-Job 这类），到了预设时间，它通过 HTTP 或 RPC 远程调用你业务服务暴露的接口，触发任务执行。任务的配置、启停、日志查看都在调度中心后台操作，业务代码本身不关心"什么时候跑"。公司有 5 个微服务，每个服务里 10 个定时任务。
2026-10-14 23:46:00
333
原创 定时任务是用外部调度（xxl-job）还是本地化（ @Scheduled）更香？以号源刷新任务为例？
调度方式没有高低之分，只有合不合适。任务少、频率可控、怕外部依赖的，本地化更稳；任务多、要管控、要分片重试告警的，外部调度更香。而"本地化"本身也有多种实现路径——`@Scheduled` 只是其中一种，自研线程 + 分布式锁是另一种。
2026-10-14 23:39:27
160
原创 MySQL 的分区和分表到底差在哪？小白入门版
分区与分表均用于解决大表性能问题，核心区别在于透明性与扩展性：分区是MySQL在单机内将一张表逻辑切块，SQL无需修改，适合按时间查询与清理；分表则需应用层动态路由，虽增加代码复杂度，但支持跨机器扩容、全局唯一约束，适用于需横向扩展或整表归档的场景。前者“零侵入”，后者“强控制”。选择应基于是否需跨机扩容及能否接受代码改动——单机瓶颈选分区，真到极限再分表。
2026-10-11 20:26:07
197
原创 MySQL 慢 SQL 排查操作手册-个人笔记版
本文通过一次线上HikariCP连接池耗尽引发的雪崩事故，系统梳理了从慢SQL排查到根本原因定位的全流程。重点介绍如何开启并验证MySQL慢查询日志（slow_query_log），利用mysql.slow_log表分析执行耗时、锁等待、扫描行数等关键指标，结合时间窗口筛选、SQL指纹聚合与索引缺失识别，精准定位拖垮服务的慢SQL。强调配置持久化、定期归档及权限管理等实战要点，为应对类似性能问题提供可复用的排查方法论。
2026-10-08 16:31:44
557
原创 系统并发与 QPS 上限：从 200 个线程到每秒几万请求
本文详解图形验证码限流优化中的核心瓶颈：Tomcat默认200工作线程为单实例并发上限，6服务×4实例共4800并发。理论QPS取决于响应时间（如100ms时约2000/QPS/实例），但实际受限于数据库连接（HikariCP 1200）或Redis单点性能。缓存可将瓶颈从数据库抬升至线程池与Redis，QPS可达数万，但需警惕缓存穿透与压测实测值。关键结论：并发看线程数，QPS靠响应时间杠杆，真实容量以压测为准，避免盲目调大线程或连接池。
2026-10-06 23:22:41
301
原创 图形验证码限流优化：从 3 秒阻塞到毫秒级拒绝的踩坑记录
一次40秒的Redis抖动因验证码接口限流设计缺陷被放大为数十分钟服务瘫痪。问题根源在于：阻塞式限流（tryAcquire(3, TimeUnit.SECONDS)）导致线程池被占满，故障恢复时积压请求引发二次雪崩；QPS设为2过低，远低于业务峰值；限流失败返回200空响应，造成前端裂图且监控盲区。改造后，改为非阻塞限流、返回429状态码、提升QPS至10并支持配置化，有效遏制故障扩散，将影响从“服务级瘫痪”压缩至“接口短暂抖动”，显著提升系统韧性。
2026-10-06 23:02:14
385
原创 接口性能优化：Redis 缓存序列化踩坑记录：@Cacheable 撞上 Stream.toList()
为性能优化添加@Cacheable后，返回值使用Stream.toList()（JDK不可变集合，final类），而Redis序列化配置NON_FINAL规则不为final类写入类型信息，导致缓存读取时反序列化失败。故障表现为每600秒周期性出现“读缓存失败”，实际是缓存写入无壳、读取需壳的不对称问题。修复方案为将返回值改为Collectors.toList()，并清除旧缓存或等待过期。建议：缓存方法禁止返回List.of()、Stream.toList()等不可变集合，避免类似陷阱。
2026-10-06 18:20:05
440
原创 JDK 动态代理 vs CGLIB 代理，一篇讲透两者的区别
JDK动态代理基于接口，生成与目标同实现接口的代理类；CGLIB基于继承，生成目标类的子类。前者需有接口且不能代理非接口方法，后者无需接口但类和方法不能为final。Spring默认使用CGLIB（SpringBoot 2.x起），因覆盖更广；两者均在自调用时失效，核心区别在于“接口”与“继承”的本质分野。
2026-09-14 23:47:09
132
原创 Spring AOP 入门：一篇小白也能看懂的切面编程文档
AOP通过代理对象将日志、事务等横切关注点统一抽取并“外挂”到方法上，解决重复代码问题。核心是切入点匹配目标方法，通知定义处理逻辑，@Around最强大，靠proceed()控制方法执行。关键在于调用必须经过代理，自调用（this.）会绕过代理导致失效，需用代理获取或拆分方法解决。
2026-09-14 23:30:45
292
原创 ThreadLocal 三兄弟的区别，小白也能看懂的版本
普通ThreadLocal与InheritableThreadLocal在线程池中均会“丢值”，因线程复用导致上下文无法传递。唯有TransmittableThreadLocal（TTL）通过“抓快照—回放—还原”三步机制，将ThreadLocal值随任务携带，实现跨线程传递。其核心在于任务包装时捕获快照，执行前临时注入，结束后自动还原，彻底解决异步场景下链路追踪断链问题。
2026-09-14 23:01:51
366
原创 最好的分布式事务，是没有分布式事务——聊聊“绕开它“的六种设计
分布式事务代价高，最佳策略是“绕开”。文章提出六种设计手法：合并事务边界、冗余快照字段、状态机+超时任务、接受最终一致、对账兜底、利用同库简化。核心思想：通过边界划分与数据建模，将一致性难度降级为本地事务+补偿，仅在资金强一致等少数场景才需TCC/Seata/XA。
2026-09-02 09:03:55
330
原创 同一个库、不同服务，还会有分布式事务问题吗？
分布式事务的判断标准不是“同库或异库”，而是“一个事务还是多个事务”。同库不同服务经Feign调用会切换线程与连接，导致本地事务断裂，产生不一致。解决方案：合并服务收回事务边界；或本地消息表+幂等消费；直改对方表是饮鸩止渴。核心：事务随连接，连接随线程，Feign断线程。
2026-09-01 23:21:02
367
原创 分布式事务到底是什么？本地事务、TCC、Seata、XA 一次讲明白（小白友好版）
先厘清本地事务与CAP/BASE理论，再对比2PC/XA、TCC、Saga、消息表和最大努力通知等方案的优劣，并介绍Seata框架与AT模式。强调多数场景可通过设计规避分布式事务，选型应权衡一致性与成本。1. 能不用就不用——最好的分布式事务是没有分布式事务；2. 必须强一致 + 并发低 → XA；3. 必须强一致 + 并发高 + 值得花成本 → TCC；4. 流程长、有第三方参与 → Saga；5. 能异步、允许秒级延迟 → 本地消息表/事务消息6、不想改代码想快速接入:Seata AT但要接受最终一致性
2026-09-01 22:57:33
459
原创 Redis 延时队列是怎么工作的？从小白疑问开始，扒开 Redisson 的内部实现
offer 之后，消息躺在哪两个结构里（Hash 存体，ZSet 存到期时间）谁把到期消息搬进 List（应用 JVM 里的 Redisson 搬运任务，集群选主单实例跑）pub/sub 在链路里传什么（只有一个时间戳，消息本体从不上频道）搬运为什么不会搬重/搬漏（两段 Lua 都是原子脚本；按 score ≤ now 全量捞）消费线程为什么不是轮询（BLPOP 阻塞挂起，数据到达被 Redis 服务端推醒）这套机制哪个环节会丢消息（存储层故障 + BLPOP 无 ACK——所以必须扫表兜底）
2026-08-30 23:06:38
624
原创 生产者确认机制，一定能防止消息丢失吗？别再被 publisher confirm 骗了！它真的防不住业务丢消息
1、publisher confirm 的能力边界很窄——它只保证消息安全到达 Broker，不保证你的业务事务有没有成功。2、数据库事务提交和发 MQ 消息是两个独立操作，天生没有原子性，不管怎么调顺序都有漏洞。3、正确的做法是本地消息表（Outbox 模式）：同一事务写入业务数据 + 消息记录，再用后台定时任务异步投递，彻底堵死时序漏洞。
2026-08-30 22:18:54
294
原创 订单超时场景，用 Redis 延时队列还是 MQ？选型、持久化、防丢消息一次讲透
1、选型看基建：超时场景的事实源在数据库，Redis 和 MQ 只是闹钟质量之分——有 RocketMQ 用它，有 RabbitMQ 用插件，都没有用 Redisson，谁都别忘了配扫表兜底。2、持久化看定位：MQ 落盘是立身之本，Redis 持久化是附属功能；Redis 主从异步复制意味着 failover 必丢窗口，资金场景别赌。3、不丢消息从来不是"开了持久化"，而是"本地消息表保生产 + 持久化副本保存储 + 手动 ACK 保消费 + 扫表对账保兜底"四层各守一关——少一层，事故报告里就会少一句辩解
2026-08-30 18:28:51
597
原创 腾讯 IM 后端重构小白教程:一次真实的架构演进复盘
之前重构过一次im，想要使用新系统，慢慢替代旧系统，那到底重构了什么?把 IM 的代码从老系统搬到新系统,这算哪门子重构?"但是刚开始我感觉重构就是把之前的im搬到了新系统中，如果只看功能清单：新系统干的还是那五件事——签发凭证、导入账号、建群、代发消息、落库归档,一件没多,一件没少。想了很久,才把答案想清楚:这次重构,改变的不是"做什么",而是"谁负责做、按什么规则做、业务怎么参与"。功能是家具,这些是户型——搬家换的是户型,不是家具。这篇教程就讲"换户型"这件事
2026-08-30 13:43:42
302
原创 腾讯 IM × TRTC 联动实战：后端如何撑起一次视频问诊（混流录制篇）
信令走 IM，媒体走 TRTC，后端只出现在通话的头和尾。混流的本质是"让云端替你把多人画面合成一屏"，录出来的是一个能直接播放的文件。录制的产物在 VOD 不在 TRTC，取文件要接受"异步"，要么轮询要么事件通知。
2026-08-30 13:03:21
485
原创 腾讯 IM 后端对接小白教程：Java 服务端如何撑起一个医患聊天系统
1. 签发凭证：`UserSigUtil` 四步流水线（JSON → HMAC → 压缩 → URL 安全 Base64），用户签名 180 天、admin 签名 720 秒；2. 管理用户：`registryUser` 把业务用户导入腾讯体系，本地表做镜像；3. 管理群：`createGroup` 建聊天室群（群号 = 订单号），10025 幂等放行，建群前自动补注册；4. 代发消息； 5. 数据留存
2026-08-29 23:49:23
472
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人