自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(77)
  • 资源 (1)
  • 收藏
  • 关注

原创 ✅ DolphinScheduler 单机部署 Checklist(基于 Docker + 本地 MySQL)

本文总结了DolphinScheduler使用MySQL数据库的配置要点:1)确保MySQL 8.0.42及以上版本,配置远程访问权限;2)验证网络连通性;3)关键步骤是为DolphinScheduler注入MySQL驱动,需修改Dockerfile并在各模块复制驱动文件;4)提供docker-compose.yml配置示例,强调使用宿主机真实IP;5)必须初始化数据库,可通过脚本或SQL文件完成;6)最后检查容器状态和日志,访问地址为http://localhost:12345

2025-07-17 19:07:25 205

原创 如何发现并解决 OOM 问题

摘要: 线上系统出现OOM问题时,可按照以下步骤排查:1️⃣ 定位类型(如堆内存、元空间等);2️⃣ 收集信息(jmap/jstack/GC日志);3️⃣ 分析根因(MAT/VisualVM检查内存泄漏或大对象);4️⃣ 优化代码与参数(清理缓存、调整堆大小);5️⃣ 监控告警(Prometheus+Grafana)。常见OOM类型包括堆溢出、元空间耗尽等,排查时需结合日志和工具(如MAT分析堆快照)。解决方案包括代码优化(限制缓存/线程池)和JVM调优(调整堆/GC参数)。案例中缓存泄漏导致OOM,改用C

2025-06-28 21:58:54 522

原创 ✅ 秒杀系统设计方案(实战 + 面试答疑全套)

摘要:本文详细介绍了高并发秒杀系统的设计方案,通过多层级防护机制解决百万QPS下库存准确性和系统稳定性问题。系统采用Redis+Lua原子扣减库存、MQ异步削峰、MySQL乐观锁实现防超卖;通过动态路径、验证码、限流组件(如Sentinel)防止刷单;前端轮询异步结果保障用户体验。关键创新点包括:三层防超卖机制(Redis预扣+MQ异步+DB校验)、四重防重复(Set去重+唯一索引+幂等处理)、动态路径+滑动验证码防机器刷单。系统实现了秒杀场景下的高并发处理、数据最终一致性和安全防护目标。

2025-06-27 18:28:11 511

原创 缓存双写策略

缓存双写策略是解决缓存与数据库一致性的核心方案,主要包括同步双写和异步双写两种方式。同步双写如Write-Through和CacheAside强调强一致性但性能开销大,而异步双写通过消息队列实现最终一致性,性能更好但存在延迟。在秒杀系统中,典型应用是CacheAside组合异步最终一致,先原子性扣减Redis库存,再通过MQ异步更新数据库,兼顾性能与强一致性。策略选择需根据业务场景权衡一致性要求、性能需求和实现复杂度。

2025-06-26 18:26:01 856

原创 动态URL生成或URL动态化

动态地址生成是秒杀系统的核心安全机制,通过时效性URL防止爬虫和脚本攻击。其核心是活动前短时间内为用户生成带有加密Token(含用户ID、商品ID等)的唯一地址。服务端采用JWT或HMAC签名验证请求合法性,配合Redis存储Token实现一次性使用。关键点包括:严格时效控制(5-30秒)、HTTPS传输、密钥安全管理、前端时间同步及降级方案。该技术有效拦截非法请求,减轻后端压力,是秒杀系统防护体系的第一道防线。

2025-06-26 18:17:25 830

原创 MySQL Join:大表关联小表 vs 小表关联大表

MySQL JOIN性能优化要点:SQL JOIN执行原理是嵌套循环(Nested Loop Join),驱动表(左表)每行都要在被驱动表(右表)匹配。优化关键在于:1)尽量用小表作为驱动表,减少循环次数;2)被驱动表的关联字段必须建立索引,避免全表扫描;3)通过EXPLAIN分析执行计划,查看是否命中索引;4)必要时使用STRAIGHT_JOIN强制指定小表为驱动表。在实际项目中,商品表关联类目表、订单表关联用户表等场景都需要遵循这些优化原则。

