游客fn3lweafizymy_个人页

2025年12月

• 12.29 19:26:54
  发表了文章 2025-12-29 19:26:54

  EFC&CTO：缓存引发数据不一致问题排查与深度解析

  在CTO测试中，通过分析EFC缓存日志发现6条读缓存记录，仅3次命中，错误集中在第3次读操作。结合offset定位及日志分析，发现问题源于缓存版本号回退导致读取旧数据（NULL），在buffer写时污染pagecache，最终刷盘覆盖正常数据。根本原因为网络慢请求致dv回退，修复方案为维护递增缓存版本号，丢弃回退版本。修复后经多轮测试验证问题消除。同时通过模拟实验揭示了pwrite、ftruncate等POSIX接口底层行为差异，加深了对内核缓存机制的理解。
• 12.29 19:25:56
  发表了文章 2025-12-29 19:25:56

  EFC&CTO：缓存引发数据不一致问题排查与深度解析

  EFC客户端更新缓存架构后，首次适配NAS场景CTO测试即出现data mismatch。排查发现并非缓存版本号导致的旧数据读取问题，而是文件系统数据被破坏——正常字符被替换为空字符，且错误集中于同一4K页内。初步判断为缓存引入导致pagecache被异常写坏，脏页回刷污染了远端数据。空字符来源及具体触发操作待进一步分析。
• 12.29 19:24:33
  发表了文章 2025-12-29 19:24:33

  从Google线上故障，谈灰度发布的重要性3

  基于IP和标签的灰度发布可有效降低配置风险。IP灰度适用于小型系统，标签灰度支持自定义键值，实现多环境、多分支精准配置，提升系统稳定性和发布灵活性，助力业务安全迭代。
• 12.29 19:23:04
  发表了文章 2025-12-29 19:23:04

  从Google线上故障，谈灰度发布的重要性2

  业务配置灰度可通过主流配置中心实现，如Nacos支持IP和标签灰度，可扩展SPI定制策略；Apollo仅支持IP灰度，二者均可二次开发。复杂场景可基于Nacos标签扩展或自研方案，多数场景推荐使用Nacos满足需求。
• 12.29 19:21:50
  发表了文章 2025-12-29 19:21:50

  从Google线上故障，谈灰度发布的重要性

  2025年6月12日，Google Cloud因新功能未充分测试且未灰度发布，导致Service Control系统出现空指针异常，引发全球大规模服务中断，持续超7小时。故障暴露了配置管理与错误处理的严重缺陷，凸显配置灰度发布在核心系统中的关键作用。
• 12.29 19:20:25
  发表了文章 2025-12-29 19:20:25

  RocketMQ：底层Netty频繁OS OOM

  JVM使用jemalloc分配native内存，排查发现无明显泄漏。通过pmap、gdb分析及Arthas查看Netty堆外内存占用，定位到RocketMQ客户端因Netty直接内存分配导致内存超1G。调整MaxDirectMemorySize引发消息积压，最终确认问题源于Netty内存管理机制。短期方案为压缩Java堆，腾出堆外空间保障MQ可用性。
• 12.29 19:19:34
  发表了文章 2025-12-29 19:19:34

  RocketMQ：底层Netty频繁OS OOM

  某核心应用出现少量机器OOM被杀，排查发现容器内存8G，JVM堆4G、MaxDirectMemorySize设为1G，但实际RSS远超预期。通过NMT定位到“Other”内存持续增长，结合Arthas发现7个不同ClassLoader加载了Netty的PooledByteBufAllocator，每个独立占用堆外内存，导致总使用量突破1G限制。其中rocketmq-client实例几乎占满1G，最终确认为多ClassLoader引发的堆外内存超额使用问题。
• 12.29 19:16:39
  发表了文章 2025-12-29 19:16:39

  Redis：内存陡增100%深度复盘

  遵循Redis命令与运维规范，避免使用KEYS、Lua脚本等高风险操作，推荐SCAN、管道、扩展数据结构提升性能。合理配置监控、慢日志、Top Key分析，及时处理大Key、热Key及计划运维事件，保障实例稳定高效运行。
• 12.29 19:15:35
  发表了文章 2025-12-29 19:15:35

  Redis：内存陡增100%深度复盘

  本文分析了Redis在11:22:02因缓冲区激增导致不可用的事故。根源在于流出带宽自然增长至96MB/s，触发输出缓冲区暴涨，连接断开后请求涌向DB，大量大KEY写入又引发输入缓冲区激增，最终占用全部内存，阻塞主线程。事故暴露了网络与存储资源双重瓶颈，凸显遵循开发运维规范的重要性，如合理设计Key、控制命令使用、优化SDK配置等，以避免性能边界被突破。
