- 博客(90)
- 资源 (1)
- 收藏
- 关注
RSS订阅原创 DiscoveryClient 和 NamingService
SpringCloud的DiscoveryClient与Nacos的NamingService是两种服务发现接口。DiscoveryClient是SpringCloud的通用抽象接口，支持多平台集成（如Nacos/Eureka），适用于SpringBoot应用，提供统一的服务查询方法。NamingService是NacosSDK专用接口，提供更细粒度的服务注册/发现功能，支持实例属性配置等底层操作。开发中可根据需求选择：SpringCloud项目优先使用DiscoveryClient，需要深度定制Nacos
2026-01-13 22:19:35
420
原创 实战都通用的 Watchdog 原理说明
RedisWatchdog是Redisson实现的分布式锁自动续期机制，解决业务执行时间超过锁有效期的问题。它通过后台线程每10秒检查并延长锁30秒有效期（基于UUID验证），确保业务完成前锁不会过期。当业务完成或进程崩溃时，Watchdog会自动停止或失效，避免死锁。该机制本质是让锁有效期与业务执行时间同步，而非固定TTL，有效防止并发安全问题。
2026-01-12 23:13:35
577
原创 RocketMQ 架构与设计原理
RocketMQ作为分布式消息中间件，在电商、支付等高并发系统中扮演关键角色。其架构包含五大核心组件：NameServer负责轻量级路由管理；Broker通过CommitLog顺序写和ConsumeQueue索引实现高吞吐存储；Producer作为异步架构入口；Consumer采用拉模式自主控制消费速率；Topic和Queue机制实现消息并行处理。设计亮点包括去中心化路由、顺序IO优化、分区并行消费、消费进度控制和事务消息保障。
2026-01-10 21:34:58
938
原创 1000 万用户排行榜设计与实现
本文提出使用Redis的ZSet（SortedSet）实现千万级用户排行榜的方案。ZSet通过跳表+Hash结构天然支持按分数排序、快速查询排名和获取TopN数据，时间复杂度为O(logN)。单条数据约70-100B，1000万用户约占用1GB内存。方案强调工程实践：分周期维护榜单、只存储userId、缓存TopN结果等优化措施，避免内存膨胀。对于超大规模数据，可采用分片ZSet配合归并查询。ZSet的原子操作确保并发安全，是千万级排行榜的理想选择，其核心在于让数据在写入时就保持有序状态。
2026-01-09 21:58:23
751
原创 数据库面试中最容易产生“语义冲突”的问题
文档的核心观点是：数据库面试中的大多数冲突，来源于讨论抽象层级不一致，而非技术理解错误。全文通过 DELETE 是否属于物理删除、InnoDB 锁模型、索引结构、事务与隔离级别等高频问题系统拆解了三种常见视角：业务 / 系统设计视角（数据是否长期存在、是否可恢复、是否可审计）存储引擎 / 实现视角（InnoDB 的具体机制与工程实现）规范 / 理论视角（SQL 标准与教科书定义）
2026-01-08 22:46:39
614
原创 数据库性能调优中的经典高频面试题
MySQL性能优化核心要点： GROUP BY优化：为分组字段创建索引（联合索引更佳），避免SELECT非聚合字段，控制结果集大小。索引是根本解决方案，合理SQL写法是关键。 百万级分页：优先使用游标分页（基于有序唯一字段），其次采用延迟关联减少回表，或限制分页深度结合缓存。游标分页效率最优，与数据量无关。 SQL突然变慢：主要排查统计信息过期（执行计划突变）、参数类型/范围变化、锁竞争及资源瓶颈。
2026-01-07 20:23:12
812
原创 怎么优化慢SQL
摘要：本文系统介绍了MySQL慢SQL优化方法论，涵盖慢SQL定位、常见问题分析及优化策略。通过开启慢查询日志和使用EXPLAIN分析执行计划，可快速识别性能瓶颈。优化措施包括：合理设计索引（避免失效）、解决排序和临时表问题、优化JOIN查询、处理大分页性能问题等。高级优化手段涉及SQL重写、读写分离、分库分表和缓存技术。这些方法不仅适用于InnoDB引擎，部分也适用于其他关系型数据库，是提升数据库性能的实用指南。
2026-01-06 22:02:48
1282
原创 为什么MySQL用b+不用B数
MySQL选用B+树而非B树作为索引结构，主要因其更适合数据库操作特性：1）数据仅存于叶子节点，内部节点键值导航使树更矮，减少I/O；2）高扇出特性支持三层索引十亿级数据；3）叶子节点链表结构高效支持范围查询；4）天然契合磁盘分页存储模型。相比B树，B+树在I/O效率、范围查询和树高控制方面优势明显，更符合关系型数据库需求。MyISAM等其他数据库引擎也普遍采用B+树结构。
2026-01-06 21:54:16
389
原创 10 亿条数据排序：外部排序与 10 路归并完整说明
本文针对10亿条数据无法一次性加载内存的排序问题，提出外部排序的标准工程解法。该方法包含两个核心步骤：首先将数据分块进行内存排序，解决内存不足问题；然后通过多路归并（使用PriorityQueue小顶堆）确保全局有序。文章详细阐述了归并排序的原理，通过示例演示了两路归并到10路归并的过程，并提供了Java实现的核心代码。分析表明该方法时间复杂度为O(NlogK)，空间复杂度为O(K)。最后强调分块排序不等于全局排序，归并阶段是保证全局有序的关键，外部排序是处理海量数据排序问题的标准工程解决方案。
2026-01-05 21:18:43
980
原创 消息积压治理与自我保护设计方案
本文提出了一套针对高并发场景下消息队列积压问题的系统性解决方案。通过实时监控RabbitMQ/RocketMQ的队列深度(Lag/QueueDepth)指标，构建了包含生产端、消费端和业务层的三级防护体系：生产端动态限流控制发送速率，消费端自适应调节并发线程和预取数量，业务层优先保障核心链路并降级非关键业务。方案采用指标驱动、自动化闭环的设计原则，实现了从监控、决策到执行的完整治理流程，有效解决了"越慢越压"的恶性循环问题，并在电商大促等场景中得到验证，确保了系统稳定性。
2025-12-18 18:20:24
1352
原创 MacOS 安全机制与“文件已损坏”排查完整指南
本文介绍了macOS的安全机制及其应对方案。主要涉及四个核心保护功能：SIP（系统完整性保护）、Gatekeeper（应用签名验证）、文件隔离属性和安全启动限制。针对"文件已损坏"等常见问题，提供了详细解决方案：检查/关闭SIP、禁用Gatekeeper、清除文件隔离属性、重新签名应用等操作步骤。特别强调了Apple Silicon芯片的兼容性问题处理（如Rosetta2）。文末建议操作完成后恢复安全设置，并指出这些方法主要适用于开发调试场景。所有操作均需在理解风险的前提下谨慎执行。
2025-08-18 19:52:23
1076
原创 MySQL、PolarDB、PolarDB-X、TableStore、MongoDB、TiDB、ClickHouse选型
本文提供了主流数据库的选型指南，从OLTP到OLAP场景全面覆盖。MySQL适合传统事务处理，PolarDB适用于云原生扩展，PolarDB-X和TiDB满足分布式事务需求。对于文档存储推荐MongoDB，时序/宽表场景可选择TableStore，分析型场景则适合ClickHouse。文章详细对比了各产品的技术特性、适用场景及限制，并针对电商、IoT、金融等典型业务给出选型建议，同时提供了各产品的官方文档链接，为数据库选型提供实用参考。
2025-08-15 19:13:26
2042
原创 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
603
原创 如何发现并解决 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
782
原创 秒杀系统设计方案（实战 + 面试答疑全套）
摘要：本文详细介绍了高并发秒杀系统的设计方案，通过多层级防护机制解决百万QPS下库存准确性和系统稳定性问题。系统采用Redis+Lua原子扣减库存、MQ异步削峰、MySQL乐观锁实现防超卖；通过动态路径、验证码、限流组件(如Sentinel)防止刷单；前端轮询异步结果保障用户体验。关键创新点包括：三层防超卖机制(Redis预扣+MQ异步+DB校验)、四重防重复(Set去重+唯一索引+幂等处理)、动态路径+滑动验证码防机器刷单。系统实现了秒杀场景下的高并发处理、数据最终一致性和安全防护目标。
2025-06-27 18:28:11
816
原创 缓存双写策略
缓存双写策略是解决缓存与数据库一致性的核心方案，主要包括同步双写和异步双写两种方式。同步双写如Write-Through和CacheAside强调强一致性但性能开销大，而异步双写通过消息队列实现最终一致性，性能更好但存在延迟。在秒杀系统中，典型应用是CacheAside组合异步最终一致，先原子性扣减Redis库存，再通过MQ异步更新数据库，兼顾性能与强一致性。策略选择需根据业务场景权衡一致性要求、性能需求和实现复杂度。
2025-06-26 18:26:01
1113
原创 动态URL生成或URL动态化
动态地址生成是秒杀系统的核心安全机制，通过时效性URL防止爬虫和脚本攻击。其核心是活动前短时间内为用户生成带有加密Token（含用户ID、商品ID等）的唯一地址。服务端采用JWT或HMAC签名验证请求合法性，配合Redis存储Token实现一次性使用。关键点包括：严格时效控制（5-30秒）、HTTPS传输、密钥安全管理、前端时间同步及降级方案。该技术有效拦截非法请求，减轻后端压力，是秒杀系统防护体系的第一道防线。
2025-06-26 18:17:25
1134
原创 MySQL Join：大表关联小表 vs 小表关联大表
MySQL JOIN性能优化要点：SQL JOIN执行原理是嵌套循环(Nested Loop Join)，驱动表(左表)每行都要在被驱动表(右表)匹配。优化关键在于：1)尽量用小表作为驱动表，减少循环次数；2)被驱动表的关联字段必须建立索引，避免全表扫描；3)通过EXPLAIN分析执行计划，查看是否命中索引；4)必要时使用STRAIGHT_JOIN强制指定小表为驱动表。在实际项目中，商品表关联类目表、订单表关联用户表等场景都需要遵循这些优化原则。
2025-06-25 18:18:45
1857
2
原创 MySQL InnoDB 锁机制详解（粒度 + SELECT FOR UPDATE + S锁/X锁）
InnoDB存储引擎的锁机制解析：InnoDB支持行锁（RecordLock）、间隙锁（GapLock）、临键锁（Next-KeyLock）等不同粒度的锁。事务级锁分为共享锁（S锁）和排他锁（X锁）。SELECT FOR UPDATE语句的锁行为取决于索引：命中索引时触发行锁，无索引时退化为全表锁，范围查询则加临键锁。合理使用锁机制需要结合事务隔离级别、索引设计和业务场景进行优化。
2025-06-23 18:35:09
1331
原创 实战教学的 Java 死锁案例
《Java死锁问题排查与解决方案》 摘要：本文介绍Java开发中常见的死锁问题，通过经典双锁互持示例展示死锁形成原理。当线程A与线程B分别持有lock1和lock2并互相请求对方锁时，会产生循环等待导致死锁。排查时可通过jps获取进程号，使用jstack分析线程栈，查找"deadlock"关键词定位问题线程。解决方案包括统一加锁顺序、使用ReentrantLock的tryLock机制、减少锁粒度以及建立监控告警系统。
2025-06-23 17:02:06
621
原创 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
1167
原创 JVM 性能调优
JVM调优实战指南：关键参数与优化思路 摘要： JVM调优是Java系统性能优化的重要环节。本文梳理了JVM内存模型和核心调优参数，提出"监控→分析→调整→验证"四步调优法。重点关注堆内存配置（-Xms/-Xmx）、GC算法选择（G1、CMS等）、元空间设置等关键参数，并提供典型生产案例：通过切换G1收集器、调整新生代比例，成功降低30%响应时间。调优需结合GC日志分析和压测验证，确保系统在高并发场景下的稳定性。
2025-06-22 09:48:14
481
原创 ES倒排索引的原理
倒排索引：全文搜索的加速器 倒排索引是一种通过“关键词→文档ID列表”映射优化搜索的数据结构，核心思想是将文档内容分词后建立反向关联。与数据库正排索引（逐行扫描）不同，倒排索引直接定位关键词所在文档，无需遍历数据。例如，搜索“喜欢”时，ES通过倒排表快速返回文档[1,3]。 Lucene底层实现中，每个关键词（Term）关联一个倒排链表（PostingsList），记录文档ID、词频、位置等信息，支持短语搜索、高亮等功能。实际应用中，text类型字段默认构建倒排索引，而聚合场景使用doc_values。
2025-06-21 15:45:23
809
原创 Elasticsearch 的原理
Elasticsearch是基于Lucene的分布式搜索引擎，其核心原理是倒排索引机制，通过建立"关键词-文档ID"映射实现高效全文搜索。采用分布式架构，数据分片存储，支持多副本保证高可用。写入时先缓存再持久化，查询时多分片并行处理。其优势在于：倒排索引快速定位、分布式并行查询、分词优化、缓存机制等，使其特别适合处理高并发搜索和日志分析场景。ES还支持结构化搜索、聚合分析等高级功能，通过合理配置可实现读写分离。
2025-06-21 15:07:48
839
原创 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
472
原创 日志类系统与交易类系统（订单/商品搜索）两种典型场景整理的 Elasticsearch 生产部署与实战优化方案
摘要：本文对比分析了Elasticsearch在日志类系统（ELK）和交易类系统的部署优化策略。日志类系统建议3Master+多Data节点架构，采用时间滚动索引、ILM生命周期管理；交易类系统需SSD+高内存配置，重点优化实时搜索、幂等写入和深度分页。核心优化包括shard数量控制、mapping规范、批量写入和查询性能提升，并强调两种场景在索引策略、数据特征上的差异。实际应用需结合监控体系保障稳定性，通过合理架构设计满足不同业务场景的性能需求。
2025-06-21 11:30:29
1198
原创 Elasticsearch 节点部署情况与优化
摘要：Elasticsearch节点类型包括Master（必需）、Data（必需）、Ingest（可选）、Coordinating（可选）和MachineLearning（可选）。生产环境建议部署3个专职Master节点、多个Data节点和独立Coordinating节点，并合理配置资源（如堆内存不超过32GB）。优化策略包括：Master节点专责管理、Data节点SSD配置、合理分配shard、JVM调优、批量写入和查询优化等。同时需监控集群指标、GC情况和慢查询，确保稳定运行。
2025-06-21 11:27:57
1121
原创 如何将关键字段数据灌输到 Elasticsearch？（实战+对比详解）
摘要：本文将各种主流数据同步方案进行对比分析，重点介绍了Canal+Kafka+自研消费者、Maxwell+Kafka+Logstash、FlinkCDC+FlinkSinktoES、DTS云同步服务四种方案的特点。其中Canal+Kafka方案灵活可控但运维复杂，适合大中型项目；Maxwell+Kafka方案部署简单，适合中小项目；FlinkCDC方案适合大数据实时场景；DTS云服务运维成本低但扩展性差。文章还提供了字段处理、幂等控制等实用技巧，并针对不同业务场景给出方案选择建议。
2025-06-21 10:20:38
1027
原创 Sharding-JDBC 核心问答总结（面试速记版）
🔥 SQL方言兼容性（如Oracle vs MySQL）优先Sharding-JDBC：云原生/高性能场景。选MyCAT：非Java语言/需MySQL协议代理。：用户ID > 订单ID > 时间戳。③ 禁止大偏移量查询（业务层面拦截）改写引擎：逻辑表名→物理表名（：非绑定表/广播表的JOIN。避免数据倾斜（如按性别分片）：跨分片去重结果可能不准确。🔥 全路由查询的性能劣化。① 业务侧改用连续查询（：分片键不一致的子查询。：跨分片UNION查询。：高频查询条件字段（如。② 限制最大归并行数
2025-06-20 18:25:56
1313
原创 Sharding-JDBC 深度实战与面试全攻略
分片设计原则单分片不超过 5000 万行预留 30% 容量用于扩容性能优化props:sql.show: true # 开启SQL日志executor.size: 20 # 并发执行线程数监控指标分片查询延迟归并结果集大小分布式事务成功率灾备方案同城双活部署分片级数据备份。
2025-06-20 18:15:23
1088
原创 实现微信红包算法，随机性越强越好
思路是每次分配时，计算当前剩余金额和剩余人数的平均值avg当前用户可随机领取金额范围是[0.01元, 2 * avg]这样保证了随机性且不会出现前几个人抢光大部分导致后面没钱的情况每次减掉已分配金额，剩余金额留给后面的人，最后一个人拿剩余金额。
2025-06-20 15:17:48
855
原创 Spring 事务种类全解（声明式 + 编程式 + 传播行为）
底层基于 AOP 实现，Spring 自动处理事务开始、提交、回滚适合大多数常规业务开发。
2025-06-20 15:01:14
429
原创 简单描述一下Spring的IOC与AOP
摘要：IoC（控制反转）将对象创建和依赖管理交给Spring容器，通过构造器/Setter/@Autowired注入对象，实现解耦。AOP（面向切面编程）将通用逻辑（如日志、事务）抽离为切面，动态织入目标方法，通过切点表达式和通知实现非侵入式增强。二者共同构建了Spring高内聚、低耦合的架构，IoC负责对象生命周期管理，AOP处理横切关注点，提升代码复用性和可维护性。
2025-06-19 18:29:37
317
原创 Redis 常用数据类型及应用场景
Redis提供了多种数据结构满足不同业务需求：String是最基础类型，用于缓存、计数等场景；Hash适合结构化对象存储；List可用作消息队列；Set实现去重集合；ZSet支持带权重的有序集合；Bitmap用于位操作场景；HyperLogLog进行基数统计；Geo处理地理位置数据；Stream构建消息队列。每种类型都有对应的典型应用场景，如排行榜使用ZSet、UV统计用HyperLogLog、附近的人用Geo等。在实际开发中，应根据业务特点选择最合适的数据结构，以提升性能和节省内存。
2025-06-19 18:02:19
545
原创 Executors提供了哪些线程池，他们各自的特点？
【线程池类型与特性对比】 1️⃣ CachedThreadPool：动态伸缩线程池，核心线程数0，最大线程数无限制，60秒空闲回收，适用短期异步任务，但可能因任务暴增导致OOM。 2️⃣ FixedThreadPool：固定线程数，无界队列，适合稳定负载场景，但任务堆积易引发OOM。 3️⃣ SingleThreadExecutor：单线程顺序执行，无界队列，风险与FixedThreadPool类似。
2025-06-19 17:52:21
622
原创 Java 修饰符：static、final、volatile 深度对比 + 示例 + 场景实战
摘要： static、final和volatile是Java中的三个重要关键字，它们分别具有不同的特性。static用于声明类级共享变量，所有实例共享；final表示变量只赋值一次，引用不可变但内容可能可变；volatile保证多线程间的可见性。组合使用时，static final常用于定义全局常量（如配置参数），static volatile适用于线程间共享状态变量（如开关标志）。在项目中，static volatile可用于灰度发布控制，volatile可确保配置更新及时生效。
2025-06-19 17:01:00
643
原创 String.intern() 原理的结构化整理，适合面试复述和深入理解
《String.intern()的优化实践与注意事项》 摘要：String.intern() 是 JVM 提供的字符串常量池优化方法。JDK7 后改进为直接引用堆对象，比 JDK6 的复制方式更节省内存。通过编译期常量折叠可自动优化，但运行时拼接仍需手动处理。在大数据日志处理等高频重复字符串场景中，使用 intern() 进行字符串去重可显著降低内存占用（约20%+），减少GC次数并提升吞吐量。优化要点包括：针对高重复字段使用、避免循环滥用、注意JDK版本差异。
2025-06-19 16:14:37
495
原创 为什么 String 类是 final 的？
Java将String设计为final类的主要原因包括：安全性与不可变特性、哈希稳定性、字符串池机制实现、线程安全性、编译器优化以及保持行为一致性。这种设计确保了String在网络地址等敏感场景的安全性，作为HashMap键的可靠性，内存高效利用，多线程环境下的安全性，性能优化以及避免继承破坏行为。典型案例展示了不可变性对Map键值可靠性的保障。这一设计综合考量了性能、安全和一致性等因素，是Java核心类库的重要设计决策。
2025-06-19 16:04:06
329
空空如也
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人