CharlesYuangc的博客

原创 SpringBoot4 MyBatisPlus JSON 类型

本文基于SpringBoot4与MyBatisPlus，实现JSON字段的自动映射。通过创建ClientInfo实体类，将TBClient.info字段由String改为ClientInfo类型，并配合@TableName注解调整，成功实现数据库JSON字符串与对象的双向映射，测试验证结果正常。

原创 【10】SpringBoot4 MyBatisPlus 枚举类型（enum）

本文基于SpringBoot 4.0.8与MyBatis-Plus 3.5.17，介绍如何在项目中使用枚举类型（enum）处理数据库字段（如用户状态）。通过定义枚举类并配置MyBatis-Plus的枚举处理器，实现数据库TINYINT类型与Java枚举的自动映射，提升代码可读性与安全性。结合Druid数据源与MySQL 8.4.11，完成建表、实体类生成及枚举配置，实现高效、规范的数据操作。

原创 【09】SpringBoot4 MyBatisPlus 增删改查（CRUD）

本文基于SpringBoot4与MyBatisPlus，实现增删改查（CRUD）功能。通过添加spring-boot-starter-test依赖，编写测试类进行数据插入、批量插入及更新操作，演示了如何使用save()、saveBatch()和update()方法完成对TbClient实体的CRUD操作，提升开发效率与代码可维护性。

原创 【08】SpringBoot4 MyBatisPlus 代码自动生成

本文基于SpringBoot 4.0.8与MyBatis-Plus 3.5.17，结合JDK 21、MySQL 8.4.11及IDEA 2026.2，介绍如何快速搭建工程并实现代码自动生成。通过配置application.yml和pom.xml，集成Druid数据源与MyBatis-Plus，定义表结构并利用代码生成器批量生成实体类、Mapper、Service等代码，提升开发效率。

原创 《【MySQL分布式】（开篇）MySQL 主从复制》

MySQL主从复制的核心是基于Binlog的异步复制机制：主库将数据变更记录到Binlog，从库通过Replication Receiver线程获取并写入本地Relay Log，再由Applier线程重放执行，实现数据同步。与InnoDB的Redo Log不同，Binlog属于Server层，用于复制和恢复。推荐使用Row模式，因其能精确记录行变化，保证一致性。关键组件包括Master的Binlog Dump Thread、从库的Receiver和Applier线程，整体流程为“Binlog → 网络传输

原创 K8S 资源菜单

原创 Kubernetes 命令式对象配置详解：使用 YAML 管理 Kubernetes 资源

本文详解Kubernetes命令式对象配置，通过YAML文件管理资源。相较于直接在命令中指定参数，使用YAML可清晰定义Namespace、Pod等资源，包含apiVersion、kind、metadata及spec等核心字段。YAML支持多资源定义（以---分隔），便于维护与复用。通过kubectl create -f命令，实现资源的高效创建与管理，提升复杂配置的可读性与可维护性。

原创 Kubernetes 命令式对象管理详解：kubectl 常用命令与资源操作

本文详解Kubernetes命令式对象管理，重点介绍kubectl常用命令与资源操作。通过get、create、delete等命令实现对Pod、Deployment、Service等资源的增删查改，结合-o yaml、-o wide等参数获取详细信息。强调使用资源缩写（如po、svc）提升效率，并说明describe命令在排查故障时对事件（Events）的监控价值。适用于快速查询、调试及临时运维场景。

原创 Kubernetes 资源管理方式详解：命令式与声明式管理

Kubernetes 资源管理分为命令式对象管理、命令式对象配置和声明式对象配置三种方式。命令式直接通过 kubectl 指令操作，简单快捷，适合临时任务；命令式对象配置使用 YAML 文件定义资源，便于保存与共享；声明式对象配置（如 kubectl apply）则关注资源最终状态，由 Kubernetes 自动判断创建或更新，实现自动化运维。声明式是主流推荐方式，支持版本控制、可重复部署，契合 GitOps 理念，是现代 Kubernetes 管理的核心。

原创 Kubernetes 资源管理入门：理解 Pod、控制器、Service 与存储的关系

Kubernetes 通过资源抽象实现应用高效管理。Pod 是最小运行单元，承载容器；控制器（如 Deployment）确保应用持续运行并自动恢复；Service 提供稳定访问入口，屏蔽 Pod IP 变化；存储机制（如 PV/PVC）实现数据持久化。四者协同，解决应用部署、高可用、访问与数据持久化等核心问题，体现 Kubernetes “声明式运维” 的设计思想。

