11月底，公司裁员的消息悄然传来，这已经是今年的第三波了，办公室里难免弥漫着几分人心惶惶的气息，但我心里却异常平静。毕竟我也是时刻准备着，也没有最初的慌张与手足无措。其实在消息传来前，我就有过主动离开的想法，后来和媳妇仔细商量了一番，觉得主动离职不如趁这次裁员顺势而为，既能体面抽身，还能拿到N+1的补偿，索性就在裁员名单统计时，主动举起了手。

后来偶然得知，在12月中旬后又裁撤了一波，加起来我们部门几乎要被整体裁撤，那一刻反倒觉得自己的决定格外明智 —— 主动选择离开，总比被动点名辞退多了一份体面与从容。而公司在12月中旬正式通知了我们这些主动离职的人，特意给了半个月居家的缓冲时间，约定12月31日正式办理离职手续，补偿与12月的工资，会在1月10号一同发放。这段不慌不忙的缓冲期，也成了我安心备战新工作的黄金时间。

## 从投石问路到全面出击

刚开始，我只是随手投了几份简历试试水，核心目的不是急于拿到offer，而是想探探当前大厂的技术招聘侧重点，摸清行业用人趋势。等心里有了大致方向后，我便立刻投入到系统复习中，查漏补缺、巩固核心技能。12月中旬，伴随着离职倒计时的临近，我正式开启了求职之路。起初面试时，面对面试官的连环提问，我还有些磕磕绊绊，不少知识点掌握得不够扎实，回答也不够流畅连贯。但我没有气馁，每次面试结束后，都会静下心来复盘总结，梳理没答好的问题、补齐遗漏的知识点，一点点打磨自己的面试状态。

进入1月份，我的面试状态彻底回暖，不管是一面的基础考察，还是二面的深度追问，都能顺利通过，每一场都成功走到了谈薪阶段。截止到目前，从正式求职开始算起，我一共拿到了7份offer，类型各不相同：有稳定靠谱的央企岗位，有薪资可观的小团队负责人岗位，也有离家较远、薪资平平的普通岗位，足够我从容权衡、谨慎选择。

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

其中，那份小团队负责人的offer，我原本还是十分期待的，其薪资不仅达到了我的预期，岗位权责也和我的职业规划高度契合。可没想到，就在offer走流程的最后阶段，却因为我是非统招本科的学历，被老板直接否决了。说真的，那一刻心里满是无奈，只剩一个大大的“服”字，我所有的努力，在一张统招本科文凭面前，仿佛都变得不值一提。

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

至于其他几份 offer，要么是离家太远，每天通勤成本太高；要么是薪资没达到我的预期，和我未来的职业规划不匹配，权衡再三，最终还是都婉拒了。

截止到目前我选择了一份同上家公司相同距离的，薪资上也在我得预期范围内的公司，也算是确定最终的去向，为我的这次找工作，画上了一个完美的句号。同时这段求职经历，让我也收获了很多，也沉淀了不少实用的求职技巧，今天就整体复盘一下，希望能给正在求职的同行们，提供一点参考。

我的整个求职流程，总结为一份 **求职框架**，大概可以分为四个阶段：面试前的准备、打招呼投简历、面试中的埋点技巧，以及面试后的复盘总结。每一个阶段都有对应的侧重点，做好每一步，才能提高求职效率，少走弯路。

求职框架的积累

求职框架的积累需要从以下2个维度思考：

* 理解面试官是怎么招人
* 理解当前的市场行情

### 面试前的准备：精准定位，拒绝盲目投递

面试前的准备，直接决定了求职的起点高低，盲目投递只会浪费时间和精力。我的习惯是，先明确自己的核心需求：薪资范围必须在自己的预算以内，公司位置尽量离家近（减少通勤内耗），岗位方向要和自己的技术栈、职业规划匹配。
另外，我会重点看目标岗位的JD，梳理出岗位要求的核心技术点，针对性地复习，同时确认当前岗位的薪资范围是否匹配自己的预算，提前摸清方向，才能在面试中有的放矢。

