- 博客(151)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 大模型基本概念和原理
大语言模型（Large Language Model，LLM）是一种基于深度学习技术构建的人工智能模型，主要用于处理自然语言相关的任务。LLM利用了大量的数据进行训练的模型，可以生成连贯的文本，理解语言并回答问题。LLM作为基础技术，提供强大的语言理解和生成能力。是构建人工智能系统的基石。：是一种基于Transformer架构的大型语言模型，它通过无监督的学习方式，对大量文本数据进行预训练，它是一个通用的语言模型，可以用于多种自然语言的处理任务，如文本生成，语言翻译，问答系统.......
2026-07-13 09:41:24
144
原创 MySQL 索引底层原理与实战优化全技术文档
1. SQL执行链路的核心瓶颈集中在存储引擎索引检索阶段，索引优化是SQL性能优化的核心；2. 三大基础索引模型各有局限，InnoDB B+树索引完美规避了树高、IO、修改性能问题，是数据库最优索引结构；3. 自增主键可有效减少页分裂，降低索引维护成本，是业务首选主键方案；4. 联合索引遵循最左前缀原则，字段顺序优先复用、次优空间，配合索引下推、覆盖索引实现极致查询性能；5. 普通索引适配写多读少，唯一索引适配读多写少、唯一性约束场景，核心差异在Change Buffer；
2026-07-12 22:18:39
459
原创 吃透Java集合核心：ArrayList、LinkedList、HashMap底层原理全解析
无扩容机制，天然支持动态长度；增删效率高（首尾O(1)、中间O(n)），查询效率低（只能遍历查找O(n)）；同样是非线程安全集合，多线程并发操作需手动加锁；内存占用更高，每个节点需额外存储两个引用地址。查询多、增删少：优先使用ArrayList，随机访问效率远超LinkedList；增删多、查询少：优先使用LinkedList，避免ArrayList大量元素迁移的性能损耗；键值对存储、快速查找：使用HashMap，JDK1.8版本性能最优，日常开发推荐指定初始容量、合理规避哈希冲突；并发场景。
2026-07-12 17:53:27
282
原创 Java核心基础：反射与泛型底层原理及实战用法详解
1.反射核心：基于类加载机制，实现运行时动态操控类结构，支持分段加载初始化，是框架动态编程的底层核心，核心能力为动态创建对象、调用方法、操作属性。2.泛型核心：通过类型参数化实现编译期类型校验，解决类型转换异常和代码冗余问题，通配符可灵活约束泛型类型范围。3.泛型擦除：为兼容旧版本、简化JVM设计、避免代码膨胀而生，是泛型语法糖的底层实现，同时带来了运行时无泛型信息等限制，桥接方法则弥补了擦除带来的多态问题。
2026-07-11 22:36:42
300
原创 一文吃透11种行为型设计模式：核心原理与实战场景全覆盖
11种行为型模式各司其职、分工明确，开发中可根据业务痛点精准选型解耦交互：中介者模式、观察者模式、责任链模式算法与流程封装：策略模式、模板方法模式请求调度管控：命令模式集合遍历封装：迭代器模式状态管控流转：状态模式、备忘录模式复杂数据操作：访问者模式自定义语法解析：解释器模式行为型模式的核心本质都是解耦、复用、提扩展性，熟练掌握每种模式的适用场景，能极大优化代码结构，减少冗余代码，让复杂业务逻辑更清晰、更易维护。
2026-07-09 22:26:56
343
原创 Java设计模式精讲：创建型+结构型模式（含生产级案例+相似模式对比）
设计模式是软件开发中沉淀的通用、可复用的最佳解决方案，专门解决项目中等核心问题。本文将系统讲解，严格贴合核心设计思想，拆解每种模式的原理、适用场景、核心特点，提供可直接上线的生产级代码案例，同时重点辨析高频相似设计模式的核心区别，完全适配业务开发、源码研读、面试刷题三大场景。
2026-07-08 23:32:11
398
原创 全方位吃透面向对象设计原则：从SOLID到通用设计思想
a.单一职责原则问题：1.为了只用很少的代码实现复杂的设计，需要耗费心机2.当程序规模不断扩大，变更不端增加后，类会变得很复杂，很难记住里面的细节3. 当类负责的东西越多的时候，可能会对类有修改b.开闭原则对扩展是开放的，对于一个类的修改，可以通过类的继承，来进行实现扩展。对修改是关闭的，类已做好了充分的准备，并可供其他类使用。c.里氏替换原则1.子类的参数类型 必须要跟超类的参数类型相匹配或者更加抽象2.子类方法返回值类型，必须跟超类方法的返回值类型或者其子类型相匹配。
2026-07-06 23:15:48
430
原创 吴恩达Agent智能体学习笔记（一）
这里所说的定制化是将你额外的知识进行整合到一个大语言模型中，想象一下，您的公司有数据库，数据湖或者像PDF等一些文档信息，如何结合这些知识来进行增强大预言模型。这种方法利用协调工具将模型与您的数据源连接起来，例如数据库，无需重新训练。例如Azure OpenAI GPT-4 可以直接用于查询数据库，而无需更改模型本身。这种方法高效且实用，避免了模型训练相关的开销。这个方法涉及在特定数据集上重新训练模型，然后重新部署更新后的模型。虽然这种方式允许定制，它是资源密集型的，并且不太常适应复杂性和运营成本。
2026-06-12 13:09:21
237
原创 面试问题总结 参考抖音大神（牛马宗宗主）
1.一个核心查询接口 业务要求P99<100ms,但是依赖的下游接口的P99为80ms，在加上自己的业务计算，P99为150ms 如何优化到100ms，如果对接口的实时要求比较高，不建议用缓存，有什么解决办法呢？解决思路：1. 量化耗时，进行链路打点，针对io调用（下游Rpc，mysql，redis，mq）；cpu（循环调用，正则匹配，对象转换）2.选择对应方案进行逐步优化，以并行调用+本地缓存预热+代码级优化下游之间无依赖关系的话，串行调用改为并行调用。
2026-05-21 23:27:41
31
原创 生产实战｜冷热数据转换：从识别、触发到落地全流程解析
冷热数据转换是“冷热分离缓存架构”的核心环节，其核心目标是“动态匹配业务需求，最大化利用内存资源，保障系统高性能、高可用”——冷数据转热时，快速迁移至热集群，享受高性能保障；热数据转冷时，及时释放热集群内存，避免资源浪费。生产落地时，只需把握三个核心：一是“精准识别”，通过量化指标+三维监控，明确冷热边界，避免误判；二是“安全转换”，遵循“先写入、再路由、后删除”的原则，保障数据一致性和业务无感知；三是“兜底保障”，通过失败重试、监控告警、限流兜底，避免转换过程中出现故障。
2026-04-26 21:33:06
398
原创 生产实战｜冷热数据混杂+内存紧张，Redis缓存架构如何做到“既省又稳”？
在“热Key集中、冷数据海量、内存紧张”的生产场景中，缓存架构的核心不是“全量缓存”，而是“精准分层、差异化管控”。本文分享的这套架构，通过“三层缓存+冷热物理隔离”，实现了热Key的高性能保障和冷数据的内存优化；通过动态内存治理和全链路兜底防护，确保了系统的稳定性和可用性；同时兼顾了成本控制，可直接落地到电商、金融、物流等各类高并发生产系统。如果你的系统正面临类似的缓存困境，不妨按照本文的方案落地实践，也欢迎在评论区交流你的生产落地经验和优化建议~
2026-04-26 13:49:31
488
原创 深入解析synchronized与Lock的四大核心区别
Java并发编程中，synchronized和Lock是两种核心线程同步机制。synchronized是Java原生关键字，使用简单但功能有限；Lock作为并发工具类，提供更灵活的锁控制。主要区别体现在：1)锁获取方式：Lock支持非阻塞获取和超时控制；2)公平性：Lock可配置公平/非公平锁；3)锁类型：Lock支持读写锁；4)线程调度：Lock通过Condition实现精准唤醒。建议简单场景用synchronized，复杂场景选择Lock以获得更好的性能和灵活性。
2026-02-08 22:25:49
1019
原创 深入剖析HBase HFile原理：文件结构、Block协作与缓存机制
HFile是HBase基于Google BigTable的SSTable（Sorted String Table）优化实现的存储文件，采用二进制格式持久化存储，具有以下核心特性：数据按Key有序排列（RowKey → ColumnFamily → Qualifier → Timestamp），支持高效的顺序扫描与二分查找。采用Block分块存储，将文件划分为多个固定大小（默认64KB，可配置）的Block，便于缓存管理与随机读写。内置索引与布隆过滤器，大幅减少磁盘I/O，提升随机读性能。支持。
2026-02-01 19:45:31
1098
原创 高性能短链系统设计与实现：支撑千万级 QPS 的技术实践
本文深入解析千万级QPS短链系统的技术实现方案。系统核心功能包括长链预处理、短链生成（采用MurmurHash+62进制压缩+布隆过滤器）、302重定向和数据统计。高性能优化通过多级缓存（Caffeine+Redis）、数据分片（基于短链前缀）和异步队列（Kafka）实现。特别针对缓存穿透（布隆过滤器+空值缓存）和缓存热点（本地缓存+数据分散）问题提供解决方案。该方案能有效支撑高并发访问，满足短链系统在互联网时代的核心需求。
2026-02-01 17:46:13
888
原创 SQL优化15种核心策略：原理+实战案例全解析
varchar的长度定义并非越大越好：MySQL中，varchar(n)的n代表字符数，若超过一定长度（如UTF8mb4编码下超过191字符），索引会无法使用前缀索引，且存储时占用更多元数据空间。核心：按业务最大需求定义长度，预留少量冗余（如+1-2字符）即可。案例场景：定义用户表用户名、邮箱字段。**反例（冗余）**：长度定义过大，影响索引效率。username VARCHAR(255), -- 实际业务中用户名最大20位。
2026-01-25 11:04:00
692
原创 接口性能优化实战：5大策略+落地案例
HikariCP是Spring Boot默认连接池，性能优异，通过合理配置核心参数，平衡连接复用与资源占用：1. 核心连接数（minimum-idle）：根据业务并发量设置，避免频繁创建连接；2. 最大连接数（maximum-pool-size）：限制连接池上限，防止数据库过载；3. 连接超时时间、空闲连接回收时间：优化连接生命周期。
2026-01-18 22:10:39
824
原创 Spring事务失效9大场景（Java面试高频）
代理机制无法生效（内部调用、static/final、非public、手动new对象）、异常处理不当（捕获不抛出、异常类型不匹配）、配置/依赖错误（存储引擎不支持、传播机制错误）。
2026-01-18 21:31:38
911
原创 超时未支付订单处理解决方案及组件宕机应对策略
方案优势劣势适用场景RocketMQ延迟消息低耦合、高吞吐、延迟精度高依赖RocketMQ集群，部署维护成本高大型电商、高并发订单场景XXL-Job定时任务实现简单、功能成熟、支持分片周期性查询，实时性略差，数据库压力大中小型系统、订单量中等场景Redis ZSet查询高效、轻量级、组件依赖低需维护定时线程高可用，订单量大时压力大中小型系统、万级以下订单场景Redis过期策略实现极简、无需定时任务可靠性差、不支持高并发，易丢失事件小型系统、千级以下订单场景。
2026-01-11 12:58:50
950
原创 千万级别表字段修改的方案
千万级别表（InnoDB存储引擎）的字段修改，核心痛点为：1.：传统DDL操作会持有表级写锁，期间业务无法插入、更新数据，对于高并发业务（如电商订单表、支付流水表），可能造成数据积压或用户体验崩溃；2.：修改字段需扫描全表数据并重建表结构，千万级数据量会占用大量CPU、内存和磁盘IO，可能导致数据库负载飙升，影响其他业务正常运行；3.：修改过程中若出现异常（如服务器宕机、网络中断），可能导致表结构损坏或数据丢失，恢复成本极高。。
2026-01-06 23:51:39
734
原创 Token自动续期技术方案全解析：原理、优缺点与生产实践
Token自动续期方案的选型需匹配业务场景：中大型分布式应用：优先选择「双Token + Redis」，兼顾安全性、扩展性和用户体验；小型单体/内部系统：选择「滑动窗口续期」，平衡开发效率和基本需求；极简单应用：可临时使用「前端定时刷新」，但需注意风险控制。生产实践中，无论选择哪种方案，都需配套完善的安全机制：Token加密传输（HTTPS）、密钥安全管理（配置中心加密存储）、异常监控（Token失效频率、续期失败告警）、主动失效机制（注销、密码修改、踢人下线），确保认证链路的安全性和稳定性。
2026-01-03 01:24:00
1347
原创 一文读懂HBase核心架构：从组件协同到HLog深度解析
HBase的核心架构围绕“高可用、高并发、可扩展”三大目标构建：ZooKeeper提供分布式协调与主节点选举，保障集群高可用；HMaster负责集群管理与Region调度，实现负载均衡与扩展；RegionServer通过MStore（内存缓冲）提升读写性能，通过HLog Store（预写日志）保障数据可靠性；HFile作为底层存储格式优化数据读写效率，HDFS提供高容错的持久化存储底座。而HLog作为数据可靠性的核心保障，其有序的结构设计与预写机制，确保了即使节点故障，数据也能通过日志完整恢复。
2026-01-03 00:43:43
843
原创 深度拆解Redis为何这么快：5大核心优化维度全解析
Redis的快，并非某一项技术的单独作用，而是5大核心优化维度的协同结果：空间换时间：SDS的预分配/惰性释放降低内存重分配开销，Zset三结构协同覆盖全场景需求，过期键双重删除平衡内存与性能；单次改批量：客户端主导的Pipeline机制减少网络往返，提升批量操作效率；同步非阻塞：Reactor模型的分而治之+事件驱动，让单线程高效处理海量并发连接；同步转异步：后台线程池处理耗时任务，避免主线程阻塞；结构自适应：Zset根据数据规模自动切换存储结构，各取所长优化性能。
2025-12-28 17:03:20
836
原创 深入分库分表：从拆分方案到平滑迁移的全链路实践
分库分表是解决大数据量、高并发场景的核心方案，主要通过垂直拆分和水平拆分实现。垂直拆分按业务属性分离冷热数据，水平拆分则采用范围切分、哈希切分或混合方式分散数据压力。实施后需解决查询难题，如强制携带分片键、建立索引表或使用基因ID算法。上线迁移需经历准备、双写、灰度切换和收尾四个阶段，确保平滑过渡。核心原则是优先考虑业务适配性，保障查询效率，并通过渐进式迁移降低风险。分库分表需权衡复杂度与性能，非必要不拆分。
2025-12-28 15:59:51
991
原创 亿级流量敏感词过滤系统设计（支持敏感词毫秒级生效）
本文设计的亿级流量敏感词过滤系统，核心是“算法优化+分布式架构+动态更新”的三位一体：通过AC-DAT算法保障匹配效率，通过分布式集群保障高吞吐高可用，通过“配置中心推送+双缓冲加载”实现敏感词毫秒级生效。基于Java生态技术栈，方案具备良好的可落地性和扩展性。AI辅助过滤：结合NLP模型识别变体敏感词（如谐音、形近字、拼音混合，如“色qíng”），弥补传统字符串匹配的不足；边缘计算部署：将过滤服务部署在边缘节点，降低跨地域请求的网络延迟；灰度发布。
2025-12-27 23:59:44
995
原创 深入理解Trie树：敏感词过滤的核心原理与实现思路
Trie树是一种专门为处理字符串集合设计的树形数据结构，其核心思想是利用字符串的公共前缀减少重复存储和匹配开销。不同于二叉树、红黑树等通用树形结构，Trie树的每个节点都对应一个字符（或字符的占位符），从根节点到某一叶子节点的路径，恰好构成一个完整的字符串。子节点指针集合：用于指向当前字符的下一个可能字符（例如用哈希表、数组存储，key为字符，value为子节点）；结束标记（isEnd/endWord）：标记当前节点是否为某一字符串的结尾（即从根到该节点的路径构成一个完整的敏感词）。
2025-12-27 23:36:49
1052
原创 深度解析Elasticsearch网络通信原理：节点协同与链接机制
ES的网络通信原理本质是“分层设计+资源隔离”的体现：通过HTTP与Transport协议的分层，实现外部交互与内部协同的隔离；通过13个链接的功能拆分，实现控制任务与数据任务的隔离，最终达成“高可靠、低延迟、高吞吐量”的通信目标。对运维与开发人员而言，这一设计带来两点核心启示：① 集群部署时，需确保9300端口（Transport协议）的通信畅通，避免防火墙阻断节点间链接，否则会导致集群分裂；② 高并发场景下，可通过调整。
2025-12-14 18:52:33
1182
原创 深入理解Elasticsearch内部线程池：类型与核心作用解析
ES内部线程池是集群并发能力的核心支撑，其通过“基础类型+专用场景”的分层设计，实现了任务的高效调度与资源隔离。从缓存线程池的临时任务处理，到固定线程池的核心业务支撑，再到search、bulk等专用线程池的场景化优化，每种线程池都有其不可替代的作用。对于ES开发者与运维人员而言，理解线程池的类型与作用，不仅能帮助快速定位性能问题（如线程池拒绝导致的请求失败），更能通过合理调优让集群发挥出最佳性能。线程池的优化本质是“资源与业务的匹配”，只有结合实际业务场景与硬件资源，才能让ES的并发能力最大化。
2025-12-14 18:42:11
1005
原创 Redis序列化生产实践：从选型到落地的案例指南
业务类型推荐方案理由通用微服务跨语言兼容、运维友好Java内部系统Kryo极致性能、零依赖高并发核心链路Protobuf字节级优化、强类型校验内存敏感场景压缩比高、轻量级。
2025-12-03 23:34:00
727
原创 深入ES内核：索引分片的源码解析与实践思考
ES索引分片的源码逻辑围绕“创建-分配-路由-迁移”的生命周期展开，核心依赖（创建）、（分配）、（路由）三大服务类，通过集群状态同步实现分布式协调。结合源码解析，给出以下实践建议：分片数规划：主分片数需结合数据量和节点数设计（如3节点集群建议主分片数为3或6），避免分片过多导致资源浪费，或分片过少无法水平扩展；副本配置：副本数建议为1-2个，过多会增加写入压力，过少则降低可用性；路由优化：查询频繁的场景可自定义路由字段（如用户ID），实现数据按业务维度分片，减少跨分片查询开销；迁移控制：通过调整。
2025-11-30 21:33:49
749
原创 深入MySQL JOIN原理：从算法到优化的全解析
MySQL JOIN查询性能优化指南 本文深入剖析了MySQL中JOIN操作的底层原理与优化策略。首先解析了JOIN的核心概念，包括驱动表与被驱动表的区别，以及四种常见JOIN类型的特点。重点讲解了三种JOIN算法：嵌套循环连接（适用于小表关联）、哈希连接（大表关联的解决方案）和合并连接（有序表的高效匹配方式）。文章提供了实用优化建议：确保被驱动表关联字段建立索引、合理选择驱动表、避免低效写法、调整内存参数等。最后通过实际案例展示了从慢查询到优化的完整过程，将执行时间从8秒优化至0.3秒。核心启示在于通过合
2025-11-24 00:40:55
752
原创 Elasticsearch高阶用法实战：从数据建模到集群管控的极致优化
数据建模是根基：好的映射设计能从根源避免性能问题，比后续调优更高效；集群管控是保障：自动化运维（ILM）和资源隔离（分片分配）是大规模集群稳定运行的关键；查询优化是核心：缓存利用和预聚合是突破并发瓶颈的有效手段，让ES从“能查”升级为“快查”。
2025-11-16 12:54:42
1135
原创 深度剖析Elasticsearch数据写入与读取：从分片同步到核心组件协同
本文深入解析Elasticsearch(ES)的数据读写流程核心机制。在写入方面，ES采用"路由→主分片写入→副本同步→持久化"的分步流程，通过translog保障数据可靠性，利用OSCache实现近实时写入。读取过程则遵循"查询→获取"两阶段模式，主副分片协同工作确保高效查询。文章详细剖析了translog的事务日志特性和OSCache的性能加速作用，并给出针对性优化建议：批量写入、调整refresh间隔、增加副本数等。通过对底层流程的拆解，揭示了ES实现高吞吐、近
2025-11-16 12:01:45
732
原创 深入Elasticsearch集群核心：启动、选主、元数据与节点重启全解析
Master是核心枢纽：选主机制的“最小主节点数”配置是避免脑裂的关键，生产环境中候选主节点数建议设为3个（确保高可用）。元数据是同步基准：所有节点的操作都以集群元数据为基准，Master的“原子修改+广播同步”确保全集群状态一致。分片恢复是容错保障：节点重启时的分片状态切换和Index Recovery机制，确保数据不丢失、服务不中断，是ES高可用的核心体现。
2025-11-16 11:53:28
817
原创 MySQL查询一行数据为何变慢？深度排查与优化指南
MySQL查询单行数据变慢的典型问题排查 摘要：本文针对MySQL中"查询一行数据变慢"的常见现象，系统分析了5大潜在原因及解决方案。核心排查路径包括：1)检查执行计划异常(全表扫描/索引失效)；2)评估索引健康度(碎片化/缓冲池命中)；3)排查锁竞争(行锁/MDL锁)；4)优化数据存储(大字段拆分)；5)检查资源配置(CPU/内存/磁盘)。通过案例演示了从普通索引升级为唯一索引的优化过程，将查询耗时从300ms降至5ms。文章强调应遵循"执行计划→索引→锁→存储→资源&quo
2025-11-01 21:36:38
767
原创 MySQL ORDER BY 深度解析：索引排序规则与关键配置参数阈值
MySQL排序性能优化关键点：索引匹配和参数调优是两大核心。索引需满足最左前缀、方向一致等规则才能避免Using filesort；关键参数sort_buffer_size决定内存/临时文件排序边界，需合理设置避免OOM。实战案例显示，通过调整sort_buffer_size并结合覆盖索引，排序耗时可从500ms降至10ms。优化应优先考虑索引设计，参数调整作为补充手段。
2025-10-13 23:40:01
750
原创 AI相关知识扫盲
文章摘要： 本文系统解析了AI系统的四大核心组件——LLM（认知大脑）、Agent（任务管家）、MCP（通信协议）和Workflow（流程中枢），阐明了各自的能力边界与协同机制。Workflow作为新增核心，通过可视化编排多任务流程、条件分支和跨组件调度，实现复杂任务的全局规划。通过企业财报生成等案例，展示了四者如何协同构建端到端智能流程，并澄清了6个常见误区。未来趋势包括AI驱动的低代码Workflow、多级流程嵌套以及组件深度协同，推动企业级自动化场景的高效落地。（149字）
2025-10-10 22:48:50
862
原创 MySQL 锁机制深度解析：原理、场景、排查与优化
本文系统介绍了MySQL中的锁机制，包括全局锁、表级锁和行锁的实现原理与应用场景。全局锁（FTWRL）锁定整个实例实现只读，适用于全量备份；表级锁包含读锁、写锁和MDL锁，适合批量操作和非InnoDB引擎；行锁基于索引实现，支持高并发事务场景。文章还分析了死锁产生原因及排查方法，并提出了统一锁定顺序等解决方案。最后强调锁选择需要在数据一致性和并发性能间取得平衡，建议根据业务特点、存储引擎和版本特性选择合适的锁策略，并通过监控工具优化性能。
2025-10-08 13:17:23
783
原创 MySQL 索引全解析：结构、优化与索引下推实战指南
索引下推是指：MySQL 执行查询时，将原本在 “服务器层” 过滤的条件（如gender='female'），下推到 “存储引擎层”，在遍历索引的同时完成过滤，只将符合条件的记录的主键值返回给服务器层，再进行回表操作。。
2025-10-04 23:04:39
963
原创 深入剖析 MySQL 中 binlog 与 redolog：区别、联系及在数据更新中的作用
在深入对比前，我们首先需要明确两种日志的基础定义和核心特性，这是理解后续内容的前提。。
2025-10-02 23:45:54
431
原创 MySQL 查询与更新语句执行过程深度解析：从原理到实践
在日常开发中，我们每天都在与 MySQL 的SELECT查询和UPDATE更新语句打交道，但你是否真正了解这些语句在数据库内部是如何 “运转” 的？理解 MySQL 的执行流程，不仅能帮助我们写出更高效的 SQL 语句，还能在遇到性能问题时快速定位根源。本文将从 MySQL 的架构设计出发，详细拆解查询语句和更新语句的完整执行过程，带大家看透 SQL 背后的 “黑盒子”
2025-10-02 23:41:01
869
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人