原创 Seata——把分布式事务理论落到 Java 微服务实践

Seata通过AT模式实现分布式事务，核心是“自动补偿”。在第一阶段，事务执行时记录数据快照（Before/After Image）至undo_log表，本地事务立即提交，释放锁，提升性能。第二阶段若全局事务成功则无需操作；失败时由TC协调各RM根据undo_log回滚，实现最终一致性。相比XA，AT减少锁持有时间，降低业务侵入，兼顾性能与一致性，是Seata最主流的事务模式。

原创 Kubernetes 核心概念：集群架构、核心组件与资源对象

Kubernetes 通过控制节点（Master）与工作节点（Node）构成集群架构，核心组件包括 API Server、Scheduler、Controller Manager 和 Etcd，分别负责接口接入、任务调度、状态维护与数据存储。Node 上的 Kubelet 和 Kube Proxy 负责执行任务与网络转发。应用以 Pod 为最小单位运行，Pod 内容器共享网络与存储，实现高效编排。整个流程从请求提交到 Pod 创建、调度、启动并对外提供服务，体现了 Kubernetes 的自动化与弹性管理能

原创 幂等、重试、去重与状态机

简单理解：同一个业务请求执行一次和执行多次，最终业务结果应该一致。支付请求：扣款 100不能继续扣款返回第一次执行的结果。

原创 《MySQL 数据库分布式是怎么做的》

MySQL分布式通过分库分表+主从复制+中间件路由实现，解决容量、并发、高可用与一致性问题。核心是水平分片（如按user_id取模）分散数据，利用ShardingSphere等中间件路由SQL至对应库。读写分离缓解压力，MySQL InnoDB Cluster保障高可用。跨库查询、JOIN与事务需谨慎设计，常采用最终一致性与数据共置策略。ID生成改用Snowflake等全局唯一方案，扩容时需迁移数据并双写校验。

原创 MQ 最终一致性、本地消息表与 Transactional Outbox

本文详解MQ最终一致性解决方案，核心为本地消息表与Transactional Outbox模式。针对“数据库与MQ不一致”问题，提出将消息写入与业务数据同库的outbox表，利用本地事务保证一致性。通过后台任务定时轮询outbox表，发送消息并更新状态，结合指数退避重试机制保障可靠性。同时强调消费者必须幂等，推荐使用唯一索引实现高效幂等控制。该方案避免了分布式事务复杂性，是微服务中实现最终一致性的实用路径。

原创 Saga——长事务与补偿事务

Saga 通过“先提交、失败后补偿”的方式解决长事务问题，适用于跨系统、流程复杂的场景。与 TCC 的“预留-确认”不同，Saga 不加锁，提升性能，但需处理最终一致性及补偿失败风险。补偿操作必须幂等、可逆，并具备业务语义性。实现方式分为事件编排（Choreography）与中心编排（Orchestration），前者松耦合但流程难追踪，后者可控性强。关键在于设计可回滚的业务逻辑，配合日志、重试与人工兜底机制，确保系统最终一致。

原创 TCC——业务层面的分布式事务

TCC（Try-Confirm-Cancel）是一种业务层面的分布式事务方案，通过在业务层实现资源预留、确认与释放，避免2PC中长时间持有数据库锁的问题。其核心思想是：Try阶段预留资源并提交本地事务，Confirm/Cancel阶段完成最终操作或回滚。相比2PC，TCC提升并发性能，但带来强业务侵入性，需解决幂等、空回滚、悬挂三大难题。关键在于通过事务ID实现幂等控制，防止重复执行；通过状态校验避免空回滚；通过严格流程设计防止悬挂。适用于高并发核心交易场景，是实现高效分布式事务的重要实践。

原创 2PC / XA——强一致分布式事务的基础模型

本文深入解析2PC/XA协议，揭示强一致分布式事务的核心机制。通过转账场景说明单阶段提交的不一致风险，引出两阶段提交的必要性：第一阶段Prepare确保所有参与者就绪并锁定资源，第二阶段统一Commit或Rollback。重点剖析Prepare的本质——事务已执行但未提交，资源持续锁定导致性能瓶颈；协调者故障引发阻塞，网络异常产生不确定状态。虽一致性强，但存在同步阻塞、资源占用久等缺陷。最后阐明2PC是协议思想，XA是其标准化接口，如MySQL中通过XA START/END/PREPARE/COMMIT实现

原创 ACID、CAP、BASE，以及强一致性和最终一致性