其实求职的本质就是 **“买卖双方的撮合”**，既然是撮合，那就 **符合一切供需的规律**，比如说我们要找好的工作，核心是 **需求的匹配**，而不是你绝对的优秀，尤其是当前的市场行情，需要特别能理解这件事，所有的跳槽都要看 **匹配度**，例如以下几个方面：

* 同行业
* 同领域
* 同类型业务

所以在同电商领域，你是淘宝京东出身，那么相比于其他人，你胜出，本质就是如此。所以在相对的匹配度情况下，需要你具备一定的延伸能力，其实掌握这部分就可以指定属于自己的投递策略了。

提示

价格是由供需关系决定的，像现在行业内卷，其实就是人多，hr少，那就是会被压价，被拒绝。要拿高薪资，需要去找行业内供需关系不平衡的领域，例如具备 AI 经验的人涨幅一定会多，因为当前这个行业里面，就是处于一种供需不平衡的状态，每个公司都要搞 AI，但是匹配的人就是少，所有有类似的经验，那就能在当前的时间点上，拿到更多的涨薪幅度。

### 打招呼投简历：掌握技巧，打破“已读不回”魔咒

我之前做过招聘，很清楚现在的求职市场有多卷，当下一个岗位开放一天，就能收到几百份简历，如何让面试官注意到你的简历，是求职过程中最难的一步。大多数招聘平台的打招呼功能，都有阅读状态回执，而我投递的很多简历，其实都没有被查阅过，连“已读”都没有，更别说获得面试机会了。

经过几次尝试，我总结了一个小经验：对于自己期待值比较高的岗位，打招呼之后先收藏；如果超过24小时，打招呼信息还是“未读”，我会再次给招聘方发送一条消息，简洁明了地突出自己的核心优势（比如8年开发经验、深耕微服务架构、有团队管理经验等），主动争取沟通机会。

这里有个前提：你的简历必须足够优秀，或者业务匹配度足够高，总得有一个亮点能抓住面试官的注意力，否则再主动，也很难获得青睐。

### 面试中的埋点技巧：主动输出，凸显自身价值

如果你的简历被拾起，并且收到了面试邀约，那么恭喜你，你已经成功了50%。剩下的50%，就需要你用扎实的技术功底、从容的心态，以及巧妙的“埋点”，充分凸显自身价值。

所谓“埋点”，就是在面试过程中，主动输出一些能体现自己优势、经验的内容，引导面试官围绕这些点提问，从而让面试官更全面地了解你的能力。我一般会从个人介绍开始埋点，我的个人介绍是这样的：

* 面试官您们好，我是XXX，拥有8年的互联网开发经验，深耕过互联网金融、电商、供应链等业务领域，长期专注于微服务分布式架构设计、源码级的驱动开发与性能调优，同时也具备多个大型互联网应用从 0-1 的架构设计的经验，也是总结形成了自己的架构设计的一套方法论。
* 在上家公司中，也是主要承担了一个开发组长的角色，主导了需求的全生命周期的管理与人才培养，掌握了从需求评审到技术方案的设计评审、代码review和需求落地后的整体效果复盘的全流程化的管理，通过技术分享和技术研讨会，提升团队整体技术水平，实现了团队价值的提升。
* 工作之余，我也是保持着一个良好习惯，经常复盘和总结，并会将一些学习到的知识体系、个人的深度思考和工作中的一些实战经历整理成文档，形成了自己的技术博客，这让我能不断地把经验转化为扎实的能力，期待未来发挥自己更大的价值。

这段话里，“架构设计的方法论”、“团队价值的提升”、“技术博客”，就是我埋下的三个核心亮点，从技术到管理，同时将我的个人成长都涵盖在内。面试官看到这些内容，大概率会围绕这些点提问，而这些都是我熟悉且能充分展现自己优势的领域，既能避免被问到陌生知识点的尴尬，也能让面试官快速捕捉到我的核心价值。