2025-06-25 18:18:45 937

原创 MySQL InnoDB 锁机制详解(粒度 + SELECT FOR UPDATE + S锁/X锁)

InnoDB存储引擎的锁机制解析:InnoDB支持行锁(RecordLock)、间隙锁(GapLock)、临键锁(Next-KeyLock)等不同粒度的锁。事务级锁分为共享锁(S锁)和排他锁(X锁)。SELECT FOR UPDATE语句的锁行为取决于索引:命中索引时触发行锁,无索引时退化为全表锁,范围查询则加临键锁。合理使用锁机制需要结合事务隔离级别、索引设计和业务场景进行优化。

2025-06-23 18:35:09 1012

原创 ThreadPoolExecutor执行过程详解

ThreadPoolExecutor执行过程详解

2025-06-23 18:21:34 476

原创 实战教学的 Java 死锁案例

《Java死锁问题排查与解决方案》 摘要:本文介绍Java开发中常见的死锁问题,通过经典双锁互持示例展示死锁形成原理。当线程A与线程B分别持有lock1和lock2并互相请求对方锁时,会产生循环等待导致死锁。排查时可通过jps获取进程号,使用jstack分析线程栈,查找"deadlock"关键词定位问题线程。解决方案包括统一加锁顺序、使用ReentrantLock的tryLock机制、减少锁粒度以及建立监控告警系统。

2025-06-23 17:02:06 477

原创 JVM 调优面试+实战汇总

《交易系统JVM调优实战:从指标异常到性能提升》 针对高并发交易系统在2000+QPS下出现的RT抖动和GC问题,团队开展了系统性JVM调优。问题表现为YGC每秒6-10次、FullGC每2分钟1次导致1.5秒卡顿。通过多维度优化:1)调整堆内存至4G并优化新生代比例,YGC降至1-2次/秒;2)改用G1GC并设置200ms最大停顿,FullGC降为2小时0次;3)限制Metaspace并修复Groovy类泄漏。

2025-06-22 10:02:29 865

原创 JVM 性能调优

JVM调优实战指南:关键参数与优化思路 摘要: JVM调优是Java系统性能优化的重要环节。本文梳理了JVM内存模型和核心调优参数,提出"监控→分析→调整→验证"四步调优法。重点关注堆内存配置(-Xms/-Xmx)、GC算法选择(G1、CMS等)、元空间设置等关键参数,并提供典型生产案例:通过切换G1收集器、调整新生代比例,成功降低30%响应时间。调优需结合GC日志分析和压测验证,确保系统在高并发场景下的稳定性。

2025-06-22 09:48:14 381

原创 ES倒排索引的原理

倒排索引:全文搜索的加速器 倒排索引是一种通过“关键词→文档ID列表”映射优化搜索的数据结构,核心思想是将文档内容分词后建立反向关联。与数据库正排索引(逐行扫描)不同,倒排索引直接定位关键词所在文档,无需遍历数据。例如,搜索“喜欢”时,ES通过倒排表快速返回文档[1,3]。 Lucene底层实现中,每个关键词(Term)关联一个倒排链表(PostingsList),记录文档ID、词频、位置等信息,支持短语搜索、高亮等功能。实际应用中,text类型字段默认构建倒排索引,而聚合场景使用doc_values。

2025-06-21 15:45:23 584

原创 Elasticsearch 的原理

Elasticsearch是基于Lucene的分布式搜索引擎,其核心原理是倒排索引机制,通过建立"关键词-文档ID"映射实现高效全文搜索。采用分布式架构,数据分片存储,支持多副本保证高可用。写入时先缓存再持久化,查询时多分片并行处理。其优势在于:倒排索引快速定位、分布式并行查询、分词优化、缓存机制等,使其特别适合处理高并发搜索和日志分析场景。ES还支持结构化搜索、聚合分析等高级功能,通过合理配置可实现读写分离。