本文系统解析ACID、CAP、BASE理论，揭示分布式系统中一致性与可用性的权衡。ACID保障单机事务的原子性、一致性、隔离性与持久性，但难以应对跨服务分布式场景；CAP指出网络分区下无法同时满足一致性（C）、可用性（A）与分区容错（P），必须在C与A间取舍；由此衍生出CP（强一致）与AP（高可用）系统。为降低复杂度，互联网普遍采用BASE模型——基本可用、软状态、最终一致性，允许短暂不一致，通过MQ、Saga等机制实现业务最终一致。实践中，应根据业务敏感度区分强一致与最终一致场景，如支付、库存需强一致，积

原创 从本地事务到分布式事务

分布式事务旨在解决跨服务、跨数据库场景下的数据一致性问题。本地事务依赖ACID特性，仅能保证单机数据一致；而微服务架构下，各服务独立部署，事务无法自动回滚。网络不可靠导致“结果不确定性”——超时不等于失败，重试可能引发重复执行，必须通过幂等性保障。分布式事务分为强一致（如2PC、Seata）与最终一致（如MQ、Saga）两条路径，核心在于应对部分成功、补偿机制与异常恢复。理解“超时不等于失败”“重试需幂等”“最终一致性”是掌握分布式事务的关键。

原创 Redis数据结构入门：String、Hash、List、Set、SortedSet全面认识

本文系统介绍Redis核心数据结构：String（字符串）、Hash（哈希）、List（列表）、Set（集合）和SortedSet（有序集合），阐述其特点与典型应用场景。String适用于缓存、计数器与验证码；Hash适合存储对象信息，支持字段级操作；List实现队列与栈，支持两端增删；Set用于去重与共同好友分析；SortedSet则支撑排行榜等排序需求。掌握这些结构是高效使用Redis解决实际业务问题的基础。

原创 【第二章】Redis基础入门：Redis是什么、为什么快以及核心特性详解

Redis 是基于内存的高性能 Key-Value NoSQL 数据库，支持多种数据结构如 String、Hash、List 等，因其内存存储、高效数据结构、IO 多路复用及单线程事件模型而具备低延迟与高吞吐。尽管核心命令处理为单线程以避免锁竞争，但可通过 IO 线程提升并发能力。数据持久化通过 RDB 快照和 AOF 日志实现，保障宕机后数据不丢失。广泛应用于缓存、计数器、排行榜等场景。

原创 【第一章】NoSQL基础入门：关系型数据库与非关系型数据库的核心区别

NoSQL（Not Only SQL）是区别于传统关系型数据库的一类非结构化数据存储方案，核心差异在于：数据结构更灵活（弱化Schema）、弱化表间关联（减少JOIN）、查询方式多样（无统一语言）、事务支持各异（部分支持ACID）。相比关系型数据库强调结构化、强一致性与复杂关联，NoSQL更注重高性能、可扩展性与灵活的数据模型，适用于大规模、高并发场景。

原创 JVM字节码基础：如何正确查看 Class 文件及其整体结构

本文介绍了JVM字节码基础，重点讲解如何正确查看和分析.class文件。由于.class是二进制文件，直接用文本编辑器打开会乱码，需通过十六进制或专用工具如jclasslib、javap进行解析。jclasslib提供图形化界面，直观展示类信息、常量池、方法等结构；javap则为JDK自带命令行工具，可反汇编字节码指令。文中还强调了魔数CAFEBABE的作用——用于验证Class文件合法性，并解释了版本号、访问标志等基础信息的含义，帮助开发者深入理解Class文件的整体结构与JVM执行机制。

原创 JVM基础：Java虚拟机的组成与完整运行流程

本文系统介绍了JVM的组成与运行流程。JVM核心由类加载器、运行时数据区、执行引擎和本地接口构成。程序从.class文件开始，经类加载器加载、连接与初始化后进入运行时数据区，包括程序计数器、虚拟机栈、堆、方法区和本地方法栈。执行引擎负责解释或编译字节码为机器指令，结合解释器与JIT即时编译器提升性能。垃圾回收器（GC）自动管理堆内存，实现对象生命周期的自动化清理。整个流程体现了JVM在跨平台执行、内存管理与性能优化方面的核心能力。

原创 JVM基础入门：从运行机制到主流虚拟机实现