提示

以上是在自我介绍中做的埋点，我们需要在面试的过程中也要做到埋点，例如 Mysql 的优化，可以提到深度分页的优化中，如果问到深度分页，可以结合 `海量数据 + 复杂查询条件`的场景，需要 ES 优化，那面试官就有可能在追问你在 ES 中是如何实现的。

结合我这几十场面试的经历，面试官的提问主要围绕以下几个方向，我也整理了自己被问到的高频问题，供同行们参考：

**（一）项目经历高频提问**

* 分库分表的实现思路、分片策略的抉择、用到的分片算法
* 分库分表存在哪些问题，深度分页如何实现，数据倾斜如何解决
* 为什么自研动态线程池，而不用开源的；自研动态线程池如何实现，有没有告警机制
* 如何保障动态切换线程的安全性
* 灰度发布是如何实现的
* Guava的令牌桶如何实现分布式限流

**（二）项目职责高频提问**

* 简历中写的“JVM调优（GC暂停时间降低70%）”，具体如何实现，调优前后指标对比
* 内存泄漏的排查分析思路
* 对ZGC的了解，其实现原理，与G1的对比优势
* SQL优化（慢查询减少90%）的具体实现方法

**（三）场景题高频提问**

* 千万级数据库表如何做新表迁移
* 如何实现秒杀场景
* 百万并发下的注册登录系统如何设计
* 提升系统QPS的手段有哪些
* Redis中list类型的使用会存在哪些问题
* 你遇到过哪些故障或者事故

**（四）基础八股文高频提问**

* AQS的实现原理，CLH变种队列的改进点
* ReententLock的实现原理，底层锁中断机制如何实现
* Object.wait与LockSupport.park的区别
* JDK 17、21的新特性了解
* 三色并发标记
* 网络IO模型有哪些，零拷贝了解过吗
* 线程池如何调优
* 你了解哪些设计模式
* 事务失效的场景有哪些
* MVCC 机制 与 Buffer Pool 、日志体系了解吗

**（五）架构师岗位高频提问**

* 现有系统的架构设计的思路
* 如何保障服务高可用
* HTTP与RPC的区别
* Redis如何保障服务一致性，Mysql缓存一致性如何保障
* Raft算法、MVCC机制的了解
* 分库分表的事务如何实现
* Nacos如何做服务剔除，网关的作用，负载均衡算法
* 限流的方式有哪些，微服务之间如何调用，OpenFeign的实现原理
* 微服务模式与SOA的区别，集群的实现方式
* Redis存储的数据在节点中是否有重复

### 面试后复盘总结：查漏补缺，稳步提升

我始终觉得，面试的核心不是“通过”，而是“成长”。不管面试结果如何，每次面试结束后，我都会花1-2小时进行复盘总结，这也是我从磕磕绊绊到自信应对的关键。

复盘的重点的有三个：一是那些完全没回答上来的问题，说明这是自己的知识盲区，会系统地查找资料、学习知识点，直到完全掌握；二是回答得不够流畅、不够全面的问题，会梳理清晰的答题思路，补充遗漏的知识点，下次遇到类似问题能从容应对；三是延伸思考，比如面试官问了分库分表的实现，我会顺便复习分库分表的其他相关知识点，形成知识体系，避免“只会一个点，不会一个面”。

就这样，一场场面试，一次次复盘，我发现自己不会的知识越来越少，答题的思路越来越清晰，面试也变得越来越顺利。从一开始的紧张忐忑，到后来的从容自信，这段求职经历，虽然有过被卡学历的无奈，有过婉拒offer的纠结，但更多的是成长和收获。

如何复盘？

