把「单机单体」演进到「分布式 + 微服务 + 高并发」的能力地图：这里记录拆分、协作、容错与性能的系统化方法，以及落地用的组件、配置与代码。
一台机器、一份代码库、一个数据库，在业务和团队长到一定规模后会同时撞上三类墙：
Gavin James 的个人技术知识库，把日常学习与工程实践中散落的知识，整理成一套可持续维护、可检索的体系。
本站是一个以 Java 后端为主线、向外延伸到数据库、框架、架构、前端与研发工具的个人知识库。内容以「专题正文 + 可运行示例」为主，目标不是搬运文档，而是把每个知识点讲成能直接用于工作的形态。
| 分区 | 覆盖内容 |
|---|---|
| Java | 基础、集合、并发、IO、JVM、新特性 |
| 数据库 | 数据库原理、SQL、MySQL、Redis、MongoDB、Elasticsearch |
| 开发 | 开发理论、规范、设计模式、重构、质量保障、算法与数据结构 |
| 框架 | Spring 生态（IoC/AOP/MVC/Boot/Cloud/Security）、ORM、消息队列、Web 容器 |
| 架构 | 分布式、微服务、高并发 |
| 前端 | HTML、CSS、JavaScript、Vue、React |
| 工具 | Git、Maven、Gradle、Linux、Docker、Jenkins、IDE |
本分区收录 Java 后端日常离不开的框架与中间件：Spring 生态负责「代码怎么组织」（IoC/AOP/事务/Web/微服务），ORM 负责「数据怎么读写」（MyBatis / JPA），消息队列负责「系统怎么解耦与削峰」（Kafka / RabbitMQ / RocketMQ），Web 与网络负责「请求与连接怎么被处理」（Tomcat / Netty）。四组内容互相咬合：一个 HTTP 请求往往由 Tomcat 接住、经 Spring MVC 分发、用 MyBatis 落库，异步环节再交给 MQ。
一套为 Java 后端工程师设计的前端补齐路线：目标不是「会造轮子」，而是能看懂前端工程、改得动页面、联得通 API。
在后端主导的系统里，页面往往是联调、排障、演示的第一现场。后端同学即便不写复杂交互，也几乎一定会遇到：
name 与后端 DTO 字段名不一致；从写下第一行代码，到它稳定跑在生产环境，中间隔着一整条工具链：版本控制、构建、IDE、操作系统、容器、持续集成。这一区讲的是这些工具「为什么这么设计、关键机制在哪、常见坑怎么绕」，目标是遇到问题能定位、能动手，而不是只会背命令。
一个后端工程师的日常，大致会跑过这样一条链路：
每个环节都既是「效率放大器」，也是「故障高发区」：Git 用错会丢代码，Maven 依赖冲突会让程序在运行期才炸，Docker 镜像写得不合理会让部署慢一倍，CI 没配好会把带病代码放进主干。理解原理，是为了在这些时刻能快速判断「是谁的问题」。
注意 id 是框中显示的内容。
也可以在不同于 id 的框中设置文本。 如果多次这样做，它将是为将使用的节点找到的最后一个文本。 此外，如果您稍后为节点定义边，则可以省略文本定义。 渲染框时将使用先前定义的那个。
This statement declares the direction of the Flowchart.
This declares the flowchart is oriented from top to bottom (TD or TB).
「一致性、可用性、分区容错三选二」是被误传最广的口号。CAP 真正说的是：当网络分区发生时，你必须在一致性和可用性之间二选一。而 BASE 是大规模系统给出的工程退让。
| 字母 | 全称 | 含义 |
|---|---|---|
| C | Consistency（一致性） | 所有节点在同一时刻看到同一份最新数据，等价于线性一致性 |
| A | Availability（可用性） | 每个到达非故障节点的请求，都能得到非错误的响应（不保证是最新数据） |
| P | Partition tolerance（分区容错） | 网络分区（节点之间消息丢失或延迟）时系统仍能继续运行 |
单机的
synchronized/ReentrantLock只管住一个 JVM。当同一段临界逻辑跑在多个实例上（定时任务防重、库存扣减兜底、唯一资源初始化），就需要一把跨进程的分布式锁。
先泼一盆冷水：能用更简单方案解决的，就不要上分布式锁。
| 场景 | 是否有更简方案 |
|---|---|
| 订单防重复创建 | 有：数据库唯一索引 + 幂等，胜过加锁 |
| 库存扣减 | 有：UPDATE stock = stock - 1 WHERE stock >= 1 原子扣减 |
| 定时任务多实例防重 | 视情况：可走「抢占式」锁或选主 |
| 唯一资源初始化（建表、刷缓存） | 分布式锁合适 |
| 复杂临界区（跨多步有副作用） | 分布式锁合适，但要配幂等 |
一个业务动作要同时写多个库/多个服务时，单机 ACID 失效了。分布式事务就是要在「跨节点」的前提下，尽量靠近「要么全成、要么全败」的语义——同时付出性能与复杂度的代价。
很多所谓的「分布式事务」其实是设计问题的症状。动手前先自问：
数据分库分表后，单库自增主键不再全局唯一。分布式 ID 要在一组机器上，生成全局唯一、尽量趋势递增、高性能、高可用的编号。
先明确需求，再谈方案。一个「合格」的分布式 ID 通常要满足：
| 要求 | 说明 | 是否必需 |
|---|---|---|
| 全局唯一 | 跨库、跨表、跨服务都不重复 | 必需 |
| 趋势递增 | 新 ID 大体大于旧 ID，利于 B+ 树索引插入，避免页分裂 | 重要 |
| 高性能 | 单机每秒生成成千上万个，不成为瓶颈 | 重要 |
| 高可用 | 发号服务不能是单点 | 重要 |
| 信息安全 | 不可被轻易猜测、推断业务量 | 视场景 |
| 语义信息 | 含时间、机器等，便于排查 | 加分项 |