分库分表 - ShardingSphere 入门指南与分片实战

在互联网应用快速发展的今天，数据量的爆炸式增长和并发访问的急剧上升给传统数据库架构带来了巨大挑战。本文将带您了解数据库架构的演进之路，深入探讨读写分离和分库分表技术如何解决海量数据场景下的性能瓶颈。

## 项目架构的演进

### 单一架构

在微服务时代出现之前，大部分项目都是一个单体应用架构，像一个 WAR 包包含所有功能的应用程序，从客户端操作传输到服务端，在写入单体数据库中

![22.jpg](https://blog.liushigong.cn/static/img/2302a17fd73a58386f30b491d2829089.22.webp)

这个阶段是公司发展的早期阶段，系统架构如上图所示。在项目运行初期，各类功能的表都在同一个数据库中，每个表都包含了大量的字段。在用户量比较少，访问量也比较少的时候，单库单表不存在问题。

这个阶段一般是属于业务规模不是很大的公司使用，因为机器都是单台的话，随着我们业务规模的增长，慢慢的我们的网站就会出现一些瓶颈和隐患问题

### 读写分离

随着访问量的继续不断增加，单台应用服务器从性能上和可用性上已经无法满足我们的需求。所以我们通过增加应用服务器的方式来将服务器集群化。

![24.jpg](https://blog.liushigong.cn/static/img/a2cc60ebba2c89046c7cb0391dabd51f.24.webp)

采用应用服务器高可用集群的架构之后，应用层性能也随之增加，但数据库的负载也在逐渐增大，随着访问量的提高，所有的压力都将集中在数据库这一层。

![25.jpg](https://blog.liushigong.cn/static/img/c7c8feee823ed254eb1c5ba362e5acb5.25.webp)

随着业务量的增长，数据库的负载也在逐渐增大，那如何去提高数据库层面的性能呢？既然应用层可以做集群化，那数据库是不是也可以多台呢？答案是当然可以，我们的数据库主要是通过 **主从复制 + 读写分离** 进行实现的，在这种架构中：

* 主库：负责所有写操作 + 部分读操作
* 从库：只能处理读操作，数据通过复制从主库同步

![26.jpg](https://blog.liushigong.cn/static/img/b87d3b89ddde78f56453d506d5760da3.26.webp)

读写分离的核心思想是将数据库的读操作和写操作分离到不同的服务器上。通常，写操作集中在主库（Master），读操作分散到一个或多个从库（Slave）。这样做的原因主要有以下几点：

* **提升读性能**：在大多数应用中，读操作的比例远高于写操作。通过增加多个从库来处理读请求，可以有效地分摊读负载，提升系统的整体读性能。
* **避免读写冲突**：当读写都在同一个数据库实例上时，写操作可能会对读操作造成阻塞（例如，写锁会阻塞读锁）。将读写分离后，读操作可以在从库上执行，从而避免受到主库写操作的影响。
* **提高可用性**：当主库出现故障时，可以快速切换到从库，保证系统的可用性。同时，从库也可以作为备份，防止数据丢失。
* **降低主库压力**：通过将读请求分流到从库，主库可以更专注于处理写请求，从而提升写操作的性能。

然而，读写分离也存在一些挑战，比如主从同步延迟问题，这可能导致从库读取到旧数据。因此，需要根据业务场景选择是否采用读写分离，以及如何分离（例如，强一致性读仍然走主库）。

为什么不能所有节点都读写？

其实主要原因是 **数据一致性问题**：

```
sql

-- 假设有两个节点都可读写
节点A: INSERT INTO users (id, name) VALUES (1, '张三');
-- 此时节点B还不知道这个数据

节点B: SELECT * FROM users WHERE id = 1;
-- 可能会返回"找不到记录"

节点B: INSERT INTO users (id, name) VALUES (1, '李四');
```

这就会导致主键冲突！数据不一致！

除了 **主从复制 + 读写分离**，那能开启多主节点吗？答案是可以的，MySQL 官方也支持此模式

```
sql

-- MySQL Group Replication 多主模式
-- 所有节点都可读写，但有限制：
SET GLOBAL group_replication_single_primary_mode=OFF;  -- 启用多主模式
```

但需要注意会存在以下几点问题：

1. 可能产生写冲突
2. 性能受限于最慢节点
3. 网络分区时可能不可用

使用 **主从复制+读写分离** 一定程度上可以解决问题，但是随着用户量的增加、访问量的增加、数据量的增加依然会带来大量的问题.

提示

MySQL读写分离后，只能有一台节点（主库）能写入，这是由MySQL的复制机制和数据一致性要求决定的，不能调整成多台节点同时写入。

部分分布式数据库或中间件（如InnoDB Cluster）支持多写模式，但需额外的数据冲突解决机制，不属于标准MySQL读写分离范畴。标准MySQL读写分离始终遵循“单主写入”。

### 数据缓存

随着访问量的持续不断增加，慢慢的我们的系统项目会出现许多用户访问同一内容的情况，比如秒杀活动，抢购活动等。

那么对于这些热点数据的访问，没必要每次都从数据库重读取，这时我们可以使用到缓存技术，比如 redis、memcache 来作为我们应用层的缓存。

![001.png](https://blog.liushigong.cn/static/img/ca720c1b448e5b511e29e47a8225da9d.001.webp)

虽然我们应用了缓存，性能得到了快速提升，但是这只能缓解读取压力，数据库的写入压力还是很大，且随着数据量的增长，性能还是会越来越慢。

我们的系统架构从单机演变到这个阶,所有的数据都还在同一个数据库中，尽管采取主从、读写分离和增加缓存的方式，但是随着数据库的压力持续增加，数据库的瓶颈仍然是个最大的问题。因此我们可以考虑对数据的垂直拆分和水平拆分。就是今天所讲的主题，分库分表。

### 分库分表

分库分表是数据库架构演进的终极手段之一，它通过打破传统单一数据库的物理边界，将一个逻辑上的大数据库（表）拆分成多个小的、独立的物理单元进行存储和管理。

* 分库：将原本存储在一个数据库中的数据，按照特定规则分布到多个数据库中。
* 分表：将原本存储在一个数据表中的数据，按照特定规则分布到多个数据表中。

这两种技术可以独立使用，但更常见的是结合使用，即“分库又分表”，以实现最大程度的扩展。

![image.png](https://blog.liushigong.cn/static/img/8c4ee155b2ccda75688ec23895ce3a5e.image.webp)

#### 分库分表解决的核心问题

**1、性能瓶颈**

单机资源上限：单台数据库服务器的CPU、内存、磁盘I/O和网络连接数存在物理极限。当数据量或并发量增长到一定规模，这些资源会成为瓶颈，导致查询变慢、事务超时。

集中式锁竞争：所有请求集中在一个数据库实例上，高并发写操作会引发激烈的锁竞争（如行锁、表锁），导致大量请求处于等待状态，系统吞吐量下降。

**2、可用性与风险集中**

单点故障：所有业务都依赖一个数据库，一旦该数据库发生硬件故障、机房网络问题或严重Bug，将导致整个系统不可用，风险高度集中。

维护困难：对单一大库进行备份、迁移、版本升级等运维操作，时间窗口长、风险高、失败回滚代价巨大。

**3、 存储与运维的物理限制**

单表数据膨胀：单表数据量过亿后，即使有索引，B+树的层级也会变深，查询性能显著下降。此外，数据文件过大，导致 `ALTER TABLE` 等DDL操作耗时极长，几乎无法在线进行。

成本与扩展性：垂直升级硬件（买更好的服务器）成本高昂，且很快就会遇到天花板。分库分表可以走向成本更低的水平扩展路线。

#### 什么情况下需要分库分表？

引入分库分表会极大地增加系统复杂度，因此不应作为首选方案。通常在经历读写分离、缓存优化、SQL与索引调优等手段后，若以下核心指标仍然告警，才需要考虑。

**1、数据量维度**

单表数据量：一般认为，MySQL单表数据量达到千万行级别是一个需要警惕的信号。当达到5000万至1亿行时，性能往往会明显下降，应考虑分表。

数据库总数据量：单个数据库实例的数据总量超过 2TB（考虑到备份、恢复和管理的便利性），应考虑分库。

**2、性能与负载维度**

关键业务查询延时：即使在优化后，核心业务的95%分位（P95）查询响应时间仍持续超过1秒，且瓶颈明确在数据库。

数据库服务器负载：数据库服务器的 CPU使用率或IO利用率长期超过70%，并且与业务增长趋势正相关。

并发连接数：数据库的活跃连接数经常接近或达到 `max_connections` 的上限。

**3、业务发展维度**

可预见的快速增长：业务处于爆发期（例如用户量、订单量预计年增长10倍以上），需要提前规划架构，避免到时被动。

高可用性要求：业务要求99.99%以上的可用性，不能接受单数据库实例故障带来的全局服务中断。

#### 分库分表的表现形式

分库分表主要有四种方式： 垂直分库、垂直分表、水平分库、水平分表

**1、垂直分库**

数据库中不同的表对应着不同的业务，垂直切分是指按照业务的不同将表进行分类，分布到不同的数据库上面，同时将数据库部署在不同服务器上，从而达到多个服务器共同分摊压力的效果

![03.jpg](https://blog.liushigong.cn/static/img/bca74a87b646de1327d137c4e4aeac43.03.webp)

我们的微服务架构中，其本质上就是垂直领域的分库应用

**2、垂直分表**

当一张表中的字段太多且包含大字段的时候，在查询时对数据库的IO、内存会受到影响，同时更新数据时，产生的binlog 文件会很大，MySQL在主从同步时也会有延迟的风险，我们可以将一个表按照业务拆分成多表，每个表存储其中一部分字段，这就是垂直分表

例如对职位表进行垂直拆分, 将职位基本信息放在一张表, 将职位描述信息存放在另一张表

![04.jpg](https://blog.liushigong.cn/static/img/1335b9863be59a69ee45ca53914b6817.04.webp)

垂直拆分带来的一些提升

* 解决业务层面的耦合，业务清晰
* 能对不同业务的数据进行分级管理、维护、监控、扩展等
* 高并发场景下，垂直分库一定程度的提高访问性能

但是垂直拆分没有彻底解决单表数据量过大的问题

**3、水平分库**

将单张表的数据切分到多个服务器上去，每个服务器具有相应的库与表，只是表中数据集合不同，这就是水平分库。简单讲就是根据表中的数据的逻辑关系，将同一个表中的数据按照某种条件拆分到多台数据库（服务节点）上面, 例如将订单表 按照id是奇数还是偶数, 分别存储在不同的库中。

水平分库分表能够有效的缓解单机和单库的性能瓶颈和压力，突破IO、连接数、硬件资源等的瓶颈。

![05.jpg](https://blog.liushigong.cn/static/img/87968c24ff24d5ccd2df92e769c6ff8c.05.webp)

**4、水平分表**

针对数据量巨大的单张表（比如订单表），按照规则把一张表的数据切分到多张表里面去。 但是这些表还是在同一个库中，所以库级别的数据库操作还是有IO瓶颈。

![06.jpg](https://blog.liushigong.cn/static/img/0806bfc9904cbb813af3628a68b384be.06.webp)

总结一下

* **垂直分表**: 将一个表按照字段分成多表，每个表存储其中一部分字段。
* **垂直分库**: 根据表的业务不同,分别存放在不同的库中,这些库分别部署在不同的服务器.
* **水平分库**: 把一张表的数据按照一定规则,分配到**不同的数据库**,每一个库只有这张表的部分数据.
* **水平分表**: 把一张表的数据按照一定规则,分配到**同一个数据库的多张表中**,每个表只有这个表的部分数据.

#### 分库分表带来的问题及解决方案

关系型数据库在单机单库的情况下,比较容易出现性能瓶颈问题，分库分表可以有效的解决这方面的问题的同时，也会产生一些比较棘手的问题.

**1、分布式事务**

当我们需要更新的内容同时分布在不同的库时, 不可避免的会产生分布式事务的问题。原来在一个数据库操作, 本地事务就可以进行控制, 分库之后 一个请求可能要访问多个数据库，如何保证事务的一致性，目前还没有简单的解决方案.

**2、跨节点关联的问题**

在分库之后, 原来在一个库中的一些表被分散到多个库，原本简单的 `JOIN`、`ORDER BY` ... `LIMIT`、`SUM/COUNT` 会变得异常困难，可能需要业务层多次查询后合并。

解决这种关联查询需要我们在代码层面进行控制，将关联查询拆开执行，然后再将获取到的结果在内存中进行拼装.

**3、分页与排序查询的问题**

分库并行查询时，如果用到了分页每个库返回的结果集本身是无序的, 只有将多个库中的数据先查出来，然后再根据排序字段在内存中进行排序，如果查询结果过大也是十分消耗资源的，同时还存在深度分页的考虑。

**4、全局唯一ID**

在水平分库分表的环境中，表中的数据存储在不同的数据库不同的表, 主键自增无法保证ID不重复, 所以不能依赖数据库自增ID，需设计分布式ID生成方案（如Snowflake、Leaf）。

**5、公共表的问题**

拆分后的数据库都需要从公共表中获取数据，某一个数据库更新看公共表其他数据库的公共表数据需要进行同步.

#### 总结一下

简单来说，分库分表是应对海量数据和高并发的“终极外科手术”，它通过水平扩展的方式解决了单机数据库在性能、可用性和存储上的根本性瓶颈，但其自身也引入了巨大的复杂性和技术挑战。

接下来带着这些问题，我们就来一起来学习一下分布式的数据库生态系统 Apache ShardingSphere

分库分表 - 数据库架构演变与分库分表的诞生

作为 Java 开发者，我需要建立了一个坚实且全面的核心技术栈指南，覆盖了后端开发的绝大部分关键领域。最近面试的过程中也是发现了一些自身的不足，尤其是在面架构师的岗位时也是发现自己的思考角度没有站在更高的地方，为了在这条路上更进一步，并在更高层次的面试中脱颖而出，我需要从“广度覆盖”转向“深度与体系化”，从“技术使用者”转向“设计决策者和问题定义者”，在此对自己掌握内容进行一次复盘。

接下来我将梳理技术栈，在现有基础上，进行深化和补充的方向，它们将使我的技术视野和能力更加立体和完整

## JVM：从调优到洞察本质

### 技术栈回顾

对于JVM，我不仅掌握经典的 **垃圾回收算法**，更对现代垃圾回收器（如 JDK8 的 `Parallel Scavenge/Old` 到 JDK11+ 的 `G1、ZGC`）的内存布局与工作机理有清晰认知。

调优实战中，我遵循明确目标：**降低GC的频率和停顿时间，提高吞吐量，避免因内存泄漏或不当数据结构引发的频繁`Full GC`**。

我能熟练通过 **GC日志分析**、**堆转储（Heap Dump）分析** 和 **线程栈分析** ，将性能问题定位到代码层面，例如内存泄漏，CPU飙升等。

### 洞察与反思

**深度不足**：
对 `ZGC、Shenandoah` 等新一代低延迟GC的运作细节（如染色指针、读屏障）理解概念没有掌握，同时缺乏在生产环境中权衡选型与调参的一手经验。

**工具链整合**：
对监控体系（如与APM整合）的运用没有体系化的了解，无法做到实现问题的主动发现而非被动响应。

### 进阶蓝图

**深度对比**：
深入研究 `ZGC/Shenandoah` 的原理，与G1进行吞吐量、延迟、内存开销的全方位对比，形成自己的选型决策树。

**实战指标化**：
设计一个压测场景，模拟不同内存压力模式，量化记录调优前后核心指标的变化（如GC频率、平均/最大停顿时间、应用吞吐量），并形成可复用的分析调优 SOP（标准作业程序）。

总结

对于 JVM 的基础、调优和问题排查能力都有了解，欠缺对未来垃圾回收器的发展趋势的深入探索与研究，同时对 JVM 运维的体系化了解不足，没有去深入指标化的探索。

这也是接下来我需要重点掌握的内容，优先级程度 ⭐️⭐️⭐️

## MySQL：从使用到架构掌控

### 技术栈回顾

我建立了从SQL执行到数据落地的完整知识链：

**精通索引结构（B+树）**、**Explain执行计划解析** 与 **SQL优化的思路（SQL语句优化、索引优化、库表优化、配置优化）**；

深入理解事务的 **ACID 实现** 与并发事务下的 **MVCC 原理**；

掌握 **InnoDB 存储引擎核心**（Buffer Pool、Change Buffer、双写缓冲区）与 **日志体系**（`undo log` 用于回滚和MVCC，`redo log` 保证崩溃恢复，`binlog` 用于主从复制） 的协作，深入主从数据最终一致性以及崩溃恢复后的数据一致性处理。

### 洞察与反思

**复杂场景**：
对 SQL 语句完整的执行流程，跨多个大表的复杂查询优化、窗口函数的性能影响、线上DDL的最佳实践（如使用pt-online-schema-change） 等高级场景经验有待加强。

**高可用认知：**
对设计和保障数据库的读写分离架构，MHA、Orchestrator 等传统方案，以及基于 `Raft/ Paxos` 的 MySQL Group Replication、InnoDB Cluster 等现代高可用架构的底层机制和适用场景了解不够深入。

### 进阶蓝图

**案例沉淀**：
系统性地复盘 1-2 个真实的复杂 SQL 优化案例，从问题发现、分析思路（执行计划解读、索引设计、重写SQL）、到验证效果，形成完整案例库。

**高可用架构研究**：
深入探究 MySQL Group Replication 的分布式一致性协议，并与 ProxySQL、Orchestrator 等中间件结合，设计一套能满足金融级 RPO/RTO 要求的高可用方案。

总结

MySQL 是我学习时长最多的模块之一，掌握程度由浅入深，从架构层面上，对于高性能与高可用的实践较少，也是接下来重点掌握的内容，优先级程度 ⭐️⭐️⭐

## JUC：构建高并发编程思维模型

### 技术栈回顾

我的知识体系围绕 **Java内存模型（JMM）** 构建：从 **可见性、有序性（`volatile`） 和原子性（`CAS`、`Atomic`类）** 三大并发特性出发，深入到 **同步锁**（ `synchronized` 及锁升级） 与 **显式锁**（`ReentrantLock`、`StampedLock`） 的对比与应用。

熟练使用 **并发工具包**（`CountDownLatch`、`CyclicBarrier`、`CompletableFuture`） 和 **线程池**（`ThreadPoolExecutor` 及其变体、`ForkJoinPool`） 来构建异步与并行任务。

理解 **并发容器**（`ConcurrentHashMap`、`CopyOnWriteArrayList`）的实现原理，并基于 `AQS` 框架，能剖析`ReentrantLock`、`CountDownLatch` 等组件的内部工作机制。

### 洞察与反思

**模式化应用**：
虽然熟悉工具，但在复杂业务场景下，如何系统性地设计无锁化结构、选择最匹配的并发模式（如生产者-消费者、读写锁模式），经验可以进一步沉淀。

### 进阶蓝图

**编程实践**：
尝试实现并发安全的list、map、set、队列、阻塞队列等数据结构，或者尝试 AQS 实现一个锁，，并与锁方案进行性能对比，验证自身代码能力。

总结

并发编程的源码我都阅读过，对包中的工具实现思路都有了解，但是没有加入自己的思考，从了解 → 深入 → 掌握 →
实现，这4个阶段中我还停留在深入层面，后续的学习中我将带入思考，自行实现工具类。
优先级程度 ⭐️⭐️⭐

## Redis：不仅仅是缓存

### 技术栈回顾

我深入理解 Redis 每种 **数据类型** 的底层数据结构（如SDS、跳表、压缩列表），并据此进行高效建模。

掌握 **持久化（RDB/AOF）机制**、**内存淘汰策略**、**事务与Lua脚本**。

熟悉 Redis Cluster 的哈希槽分片、节点通信（Gossip协议）、故障转移与选举流程。

### 洞察与反思

**算法实现**：
对近似 LRU 算法的具体实现（随机采样、淘汰池机制）了解不深，影响了对缓存行为的精准预测。

**线程模型**：
对 Redis 的架构设计、线程模型上不太清晰。

### 进阶蓝图

**编程实践**：
尝试实现分布式锁、限流器、布隆过滤器、延迟队列等核心模式，验证自身代码能力。

**一致性深度**：
对 Redis Cluster 的主从异步复制在极端情况下的数据一致性边界，以及 Redis 哨兵/Cluster与Raft协议的异同，认知有待深化。

总结

Redis 中各类解决方案思路都能说出123，但是没有自己的实践，没有进行过性能测试；对线程模型一直是一知半解，可能是因为对操作系统不了解导致的；对集群的一致性模型的掌握也欠缺，在学习过程中应该思考其一致性，可用性的保障；优先级程度 ⭐️⭐️⭐⭐

## 数据结构与算法：从理论到工程决策

### 技术栈回顾

我系统掌握了从 **物理结构（数组、链表）** 到 **逻辑结构（栈、队列、树、图）** 的体系，熟悉常用 **排序** 与 **查找** 算法，并能运用分治、动态规划、贪心、回溯等核心算法思想解决复杂问题。

重点理解 **红黑树**、**B/B+树**、**跳表** 等高级数据结构在工程（如Java HashMap、数据库索引、Redis Zset）中的应用。

### 洞察与反思

**工程转化**：
在解决实际业务问题时，如何快速地从问题域抽象出合适的数学模型和数据结构，这一“第一性原理”的思维能力仍需刻意练习。

**权衡分析**：
在面对时间和空间的权衡时，有时缺乏足够的数据支持和量化分析，多依赖于经验。

### 进阶蓝图

**场景化应用**：
针对工作中遇到的实际问题（如最近最少使用缓存、任务调度依赖判环），手写实现对应的数据结构（LRU Cache）或算法（拓扑排序），并分析其时间/空间复杂度。

**LeetCode系统训练**：
按照算法标签和公司真题进行专题训练，重点突破动态规划和深度优先/广度优先搜索，并总结通用解题模板。

总结

掌握了数据结构和算法思想，需要多刷题多锻炼，每天刷一题。优先级程度 ⭐️⭐️⭐⭐

## spring IOC/ AOP/ 事务/ MVC/ springboot / mybatis 源码

### 技术栈回顾

我深入理解 **Spring IoC容器** 的Bean生命周期、依赖注入原理、循环依赖解决（三级缓存）；

掌握 **Spring AOP 的代理机制（JDK动态代理与CGLIB）**、切面执行流程；熟悉 **Spring声明式事务** 的传播行为、隔离级别及 基于 AOP 的实现原理。

掌握 **MVC 执行流程** 与 **SpringBoot 自动装配** 原理。

对 **MyBatis 的核心流程**，包括 SQLSession 的生命周期、Mapper 接口的绑定、以及一级/二级缓存机制有清晰认知。

### 洞察与反思

对于 **编写高效的MyBatis插件（Interceptor）** 等高级扩展特性，缺乏实战经验。

### 进阶蓝图

深入探索 **MyBatis Plugin拦截机制** 进行专题源码阅读，绘制核心时序图，并撰写分析文章。

总结

Spring 源码的扩展与自定义插件的实现都了然于胸，需要深入了解 Mybatis，优先级程度 ⭐️⭐️

## 分库分表：从拆分到治理

### 技术栈回顾

我理解分库分表的核心 **路由算法（取模、范围、一致性哈希）**，并能根据业务特点（如用户ID、时间）进行合理选型，同时关注 **数据倾斜** 与 **热点问题** 的预防。

### 洞察与反思

**复杂查询**：
对跨分片查询（尤其是分页、排序、聚合） 的性能问题和解决方案（如归并查询、二次查询法）缺乏实战经验。

对 ShardingSphere 中间件的基本原理认知不足。

### 进阶蓝图

**实战设计**：

模拟设计一个电商订单分库分表方案，详细阐述路由键选择、历史数据迁移、分布式ID生成、跨分页查询等问题的解决方案。

总结

掌握 ShardingSphere 基本原理认知，掌握分片路由的算法，ID生成，对复杂查询进行实操，并编写出解决方案，深入探究分库分表的问题，并进行一次实战。优先级程度 ⭐️⭐️⭐️⭐️

## 消息队列：企业级异步解耦基石

### 技术栈回顾

我了解主流消息中间件的核心差异与选型考量：

* Kafka 的高吞吐与流式处理
* RabbitMQ 的灵活路由与高可靠性
* RocketMQ 的金融级事务与顺序消息

掌握 **事务消息**、**顺序消息**、**延迟消息** 实现原理，并能设计应对 **消息丢失**、**重复消费**、**消息堆积**的端到端可靠性方案。

### 洞察与反思

**运维视角**：
对消息队列的监控指标（堆积量、消费延迟）、集群扩缩容、版本升级等运维层面经验不足。

### 进阶蓝图

深入探索 RocketMQ 源码实现，掌握其设计理念，了解内部高性能、高可靠和数据一致性的实现方式。

总结一份《RocketMQ 实战避坑指南》，涵盖可靠性设计、性能调优和运维监控。

总结

对于 RocketMQ 还停留在会用阶段，简历中也是一笔带过，对消息中间件所遇到问题的解决方案都有所了解，需要结合源码深度去探究，并进行场景实战。优先级程度 ⭐️⭐️⭐

## 搜索引擎：ES深度应用

### 技术栈回顾

我熟练使用ES进行 **数据检索**、**聚合分析**，理解 **倒排索引**、**分词器** 的基本原理。了解ES集群架构、分片与副本机制。

### 洞察与反思

**分片设计**：
对分片数量、大小设定背后的权衡（查询性能、写入吞吐、节点恢复速度）缺乏量化依据。

**深度分页性能**：
对深度分页（from+size）的性能问题及替代方案（search\_after、滚动查询）的应用场景理解不深。

### 进阶蓝图

**原理深挖**：
学习 Lucene 底层文件格式（如.fdt， .fdx）和索引合并（Merge）策略，理解ES性能的根基。

**性能优化实践**：
针对一个实际索引，进行分片策略调整、Mapping优化（如避免嵌套类型）、查询DSL优化，并记录性能提升数据。

总结

目前只掌握了 ES 的基础概念，需要深入思考倒排索引的原理，做到对分片设计、深度分页、DSL优化的完整方案。优先级程度 ⭐️⭐️⭐

## 微服务与 Spring Cloud：从框架到治理

### 技术栈回顾

我掌握微服务核心组件：

* Nacos（服务注册发现、配置中心）
* Sentinel‌（微服务流量控制）
* OpenFeign（声明式HTTP客户端）
* Gateway（API网关与路由）
* LoadBalancer（客户端负载均衡）

理解其核心机制，如服务心跳、配置动态刷新、流量控制、熔断降级、负载均衡策略，并阅读过部分核心源码。

### 洞察与反思

**网络通信深度**：
对 OpenFeign 与 gRPC 等RPC框架的底层网络通信模型（HTTP/1.1 vs HTTP/2）、序列化效率对比理解不深。

**服务治理体系**
：对全链路灰度发布、熔断降级的高阶策略、服务网格（Service Mesh） 等更上层的服务治理体系接触较少。

**一致性模型**：
对 Nacos 底层（默认AP，支持CP切换）及配置中心的一致性模型理解不够透彻。

### 进阶蓝图

**网络通信探究**：
深入学习 HTTP/2 与 gRPC 协议，并与传统HTTP/1.1下的OpenFeign进行性能对比测试。

**治理能力建设**：
研究 Sentinel 的熔断、热点参数限流高级规则，并设计一个基于 Nacos 元数据的全链路灰度发布方案。

**一致性研究**：
探究 Nacos 的 Distro (AP) 和 Raft (CP) 协议实现，理解其适用场景。

提示

RPC 是提升QPS性能的手段之一，需要深入了解其底层网络通信模型，同时在架构层面对服务治理、熔断机制要有认知，掌握分布式算法后，重新理解 Nacos 的一致性模型。优先级程度 ⭐️⭐️⭐

## 分布式

### 技术栈回顾

我能运用分布式基础组件解决常见问题：

* 基于 Redis/ZooKeeper 的分布式锁
* 基于令牌桶/漏桶的分布式限流
* 基于Redis ZSet/消息队列的延迟任务
* 基于Seata/TCC的分布式事务

了解一致性哈希、Gossip协议、Paxos/Raft 等核心分布式算法的基本思想。

### 洞察与反思

**理论到实践**：
对 Paxos、Raft 等算法的理解多停留在认识层面，缺乏在真实中间件（如Etcd、Consul）中跟踪其实现和调试的实践经验。

**全局视野**：
在复杂业务场景下，如何有机组合这些分布式组件与模式，形成稳定健壮的分布式架构，能力有待提高。

### 进阶蓝图

深入阅读 Raft 算法，尝试设计一个简易的分布式配置中心，亲自实现其核心的一致性协议（简化版 Raft）和集群通信。

总结

对于分布式解决方案的实现原理都已掌握，需要深入理解分布式算法：一致性哈希、Gossip协议、Paxos/Raft 。基于此思想，去代入思考中间件的实现。优先级程度 ⭐️⭐️⭐⭐️⭐

## 云原生

### 技术栈回顾

目前对云原生体系了解尚浅。

### 洞察与反思

云原生（容器化、K8s、服务网格）已成为现代应用架构的事实标准，缺乏这部分知识将难以设计和运维真正弹性、高可用的分布式系统。

### 进阶蓝图

学习路径：

* 第一步：深度系统学习 Docker（镜像、容器、网络、存储）。
* 第二步：深入学习 Kubernetes核心概念（Pod, Deployment, Service, Ingress, ConfigMap/Secret）及控制器模型。
* 第三步：将个人Spring Cloud项目容器化并部署到K8s，用Service替代Nacos进行服务发现。
* 第四步：了解 Service Mesh（Istio） 概念，理解其如何将治理能力下沉。

## 系统设计

### 技术栈回顾

目前缺乏系统性的方法论和实战经验。

### 洞察与反思

高级开发与架构师的核心分水岭在于系统设计能力。这要求不仅懂技术细节，更能从场景、约束、权衡出发，进行顶层设计。对经典场景的深度剖析，不仅知道“怎么做”，更要理解“为什么这么做”以及“代价是什么”。

结合 “如何提升系统的性能，如何保障系统的可用性，如何做到数据一致性” 等问题的考量

### 进阶蓝图

**方法论学习**：
采用 《系统设计面试》 等经典方法论，练习从需求澄清（QPS、延迟要求）、容量估算、顶层设计（框图）、到核心组件深挖的完整流程。

**场景精研**：
针对短链系统、秒杀系统、Feed流系统等经典场景，分别产出多套设计方案（简单版、高可用版、海量数据版），并对比其优劣与适用条件。重点思考数据一致性、扩展性、成本的权衡。

总结

结合场景设计，代入思考，进行实战： 优先级程度 ⭐️⭐️⭐⭐️⭐

* 电商中订单过期如何实现
* 如何设计秒杀系统
* 如何让系统支撑 10w QPS
* 如何设计一个支撑10亿的会员系统
* 如何设计一个短链系统
* 如何设计一个10w QPS 的优惠券发卷系统

## 软技能

### 技术栈回顾

主导小组内的需求全生命周期管理，采用 "双阶段Review"，进行技术方案与代码 Review，主导组内问题复盘。

### 洞察与反思

在主导跨团队技术方案、推动重大技术债务偿还、将个人知识转化为团队资产等方面，主动性和方法论上仍有提升空间。技术影响力建设尚未体系化。

* 技术领导力：如何主导一个技术方案的设计与落地？如何做技术评审？如何推动团队技术债务的偿还？
* 沟通与影响：如何向非技术人员（产品、运营）解释技术方案？如何说服同事或上级采纳你的技术建议？
* 学习能力与知识体系化：如何快速学习一门新技术并将其融入现有知识体系？建立个人知识库（如用Obsidian、Notion）是很好的习惯。
* 开源贡献意识：不仅仅是使用开源，尝试阅读更多源码，提交Issue，甚至修复Bug并提交PR。这是深度理解技术和建立个人影响力的绝佳途径。

### 进阶蓝图

**主动担当**：
主动主导一个跨模块的技术方案设计，并练习撰写清晰的技术方案文档，组织评审会议。

**知识输出**：
坚持撰写技术博客，并将内部分享沉淀为团队的“最佳实践” 或 “技术雷达” 文档。

**开源参与**：
为自己常用的一个开源项目（如Spring、Apache Commons）提交一个 Bug Fix 或 文档改进 的PR，迈出第一步。

## AI

### 技术栈回顾

了解AI的基本概念，但未与后端开发工作流结合。

### 洞察与反思

AI工程化（MLOps）和后端开发的结合点（如模型服务化、特征存储、推理加速）是未来的趋势，提前了解有助于拓宽技术视野。

### 进阶蓝图

应用入门：学习使用 OpenAI API 或开源大模型，在个人项目中接入一个智能对话或内容生成的简单功能。

工程化了解：了解 模型即服务（Model Serving） 的基本概念和框架（如 TensorFlow Serving、Triton），理解后端如何为AI模型提供高并发、低延迟的推理服务。

## 总结

本次复盘让我清晰地看到了自身技术栈的广度与深度边界。下一步，我将从分布式理论和系统设计实战这两个领域横向突破。

职业规划 - 自身技术栈的深度复盘与前瞻性规划

面试的本质是一场开卷考试，永远不知道下一场会考什么，但通过持续、高质量的复盘，可以让自己的“知识库”越来越厚，直到应对任何问题都游刃有余。

本文将对京东美团的面试考点进行一次复盘，只有面对自己的不足才能更好的突破自己，**祝我复盘有得，早日拿到心仪的Offer！**

![](https://blog.liushigong.cn/static/img/fea0054f798ac17683f642781064b729.image.webp)

## 面试问题记录

| 类型 | 京东 | 美团 |
| --- | --- | --- |
| 自我介绍 | - | - |
| 项目介绍 | - | - |
| 分库分表 | 根据什么算法进行的分库分表 | 分库分表都需要注意哪些 |
|  | 根据业务id与日期如何分片的 |  |
| 线程池 |  | 为什么自研动态线程池组件 |
|  |  | 为什么要使用动态线程池 |
|  |  | 自研线程池中为什么采用区间线程数  相比于传统动态线程池,它的优势是什么 |
| JVM | 如何进行调优的 |  |
|  | 描述一下调优的场景与效果 |  |
|  | GC 指标是怎样的，调优后的指标是怎样的 |  |
|  | QPS 是否有提升，对接口的响应有没有提升 |  |
| SQL | 慢SQL是如何处理的 | SQL 是如何进行优化 |
|  | SQL 是如何优化的 | SQL 中索引覆盖的效果 |
|  | 具体的调优案例 |  |
| 场景设计 | 系统的从0到1，是如何设计的，需要注意哪些方面 |  |
| 软技能 | 如何提效代码 Review |  |
| 源码 |  | Mybatis 中的 Mapper 接口执行 SQL 的流程 |
|  |  | Spring 中的事务的实现原理 |
| 算法 |  | 二分查找 |

## 面试前准备的复盘

从整体来看，我在面试前没有做好充足的准备，在此反思一下自己，应该从把握每一次机会

> 对于jb的岗位匹配度，应该提前进行关注，根据业务方向预测可能被问到的技术点，提前准备 **场景案例**

在自我介绍中，往往考察的是个人的陈述能力，对自我是否有一个清晰的认知，自信大方的去介绍自己

> 我需要突出自身的亮点，突出自己积极向上的一面

## 项目经验陈述复盘

项目介绍中，需要考察自己对项目业务理解程度，以及在项目中的技术贡献，价值几何

**我的回答：**

> 我们公司主体是做光伏的建站发电的，主要是对建站的一站式管理，像“录单 → 踏勘 → 设计 → 签约 → 仓配 → 施工 → 结算 → 运维 → 清分”，前期主要负责“施工、结算、运维”模块，后期职责划分后主要负责“结算、清分”模块，在开发过程中也是遇到一些技术难点，像开源组件的动态线程池内存泄漏，然后自研动态线程池...巴拉巴拉；对结算模型的重构，结合“工厂+抽象模板”设计模式搭建结算三层领域架构模型，主要业务分为三层维度..... 巴拉巴拉；对运维的逆变器发电数据，使用分库分表... 巴拉巴拉；然后面试官开始了询问

**考察分析：**

> 对项目的准备是否充分，是否真正的了解自己所做的项目

**不足：**

> 对项目的内容没有做到清晰的描述，，过多赘述技术方案上的实现，没有做好 **埋点**，导致面试官无从问起

**改进：**

项目部分，这是展示核心技术能力的舞台，要清晰的表达出你的 **技术贡献** 和 **架构思维**。

> 我们公司主体是做光伏的建站发电的，每一电站都创建一个订单，主要是对建站订单的一站式管理，订单的主要流程从 “录单（业务合伙人与电站用户信息确认进行信息录入） → 踏勘（有踏勘合伙人对屋顶进行勘探，测量长度宽度，障碍物等） → 设计（主要是建站的CAD制图与预估物料配置） → 签约（与电站用户签合同的环节） → 仓配（根据设计所需的物料，从仓库进行配货出库） → 施工（当施工队接货后进行施工环节） → 并网（与国家电网进行合闸） → 结算（施工、并网完成后，会根据不同阶段进行结算） → 运维（则是对电站逆变器发电后进行运维） → 清分（根据发电量收益进行清分） ”，以上是业务的主体流程。
>
> 在业务快速发展的过程中，也是遇到了一些挑战，像结算单生成的扩展性不足，结合设计模式进行的重构；使用开源动态线程池组件导致内存泄漏的问题，排查问题与自研轻量级的动态线程池组件；电站逆变器发电量数据过大，进行分库分表的扩展等。

在2分钟内过了业务的大流程，让面试官有个大概得了解后，开始进行埋点，描述在业务发展的过程中所遇到的问题与挑战。

## 面试过程技术深度复盘

这是重中之重，我结合面试的问题分模块详细梳理。

### 分库分表

#### 面试问题：分库分表的算法是怎样的

**我的回答：**

> 我是通过哈希的方式，对电站id进行取模的方式，为了防止数据的倾斜，采用时间+逆变器id进行复合分片，吧啦吧啦

**考察分析：**

> 为什么使用分库分表？  
> 如何选择分片键（如你提到的电站id、时间、逆变器id）？
> 对分库分表常见算法的理解（如：哈希取模、范围分片、一致性哈希、复合分片等）
> 是否了解这些算法的优缺点和适用场景
> 分库分表会产生的问题以及如何解决的？

**不足：**

> 没有做好项目案例的准备，不能系统性的回答，没有先构建一个清晰的框架，对于分片算法掌握的广度不足

**改进：**

准备项目的案例，需要重新组织一下回答，使其更加结构化，用 **STAR原则** 陈述

> 我们每个电站下会有一到多个逆变器，而每个逆变器在光照后会进行发电的工作，每隔5分钟会传输一条发电量数据，预估一个逆变器一天产生120条数据，一年预计4w多条数据，而我们电站的数量是一个持续增长的过程，整体拆分成8个数据库，128个表，总计1024张表，截止到目前支撑存储83多亿的数据量；
>
> 分库分表中最核心的就是路由算法：
>
> * 哈希取模：均匀分布，但扩容困难
> * 一致性哈希：扩容友好，需配合虚拟节点
> * 范围分片：适合范围查询，但要防止数据倾斜
> * 配置表路由：灵活，但有单点瓶颈
>
> 对于分片键选择原则上，需要结合实际的业务场景：
>
> 1. 数据分布要尽可能均匀
> 2. 查询频次最高的字段
> 3. 业务上根据电站查询多个逆变器
> 4. 考虑业务增长模式
>
> 最终我们选择哈希取模的路由算法，采用电站ID作为数据库的分片键，保障了同一个电站下的逆变器在同一个库中。
> 对于数据表的分片，我们设计的分片方案结合了 **哈希取模** 和 **动态再平衡**，本质上是一种负载感知的动态再平衡策略。选择逆变器ID作为数据库表的分片键，确保同一个逆变器数据在同一张表中。核心路由使用哈希取模，确保同一个逆变器的数据在同一张表。同时，我们每天定时监控各分片的数据量，如果发现数据倾斜（20%的差异），则进行动态调整：将原本哈希到数据量多的分片的某些逆变器重新映射到数据量少的分片，并通过Redis记录这些异常映射（即非哈希取模的映射）。查询时，先查Redis是否有自定义映射，如果没有则使用哈希取模。
>
> 为了控制再平衡频率，避免频繁路由变更，我们也会计算出下次平衡时间，也就是当平衡完成+倾斜率需达到10%的天数日期作为判断。

STAR原则

* Situation：项目背景与技术选型
* Task：你承担的核心职责
* Action：技术方案设计与实施细节
* Result：性能指标提升与业务价值

### 线程池

#### 面试问题：为什么自研动态线程池组件

**我的回答：**

> 原本我们是采用开源的动态线程池组件 DynamicTp v1.1.9 版本，后来产生了内存泄漏，所以开始的自研

**考察分析：**

> 项目中为什么采用动态线程池？对使用上的场景是否真正的理解，同时考察自研的线程池有什么优势？

**不足：**

> 没有体现出掌握的源码深度，有一定的功力才能自研，没有做好埋点

**改进：**

> 原本我们是采用开源的动态线程池组件 DynamicTp v1.1.9 版本中，后来发现其存在 ScheduledDtpExecutor 内存泄漏问题，通过增强机制会将 DtpRunnable 对象存储在功能性的 Map 结构中。
>
> 然而，ScheduledThreadPoolExecutor 在内部会将提交的任务包装成 ScheduledFutureTask 对象。这种包装导致了框架在执行 beforeExecute 和 afterExecute 钩子方法时，无法从 Map 中正确移除对应的任务对象，从而导致了内存泄漏的问题，因此我们决定自研动态线程池的组件，同时做了很多的扩展。

埋点

* 内存泄漏问题的排查思路
* 动态线程池Bean的创建
* 动态线程池配置的Bean刷新
* ScheduledThreadPoolExecutor 源码
* FutureTask 源码

#### 面试问题：相比于传统动态线程池,它的优势是什么

**我的回答：**

> 巴拉巴拉

**考察分析：**

> 为什么耗时自研线程池组件？比传统的线程池组件的优势是什么？

**改进：**

> 传统的动态线程池：需要人工观察监控指标 -> 判断需要调整 -> 修改配置 -> 推送生效。响应延迟高，依赖人工经验。无法根据系统真实负载自动弹性伸缩。
>
> 在自研的组件中，我们实现了 **“线程数范围区间+自动扩容”** 机制。
>
> * 根据自动感知负载，当任务队列的阈值达到80%以后，计算最大线程数、任务执行速率是否足以支撑任务增长率，如果不满足则开始扩容，每次扩容区间差的一半，直到扩容到满足支撑任务增长率
> * 线程数范围区间内智能调整，在预设的 `[minThreads, maxThreads]` 范围内动态寻找最优值
> * 设置一个冷却期，在每次调整后的一段时间内不再调整，避免频繁调整造成系统不稳定，防止震荡
>
> 自研轻量级架构的优势：
>
> * 避免复杂依赖，稳定性更高
> * 基于工厂类获取线程池，无需 Bean 的注入，扩展性更强
> * 无需人工干预，做到了响应更快
> * 可根据不同业务线程池可以设置不同的弹性策略，自动选择最合适的线程数

### JVM

#### 面试问题：JVM是如何进行调优的

**我的回答：**

> 我们使用的是jdk11，从jdk9开始默认的垃圾回收器是G1,其内存结构与jdk8已不一致，像jdk8的内存结构从物理上划分为年轻代，老年代，而G1则是划分为一块块的region区域，在逻辑上的承担年轻代，老年代的角色。而调优的思路主要分为低延迟与吞吐量。

**考察分析：**

> 查看你是否会真正的调优，根据不同的场景如何调优

**不足：**

> 不能一上来就根据调优的方向，设置JVM参数

**改进：**

> 我们通常不会进行过早的优化，但是当系统出现性能问题（如GC频繁、CPU负载高、响应慢）时，我们需要进行JVM调优。调优的目标通常是：降低GC的频率和停顿时间，提高吞吐量，避免内存泄漏和内存溢出。
>
> 我得调优思路是：
>
> * 监控发现性能问题： 通过查看GC统计 `jstat -gc <pid> 1000 10`，查看堆内存信息 `jstat -gccapacity <pid>`, 生成堆转储文件查看内存对象信息 `jcmd <pid> GC.heap_dump ./dump.hprof`
> * 分析定位根本原因：开启GC日志进行分析
> * 优化应用代码和架构：找到业务的大对象场景，进行优化
> * 最后才是JVM参数调优

提示

先不要调优！ 这是最重要的原则。调优应该是数据驱动、问题导向的，而不是盲目地进行。

### SQL

#### 面试问题：SQL 是如何进行优化

**我的回答：**

> 在我看来慢sql优化主要🈶2个方向，一个是sql本身的优化，要符合小表驱动大表的方式，将筛选量多的条件优先处理，一种是索引上的优化，根据 explain 排查索引命中情况，

**考察分析：**

> 对 SQL 的优化掌握的是否全面

**不足：**

> 没有回答完整，且没有系统性的思路

**改进：**

> SQL 的优化其实可以分为：SQL语句优化、索引优化、数据库结构优化和系统配置优化。
>
> SQL 语句上的优化：
>
> * 避免使用SELECT \*
> * 小表驱动大表
> * 避免在WHERE子句中使用函数或表达式
> * 注意数据类型转换
>
> 索引优化
>
> * 注意索引顺序，最左原则
> * 选择性更高的字段放左侧
> * 使用覆盖索引
> * 避免过度索引，索引会占用空间，并且降低写操作
> * 定期检查索引使用情况，使用EXPLAIN分析查询，删除未使用的索引。
>
> 数据库结构优化
>
> * 选择合适的数据类型，越小越好
> * 使用NOT NULL，允许NULL的列需要额外的存储空间，并且查询时需要进行判断。
> * 适当冗余，减少表关联，提高查询效率
>
> 系统配置优化
>
> * 调整缓冲区大小，InnoDB的缓冲池（innodb\_buffer\_pool\_size），通常设置为系统内存的70%-80%。
> * 调整连接数,根据并发请求调整最大连接数（max\_connections）。
>
> 除了以上的优化项外，发现慢SQL与索引命中分析也是重中之重
>
> * 开启慢查询日志
> * 使用EXPLAIN分析查询

案例：

关联查询订单的最后一次关单时间，从数百万的操作记录中筛选，响应时间越来越慢，影响系统吞吐量，sql如下

select ...,（select close\_time from operate\_log where order\_id = order\_id and work\_type = xxx）as close\_time from order\_main where ....;

方式，从sql上优化：查询表数据量与查询条件，按照小表驱动大表的形式调整，
查看索引：查看创建的索引结构，根据数据分析通过 explain 查看索引命中情况，适当调整索引顺序或新建索引，从索引底层的B+树结构上来看，应该以做前缀作为查询的顺序；
索引失效：表字符集不一致，导致索引失效

### 软技能

#### 面试问题：如何提效代码 Review

**我的回答：**

**考察分析：**

> 是否真正的理解代码 Review，给团队带来提升

**不足：**

**改进：**

> 代码Review是保证代码质量的关键步骤,它可以帮助在代码集成之前发现问题，减少后续测试阶段和生产环境中的缺陷。同时，它也是团队技术交流和知识传递的好机会。
>
> * **质量保证**：发现bug、安全漏洞、性能问题
> * **知识共享**：团队成员互相学习，了解系统不同部分
> * **规范统一**：确保代码风格和架构一致性
> * **mentorship**：帮助团队成员成长
>
> 我们在需求开发中采用 **"双阶段Review"**
>
> * 设计Review：编码前的技术方案评审，确保技术方案合理，避免错误的设计决策
> * 代码Review：编码完成后的实现细节评审
>
> 应该做的 ✅
>
> * 对事不对人：评论代码，不评论人
> * 提供具体建议：不只说"不好"，要说"怎么改"
> * 及时响应：在约定时间内完成Review
> * 保持学习心态：把每次Review当作学习机会

### 算法

#### 面试问题：二分查找

写个二分查找，一个升序的数据，去查找是否存在某个值，如果存着，则返回下标，否则返回-1

**我的回答：**

**考察分析：**

> 算法的掌握程度

**不足：**

> 整体思路清晰，但是编码上的边界值控制没有把控好

**改进：**

> 脱离idea，手写算法

## 总结：

回答问题的思路：

* 是什么？
* 解决了什么问题？
* 为什么能解决此问题（也就是实现原理）

如果是项目上的询问，在上面回答问题思路的基础上，继续描述：

* 场景案例
* 承担职责
* 技术方案与实现细节
* 性能指标

本次面试暴露了我在项目案例准备上与手写算法上的不足，接下来本周，重点攻克分库分表、JVM调优实战的案例和脱离 idea 的手写算法。

面试记录 - 京东美团的面试复盘

随着每次的面试，你是否有这么一种经历：在回答问题时大脑飞速运转，明明会这些内容，但是思绪杂乱，脑海中的知识无法聚集的感觉，这就是我们遇到的第一道技术壁垒。你不是输在能力上，而是输在记忆与整理的效率上。

我整理博客内容，凝练成一份直击考点的面试“求生”指南，同时根据此目录进行后续的查漏补缺。

![image.png](https://blog.liushigong.cn/static/img/c03a33f31b40d98fefcb06fed028eb52.image.webp)

## JVM 虚拟机

掌握基础的内存布局，到对象分配，“判断对象已死”，垃圾回收算法，类加载机制，编译原理以及一些JVM参数的调优，监控指令与掌握 CPU、内存、线程异常分析的手段

* [构建 JVM 学习的知识体系](/post/1)
* [分享我的 JVM 调优思路](/post/3)
* [告别“祖传”配置：深入理解 JDK 8→17 的 JVM 参数与 GC 调优新思路](/post/153)
* [性能优化 - JVM 命令行工具全解析与实战指南](/post/86)
* [线上性能问题 - CPU 飙升100%+](/post/46)
* [线上性能问题 - 内存泄漏的最佳排查思路](/post/88)
* [线上性能问题 - 玩转 MAT 分析内存泄漏](/post/89)

## 并发编程

问的最多的模块，学好并发，面遍天下

* [并发编程 - 高效并发核心模型](/post/5)
* [并发编程 - ThreadLocal 详解与源码分析](/post/6)
* [并发编程 - 深入理解 synchronized](/post/58)
* [并发编程 - 深入理解 Atomic 原子类](/post/59)
* [并发编程 - JUC 工具类的实现原理](/post/60)
* [并发编程 - 并发容器全解析](/post/61)
* [并发编程 - CompletableFuture 任务编排与源码解读](/post/62)
* [并发编程 - FutureTask 应用&源码分析](/post/63)
* [并发编程 - ForkJoinPool 深度源码解析](/post/64)
* [并发编程 - ThreadPoolExecutor 源码与实战](/post/65)
* [并发编程 - ReentrantLock 源码解读](/post/66)
* [并发编程 - ReentrantReadWriteLock 源码解读](/post/67)
* [并发编程 - 深入了解 AbstractQueuedSynchronizer](/post/68)
* [并发编程 - CopyOnWriteArrayList 源码分析](/post/69)
* [并发编程 - 深入解析 ConcurrentHashMap](/post/70)
* [并发编程 - 高性能队列 Disruptor](/post/72)

## 数据结构与算法

面大厂必备模块，后续在更新刷题记录

* [算法-数据结构基础1](/post/33)
* [算法-数据结构基础2](/post/42)
* [算法-理论基础](/post/34)
* [算法-核心算法思想](/post/35)
* [算法-经典排序算法](/post/36)

## Mysql

市面上 90% 都使用 mysql，学会使用后，还要掌握其实现机制的原理，生产中的问题大部分都是没有掌握其原理，这是必不可少的。

* [数据库- Mysql 索引原理与高性能调优](/post/20)
* [数据库 - 深入了解 Mysql 事务与并发控制](/post/84)
* [数据库 - Mysql 可重复读如何解决幻读？](/post/97)
* [数据库 - 深度探索 Mysql 的 binlog、redo log、undo log](/post/98)

## 中间件

**Redis**

学会用，学会怎么用

* [Redis - 基础数据类型与底层结构的实现](/post/91)
* [Redis - 高级数据类型与自带的解决方案](/post/92)
* [Redis - IO模型、通信协议、持久化、管道与事务](/post/93)
* [Redis - 过期策略与内存淘汰策略](/post/94)
* [Redis - 主从同步、Sentinel与Cluster](/post/95)
* [Redis - 面试中常见的缓存问题与方案](/post/96)

**MQ**

* [你真的会应对消息队列中的消息堆积吗？](/post/109)

**ES**

* [Elasticsearch 入门：从零开始理解分布式搜索引擎](/post/137)

## 分布式

**分布式汇总，后续在补充文章吧**

![image.png](https://blog.liushigong.cn/static/img/b8e83177fc2c6f1b000e0aafb7d8ebed.image.webp)

**限流**

![image.png](https://blog.liushigong.cn/static/img/5e0ad707bc7e761485fed4b85aacd412.image.webp)

**分布式事务**

* [构建自己的分布式事务底层实现的思维模型](/post/101)
* [XA 强一致性分布式事务原理与实战](/post/105)
* [TCC 最终一致性分布式事务原理与实战](/post/106)
* [可靠消息投递分布式事务原理与实战](/post/107)
* [最大努力通知型分布式事务原理与实战](/post/108)

## 源码

对于源码的掌握，我更加的了然于胸，开始学习的时候，还没开始写博客，都是做思维导图和流程图居多，后续在整理成博客文章，此处直接晒图，看图捋一遍过程，也相当于复习了

**Spring IOC 全生命周期流程**

![image.png](https://blog.liushigong.cn/static/img/98d968115dfc62ac935431d4ade67364.image.webp)

**Spring AOP & 事务执行流程**

![image.png](https://blog.liushigong.cn/static/img/eb385e2c7555637a6880145745418f07.image.webp)

**Spring MVC 源码调用过程**

![image.png](https://blog.liushigong.cn/static/img/17c25d33c11fb8c2c621bed17ec79e9e.image.webp)

**Spring MVC 核心执行流程**

![image.png](https://blog.liushigong.cn/static/img/4fece2d1c81643a8abd16270242cf1db.image.webp)

**Mybatis 启动流程分析**

![image.png](https://blog.liushigong.cn/static/img/fee2ad91d1ec5ad3cc40a2bb205c5d2e.image.webp)

**Mybatis 执行流程分析**

![image.png](https://blog.liushigong.cn/static/img/1b4eb6824091061b3fc2ee334fac003d.image.webp)

* [Spring 源码分析之 Bean 的全生命周期](/post/11)
* [SpringBoot - 自动装配原理的满分解读](/post/16)

**Nacos**

* [微服务 - Nacos 注册中心工程化应用](/post/117)
* [微服务 - Nacos 2.X 服务注册的源码分析](/post/119)
* [微服务 - Nacos 2.X 心跳机制的源码分析](/post/120)
* [微服务 - Nacos 2.X 服务发布订阅的源码分析](/post/121)
* [微服务 - Nacos 2.X 配置中心工程化应用](/post/122)
* [微服务 - Nacos 2.X 配置中心动态刷新的源码分析](/post/123)
* [微服务 - Nacos 常见的面试问题汇总](/post/124)

## 面试

* [面试技巧 - 如何写好简历](/post/51)
* [面试技巧 - 如何优雅的去谈薪](/post/52)
* [面试技巧 - 高频灵魂问题应答库](/post/55)