需要明确一点，我们的复盘，一定 **不要来自于个人的认知**，而是要 **来自于市场给你的反馈**，完全可以根据简历的通过率，面试通过率，面试的具体内容等，去 **有针对性的调整** 求职策略、简历或者面试过程，这才是复盘与求职的最最最核心能力。

像我个人就是在面试完成以后，都会带上一个个人问题：**在我的本次面试过程中存在哪些不足呢，方便我后续的复盘和总结**。 大多数的时候，面试官会指出你的不足，这也是我们后续需要复盘提升的方面。

目前我个人面试过程中还存在一些需要学习改进的地方：

* 面试讲述太繁琐，我目前是由 “浅” 到 “深”，接下来就是 由 “深” 到 “简”
* 深入底层的基础知识，像操作系统、网络原理、软件工程等，由点成面进行延伸
* 管理上的方法论，目前还处于一种 “野鸡” 状态，需要系统化的学习

## 总结

总结一下，能不能拿到好的 offer，简历只是你的敲门砖，而面试技巧是你的加分项，其实现在大家都有，而且由于这种技巧层面的普及，尤其是 AI 的出现，大家现在都会。而现在公司的招人策略，都是倾向于 **横向对比**，也就是集中看一批候选人选出优秀者，其本质上就是看你能不能再专业领域上面拼过其他人，能不能再横向对比中胜出，所以说过往中复盘，总结，提升应该去花更多的时间，提高自己的核心竞争力。

最后，想对正在求职的同行们说一句：求职路上，难免会遇到挫折和不顺，可能会被拒绝，可能会迷茫，但请不要放弃。认真做好每一次准备，做好每一次复盘，查漏补缺，稳步提升，你总会遇到那个认可你、适合你的岗位。加油，我们都能在自己的领域里，闪闪发光～

一个高级牛马 2025 ~ 2026 的求职赎身记

支撑百万级并发：从 RT、QPS 到全链路压测的指标拆解与落地

在互联网应用的演进过程中，支撑百万级并发（QPS）是许多大型系统必须跨越的一道门槛。这不仅仅是硬件堆叠的问题，更是一场关于架构设计、资源调度、数据一致性和异步处理的艺术。本文将结合微服务拆分、连接池、RPC、线程模型、缓存、消息队列及数据库优化等多个维度，深入探讨其执行原理、解决的瓶颈以及潜在的缺点。

今天我将自己所掌握的支撑高并发体系的知识内容进行总结，从微服务拆分到分库分表，各个层面都有考虑，但深层需求可能不只是罗列技术，而是如何将这些技术整合，并在设计时的权衡和取舍，形成完整的架构思路。

本文不涉及硬件的调整，毕竟想要提升并发能力，最简单的无非就是一台机器不够那就十台，只要老板同意，沙漠都能种出水果。

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

### 微服务分布式的拆分

将单体应用拆分为多个独立的、围绕业务能力构建的小型服务（微服务），每个服务独立部署、扩展和维护，结合服务注册与发现（如Nacos, Eureka）机制实现动态寻址。

当我们的服务存在单点故障与性能瓶颈时，微服务，分布式集群部署应然而生。根据业务的垂直领域拆分后，其隔离性与可用性增强，同时针对一些特定高负载模块可以进行独立扩容，扩展性非非常强。

在高并发的场景下，其一台机器的资源是有限的，大多数情况下，我们采用 Tomcat 作为 Web 容器，其中内部配置的 `Executor` 和 `Connector` 共同构成了连接处理模型。通过配置 `maxThreads`（最大工作线程数）、`acceptCount`（等待队列长度）等参数，形成一个线程池来处理 HTTP 请求，当微服务拆分以后，每个服务都对应一个 Web 容器处理请求，并发度立马提升上来了，如果还存在瓶颈，那么单个微服务的分布式集群部署，也是可以提升并发量的手段。

Tomcat 容器的优化

