- 博客(983)
- 资源 (9)
- 收藏
- 关注
RSS订阅
原创 MyBatis源码学习系列文章目录
系列文章目录MyBatis开发要点MyBatis一级缓存MyBatis二级缓存MyBatis日志模块MyBatis日志增强MyBatis数据源MyBatis缓存模块（二级缓存深入理解）MyBatis反射模块MyBatis工作流程-初始化阶段一MyBatis工作流程-初始化阶段二MyBatis工作流程-代理封装阶段MyBatis工作流程-数据访问阶段MyBatis工作流程-与Spring整合...
2021-04-24 21:44:25
289
原创 MyBatis工作流程-与Spring整合
系列文章目录MyBatis开发要点MyBatis一级缓存MyBatis二级缓存MyBatis日志模块MyBatis日志增强MyBatis数据源MyBatis缓存模块（二级缓存深入理解）MyBatis反射模块MyBatis工作流程-初始化阶段一MyBatis工作流程-初始化阶段二MyBatis工作流程-代理封装阶段MyBatis工作流程-数据访问阶段MyBatis工作流程-与Spring整合文章目录系列文章目录 前言与MyBatis相关的Beanbean实例化的流程1. Sql
2020-12-19 16:12:11
271
1
原创 兼容Oracle与MySQL的一些事
文章目录前言一、字段类型差异二、函数差异 1、几种兼容方案a. 利用Mybatis的特性b. 是否存在相同的函数c. 自定义同名函数三、语法差异四、锁的差异总结前言由于公司目前主要使用的数据库为Oracle，然后部分兼容MySQL，后期会考虑全部支持Oracle和MySQL。由于二者的各种差异，我们必须有一套可行的方案减少工作量。在兼容Oracle与MySQL的那些事中我们已经仔细讨论过在数据层对多数据库的支持了，接下来的目标就是结合这种支持同时考虑其他手段达到目标了。本文从以下几点来谈一下对兼容考
2020-11-09 10:56:58
2103
7
原创 Java并发利器：AtomicStampedReference解析
假设有一个栈，初始状态为A → B → C，栈顶是 A。线程1 读取栈顶为 A，准备执行 CAS（期望 A，替换为 D）。此时线程2 弹出 A，再压入新节点 A’（内容相同但地址不同，或甚至同一个 A 被回收后重用）。A → B → C（看起来没变）。线程1 执行 CAS：发现栈顶仍是 A，于是成功替换为 D。但实际上，中间发生了变化（A 被弹出又压入），但 CAS 无法感知，这就是ABA 问题。值看起来没变，但语义已变。是 Java 并发编程中解决 ABA 问题的经典工具。
2025-12-22 17:33:53
765
原创 Java线程安全利器：CopyOnWriteArraySet详解
是 CopyOnWriteArrayList的 Set 封装版，通过委托 + 去重逻辑，实现了线程安全的无重复集合。“牺牲写性能，换取极致的读性能和遍历安全性”在合适的场景下（小、读多、写少），它是优雅且高效的解决方案；但在高写频或大数据场景下，应考虑其他并发 Set 实现。如果你正在处理回调注册、监听器管理、配置项缓存等场景，很可能就是你要找的工具。
2025-12-22 16:05:03
410
原创 Java线程安全利器：CopyOnWriteArrayList详解
特性说明线程安全所有可变操作加锁，读操作无锁但可见性由volatile保证内存一致性happens-before：写入前的操作对后续读取该元素的线程可见允许 null 元素null被当作普通元素处理fail-safe 迭代器基于快照，不抛高写成本每次写都复制整个数组，适合小规模、低频修改最终一致性读操作可能看到“过期”数据，但不会出错是为高并发读、低频写场景量身定制的线程安全容器。它用空间换时间 + 最终一致性的思路，巧妙避免了读写冲突，是并发编程中“乐观锁”思想的经典体现。
2025-12-22 15:24:22
292
原创 深入解析ThreadLocalMap核心实现
特性说明哈希冲突线性探测（开放寻址）Key 引用类型WeakReference（防 ThreadLocal 本身泄漏）Value 生命周期依赖 stale entry 清理，否则内存泄漏清理时机get/set/remove 时触发 expunge/cleanSomeSlots/rehash扩容条件size ≥ 2/3 * capacity，且清理后仍 ≥ 3/4 * threshold最佳实践使用完务必remove()如有需要，我可以进一步画出ASCII 流程图或UML 结构图。
2025-12-22 15:17:03
729
原创 深入解析ThreadLocal：线程私有变量的秘密
ThreadLocal 不是“线程”，而是“每个线程拥有自己独立副本的变量”。正常变量：所有线程共享同一个值。每个线程调用get()时，拿到的是自己独有的值，互不干扰。典型用途：用户会话 ID（Web 应用中每个请求线程保存自己的用户信息）数据库连接 / 事务上下文SimpleDateFormat（非线程安全，可用 ThreadLocal 封装）概念说明存储位置数据存在（Map）中，不是 ThreadLocal 里key 类型对象（弱引用）value 类型。
2025-12-22 15:08:23
534
原创 深入解析Kafka核心：Partition类源码揭秘
Da.txt中的Partition类是Kafka 副本机制的大脑维护分区的角色、状态、日志、元数据实现Leader 选举后的状态初始化管理ISR 的动态扩缩容推进高水位（HW）以保证一致性支持分区迁移（futureLog）提供JMX 监控指标使用精细锁控制并发安全💡 如果你想深入理解 Kafka 的一致性模型、故障恢复、副本同步、限流、监控，这个类是必读源码。“ISR 是怎么判断副本落后的？“Leader Epoch 如何防止数据丢失？
2025-12-16 14:11:25
879
原创 Kafka副本同步机制核心解析
是 Kafka高可用、强一致性副本机制的核心执行者拉取Leader 数据校验offset 和 epoch 一致性写入本地日志更新HW / LSO截断脏数据限流异常副本理解它，就理解了 Kafka 如何做到“即使宕机，也不丢数据、不错数据”。如果你正在调试副本同步延迟、ISR 频繁变动、或数据不一致问题，深入这个类会非常有帮助。需要我进一步解释某个方法（比如）或画更详细的时序图吗？
2025-12-16 14:10:12
707
原创 Kafka高可用：延迟请求处理揭秘
当 Producer 要求“所有副本写入成功”（acks=-1），而 Leader 虽已写入但 Followers 还未同步时，Kafka 会将该请求挂起为一个延时操作，注册到对应分区的监听器上；一旦 Followers 追上或超时，就自动完成并回复 Producer。这种机制既保证了数据一致性，又避免了线程阻塞，是 Kafka 高性能的关键设计之一。如果你还想了解Purgatory内部如何管理延时请求、如何避免内存泄漏、或者如何通知 Purgatory，也可以继续问！
2025-12-16 10:03:19
918
原创 Kafka元数据缓存机制深度解析
是 Kafka Broker 的元数据中心枢纽高性能：读无锁、Copy-on-Write、避免分配一致性：快照语义，避免脏读灵活性：支持多 Listener、动态更新、部分更新健壮性：处理 Broker 下线、Listener 缺失、分区删除等边界情况理解它，就理解了 Kafka如何在分布式环境下高效同步和使用集群拓扑信息。如果你有具体问题（比如某段逻辑、某个字段用途、或如何调试），可以继续问！
2025-12-16 09:46:58
660
原创 Kafka核心揭秘：ReplicaManager如何保障高可用
是 Kafka Broker 的“副本大脑”它既是数据管道的枢纽（协调读写与复制），也是一致性协议的执行者（维护 HW/LEO/ISR），更是故障自愈的守门人（处理磁盘失效、触发重平衡）。其设计体现了 Kafka 对高性能、强一致性、高可用的综合权衡，是理解 Kafka 内部机制的关键入口。
2025-12-15 19:58:46
678
原创 Kafka高水位与日志末端偏移量解析
概念含义表示当前副本（Replica）日志中下一条待写入消息的 offset。即：已有消息的最大 offset + 1。例如 LEO=10 表示已写入 [0, 9] 共 10 条消息。表示已被所有 ISR（In-Sync Replicas）副本成功复制的消息的最高 offset。消费者只能消费 offset < HW 的消息，以确保读取的是“已提交”且“多副本一致”的数据。LEO= “我写到哪了”（本地进度）HW= “大家都确认到哪了”（全局共识）
2025-12-15 19:52:29
854
原创 Kafka副本管理核心机制解析
功能说明Leader 管理识别本机 Leader 分区，提供 LEO/HW持久化定期 checkpoint 高水位容错处理磁盘故障，自动下线分区指标暴露副本健康状态关闭优雅 shutdown，保证一致性扩展性可插拔的 fetcher / selector协议支持支持 LeaderEpoch 查询、Leader 选举如果你是在阅读 Kafka 源码、调试副本问题、或开发自定义存储层，理解这些方法非常关键。需要更深入某一部分（比如或），可以继续提问！
2025-12-15 19:51:55
977
原创 Kafka副本管理核心机制全解析
它实现了 Kafka Broker 如何动态响应 Controller 指令，完成分区 Leader/Follower 角色切换，并维护副本同步、读写分离、限流、ISR 等核心机制。你可以把它看作 Kafka副本生命周期管理的中枢神经。“为什么 makeFollower 要先 truncate 日志？“ReplicaSelector 是怎么工作的？“HW 和 LEO 的关系是什么？欢迎继续提问！我可以深入某一部分详细解释。
2025-12-15 19:50:03
803
原创 深入解析Kafka Broker核心读写机制
机制说明根据客户端类型控制可见性（HW / LSO / LEO）使用 Purgatory 实现“条件满足再响应”（Produce/Fetch/Delete）细粒度监控（成功/失败请求、字节速率、消息速率）区分“预期异常”（如 NotLeader）和“系统异常”（如 IO 错误）支持副本同步限流（支持 KIP-392：消费者可从 Follower 读（需 ClientMetadata）你看到的这段代码，是 Kafka高可靠、高性能、多租户写入路径：安全追加 + 多级 ACK + 延迟确认读取路径。
2025-12-15 19:48:41
609
原创 Kafka日志迁移与查询机制解析
机制目的实现无停机、安全的日志迁移复用现有副本同步逻辑，保证一致性支持“预设目录”，适用于尚未创建的分区迁移期间暂停 Log Compaction，避免冲突提供可观测性，便于运维这两段代码体现了 Kafka面向运维友好、高可用、可扩展：通过“未来副本 + 异步复制”实现安全在线迁移：提供细粒度存储视图，支撑自动化运维它们共同构成了 Kafka存储层弹性调度的基础，是大规模集群管理的关键能力。如果你正在做磁盘扩容、性能调优、容量规划，这些接口非常实用。需要我进一步解释。
2025-12-15 19:47:32
935
原创 深入解析Kafka核心写入逻辑
机制目的先写 Leader，再异步同步 Follower保证写入高性能Purgatory（炼狱）模式统一处理“不能立即完成”的请求（Produce/Fetch/Delete）acks=-1触发等待实现强一致性语义HW（High Watermark）推进作为完成条件确保 ISR 副本都已持久化协调删除操作保证日志截断的一致性这段代码体现了 Kafka高吞吐 + 可配置一致性快速写 Leader→ 保证性能异步同步 Follower→ 保证可扩展性Purgatory 延迟机制。
2025-12-15 19:46:03
939
原创 Kafka副本管理核心：ReplicaManager揭秘
Apache Kafka Broker 端核心组件 它是 Kafka 实现 副本管理、ISR（In-Sync Replicas）维护、Leader/Follower 同步、日志存储协调 的中枢。下面我将从 整体定位、关键字段、核心机制、工作流程 四个维度，帮你系统性理解这段代码的含义和设计思想。每个 Kafka Broker 启动时都会创建一个 实例，它：：本 Broker 所有托管分区的容器。 是一个密封类（sealed trait），有三种状态：：正常在线：所在日志目录故障，分区不可用：
2025-12-15 19:43:36
1085
原创 Sentinel系统保护规则深度解析
继承包含上述 5 个阈值字段setter 方法中，≤ 0 的值表示“清除该阈值”支持动态更新（通过Sentinel 的 SystemRule 是一个“系统级熔断器”🛡️从全局视角保护应用，防止资源耗尽📈实时采集CPU、Load、QPS、RT、线程 5 大指标🧠引入 BBR 思想，避免误判🐳兼容容器环境，精准获取进程 CPU⚙️支持动态配置，无需重启💡最佳实践：在生产环境中，务必配置 SystemRule。
2025-12-12 15:50:43
850
原创 深入解析Sentinel熔断机制
特性说明基于滑动窗口统计使用LeapArray实现高精度、低内存的实时统计防误判机制避免低流量时因个别慢请求误熔断快速失败OPEN 状态下直接拒绝，不消耗资源自动恢复timeWindow后自动尝试恢复（HALF_OPEN）策略灵活支持 RT、异常比例、异常数三种主流熔断场景你看到的代码体现了 Sentinel现代熔断器“基于实时指标 + 滑动窗口 + 状态机” 实现自适应熔断更精准（比例 vs 绝对次数）更稳定（防抖：minRequestAmount）更智能（自动探测恢复）理解这些，你就能。
2025-12-12 15:31:05
793
原创 Sentinel熔断降级核心：DegradeSlot解析
Spi：Sentinel 的 SPI 扩展机制，表示这是一个可插拔的组件。：指定在责任链中的执行顺序（通常在限流之后、系统规则之前）。继承：说明它处理的是类型的统计节点（用于记录 QPS、响应时间等指标）。A：可以通过 SPI 替换实现，或使用动态加载规则。是 Sentinel 实现熔断降级入口检查：是否被熔断？是 → 快速失败出口上报：记录真实请求结果，驱动熔断状态机与规则解耦：通过和接口支持多种策略它体现了“故障快速失败 + 自动恢复”的容错设计理念，是微服务稳定性的重要保障。
2025-12-12 15:09:48
540
原创 深入解析Sentinel熔断器核心机制
graph TDA[请求到来] --> B{tryPass?B -- CLOSED --> C[放行]B -- OPEN & 超时 --> D[转 HALF_OPEN, 放行一次]B -- OPEN & 未超时 --> E[拒绝]B -- HALF_OPEN --> F[拒绝（已放行探测）]C --> G[执行业务]D --> GG --> H{完成 or 异常 or 被 block?H -- 正常完成 --> I[onRequestComplete: 更新统计]
2025-12-12 09:54:32
613
原创 Sentinel熔断降级规则管理详解
是 Sentinel 熔断功能的中枢控制器接收规则（静态或动态）；验证规则（确保参数合法）；生成熔断器（按策略创建实例）；提供运行时支持（Slot 通过获取熔断器执行检查）。理解它，就理解了 Sentinel 熔断机制的“配置到执行”全链路。如果你对的具体工作原理（如状态机、指标统计）感兴趣，也可以继续深入！
2025-12-11 18:59:38
905
原创 Sentinel黑白名单授权控制详解
resource：受保护的资源名（如 “/api/order”）limitApp：逗号分隔的调用方列表（如 “service-a,service-b”）strategy0（白名单）1（黑名单）limitApp中的值必须与返回的值完全一致（区分大小写、无空格）。这套机制实现了基于调用方身份的访问控制，核心思想：谁（origin）可以访问什么资源（resource）？通过插入处理链；通过管理规则；通过执行黑白名单判断；每个资源一条规则，支持白名单或黑名单。非常适合微服务内部调用鉴权。
2025-12-11 13:34:49
842
原创 Sentinel预热限流器深度解析
实现了一种带预热的匀速排队限流器阶段行为预热期请求间隔较长（QPS 低），随时间逐渐缩短稳定期请求按固定间隔（1/count 秒）通过超过速率请求排队等待，最多等，超时拒绝适用于对系统稳定性要求高、且能接受少量延迟的场景，如数据库写入、支付接口等。如果你有具体疑问（比如某行代码、为什么用slope怎么算等），欢迎继续问！源码如下@Override@Override} else {} else {} else {try {
2025-12-11 10:35:39
708
原创 Sentinel预热限流器深度解析
Sentinel的实现了智能的预热限流核心思想：令牌数代表系统空闲程度，越多表示系统越"冷"预热过程：从低QPS逐渐过渡到稳定QPS，避免冷启动冲击动态调整：根据系统负载自动调整允许的QPS生产就绪：已经在阿里巴巴大规模生产验证这种设计非常适合微服务架构和云原生环境，其中服务实例经常需要动态扩缩容，每个新实例都需要一定的预热时间才能达到最佳性能。
2025-12-11 10:30:42
407
原创 Sentinel预热限流：WarmUpController原理详解
用令牌桶的“剩余令牌数”表征系统冷热状态，动态调整 QPS 上限，实现平滑预热。✅冷启动保护：避免系统刚启动被打垮；✅自适应调整：根据实际 QPS 动态加令牌；✅线性模型：简单高效，易于理解和配置；✅非阻塞：超限直接拒绝，不阻塞线程。
2025-12-10 15:24:48
709
原创 Sentinel限流核心：ThrottlingController设计详解
精确控制时间槽 + 并发安全抢占 + 超时兜底”精确：自适应纳秒/毫秒，支持任意 QPS；安全：AtomicLong + 双重检查，避免并发错误；可靠：超时拒绝 + 回滚机制，保证 SLA；实用：虽阻塞，但在合适场景下无可替代。如果你在系统中需要严格匀速、不丢请求、可容忍等待的限流策略，是一个经过生产验证的优秀实现。以下为源码/*** ThrottlingController 是一个基于时间窗口的流量控制控制器。* 它通过限制单位时间内允许通过的请求数量来实现限流功能，
2025-12-10 14:48:58
561
原创 高精度时间戳优化方案解析
自适应：根据实际 QPS 动态启停高精度时间缓存；低侵入：对外 API 与完全一致；可观测：通过RecordLog输出状态切换日志，便于排查；资源友好：低负载时不占用额外 CPU，解决 Issue #1702 的“空转 CPU”问题；滑动窗口统计：精准计算 QPS，避免瞬时抖动误判。
2025-12-10 13:34:15
581
原创 Sentinel流量整形控制器全解析
控制器算法类型是否排队是否动态阈值适用场景快速失败❌ 否❌ 否通用限流、防刷、微服务保护匀速排队✅ 是（可超时）❌ 否平滑请求、DB/第三方 API 保护冷启动❌ 否✅ 是（从低到高）系统启动期、缓存预热冷启动 + 匀速✅ 是✅ 是高稳定性要求的核心服务Sentinel 的流量整形控制器提供了从简单拒绝到智能排队+预热快Default—— 超了就拒稳Throttling—— 匀速放行柔WarmUp—— 冷启保护稳+柔—— 二者兼得理解这些控制器，就能根据业务特性。
2025-12-10 13:20:23
976
原创 Sentinel三大流控策略全解析
策略判断依据适用场景是否依赖DIRECT当前资源自身流量（可按 origin 细分）通用限流、多租户隔离❌ 否RELATE另一个资源（refResource）的全局流量保护依赖、联动限流✅ 是CHAIN当前调用链的入口资源是否匹配 refResource链路级精细化控制✅ 是DIRECT→ “我自己不能太忙”RELATE→ “他太忙了，我得帮他挡一挡”CHAIN→ “只有从那条路来的人，我才管”理解这三种策略，就能在复杂微服务架构中实现精准、灵活、安全的流量治理。
2025-12-10 10:58:16
397
原创 Sentinel限流核心逻辑解析
graph TDA[开始] --> B{limitApp == origin?B -- 是 --> C{strategy == DIRECT?C -- 是 --> D[返回 originNode]C -- 否 --> E[调用 selectReferenceNode]B -- 否 --> F{limitApp == 'default'?F -- 是 --> G{strategy == DIRECT?G -- 是 --> H[返回 clusterNode]G -- 否 --> E。
2025-12-10 10:37:01
805
原创 Sentinel流控规则检查源码级分析
层面说明作用Sentinel 的流控核心检查器，决定请求是否被限流。核心逻辑遍历规则 → 选择统计节点 → 调用限流算法 → 决策放行/拒绝。关键抽象FlowRule（规则）、Node（统计）、Controller（算法）、Context（上下文）。扩展性支持本地/集群、多种策略、自定义 origin。容错集群失败可降级，避免系统不可用。💡一句话总结是 Sentinel 的“交通警察”，根据预设规则（限速牌）和实时车流量（Node 统计），决定是否让当前“车辆”（请求）通行。正确配置流控规则；
2025-12-10 10:02:22
926
Spring Boot整合Druid Demo项目代码包
2020-03-03
simpe-demo-diffdb.7z
2020-11-10
动态多数据源示例代码
2020-11-04
Spring Boot中整合MyBatis
2020-04-01
编程式创建Aspect代理源码
2020-05-27
Spring Boot中整合MyBatis
2020-04-01
springcloud.zip
2020-03-15
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人