JVM 的全称是，中文通常称为Java 虚拟机。加载并运行 Java 字节码文件。Java 程序并不是直接由操作系统执行的，而是需要经过编译和 JVM 运行两个阶段。Java 源代码↓javac 编译↓.class 字节码文件↓JVM 加载并执行↓机器指令↓CPU 执行例如，我们编写一个这个.class文件并不是 Windows、Linux 或 macOS 能够直接执行的机器指令，而是一套统一格式的Java 字节码指令。真正负责读取并执行这些字节码指令的，就是 JVM。

原创 《Docker 镜像构建详解：docker commit、Dockerfile 与 docker build 实战》

本文详解Docker镜像构建的两种方式：docker commit与Dockerfile+docker build。前者适合快速实验，但难以追溯构建过程；后者通过可复现、可版本控制的脚本实现自动化构建，是生产环境推荐方案。文章结合Tomcat与Nginx实战案例，演示了镜像创建、标签打标、推送Docker Hub全流程，并深入解析Dockerfile常用指令及分层构建机制，强调其在持续集成中的核心价值。

原创 《MySQL 用户管理详解：CREATE USER、修改密码、密码策略、认证插件与账户锁定》

本文详解MySQL用户管理，涵盖创建用户、修改密码、认证插件选择、密码策略与账户锁定机制。强调用户由用户名@主机唯一确定，权限需通过GRANT赋予，建议避免使用root账号，优先创建专用账号并限制连接来源。重点介绍CREATE USER、ALTER USER、DROP USER等命令，推荐使用SHOW GRANTS查看权限，并说明mysql.user系统表的作用及安全配置要点，提升数据库安全性与运维规范性。

原创 《MySQL 在线 DDL 实战：gh-ost 安装、压测、迁移与 Cut-over 全流程》

本文详细演示了在MySQL生产环境中使用gh-ost实现在线DDL变更的全流程：从安装部署、环境检查、创建专用账号，到执行noop预检、正式迁移、压测观察及延迟cut-over。重点强调了binlog配置、权限管理与安全实践，通过单机测试环境完整呈现数据复制、binlog同步与表结构切换过程，确保大表变更时业务零中断，具备极强实战指导意义。

原创 《MySQL 在线 DDL 神器 gh-ost：原理、工作流程、Binlog 同步与生产实践详解》

gh-ost 是 GitHub 开源的 MySQL 在线表结构变更工具，通过“影子表”（Ghost Table）机制实现无锁 DDL。它不依赖 Trigger，而是读取 Binlog 同步数据变化，分批复制历史数据并实时同步新写入，确保原表与影子表一致。整个过程避免大表重建带来的锁表和性能瓶颈，适用于高并发、大规模生产环境，显著降低业务影响。

原创 《MySQL InnoDB Buffer Pool 详解（二）：Free、Clean、Dirty 三种缓冲页状态与三大链表》

<think>我们只需要根据用户要求生成摘要，≤150字。内容是关于MySQL InnoDB Buffer Pool的页面状态和链表。摘要应概括核心：Buffer Pool按页管理，三种状态Free/Clean/Dirty，以及三大链表（Free、LRU、Flush）的作用。注意字数。</think>本文详解InnoDB Buffer Pool按页管理机制，介绍Free、Clean、Dirty三种缓冲页状态及转换关系，并阐述Free List、LRU List、Flush List三大链表如何高效管理页面，

原创 《MySQL InnoDB 内存结构详解：Buffer Pool、Log Buffer 与线程级缓冲区》

<think>我们根据用户要求，需要根据内容生成≤150字的摘要。内容关于MySQL InnoDB内存结构，特别是Buffer Pool、Log Buffer和线程级缓冲区。摘要需要涵盖核心要点：内存对数据库性能的重要性，InnoDB的内存结构包括Buffer Pool缓存数据和索引，以页为单位管理，以及redo log buffer等。用户要求“≤150字”，需要简洁。 总结关键点：本文介绍MySQL InnoDB内存结构，强调内存减少磁盘IO；核心是Buffer Pool，缓存数据页和索引页，以16KB

原创 《Docker 架构详解：Client、Daemon、Image、Container 与 Registry 的关系》

学习 Docker 时，除了要知道镜像和容器是什么，更重要的是理解 Docker 各个组件之间是如何协同工作的。这些命令并不是 Docker 客户端自己完成所有操作。Docker 本质上采用的是一种Client-Server（客户端/服务端）架构。用户通过 Docker Client 发送指令，Docker Daemon 接收并执行指令，最终完成镜像下载、镜像构建、容器创建、容器运行等操作。

原创 《深入理解 MySQL InnoDB：表空间、Page、Redo Log、Undo、Binlog 与慢查询日志一次讲清楚》