现在主流的还是微服务架构，想要提升最大的并发处理能力，那么 Tomcat Web 容器的优化也是必不可少的。例如 `maxThreads`（最大工作线程数）、`acceptCount`（等待队列长度）等参数的配置。

像传统的 Tomcat 线程池（BIO）在处理IO操作（如数据库查询、RPC调用）时，线程会被阻塞挂起，导致线程利用率不高。尽可能的使用 Tomcat 8 及以后得版本，其默认的 I/O 模型改为了 NIO，这是一个非常重要的架构升级，主要是为了解决高并发场景下的性能和扩展性问题。

**缺点：**

虽然拆分了微服务，但是同样也带了各种问题，例如：

* 运维复杂度剧增：需要管理成百上千个服务的部署、监控和日志收集。
* 网络通信开销：服务间调用引入网络延迟，且需处理网络分区、超时、重试等分布式固有问题。
* 分布式事务难题：数据一致性从单机事务变为跨服务的分布式事务，实现难度大。

### RPC 框架的选择

RPC（远程过程调用）框架屏蔽了底层网络通信细节，让服务调用像本地方法调用一样简单。常见的有基于 HTTP 的`Feign/OpenFeign`，基于 TCP 的 `Dubbo/gRPC/Thrift`。

**解决的瓶颈：**

从通信效率而言，相比 `HTTP`，在建立 TCP 连接后，存在 **队头阻塞** 的性能瓶颈，同时传输协议采用 JSON 格式，定义的请求头与请求体内容体积大，占用带宽的传输。

而基于 TCP 的 RPC 框架，通常采用自定义传输层协议（例如 Dubbo）又或者采用成熟的 HTTP/2.0 协议，其无限并发流解决了传统 HTTP 1.1 的性能瓶颈问题，同时采用二进制序列化（如Protobuf, Hessian），传输体积更小，解析更快。

### 线程池

Java 中通过 `ThreadPoolExecutor` 自定义线程池，核心参数包括核心线程数、最大线程数、队列、拒绝策略等，将大幅度利率 CPU 资源，用于异步处理耗时任务（如发短信、写日志），提升了并发性能。

**解决的瓶颈：**

* 资源控制：防止无限制创建线程导致系统崩溃。
* 异步解耦：将非核心业务（如通知、统计）异步化，缩短主链路响应时间。

**缺点：**

* 配置复杂且易出错：不同业务场景（CPU密集型 vs IO密集型）需不同配置，配置不当会导致死锁、线程饥饿或OOM。
* 线程泄漏风险：如果任务中发生死循环或阻塞未处理，可能导致线程池耗尽。

提示

线程池是我们编码中最常用的并发提升手段了，就不过多陈述。

### JDK21 的虚拟线程

JDK21 引入的 **虚拟线程（Virtual Threads）**，这是划时代的变化，让我们系统天然的支撑高并发与高吞吐。本质就是轻量级线程，从底层的操作系统调用，变为了由 JVM 调度。一个操作系统层面的平台线程，管理着多个虚拟线程，类似于一致性哈希算法中的虚拟节点，与物理节点存在映射关系。它允许创建数百万个虚拟线程而不会耗尽内存。通过 `Executors.newVirtualThreadPerTaskExecutor()` 创建。

**解决的瓶颈：**

虚拟线程的出现，解决了我们传统线程池中，RPC 调用与 IO 调用时产生的线程阻塞，CPU资源浪费的情况。同时传统平台线程（Platform Threads）受限于OS线程数，创建百万级线程不现实。而虚拟线程解决了此类问题，一个虚拟线程只占用4KB，同时当虚拟线程遇到 IO 阻塞时，JVM 会自动将其从载体线程（Carrier Thread）上卸下，调度其他虚拟线程运行，极大提升了吞吐量。

**一句话，虚拟线程是将 CPU 资源利用到了极致，比我更像纯牛马。**

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

虽然虚拟线程强大，但是也存在一些 **缺点：**