2025-06-21 15:07:48 558

原创 Elasticsearch 是什么时候保存数据的?

Elasticsearch写入机制采用WAL(预写日志)模式:数据先写入内存缓冲区和translog(事务日志),默认每秒refresh一次生成可搜索的segment文件,但仅flush操作(手动或自动触发)才会持久化到磁盘。关键参数包括refresh_interval(1秒)和translog.flush_threshold_size(512MB)。为确保数据不丢失,需配置合理的flush策略,重要数据可强制refresh,并设置durability:request保证translog同步写盘。

2025-06-21 14:30:00 363

原创 日志类系统与交易类系统(订单/商品搜索)两种典型场景整理的 Elasticsearch 生产部署与实战优化方案

摘要:本文对比分析了Elasticsearch在日志类系统(ELK)和交易类系统的部署优化策略。日志类系统建议3Master+多Data节点架构,采用时间滚动索引、ILM生命周期管理;交易类系统需SSD+高内存配置,重点优化实时搜索、幂等写入和深度分页。核心优化包括shard数量控制、mapping规范、批量写入和查询性能提升,并强调两种场景在索引策略、数据特征上的差异。实际应用需结合监控体系保障稳定性,通过合理架构设计满足不同业务场景的性能需求。

2025-06-21 11:30:29 954

原创 Elasticsearch 节点部署情况与优化

摘要:Elasticsearch节点类型包括Master(必需)、Data(必需)、Ingest(可选)、Coordinating(可选)和MachineLearning(可选)。生产环境建议部署3个专职Master节点、多个Data节点和独立Coordinating节点,并合理配置资源(如堆内存不超过32GB)。优化策略包括:Master节点专责管理、Data节点SSD配置、合理分配shard、JVM调优、批量写入和查询优化等。同时需监控集群指标、GC情况和慢查询,确保稳定运行。

2025-06-21 11:27:57 689

原创 如何将关键字段数据灌输到 Elasticsearch?(实战+对比详解)

摘要:本文将各种主流数据同步方案进行对比分析,重点介绍了Canal+Kafka+自研消费者、Maxwell+Kafka+Logstash、FlinkCDC+FlinkSinktoES、DTS云同步服务四种方案的特点。其中Canal+Kafka方案灵活可控但运维复杂,适合大中型项目;Maxwell+Kafka方案部署简单,适合中小项目;FlinkCDC方案适合大数据实时场景;DTS云服务运维成本低但扩展性差。文章还提供了字段处理、幂等控制等实用技巧,并针对不同业务场景给出方案选择建议。

2025-06-21 10:20:38 848

原创 Sharding-JDBC 核心问答总结(面试速记版)