InnoDB 是 MySQL 最常用、也是默认的事务型存储引擎。但一条数据真正落到磁盘后，并不是简单地“保存到一个表文件里”。表空间↓段↓区↓页↓行.ibd 数据文件redo logundo logbinlogerror logrelay logPID 文件Socket 文件这些组件共同完成数据存储、事务恢复、主从复制、故障排查以及 SQL 性能分析。本文就从底层存储结构开始，系统梳理 InnoDB 的核心组成。更重要的是理解 SQL 背后发生了什么。

原创 《MySQL 体系架构详解：Server 层、SQL 执行流程与 InnoDB、MyISAM、MEMORY 存储引擎》

但一条 SQL 从客户端发送到 MySQL 后，并不是直接去磁盘读取数据。MySQL 内部需要经历连接管理、SQL 解析、查询优化、执行计划选择、存储引擎访问等多个过程。Server 层负责连接管理、SQL 解析、查询优化和执行协调；存储引擎层负责数据和索引的实际存储与读取。可以先建立这样一个整体认识：理解这套架构，是继续学习 MySQL 索引、事务、锁、MVCC、SQL 优化和 InnoDB 原理的重要基础。即存储引擎。数据怎么保存？索引怎么组织？数据怎么读取？事务怎么实现？锁怎么实现？

原创 MySQL ORDER BY 性能优化详解：Using filesort、联合索引、ASC/DESC 与覆盖索引

在 MySQL 中，ORDER BY是非常常见的排序操作。SQL 本身很简单，但当数据量越来越大时，排序可能成为查询性能瓶颈。MySQL 对ORDER BY利用索引本身的有序性返回结果无法利用索引顺序，需要额外执行 filesort 排序因此，优化ORDER BY尽可能让 MySQL 利用索引本身的顺序完成排序，减少额外的 filesort。本文围绕 MySQLORDER BY到底是什么意思又是什么意思为什么联合索引可以优化排序为什么可以走索引，而可能不行。

原创 MySQL 主键优化详解：InnoDB 页分裂、页合并与主键设计原则

InnoDB 使用“页”作为磁盘管理和数据组织的重要单位。一个数据页并不是只能容纳一条记录，而是可以存储多行数据。页中的记录按照索引键顺序排列。251020253040如果当前数据页还有足够空间，那么直接插入即可。但如果当前数据页已经没有足够空间，InnoDB 就可能需要申请新的数据页，将原页面中的一部分记录移动到新页中，然后重新调整索引结构。这就是页分裂。原数据页：↓ 插入 25空间不足↓页面 A 页面 B因此，页分裂本质上是为了在保持索引有序的同时，为新的记录腾出空间。

原创 MySQL SQL 优化之 LIMIT 深度分页优化：覆盖索引 + 子查询

所谓覆盖索引（Covering Index），可以简单理解为：查询所需要的字段都能够直接从索引中获取，不需要再回到数据行中读取其他字段。SELECT idid而id本身就是主键索引中的内容，因此可以直接利用索引完成这一阶段的分页查询。但这里又会出现一个问题。商品名称价格图片品牌分类...因此，还需要进行第二步查询。进行分页时，随着offset不断增大，就会出现明显的深度分页性能问题。SELECT *

原创 MySQL 8.4 MGR 详解：从零理解 MySQL Group Replication 高可用架构

MySQL 组复制例如：关系。GroupMember这些成员之间会进行通信。成员管理故障检测数据复制事务认证冲突检测Primary 选举成员恢复MGR 是 MySQL 官方提供的组复制技术，它让多台 MySQL Server 组成一个复制组，通过组通信、事务复制、故障检测、成员管理和 Primary 选举等机制，提高数据库的高可用能力。事务认证 / 冲突检测这是理解 MGR 非常关键的机制。

原创 MySQL 8.4 LTS：会话与线程的 1:1 关系，以及如何与操作系统线程绑定排查

文章摘要 MySQL 8.4 LTS采用"one-thread-per-connection"模式，每个客户端连接对应一个独立的前台线程（会话线程）。通过performance_schema.threads表可清晰追踪三层ID关系：MySQL内部线程ID(THREAD_ID)、会话ID(PROCESSLIST_ID)和操作系统线程ID(THREAD_OS_ID)。8.4版本将8.0的OS_THREAD_ID列重命名为THREAD_OS_ID，该值对应Linux的LWP线程号，可通过ps -T命令查看。实际排