* JDK版本限制：需要JDK21+。
* 并非万能：对于CPU密集型任务，虚拟线程优势不明显，甚至可能因频繁调度带来额外开销。仍需合理使用结构化并发（Structured Concurrency）管理生命周期。

### 一级缓存，二级缓存

缓存也是我们提升并发性能最常用的手段：

* 一级缓存：本地缓存（如Caffeine, Guava Cache），存储在应用JVM内存中，访问速度极快，无网络开销。
* 二级缓存：分布式缓存（如Redis, Memcached），存储在独立服务中，数据共享，容量大。

我发现微服务架构中，使用最频繁的还是分布式缓存，对于本地缓存反而使用的并不太多，我个人觉得造成这种情况的原因可能是因为大多数的系统的 QPS 并不太高，分布式缓存足以支撑，同时本地缓存还需要保证一致性问题，比如通过 MQ 广播机制进行缓存更新，增加了系统复杂度，或许会让人望而生怯吧。

**解决的瓶颈：**

对于高并发性能的角度来考虑，通过缓存热点数据，减少对数据库的直接访问，降低数据库负载。同时使用本地缓存极大降低了读取延迟，将机器资源也算是利用到家了。

也存在了一些 **缺点：**

* 数据一致性问题：缓存与数据库、不同实例间的本地缓存可能存在不一致。
* 缓存穿透/雪崩/击穿：需额外设计（布隆过滤器、互斥锁、随机过期时间）来防范。

本地缓存对系统内存占用的问题

我探索过一些方案，有些人觉得本地缓存占用 JVM 堆内存，可能会导致 GC 压力增大。

我个人觉得缓存本身解决热点数据问题，对于高频读，低频写的热点数据而言，从数据量上来看，大多数也不会占用太多的空间，与分布式缓存从性能成本上考虑，还是很有必要的，如果真的要缓存几百M的热点数据，那么就需要额外的一些考虑。

### Redis 分桶

其实 Redis 分桶，是将一个大 Key 的数据拆分成多个子Key（桶）存储。例如，一个包含百万个元素的集合，可以按Hash 取模拆分成 100 个Key，每个 Key 存储约1万个元素。

为什么要分桶呢，这还得从 Redis cluster 说起，其集群原理是通过哈希槽实现的，每个集群下的主节点负责一部分哈希槽的节点，当key通过 CRC16 算法计算出哈希槽节点，会到对应的节点上进行数据的读写，那么问题来了，如果某个 key 需要支撑百万并发呢，那么所处在哈希槽节点的机器，不就存在性能瓶颈了么？接下来我们瞅瞅 Redis 分桶还解决了哪些问题。

**解决的瓶颈：**

* 解决热点Key问题：分散单个 Key 的访问压力，更好利用 Redis 集群的多个节点解决读写瓶颈。
* 大 Key 阻塞：Redis是单线程处理命令，操作大Key（如 hget 百万级 Hash）会导致 Redis 阻塞，引发超时。
* 网络传输慢：大 Key 的网络传输耗时长，占用带宽。

**缺点：**

* 编程复杂度：读写数据时需要遍历所有桶，逻辑变复杂。
* 原子性挑战：跨桶的操作难以保证原子性（除非使用Lua脚本）。

数据一致性可采用 Lua 脚本，保障原子性

Redis 支持使用 Lua 脚本执行多条命令。Lua 脚本在 Redis 服务端以原子性方式执行，期间不会被其他命令插入，同时减少了网络开销，将多个操作合并为一次网络请求。

Lua 脚本也是存在一定的阻塞风险：如果Lua脚本执行时间过长，会阻塞 Redis 主线程，影响其他请求。需严格控制脚本逻辑的简洁性。

### MQ 异步削峰填谷