🔥 SQL方言兼容性(如Oracle vs MySQL)优先Sharding-JDBC:云原生/高性能场景。选MyCAT:非Java语言/需MySQL协议代理。:用户ID > 订单ID > 时间戳。③ 禁止大偏移量查询(业务层面拦截)改写引擎:逻辑表名→物理表名(:非绑定表/广播表的JOIN。避免数据倾斜(如按性别分片):跨分片去重结果可能不准确。🔥 全路由查询的性能劣化。① 业务侧改用连续查询(:分片键不一致的子查询。:跨分片UNION查询。:高频查询条件字段(如。② 限制最大归并行数

2025-06-20 18:25:56 943

原创 Sharding-JDBC 深度实战与面试全攻略

分片设计原则单分片不超过 5000 万行预留 30% 容量用于扩容性能优化props:sql.show: true # 开启SQL日志executor.size: 20 # 并发执行线程数监控指标分片查询延迟归并结果集大小分布式事务成功率灾备方案同城双活部署分片级数据备份。

2025-06-20 18:15:23 779

原创 实现微信红包算法,随机性越强越好

思路是每次分配时,计算当前剩余金额和剩余人数的平均值avg当前用户可随机领取金额范围是[0.01元, 2 * avg]这样保证了随机性且不会出现前几个人抢光大部分导致后面没钱的情况每次减掉已分配金额,剩余金额留给后面的人,最后一个人拿剩余金额。

2025-06-20 15:17:48 291

原创 Spring 事务种类全解(声明式 + 编程式 + 传播行为)

底层基于 AOP 实现,Spring 自动处理事务开始、提交、回滚适合大多数常规业务开发。

2025-06-20 15:01:14 318

原创 简单描述一下Spring的IOC与AOP

摘要:IoC(控制反转)将对象创建和依赖管理交给Spring容器,通过构造器/Setter/@Autowired注入对象,实现解耦。AOP(面向切面编程)将通用逻辑(如日志、事务)抽离为切面,动态织入目标方法,通过切点表达式和通知实现非侵入式增强。二者共同构建了Spring高内聚、低耦合的架构,IoC负责对象生命周期管理,AOP处理横切关注点,提升代码复用性和可维护性。

2025-06-19 18:29:37 211

原创 Redis 常用数据类型及应用场景

Redis提供了多种数据结构满足不同业务需求:String是最基础类型,用于缓存、计数等场景;Hash适合结构化对象存储;List可用作消息队列;Set实现去重集合;ZSet支持带权重的有序集合;Bitmap用于位操作场景;HyperLogLog进行基数统计;Geo处理地理位置数据;Stream构建消息队列。每种类型都有对应的典型应用场景,如排行榜使用ZSet、UV统计用HyperLogLog、附近的人用Geo等。在实际开发中,应根据业务特点选择最合适的数据结构,以提升性能和节省内存。

2025-06-19 18:02:19 456

原创 Executors提供了哪些线程池,他们各自的特点?

【线程池类型与特性对比】 1️⃣ CachedThreadPool:动态伸缩线程池,核心线程数0,最大线程数无限制,60秒空闲回收,适用短期异步任务,但可能因任务暴增导致OOM。 2️⃣ FixedThreadPool:固定线程数,无界队列,适合稳定负载场景,但任务堆积易引发OOM。 3️⃣ SingleThreadExecutor:单线程顺序执行,无界队列,风险与FixedThreadPool类似。

2025-06-19 17:52:21 432

原创 Java 修饰符:static、final、volatile 深度对比 + 示例 + 场景实战

摘要: static、final和volatile是Java中的三个重要关键字,它们分别具有不同的特性。static用于声明类级共享变量,所有实例共享;final表示变量只赋值一次,引用不可变但内容可能可变;volatile保证多线程间的可见性。组合使用时,static final常用于定义全局常量(如配置参数),static volatile适用于线程间共享状态变量(如开关标志)。在项目中,static volatile可用于灰度发布控制,volatile可确保配置更新及时生效。

2025-06-19 17:01:00 432

原创 String.intern() 原理的结构化整理,适合面试复述和深入理解

《String.intern()的优化实践与注意事项》 摘要:String.intern() 是 JVM 提供的字符串常量池优化方法。JDK7 后改进为直接引用堆对象,比 JDK6 的复制方式更节省内存。通过编译期常量折叠可自动优化,但运行时拼接仍需手动处理。在大数据日志处理等高频重复字符串场景中,使用 intern() 进行字符串去重可显著降低内存占用(约20%+),减少GC次数并提升吞吐量。优化要点包括:针对高重复字段使用、避免循环滥用、注意JDK版本差异。

2025-06-19 16:14:37 408

原创 为什么 String 类是 final 的?

Java将String设计为final类的主要原因包括:安全性与不可变特性、哈希稳定性、字符串池机制实现、线程安全性、编译器优化以及保持行为一致性。这种设计确保了String在网络地址等敏感场景的安全性,作为HashMap键的可靠性,内存高效利用,多线程环境下的安全性,性能优化以及避免继承破坏行为。典型案例展示了不可变性对Map键值可靠性的保障。这一设计综合考量了性能、安全和一致性等因素,是Java核心类库的重要设计决策。

2025-06-19 16:04:06 243

原创 【通用 + 可落地 + 面试可用】的数据预热方案

数据预热是指在系统启动或业务前置阶段提前加载热点数据到缓存等中间件中,避免冷启动时缓存未命中问题。常见场景包括缓存冷启动、击穿、雪崩等。典型预热方式包括:1)启动时预热固定热点数据;2)定时任务更新动态热点;3)热点探测异步加载;4)运维手动触发。设计需考虑缓存一致性、多级缓存、扩容同步等问题。电商系统常应用于商品详情页、促销活动等场景,采用自动+定时+异步预热组合策略,并设置随机过期时间防止雪崩。面试时可结合具体业务场景说明预热机制的设计和实施效果。

