这是一个基于 Hexo + Markdown + GitHub Pages 的个人博客方案，部署成本低、维护简单、主题生态丰富。 在真正动手前，先来看一下整个系统是如何协作的： Hexo 是一个 静态博客生成器，你只负责写 Markdown 文件，Hexo 会把它们转换成 HTML 页面。 GitHub Pages 是一个 免费静态网站托管服务，负责把生成好的网页放到公网。 主题（如本网站使用的

@Transactional 注解无疑是我们处理数据库事务最得力的助手。然而，在复杂的业务链路下，仅仅知道“加上注解就能回滚”是远远不够的，我们还需要掌握事务的传播行为以及各种隐蔽的失效场景。 @Transactional 是如何工作的要理解事务为何生效、又为何失效，首先必须明白 @Transactional 是如何工作的。 @Transactional 注解的实现高度依赖于 Spring AOP

Redis 有五大基础数据类型（String、List、Hash、Set、ZSet），antirez 在设计时做了十分精准的抽象： 单一标量 对应 String 线性序列 对应 List 键值映射 对应 Hash 无序且不重复的集合 对应 Set 带权重的排序集合 对应 ZSet 这五种类型是“正交”的（互相不可替代），且构成了图灵完备级别的数据表达能力，能够映射 99% 的业务数据模型。 R

TCP 与 UDP想象你正在开发一个实时对战游戏。当玩家按下“开火”键时，数据必须毫秒级到达服务器。如果网络稍微抖动，你希望发生什么？ 游戏卡住，等待 2 秒，直到这个“开火”指令确认送达，然后画面瞬间快进。 丢弃这个指令，画面保持流畅，玩家可能只是觉得刚才没打中。 显然后者体验更好。 但在另一个场景，当你从银行下载电子账单时，如果底层发生丢包导致文件损坏或解析出极度荒谬的金额，这是绝对不可接

从计算机科学的视角来看，数据库管理系统本质上是一个维护 ACID 特性的状态机。在单线程模型下，状态转换是确定的。然而，一旦引入并发，系统便陷入了混乱。 InnoDB 存储引擎的并发模块主要目的就是 在并发吞吐量与数据一致性之间寻找平衡。这是一个零和博弈——隔离性越高，并发度就越低。 并发带来的问题当多个事务同时操作同一份数据时，如果没有合适的隔离机制，可能会出现以下三种一致性问题： 脏读：一个

MySQL 最本质的特征在于其 逻辑架构与存储实现的完全解耦。这种分层架构决定了 MySQL 的生态灵活性，但也引出了独有的性能挑战与架构权衡。 分层MySQL 的 宏观架构自上而下严格划分为四层，层级间通过标准的 API 接口进行交互。 整体执行流程：客户端请求 → 网络连接层处理 → Server 层解析/优化/执行 → 存储引擎层做数据读写 → 文件系统层落地磁盘。 各层

我们的故事从一个简单的 UPDATE 事务开始。 为了在 极致的性能（内存） 和 可靠（磁盘） 之间找到完美的平衡，InnoDB 内部有着一套复杂且环环相扣的机制。 到达引擎层之前还有很多步骤，本篇不涉及 Buffer PoolBuffer Pool 是 InnoDB 在 内存中开辟的一块区域，用来 缓存磁盘上的数据页和索引页。它是 InnoDB 性能的基石。 为什么要有 Buffer Poo

ThreadLocal 是 一个用于存储线程私有变量的工具，它 为每个线程维护独立的变量副本，实现线程间数据隔离，避免了多线程并发访问的安全问题；还可在同一线程内完成上下文参数的隐式透传，避免方法间显式传参。 在并发编程中，我们习惯于讨论如何用“锁”来控制对共享资源的访问。但 ThreadLocal 提供了一种完全不同的思路：与其争抢，不如隔离。 ThreadLocal 的 设计初衷并非为了解决多

在探讨 Redis 的并发模型前，必须明确其所处的物理环境：这是一个 纯内存数据库。 现代 CPU 访问一次一级缓存（L1 Cache）的时间约 1 纳秒，访问一次主存（RAM）的时间约 100 纳秒。而一次同城机房的千兆网络 RTT（往返延迟）大约在 500 微秒（500,000 纳秒）。 这意味着，CPU 计算和内存读写的速度，与网络报文到达网卡的速度之间，存在数千倍的鸿沟。 因此对于 Red

在单体应用时代，事务（Transaction）是数据库送给开发者最昂贵的礼物。你只需要由 Spring 加上 @Transactional 注解，数据库就会保证：要么全做，要么全不做。 但当你把系统从单体拆分成微服务，或者引入了多个数据库时，这个“魔法”失效了。 假设你在开发一个电商系统。用户点击“下单”按钮，后台需要发生两个动作： 订单服务：在订单库创建一条订单记录。 库存服务：在库存库扣减一