引入消息队列（如Kafka, RocketMQ, RabbitMQ）作为生产者和消费者之间的缓冲层。生产者将请求/事件发送到 MQ后立即返回，消费者按自身处理能力从 MQ 拉取消息处理，是解决写入瓶颈的最佳手段。

* 系统解耦：上下游系统不直接依赖，一方故障不影响另一方。
* 流量削峰：在流量洪峰（如秒杀）时，MQ作为“蓄水池”，暂存超出系统处理能力的请求，防止系统被瞬间打垮。
* 异步处理：非核心链路（如发红包、更新统计）异步化，提升主链路响应速度。

**缺点：**

* 提高了系统复杂性：引入 MQ 增加了系统组件，MQ 本身故障会影响整个系统。
* 数据一致性延迟：引入了最终一致性，无法立即看到操作结果。
* 消费问题：需保证消费者业务的幂等性、解决消息顺序、消息堆积等问题。

### 读写分离与分库分表

利用数据库主从复制机制，主库负责写入，一个或多个从库负责读取，解决了读性能的瓶颈问题。

**解决的瓶颈：**

* 读写互相影响：复杂的查询（报表、列表）会消耗大量数据库资源，影响写入性能。读写分离将读压力分流到从库。
* 读扩展性：通过增加从库数量，可以线性提升系统的读吞吐量。

主从延迟

读写分离架构下最大的问题就是主从延迟，数据从主库同步到从库有延迟（毫秒级），导致刚写入的数据可能在从库读不到（最终一致性），这是无法避免的。从库越多，延迟越大，主库需向所有从库发送 binlog，从库数量增加会加重主库IO负担。

对于一致性要求较高的数据，解决方案就是可以 **强制路由读主库**。

当单库单表数据量过大（如超过千万行）或写入 TPS 超过单机极限时，通过中间件（如ShardingSphere, MyCat）按照分片键（如用户ID、订单ID）将数据水平拆分到多个数据库或表中，这样写入时，就从不同库的连接池资源进行处理，解决了写入瓶颈的问题。

* 单机存储与性能瓶颈：突破单机磁盘、内存、CPU的限制，实现数据库的水平扩展。
* SQL性能下降：大表的查询、更新、索引维护成本极高。分表后数据量级降低，SQL执行效率提升。

**缺点：**

* 架构复杂度剧增：引入了分布式数据库的复杂性。
* 分布式事务难题：跨库事务无法使用本地事务，需引入Seata等分布式事务框架，或采用最终一致性方案。
* 跨库JOIN与聚合：原本简单的JOIN查询和COUNT/SUM聚合变得非常困难，通常需要通过应用层聚合或借助ES等外部系统解决。
* 扩容成本：重新分片（Resharding）数据迁移过程复杂且风险高。
* 深度分页：多个表数据的需要合并到一起进行分页，深度分页问题没有完美的解决方式。

注意

分库分表的引入，与分布式的引入一样，存在着很多问题，我们应该先从数据库层面、索引层面、SQL层面进行优化，在非无法避免的情况下，最好不要引入分库分表，复杂性真的是太高了。

**总结**

支撑百万级并发是一个系统工程，没有银弹，如何突出自己的价值给公司节省多少资源就在此时此刻。

上述每个维度都是解决特定瓶颈的利器，但也带来了相应的复杂性和新的挑战。在实际架构设计中，我们需要根据业务场景的特点（读多写少？强一致性要求？数据量级？），权衡利弊，组合使用这些技术手段，构建一个高可用、高性能、可扩展的分布式系统。

同时，完善的监控、告警和预案机制也是保障系统稳定运行不可或缺的一环。

支撑百万级并发：纵观微服务的全链路实战设计

对于源码的掌握我了然于胸，记得 21 年开始学习 Spring IOC 源码的时候，我足足看了半年多，一点一点的去分析，可惜当时还没开始写博客，都是做思维导图和流程图居多，后续在整理成系列的博客文章，此处直接晒图，看图捋一遍过程，也相当于复习了

**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)