2025-06-19 11:55:39 226

原创 ThreadLocal 与 TransmittableThreadLocal 在“线程池上下文传递”上最核心的差异。

ThreadLocal与TTL的核心区别在于线程池中的上下文传递能力。普通ThreadLocal无法将主线程变量传递给子线程,且不支持线程池复用场景,容易导致内存泄漏需手动清理。而TTL通过装饰器模式,在任务提交时自动复制主线程上下文到线程池线程,确保变量正确传递,但仍需try-finally清理避免残留。典型应用场景包括TraceID追踪和用户上下文传递,TTL特别适合需要跨线程池维护上下文一致性的场景。面试时可强调TTL的Executor增强机制是其实现跨线程传递的关键。

2025-06-19 11:44:13 254

原创 ThreadLocal 和多线程有什么区别

ThreadLocal与多线程的区别与配合使用 ThreadLocal是为解决多线程共享变量冲突而设计的线程隔离机制,每个线程拥有独立的变量副本,常用于保存用户信息、事务连接等线程私有数据。而多线程技术(Thread/Executor)主要用于实现任务并发执行,提升程序吞吐量。两者的核心区别在于:ThreadLocal不控制线程运行但保证线程安全,多线程则管理线程生命周期但需额外处理线程安全问题。

2025-06-19 11:42:10 717

原创 ThreadLocal / volatile / 事务上下文传递总结

《线程安全与内存泄漏排查指南》摘要: 针对ThreadLocal引发的内存泄漏问题,建议采用jmap+MAT工具分析堆内存,重点排查ThreadLocalMap中残留的Entry。关键解决方案包括:1.显式调用remove();2.使用弱引用优化;3.线程池场景需注意生命周期管理。面试常见问题解析:ThreadLocal适用于上下文传递但需防范泄漏和线程复用问题;volatile需结合CAS解决原子性;Spring事务跨线程问题可通过TransmittableThreadLocal或TCC模式解决。

2025-06-19 11:04:50 862

原创 JVM GC 面试答题详细说明

JVM垃圾回收优化实践 CMS垃圾回收器通过并发标记清理机制降低FullGC停顿时间,适合对延迟敏感的在线业务(如电商秒杀),但其内存碎片问题可能导致回收失败。G1作为替代方案,采用分区管理和停顿预测机制,更适应大堆内存场景。内存担保机制防止晋升失败引发的OOM,需合理配置参数避免频繁FullGC。实际业务中,通过调整堆大小、优化GC参数、切换G1及代码优化,可有效解决高并发场景下的GC问题,提升系统稳定性。监控与异步处理也是关键的优化手段。

2025-06-18 18:18:34 774

原创 常用技术/运营指标整理(通俗解释 + 面试用法)