• 12.29 19:13:43
  发表了文章 2025-12-29 19:13:43

  Redis：内存陡增100%深度复盘

  缓冲区用于暂存数据，防止处理速度跟不上发送速度导致丢数据。Redis通过输入/输出缓冲区管理命令与响应，但输出缓冲区在Pub/Sub模式下可能剧增，理论最大占用达9.375GB，远超实例内存（如2GB），导致SET/GET失败，系统无法正常工作。
• 12.29 19:12:28
  发表了文章 2025-12-29 19:12:28

  Redis：内存陡增100%深度复盘

  Redis内存耗尽真相：缓冲区成“罪魁祸首”！`used_memory`接近`maxmemory`上限，`used_memory_overhead`高达1GB，其中`mem_clients_normal`占1GB，而实际数据仅23.93MB。客户端输出缓冲区过度占用导致内存濒临崩溃，非碎片问题。优化缓冲区配置刻不容缓。#Memory #Redis
• 12.29 19:10:52
  发表了文章 2025-12-29 19:10:52

  Redis：内存陡增100%深度复盘 简单回顾

  大KEY随流量激增占满带宽，5分钟内致Redis内存100%，触发全面超时。内存满并非直接致崩，主因或是过期Key集中删除阻塞，或非正常写入导致淘汰机制失灵，引发性能雪崩。
• 12.29 19:08:50
  发表了文章 2025-12-29 19:08:50

  XXLJOB：超长定时任务慢节点优化实践

  通过视图落表、节点拆分缓解计算堆积，结合前置裁剪与mapjoin优化数据倾斜，利用distmapjoin提升大表关联效率，并拆分节点降低回刷成本，全面提升宽表产出时效与稳定性。
• 12.29 19:08:07
  发表了文章 2025-12-29 19:08:07

  XXLJOB：超长定时任务慢节点优化实践

  本文分析了大数据任务中慢节点的成因，定位出数据倾斜与join资源不足两大主因，并提出加盐打散、提升实例数等快速优化方案。通过梳理代码主干链路，发现存在计算堆积、热点倾斜及回刷成本高等问题，最终明确提早产出、降低回刷耗时、节省资源三大优化目标，为后续深度优化奠定基础。
• 12.29 19:05:53
  发表了文章 2025-12-29 19:05:53

  FastJson：大面积故障规避案例

  翻阅掘金文章定位诡异NPE问题，发现FastJson解析Lambda表达式{}触发kotlin_error静态标记位，致全局反序列化失败。问题源于Kotlin语法误用，混编场景下需格外谨慎，框架亦不可盲信。
• 12.29 19:03:45
  发表了文章 2025-12-29 19:03:45

  FastJson：大面积故障规避案例

  工程为Kotlin/Java混编，偶用Groovy。预发环境突现大量FastJson反序列化错误，排查发现rass-sdk-core引入低版本FastJson，排除后问题仍存。进一步定位为Kotlin数据类反序列化异常，疑为依赖或环境兼容性问题，耗时逾日，终未根除，凸显混编环境下依赖与兼容性治理之难。
• 12.29 19:02:24
  发表了文章 2025-12-29 19:02:24

  线程池：故障梳理总结

  调用量大易引发线程池满、连接池阻塞等问题，导致服务雪崩。常见原因包括远程调用超时、未合理设置限流与超时参数、压测未预热、SQL未加Limit等。需践行fast-fail理念，合理配置Dubbo、HTTP、Druid、Redis等连接池的超时与队列参数，实施多维流控与背压机制，保障系统稳定。
• 12.29 19:01:03
  发表了文章 2025-12-29 19:01:03

  线程池：故障梳理总结

  数据库常见慢SQL问题包括：热更新导致行锁争抢、大表加字段未走Online DDL引发元数据锁、索引选择错误导致全表扫描、深分页查询性能差。典型案例有高并发更新count字段致线程池满、DDL锁表致服务不可用、order by id误走主键扫描致CPU 100%、深分页拖垮数据库连接池。建议采用无事务更新、Online DDL、强制指定索引、NextToken替代深分页等优化方案。
• 12.29 18:59:45
  发表了文章 2025-12-29 18:59:45

  一场FullGC故障排查

  针对JVM中大对象引发频繁Full GC的问题，可采取“治本”或“治标”两类方案：一是将数据移出内存，存入Redis等缓存系统，从根本上避免内存压力；二是优化对象结构，删除无用字段，减少内存占用。前者效果彻底但改造成本高，后者改动小但极端场景下仍存风险。排查时应结合GC日志、堆快照与监控工具定位根源，通过代码分析与现象验证解决问题，并根据实际场景选择合适策略。
