- 博客(178)
- 资源 (3)
- 收藏
- 关注
RSS订阅原创 Raft 协议：分布式一致性算法的核心思想
核心结论易用性：Raft 通过明确角色和任期机制，大幅降低分布式一致性实现难度。强一致性：通过多数派提交和日志匹配原则，确保系统状态严格一致。适用场景：适合需要强一致性的系统（如配置中心、分布式锁服务）。
2025-05-17 16:42:33
624
原创 MySQL UPDATE 执行流程全解析
MySQL 的UPDATE执行流程是解析 → 优化 → 锁管理 → 数据修改 → 日志记录的精密协作过程。优先使用索引，避免全表扫描。控制事务粒度，减少锁竞争。合理配置日志策略，平衡性能与数据安全。通过结合EXPLAIN分析和索引优化，开发者可以高效定位性能瓶颈。下一篇我们将深入探讨 InnoDB 的 MVCC 实现原理，敬请期待！
2025-05-17 13:23:30
603
原创 MySQL 查询执行流程全解析
MySQL 查询执行流程是 解析 → 优化 → 执行 的精密协作过程。优先使用覆盖索引，避免回表开销。控制连接条件顺序，利用小表驱动大表。避免隐式类型转换，防止索引失效。通过结合EXPLAIN分析和索引优化，开发者可以高效定位性能瓶颈。下一篇我们将深入探讨 InnoDB 的 MVCC 实现原理，敬请期待！
2025-05-17 12:17:33
992
原创 MyISAM 的索引存储机制：非聚簇索引的深度解析
MyISAM 索引的核心结论非聚簇索引的本质：• 数据与索引分离，索引叶子节点存储数据指针。• 主键索引与二级索引逻辑一致，无物理存储差异。性能特征：• 优势：插入效率高，索引重建成本低。• 劣势：查询需两次 I/O，范围查询性能差。
2025-05-17 11:12:31
678
原创 MySQL 聚簇索引与非聚簇索引：底层原理与实战深度解析
关键结论聚簇索引 是数据存储的物理顺序，主键设计直接影响性能。非聚簇索引 需回表查询，适合加速特定字段的筛选。覆盖索引 和 最左前缀原则 是优化查询的核心手段。
2025-05-17 10:58:56
963
原创 深入理解 Java 中的 volatile：从底层原理到实践
volatile通过 MESI 协议 维护缓存一致性，通过 内存屏障 保证可见性和有序性，最终通过 happens-before 规则 定义多线程间的内存语义。• 核心价值：轻量级同步，适用于状态标志、双重检查锁定等场景。• 局限性：无法替代锁或原子类，需根据场景选择合适方案。理解volatile的底层原理，能帮助开发者写出更高效、更安全的并发代码。在下一篇博客中，我们将深入探讨与volatile的协作机制。
2025-05-17 10:29:13
936
原创 MySQL锁机制详解与加锁流程全解析
深入理解MySQL锁机制需要结合具体存储引擎实现，其中InnoDB的锁机制设计充分体现了性能与一致性的平衡。通过合理使用索引、优化事务逻辑、选择合适隔离级别，可以显著降低锁冲突概率。建议开发者在关键业务操作前进行锁分析，使用EXPLAIN验证执行计划，结合监控锁状态，最终构建高性能、高并发的数据库应用。
2025-05-16 18:04:53
1065
原创 深入解析ZAB协议：ZooKeeper的分布式一致性核心
ZAB协议通过高效的Leader选举、事务广播和恢复机制，在分布式系统中实现了强一致性。尽管存在单点写入的性能限制，但其在ZooKeeper等场景下的稳定性和成熟度使其成为工业界的重要选择。理解ZAB的设计哲学，有助于开发者更深入地掌握分布式协调服务的底层逻辑。进一步学习建议阅读ZooKeeper源码中的和模块。使用ZooKeeper命令行工具观察事务日志（通过Jepsen等工具测试ZooKeeper的分布式一致性边界。
2025-05-16 17:24:05
800
原创 Redis数据结构详解：应用场景与使用指南
Redis作为高性能的键值存储系统，凭借其丰富的数据结构，在缓存、实时统计、消息队列等场景中广泛应用。本文将深入解析Redis的7种核心数据结构及其经典应用场景，并提供详细的使用示例。
2025-05-16 16:55:22
867
原创 分布式锁: Redis和ZooKeeper两种分布式锁对比
Redis 分布式锁优势在于性能和简单性，适合高并发、允许短暂不一致的场景；风险在于主从切换和时钟问题，需结合业务设计补偿机制。ZooKeeper 分布式锁优势在于强一致性和可靠性，适合关键业务场景；代价是性能和复杂度，需权衡吞吐量需求。最终建议若系统要求高性能 + 最终一致性，选择 Redis（配合 Redisson）。若系统要求强一致性 + 高可靠，选择 ZooKeeper（配合 Curator）。
2025-05-16 15:58:31
1096
1
原创 分布式锁: Redisson红锁（RedLock）原理与实现细节
Redisson 的 RedLock 实现通过多节点协作，显著提升了分布式锁的可靠性，但其复杂性、性能损耗和潜在风险（如时钟问题）需谨慎评估。技术选型建议常规场景：优先使用单节点 Redis 锁（结合业务幂等性）。高可靠场景：评估 RedLock 或转向 ZooKeeper/etcd。混合方案：对关键资源使用 RedLock，非关键资源使用单节点锁。最终，分布式锁的可靠性不仅依赖中间件，还需结合业务层的容错设计（如事务补偿、异步校对），才能构建健壮的分布式系统。
2025-05-16 15:44:19
1113
原创 分布式锁: Redisson 实现分布式锁的原理与技术细节
Redisson 的分布式锁通过Lua 脚本原子性操作看门狗自动续期可重入设计，解决了原生 Redis 锁的多个缺陷，成为 Java 生态中的首选方案。其在高可用场景下的稳定性（如集群、哨兵支持）和丰富的锁类型（公平锁、联锁等），使其适用于电商库存扣减、分布式任务调度等高并发场景。然而，分布式锁并非银弹，在极端情况下（如 Redis 集群脑裂、时钟跳跃）仍需结合业务设计兜底策略（如幂等性、状态补偿）。对于更高一致性要求的场景，可考虑ZooKeeper或etcd，但需接受性能损耗的权衡。
2025-05-16 15:43:24
687
原创 Kafka消息路由分区机制深度解析：架构设计与实现原理
通过实现Partitioner接口，开发者可以创建业务特定的路由逻辑。时间窗口路由：将同一时间段的消息集中到特定分区地理位置路由：根据客户端IP选择就近分区业务分片路由：基于实体ID进行分片映射自定义策略需要特别注意分区数变更时的兼容性问题。Kafka的分区路由机制揭示了分布式系统设计的核心哲学——在约束条件下寻求最优解。精准诊断生产环境中的性能瓶颈设计出弹性可扩展的消息处理架构前瞻性地应对未来业务规模的增长。
2025-05-15 22:56:45
1254
原创 Kafka消费者分组机制深度解析
监控行为本身会改变系统状态（如JMX指标采集）日志级别设置影响故障排查效率跟踪调试可能引发级联再平衡采用非侵入式监控（eBPF技术）保持协议版本一致性实施灰度再平衡策略通过这种四维视角的解析，开发者可以超越表象认知，真正掌握Kafka消费者组在时空连续体中的运行规律，从而构建出弹性、高效的消息消费系统。
2025-05-15 18:34:10
773
原创 Spring事务失效的八大核心原因与深度解析
通过系统性理解这八大失效场景，开发者可快速定位95%以上的事务异常问题。事务管理如同精密钟表，需要每个齿轮（配置项）的精准配合，才能保证系统数据安全的持续运转。注解的方法，在方法执行前后开启/提交事务。当代理链路被破坏或事务控制要素缺失时，就会导致事务失效。Spring事务管理基于动态代理机制实现，通过AOP拦截带有。自定义回滚异常未声明。
2025-05-13 11:21:18
1274
原创 Spring @Transactional事务传播机制与MySQL事务原理解析
属性定义了7种传播行为，其本质是描述多个事务方法嵌套调用时，事务上下文如何传递和协作。MySQL作为底层数据库，通过。通过理解传播机制与MySQL事务实现的对应关系，开发者可以更精准地设计事务边界，在保证数据一致性的同时实现最佳性能。在分布式系统与多层服务调用场景中，事务边界的控制直接影响数据一致性。实现事务原子性，两者通过JDBC驱动协同工作。
2025-05-13 10:31:29
825
原创 Kafka 消息可靠性深度解析：大流量与小流量场景下的设计哲学
在分布式消息系统的设计中，消息可靠性保障本质上是系统在三者之间动态博弈的结果。Kafka作为现代流式架构的核心组件，其消息可靠性机制在不同流量场景下呈现出截然不同的设计哲学。本文将从系统设计原理层面，解构大流量与小流量场景下的可靠性保障机制差异，揭示背后的分布式系统设计智慧。
2025-04-29 18:08:19
767
原创 分布式事务：Saga分布式事务核心机制、实现模式与问题分析
Saga通过牺牲强一致性换取可用性和分区容忍性，适用于跨微服务的长事务场景。开发团队需重点解决补偿事务设计、消息可靠投递、分布式追踪三大技术难点。建议在业务设计阶段采用事件风暴（Event Storming）方法明确Saga边界，并结合Seata、ServiceComb等成熟框架降低实现复杂度。
2025-04-28 10:32:47
491
原创 分布式事务：深度解析TCC分布式事务（原理、优缺点与潜在问题）
TCC（Try-Confirm-Cancel）是一种基于业务补偿的分布式事务解决方案，通过将事务拆分为三个阶段实现最终一致性：fill:#333;color:#333;color:#333;fill:none;成功失败开始Try阶段:资源预留Confirm阶段:提交Cancel阶段:回滚完成TCC通过将事务控制权交给业务系统，在分布式环境下实现了柔性事务控制，但其代价是将复杂度转移到了业务层。完备的日志系统：记录完整的事务生命周期智能的重试策略：指数退避+熔断机制严格的幂等控制。
2025-04-28 09:49:00
971
原创 分布式事务：深度解析分布式事务三阶段提交（3PC）协议
3PC协议通过引入预提交阶段和超时机制，显著提升了分布式系统的可用性。尽管不能完全解决所有分布式一致性问题，但在中等规模分布式系统中仍具有重要应用价值。在实际工程实践中，建议根据业务特点选择合适的事务方案，结合消息队列、补偿事务等机制构建完整的分布式事务解决方案。
2025-04-27 17:56:22
735
原创 Redis故障防御体系：构建七层免疫系统的设计哲学
当Redis遭遇写入阻塞或服务崩溃时，本质上是系统边界的多重防御机制被击穿。本文摒弃碎片化的解决方案，从系统工程的全局视角，构建七层递进式防御体系，揭示高可用架构的深层设计逻辑。
2025-04-27 14:07:20
958
原创 Redis内存管理三部曲：淘汰、过期与惰性删除的协同哲学
Redis的内存管理机制揭示了一个普适真理：在约束条件下创造价值，才是工程艺术的精髓。淘汰算法是选择与放弃的智慧，过期策略是时间管理的艺术，惰性删除是效率优先的哲学。三者构成的动态平衡系统，恰似市场经济中"看不见的手"，在微观决策中实现宏观层面的资源最优配置。理解这些机制的本质，开发者便掌握了在高性能与稳定性之间走钢丝的平衡杆，在内存的方寸之地开辟出无限可能。
2025-04-27 11:52:30
374
原创 分布式事务 两阶段提交协议（2PC的原理、挑战）
尽管2PC存在诸多争议（如性能问题、单点故障），但它仍然是理解分布式一致性的基石。本文将深入探讨2PC的核心原理、实现细节、缺陷及其在工业界的优化实践。在分布式系统中，数据和服务往往分布在多个节点上。这种跨服务的原子性操作需求，催生了。，而其中最经典的方案之一便是。
2025-04-25 16:07:10
843
原创 Redis-缓存应用 本地缓存与分布式缓存的深度解析
本地缓存与分布式缓存并非互斥关系，而是互补的“黄金组合”。本地缓存追求极致的性能，Redis保障全局的一致性与扩展性。在架构设计中，需结合业务场景灵活选用，通过多级缓存、失效策略与一致性机制，构建高性能、高可用的缓存体系。未来，随着云原生与Serverless技术的发展，缓存服务将进一步与基础设施融合，例如通过Sidecar模式将本地缓存与Redis结合，或利用内存网格（如Hazelcast）实现自动分片与弹性伸缩。缓存技术的演进，将持续推动分布式系统的性能边界。附录：Redis与本地缓存的典型配置对比。
2025-04-24 15:28:55
803
原创 Kafka 详细解读
产品经理（Producer）拍脑袋想出新需求 → 按 Key 哈希到某个 Partition → 扔给对应技术组（Broker）技术组把需求文档（消息）存到硬盘 → Leader 程序员（Partition Leader）同步给实习生（Follower）Leader 程序员突然猝死 → HR（ZooKeeper）发起紧急选举 → 手速最快的实习生（ISR Follower）上位。：管理 Broker 元数据、Consumer Offset（早期版本）、协调选举。：存数据、传数据、24小时待命，还要被甩锅。
2025-04-21 18:17:15
969
原创 Java synchroinzed和ReentrantLock
必须老老实实排队（hasQueuedPredecessors()检查队列）下次面试被问锁机制，直接把这拍面试官脸上！（拍桌子）现在够不够底层？这他妈就是锁的黑暗森林法则——新线程可以直接插队抢锁（不管队列里有没有人）当锁启用时，Mark Word变身成。优点：吞吐量高（减少线程切换）缺点：性能损失约10%-15%缺点：可能饿死老线程。
2025-04-20 21:56:19
730
原创 MySql 三大日志（redolog、undolog、binlog）详解
redo logundo logbinlog谁家的InnoDB亲儿子InnoDB亲儿子MySQL Server层的干儿子存啥物理日志（在哪个页改了啥）逻辑日志（旧数据长啥样）逻辑日志（执行的SQL语句）干啥用崩溃恢复（保数据）回滚+MVCC（保一致性）主从同步+数据恢复（保逻辑）吐槽“硬盘不够？循环覆盖！“长事务我***弄死你！你硬盘是SSD吗！最后一句忠告想不丢数据？redo log和binlog一个都不能少（除非你心大）。想不卡死？别开长事务，不然undo log能把你硬盘塞成砖头。
2025-04-19 11:25:44
654
原创 Java G1垃圾回收器设计理念
（默认约1~32MB），每个Region可以是Eden、Survivor、Old或Humongous区域，打破传统分代模型的物理隔离。G1（Garbage-First）垃圾回收器是Java在应对大内存、低延迟场景下的里程碑式设计，其核心思想颠覆了传统分代模型的限制。传统GC（如CMS）的停顿时间像开盲盒，而G1像滴滴打车——明确告诉用户“预计等待时间8分钟”。传统分代模型像固定隔间的老式厕所，而G1则是可拆卸的集装箱厕所，随时根据需求重组空间。将存活对象移动到空白Region，自然完成内存整理。
2025-04-17 17:27:17
827
原创 Java CMS和G1垃圾回收器
把旱厕切成2048个瓷砖格子（Region），每个格子可随时变身新坑/陈年坑。（特点：能一边拉屎一边掏粪，但容易翻车）（特点：把厕所划成格子间，精准爆破）
2025-04-17 16:57:19
1028
原创 Spring的启动流程
整个过程像他妈流水线——你写XML/注解，Spring流水线工人（容器）给你拼装对象，最后还给你擦屁股。，而不是亲自当接生婆！
2025-04-15 13:54:05
383
原创 validate 复合参数校验
1、后台实体类public class Parent { //年龄 private int age; //姓名 private String name; //用户 private User user; public int getAge() { return age; } public void setAge(int age) { this.age = age; }
2018-01-17 10:54:34
892
1
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人