我们服务日活(DAU)在 10w 左右,日均 PV 达 50w,接口平均 QPS 在 800~1500 区间,峰值可达 2500。针对这些指标,我们在入口设置了 Sentinel 限流 + 熔断策略,配合缓存和异步队列提升系统吞吐。“我们这个接口日常 QPS 在 1000 左右,双十一会飙升到 8000,所以我们做了限流和缓存预热”“系统 TPS 不高,但 RT 要求很低,核心接口响应时间需控制在 100ms 内”“页面 PV 虽高,但 UV 实际并不多,刷量可能性较大”

2025-06-18 18:05:17 723

原创 Sentinel 限流的核心原理 + 实践配置 + 源码理解 + 场景落地

摘要: Sentinel是阿里开源的流量防控组件,支持QPS限流、并发线程控制、热点参数限流等多种策略,通过滑动窗口统计和令牌桶等算法实现精准控制。其核心流程基于责任链(SlotChain),由FlowSlot执行限流检查,FlowRuleChecker对比阈值后拦截或放行请求。支持来源应用、集群等维度限流,可通过控制台或代码配置规则。高并发场景推荐结合WarmUp预热、RateLimiter匀速器及热点限流,保障系统稳定。

2025-06-18 17:56:00 1068

原创 MySql 事务怎么实现的

MySQL 中事务的实现,是数据库可靠性和一致性保障的核心机制。以下是从 原理 + 实践 + 面试回答模板 的详细说明,帮助你理解和应对高质量面试。

2025-06-18 10:59:15 420

原创 带过滤规则的群发短信

文章摘要: 短信群发需通过过滤规则精准触达目标用户,提升效果并降低成本。常见过滤维度包括用户身份、活跃度、地理位置等,实现方式有SQL查询或DSL规则引擎(如JSON配置转SQL)。技术实现建议结合分页查询、异步队列(如MQ)及缓存优化(Redis),支持可视化DSL配置以提高运营灵活性。核心流程:规则配置→SQL转换→分页查询→异步投递,同时需处理大数据分片、限流及失败重试,确保高效合规。面试要点包括规则设计、性能优化及异步处理机制。

2025-06-17 16:02:23 905

原创 Eureka、Nacos、Zookeeper 优雅上下线机制

三大注册中心优雅上下线机制对比 本文对比了Eureka、Nacos和Zookeeper在服务上下线机制上的差异。Eureka通过状态标记和心跳机制实现,Nacos整合健康检查并支持REST API操作,Zookeeper则依靠临时节点管理。文章详述了各中心的优雅上下线实现方法,并给出选型建议:Spring Cloud推荐Eureka/Nacos,多语言系统可选Nacos/ZK,需强一致性的场景适合Zookeeper。最后总结了"上线三步骤"和"下线三守则"的口诀,强调

2025-06-17 15:02:34 1352 1

原创 两个有序数组合并成一个 (归并算法的合并实现,同时也是双指针方法的典型例)

摘要:归并排序采用"分治"策略,先递归拆分数组至单个元素,再通过合并有序子数组完成排序。核心操作是双指针法合并两个有序数组:比较指针元素,较小者加入结果,剩余元素直接追加。合并时间复杂度为O(m+n),整体排序复杂度O(nlogn)。示例展示了Java实现代码,包括merge函数和递归调用过程。该算法空间复杂度O(n),适用于链表和外部排序,面试需突出其稳定性和分治思想。

2025-06-16 18:21:01 763

原创 「时间复杂度」和「空间复杂度」

摘要:时间复杂度衡量代码执行步骤数量,与数据量n成正比,如O(n)为线性时间,O(n²)为平方时间。空间复杂度评估额外内存使用量,新建数组时为O(m+n),就地操作为O(1)。口诀:时间复杂度看步数增长,空间复杂度看内存开销。(98字)

2025-06-16 17:57:16 309

原创 找数组中是否有两个数之和等于目标值

解法时间复杂度空间复杂度思路暴力双循环O(n²)O(1)穷举所有组合HashSet优化O(n)O(n)边查边存,空间换时间。

2025-06-16 17:48:50 356

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除