• 12.29 18:58:58
  发表了文章 2025-12-29 18:58:58

  一场FullGC故障排查

  项目中解析用户上传的Excel样本时，将数据存为List<Map<String, String>>导致内存膨胀。一个17MB的文件占用堆内存达128MB，空间效率仅约13.4%。主因是HashMap对象头、包装类等额外开销大，且数据在JVM中驻留4-12小时，易引发OOM。需优化存储结构以降低内存占用。
• 12.29 18:57:01
  发表了文章 2025-12-29 18:57:01

  一场FullGC故障排查

  收到JDOS容器CPU告警（达104%），排查发现线程执行跑批任务导致高CPU。初期怀疑Full GC，但机器内存仅62%，与预期不符。排除流量突增等因素后，转向JVM监控，通过SGM发现老年代内存被打满后清理，确认为Full GC引发。dump堆内存并用JProfiler分析，定位到多个大List对象占用近900MB，内含大量Map键值对，最终锁定代码中大对象创建问题。
• 12.29 18:53:20
  发表了文章 2025-12-29 18:53:20

  大模型应用开发中MCP与Function Call的关系与区别

  Function Call依赖模型直接调用工具，适用于单一场景；MCP通过标准化协议实现模型与工具解耦，支持跨模型、跨设备的动态集成。二者可协同工作，形成“意图解析-协议传输-工具执行”分层架构，未来将趋向融合，推动AI应用生态标准化发展。
• 12.29 18:51:39
  发表了文章 2025-12-29 18:51:39

  大模型应用开发中MCP与Function Call的关系与区别

  MCP是模型与外部系统交互的通用协议，实现多模型兼容的标准化通信；Function Call则是模型调用外部工具的具体机制。前者为“桥梁”，后者为“工具”，二者协同拓展大模型能力边界，提升应用灵活性与智能化水平。
• 12.29 18:49:47
  发表了文章 2025-12-29 18:49:47

  全面认识MCP：大模型连接真实世界的“USB-C接口”

  MCP通过动态上下文窗口、多步骤流程支持与标准化通信协议，实现AI智能体对用户偏好、会话历史与环境数据的持续记忆与灵活响应。其基于JSON-RPC 2.0的统一接口，支持Stdio、HTTP/SSE等传输方式，简化了大模型与工具系统的集成。借助MCP，AI应用可高效完成数据分析、办公自动化等复杂任务，提升处理能力的同时保障安全合规，推动大模型在真实场景中的落地应用。
• 12.29 18:47:18
  发表了文章 2025-12-29 18:47:18

  全面认识MCP：大模型连接真实世界的“USB-C接口”

  MCP解决AI工具集成难题，打破“工具孤岛”。通过标准化协议，实现模型与工具的即插即用，降低开发成本，提升AI连接现实世界的能力。
• 12.29 18:43:27
  发表了文章 2025-12-29 18:43:27

  全面认识MCP：大模型连接真实世界的“USB-C接口”

  大模型正从对话引擎进化为能执行任务的智能体，MCP（模型上下文协议）成为关键推手。由Anthropic提出的MCP，作为AI时代的“万能接口”，正统一大模型与工具、数据的连接标准，实现安全、高效集成，被全球众多AI应用广泛采纳，推动智能体快速发展。
• 12.29 18:38:48
  发表了文章 2025-12-29 18:38:48

  详解RAG五种分块策略，技术原理、优劣对比与场景选型之道

  RAG通过检索与生成结合，突破大模型在企业应用中的局限，支持知识动态更新、降低幻觉风险。分块策略是其核心，直接影响检索效率与答案准确性。本文系统解析固定大小、语义、递归、结构化及LLM-based五种分块方法，对比优劣，提出选择建议，并探讨RAG在高风险领域的可验证性挑战与前沿优化方向。
• 12.29 17:28:58
  发表了文章 2025-12-29 17:28:58

  向量数据库的工作原理

  向量数据库通过将非结构化数据转化为高维向量嵌入，利用HNSW、IVF-PQ等索引技术实现高效相似性搜索。其采用列式存储、量化压缩与分布式架构，优化高维向量的存储与检索，支持AI场景下的大规模近似最近邻查询，显著提升搜索效率与可扩展性。
• 12.29 17:27:00
  发表了文章 2025-12-29 17:27:00

  向量数据库的相关概念

  向量数据库将文本、图像等非结构化数据通过嵌入模型转化为高维向量，支持高效存储与近似最近邻检索。具备多模态处理、混合查询、分布式扩展、实时更新等特性，广泛应用于推荐系统、语义搜索等场景，助力AI应用实现快速精准的相似性匹配。
• 12.29 17:25:40
  发表了文章 2025-12-29 17:25:40

  向量数据库的基本概念

  向量数据库是专为存储和检索高维向量设计的系统，能将图片、文本等非结构化数据转化为“数字指纹”（向量），通过相似性搜索快速找到相近内容，广泛应用于推荐系统、图像识别和AI搜索等领域。
• 12.29 17:24:39
  发表了文章 2025-12-29 17:24:39

  大模型专业名词解释手册

  本手册由油炸小波设计提示词，Manus创作，系统梳理大语言模型核心概念，涵盖基础架构、训练方法、优化技术、应用推理及伦理评估。内容详实，术语权威，助力深入理解AI大模型世界。
• 12.29 17:23:48
  发表了文章 2025-12-29 17:23:48

  RocketMQ：A2A协议实现多智能体优化

  Apache RocketMQ 推出轻量级通信模型 LiteTopic，专为 AI 多智能体协作设计，支持海量会话、上下文持久化与断点续传。结合 A2A 协议与阿里 AgentScope 框架，实现高可靠、低延迟的智能体通信，助力企业构建稳定高效的多智能体应用。
• 12.29 17:22:13
  发表了文章 2025-12-29 17:22:13

  整合切面，参数拦截+过滤

  该类基于Spring AOP实现请求参数日志记录，通过@Aspect切面拦截Controller层方法，记录请求来源、URL、方式、参数及执行耗时，便于调试与监控，支持后续扩展如数据存储或脱敏处理。
• 12.29 17:21:05
  发表了文章 2025-12-29 17:21:05

  整合Logback，滚动记录+多文件

  本配置为logback日志系统设置，支持控制台与文件双输出，按级别分离日志，包含INFO、ERROR、SQL、请求参数、支付、定时任务等模块，支持每日滚动归档，保留15天历史记录，路径可配置，适用于SpringBoot项目。
• 12.29 17:20:18
  发表了文章 2025-12-29 17:20:18

  @Inherited

  @Inherited用于注解，使子类继承父类中标记该注解的元数据，仅适用于类继承，接口继承和实现均不生效。
• 12.29 17:19:36
  发表了文章 2025-12-29 17:19:36

  SpringBoot使用汇总

  Spring Boot是Spring生态的现代化开发框架，简化配置、编码与部署，内嵌服务器，开箱即用，助力微服务发展。
• 12.29 17:16:37
  发表了文章 2025-12-29 17:16:37

  3.分页

  本文介绍了五种分页实现方式：MyBatis自带RowBounds内存分页、PageHelper插件分页、SQL原生分页、数组分页及拦截器分页。前两者属逻辑分页，查全量数据后处理，适合小数据；后三者为物理分页，直接控制查询范围，大数据场景更高效。总结指出：物理分页应优先于逻辑分页，避免内存溢出，提升性能。
• 12.29 17:15:34
  发表了文章 2025-12-29 17:15:34

  2.映射关系(1-1 1-n n-n)

  MyBatis中通过resultMap实现一对一、一对多、多对一及多对多映射。一对一用于属性与字段映射；一对多通过`<collection>`关联主表与子表（如用户对应多个角色）；多对一使用`<association>`（如博客关联作者）；多对多借助中间类实现（如用户与部门互相关联），灵活构建复杂数据结构。
• 12.29 17:14:40
  发表了文章 2025-12-29 17:14:40

  Mybatis1.常见配置

  MyBatis配置优先级：方法参数 > resource/url > properties内属性。核心设置包括缓存、延迟加载、主键生成等。支持多环境配置，通过environments指定，默认使用development。事务管理可选JDBC或MANAGED，与Spring集成时由Spring接管。
• 12.29 16:58:06
  发表了文章 2025-12-29 16:58:06

  4-MongoDB索引知识

  MongoDB索引通过B树结构提升查询效率，避免全表扫描。支持单字段、复合、地理空间、文本和哈希索引，优化相等匹配、范围查询、排序及全文搜索，显著提升大数据量下的查询性能。
• 12.29 16:56:30
  发表了文章 2025-12-29 16:56:30

  2-MongoDB常用命令

  MongoDB默认数据库为test，未指定时集合存于此。数据库名需为小写UTF-8字符串，不含空格、.、$等特殊字符，最长64字节。保留数据库：admin（权限管理）、local（本地存储）、config（分片配置）。集合名不可为空或含\0，不以"system."开头，避免使用$。文档键区分大小写，不可重复，键名不可含\0，.和$有特殊用途，建议避免以下划线开头。插入数据可自动生成_id，未指定字段可为null或省略，日期用new Date()，整型需用NumberInt()。
• 12.29 16:54:19
  发表了文章 2025-12-29 16:54:19

  1-MongoDB相关概念

  MongoDB是一款高性能、无模式的文档型数据库，适用于高并发、海量数据、高扩展性场景。广泛应用于社交、游戏、物流、物联网及视频直播等领域，支持灵活的数据模型、丰富的查询及水平扩展，是Web2.0和大数据时代的理想选择。
• 12.29 16:52:25
  发表了文章 2025-12-29 16:52:25

  Thread.sleep(0) 到底有什么用

  Thread.Sleep用于暂停线程执行，Sleep(1000)不保证精确唤醒时间，因CPU调度受优先级和竞争影响；Sleep(0)则触发系统立即重新分配CPU，让其他线程有机会运行，常用于避免界面假死。两者作用不同，不可简单省略。
• 12.29 16:51:04
  发表了文章 2025-12-29 16:51:04

  零拷贝3

  线程是调度的基本单位，进程是资源分配的基本单位。进程为线程提供虚拟内存等资源，线程间共享资源，切换时开销更小。中断会打断进程，引发上下文切换，消耗CPU资源。过多切换和内存拷贝降低性能，零拷贝技术通过减少切换与拷贝提升文件传输效率。
• 12.29 16:49:13
  发表了文章 2025-12-29 16:49:13

  零拷贝2

  进程上下文切换指从一个进程切换到另一个进程运行，需保存和恢复用户态与内核态资源，开销较大；而系统调用不切换进程，仅在内核态执行，开销较小。上下文切换涉及虚拟内存、栈、寄存器等的保存与恢复，频繁切换会消耗大量CPU时间，影响性能。Linux通过TLB加速地址转换，但切换时需刷新TLB，进一步增加成本。切换主要发生在时间片耗尽、资源不足、主动挂起、高优先级进程就绪或硬件中断等场景。
• 12.29 16:47:04
  发表了文章 2025-12-29 16:47:04

  零拷贝

  实现文件传输时，若采用传统read/write方式，每32KB需两次系统调用，引发4次上下文切换，1万次共4万次切换，性能低下。主因是频繁的用户态与内核态切换开销大，且数据需经内存缓冲中转。可优化为使用零拷贝技术（如sendfile），减少数据复制和上下文切换，提升传输效率。
• 12.29 16:43:27
  发表了文章 2025-12-29 16:43:27

  线程池

  线程池通过复用线程提升性能，避免频繁创建与销毁的开销。它统一管理线程，提高资源利用率，防止过度切换。Java中通过Executor框架实现，核心类包括ExecutorService、ThreadPoolExecutor等，Executors为便捷工厂类，ScheduledThreadPoolExecutor支持定时调度，整体基于池化思想优化并发编程。
• 12.29 16:40:41
  发表了文章 2025-12-29 16:40:41

  Java泛型类型擦除以及类型擦除带来的问题

  Java泛型在编译时会进行类型擦除，所有泛型信息被移除，仅保留原始类型。例如`List<String>`和`List<Integer>`在运行时均为`List`，类型参数被擦除，统一替换为`Object`或限定类型。通过反射可绕过泛型限制添加不同类型元素，证明泛型仅在编译期有效。
• 12.29 16:38:25
  发表了文章 2025-12-29 16:38:25

  常见加载顺序

  本示例展示了Java中各类代码块的执行顺序：静态代码块随类加载执行，仅一次；局部代码块在main函数中直接执行；构造代码块每次创建对象前执行；构造器随后执行。输出顺序体现其优先级：静态 > 局部 > 构造。
• 12.29 16:36:44
  发表了文章 2025-12-29 16:36:44

  ArrayList扩容机制

  ArrayList初始化容量为0，添加第一个元素时触发扩容，minCapacity设为10，执行grow()，容量从0扩至10。后续添加元素至第10个时均不扩容。添加第11个时，minCapacity为11，大于当前容量10，再次调用grow()，新容量为15。grow()通过比较minCapacity与旧容量的1.5倍决定新容量，不超过最大值。注意：length用于数组，length()用于字符串，size()用于集合。