diff --git a/README.md b/README.md index 2e8f1368165..7c8eafa8d52 100755 --- a/README.md +++ b/README.md @@ -15,12 +15,23 @@ > - **面试资料补充**： > - [《Java 面试指北》](https://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html)：四年打磨，和 [JavaGuide 开源版](https://javaguide.cn/)的内容互补，带你从零开始系统准备面试！ > - [《后端面试高频系统设计&场景题》](https://javaguide.cn/zhuanlan/back-end-interview-high-frequency-system-design-and-scenario-questions.html)：30+ 道高频系统设计和场景面试，助你应对当下中大厂面试趋势。 -> - **使用建议** ：有水平的面试官都是顺着项目经历挖掘技术问题。一定不要死记硬背技术八股文！详细的学习建议请参考：[JavaGuide 使用建议](https://javaguide.cn/javaguide/use-suggestion.html)。 +> - **使用建议** ：如果你想要系统准备 Java 后端面试但又不知道如何开始的，可以参考 [Java 后端面试通关计划（后端通用）](https://javaguide.cn/interview-preparation/backend-interview-plan.html)。 > - **求个 Star**：如果觉得 JavaGuide 的内容对你有帮助的话，还请点个免费的 Star，这是对我最大的鼓励，感谢各位一起同行，共勉！传送门：[GitHub](https://github.com/Snailclimb/JavaGuide) | [Gitee](https://gitee.com/SnailClimb/JavaGuide)。 > - **转载须知**：以下所有文章如非文首说明为转载皆为 JavaGuide 原创，转载请在文首注明出处。如发现恶意抄袭/搬运，会动用法律武器维护自己的权益。让我们一起维护一个良好的技术创作环境！ +## 面试准备 + +- [⭐Java 后端面试通关计划（涵盖后端通用体系）](./docs/interview-preparation/backend-interview-plan.md) (一定要看 :+1:) +- [如何高效准备 Java 面试？](./docs/interview-preparation/teach-you-how-to-prepare-for-the-interview-hand-in-hand.md) +- [Java 后端面试重点总结](./docs/interview-preparation/key-points-of-interview.md) +- [Java 学习路线（最新版，4w+ 字）](./docs/interview-preparation/java-roadmap.md) +- [程序员简历编写指南](./docs/interview-preparation/resume-guide.md) +- [项目经验指南](./docs/interview-preparation/project-experience-guide.md) +- [面试太紧张怎么办？](./docs/interview-preparation/how-to-handle-interview-nerves.md) +- [校招没有实习经历怎么办？实习经历怎么写？](./docs/interview-preparation/internship-experience.md) + ## Java ### 基础 @@ -203,6 +214,7 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8](https://docs.oracle. **重要知识点：** - [MySQL 索引详解](./docs/database/mysql/mysql-index.md) +- [MySQL 索引失效场景总结](./docs/database/mysql/mysql-index-invalidation.md) - [MySQL 事务隔离级别图文详解)](./docs/database/mysql/transaction-isolation-level.md) - [MySQL 三大日志(binlog、redo log 和 undo log)详解](./docs/database/mysql/mysql-logs.md) - [InnoDB 存储引擎对 MVCC 的实现](./docs/database/mysql/innodb-implementation-of-mvcc.md) @@ -325,11 +337,14 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8](https://docs.oracle. ## 分布式 +- [⭐分布式高频面试题](https://interview.javaguide.cn/distributed-system/distributed-system.html) + ### 理论&算法&协议 - [CAP 理论和 BASE 理论解读](https://javaguide.cn/distributed-system/protocol/cap-and-base-theorem.html) - [Paxos 算法解读](https://javaguide.cn/distributed-system/protocol/paxos-algorithm.html) - [Raft 算法解读](https://javaguide.cn/distributed-system/protocol/raft-algorithm.html) +- [ZAB 协议解读](https://javaguide.cn/distributed-system/protocol/zab.html) - [Gossip 协议详解](https://javaguide.cn/distributed-system/protocol/gossip-protocol.html) - [一致性哈希算法详解](https://javaguide.cn/distributed-system/protocol/consistent-hashing.html) diff --git a/docs/.vuepress/components/unlock/GlobalUnlock.vue b/docs/.vuepress/components/unlock/GlobalUnlock.vue index c5bbf1aa990..a1abdcb316a 100644 --- a/docs/.vuepress/components/unlock/GlobalUnlock.vue +++ b/docs/.vuepress/components/unlock/GlobalUnlock.vue @@ -18,12 +18,12 @@ >
-

继续阅读全文

+

人机验证

- 抱歉，由于近期遭受爬虫攻击，为保障正常阅读体验，本站部分内容已开启一次性验证。验证后全站自动解锁。 + 为保障正常阅读体验，本站部分内容已开启一次性验证。验证后全站解锁。

@@ -34,11 +34,9 @@ />

扫码/微信搜索关注 - JavaGuide 官方公众号 -

-

- 回复 “验证码” 获取 + “JavaGuide”

+

回复 “验证码”

@@ -357,13 +355,13 @@ watch( } .qr-image { - width: 136px; - height: 136px; + width: 180px; + height: 180px; } .qr-tip { margin: 0.45rem 0 0; - font-size: 0.86rem; + font-size: 0.96rem; } .highlight { diff --git a/docs/.vuepress/components/unlock/UnlockContent.vue b/docs/.vuepress/components/unlock/UnlockContent.vue index 3da283d20bf..f85351ae8f4 100644 --- a/docs/.vuepress/components/unlock/UnlockContent.vue +++ b/docs/.vuepress/components/unlock/UnlockContent.vue @@ -9,17 +9,17 @@
🔒 -

继续阅读全文

+

人机验证

- 抱歉，由于近期遭受大规模爬虫攻击，为保障正常阅读体验，本站深度内容已开启一次性验证。验证通过后，全站内容将自动解锁。 + 为保障正常阅读体验，本站部分内容已开启一次性验证。验证后全站自动解锁。

公众号二维码

- 扫码关注公众号，回复 “验证码” 获取 + 扫码关注公众号，回复 “验证码”

diff --git a/docs/.vuepress/sidebar/index.ts b/docs/.vuepress/sidebar/index.ts index 3a44d8cbe45..abe420496e5 100644 --- a/docs/.vuepress/sidebar/index.ts +++ b/docs/.vuepress/sidebar/index.ts @@ -33,6 +33,7 @@ export default sidebar({ collapsible: true, prefix: "interview-preparation/", children: [ + "backend-interview-plan", "teach-you-how-to-prepare-for-the-interview-hand-in-hand", "resume-guide", "key-points-of-interview", @@ -280,6 +281,7 @@ export default sidebar({ "mysql-high-performance-optimization-specification-recommendations", createImportantSection([ "mysql-index", + "mysql-index-invalidation", { text: "MySQL三大日志详解", link: "mysql-logs", @@ -446,7 +448,10 @@ export default sidebar({ ], }, "system-design-questions", - "design-pattern", + { + text: "设计模式常见面试题总结", + link: "https://interview.javaguide.cn/system-design/design-pattern.html", + }, "schedule-task", "web-real-time-message-push", ], @@ -457,6 +462,10 @@ export default sidebar({ prefix: "distributed-system/", collapsible: true, children: [ + { + text: "⭐分布式高频面试题", + link: "https://interview.javaguide.cn/distributed-system/distributed-system.html", + }, { text: "理论&算法&协议", icon: ICONS.ALGORITHM, @@ -466,6 +475,7 @@ export default sidebar({ "cap-and-base-theorem", "paxos-algorithm", "raft-algorithm", + "zab", "gossip-protocol", "consistent-hashing", ], diff --git a/docs/README.md b/docs/README.md index 03f03bf1c80..d94d02fa73a 100644 --- a/docs/README.md +++ b/docs/README.md @@ -2,7 +2,7 @@ home: true icon: home title: JavaGuide（Java 面试 & 后端通用面试指南） -description: JavaGuide 是一份面向后端学习与面试的指南，以 Java 面试为核心，同时覆盖数据库/MySQL、Redis、分布式、高并发、高可用、系统设计等通用后端知识，适用于校招/社招复习。 +description: JavaGuide 是一份 Java 面试和后端通用面试指南，同时覆盖数据库/MySQL、Redis、分布式、高并发、高可用、系统设计等通用后端知识，适用于校招/社招复习。 heroImage: /logo.svg heroText: JavaGuide tagline: Java 面试 & 后端通用面试指南，覆盖计算机基础、数据库、分布式、高并发与系统设计 @@ -42,10 +42,11 @@ footer: |- ## 🌟文章推荐 +- **面试准备**： [Java 后端面试通关计划（涵盖后端通用体系）](https://javaguide.cn/interview-preparation/backend-interview-plan.html)（如果你想要系统准备 Java 后端面试但又不知道如何开始的，一定要看这篇） - **Java 系列**：[Java 学习路线 (最新版，4w + 字)](https://javaguide.cn/interview-preparation/java-roadmap.html)、[Java 基础常见面试题总结](https://javaguide.cn/java/basis/java-basic-questions-01.html)、[Java 集合常见面试题总结](https://javaguide.cn/java/collection/java-collection-questions-01.html)、[JVM 常见面试题总结](https://interview.javaguide.cn/java/java-jvm.html) - **计算机基础**：[计算机网络常见面试题总结](https://javaguide.cn/cs-basics/network/other-network-questions.html)、[操作系统常见面试题总结](https://javaguide.cn/cs-basics/operating-system/operating-system-basic-questions-01.html) - **数据库系列**：[MySQL 常见面试题总结](https://javaguide.cn/database/mysql/mysql-questions-01.html)、[Redis 常见面试题总结](https://javaguide.cn/database/redis/redis-questions-01.html) -- **分布式系列**：[分布式 ID 介绍 & 实现方案总结](https://javaguide.cn/distributed-system/distributed-id.html)、[分布式锁常见实现方案总结](https://javaguide.cn/distributed-system/distributed-lock-implementations.html) +- **分布式系列**：[分布式高频面试题总结](https://interview.javaguide.cn/distributed-system/distributed-system.html) ## 🚀 PDF 版本 & 面试交流群 @@ -56,7 +57,7 @@ footer: |- ## 🌐 关于网站 -JavaGuide 已经持续维护 6 年多了，累计提交了接近 **6000** commit ，共有 **570+** 多位贡献者共同参与维护和完善。真心希望能够把这个项目做好，真正能够帮助到有需要的朋友！ +JavaGuide 已经持续维护 6 年多了，累计提交了 **\*\*\*\***6000+**\***\*** commit ，共有 \***\*\***\*620+\*\*\***\*\*\* 多位贡献者共同参与维护和完善。真心希望能够把这个项目做好，真正能够帮助到有需要的朋友！ 如果觉得 JavaGuide 的内容对你有帮助的话，还请点个免费的 Star（绝不强制点 Star，觉得内容不错有收获再点赞就好），这是对我最大的鼓励，感谢各位一路同行，共勉！传送门：[GitHub](https://github.com/Snailclimb/JavaGuide) | [Gitee](https://gitee.com/SnailClimb/JavaGuide)。 diff --git a/docs/about-the-author/zhishixingqiu-two-years.md b/docs/about-the-author/zhishixingqiu-two-years.md index f28927dfc35..f1f7885390a 100644 --- a/docs/about-the-author/zhishixingqiu-two-years.md +++ b/docs/about-the-author/zhishixingqiu-two-years.md @@ -74,7 +74,7 @@ star: 2 星球更新了 **《Java 面试指北》**、**《Java 必读源码系列》**（目前已经整理了 Dubbo 2.6.x、Netty 4.x、SpringBoot2.1 的源码）、 **《从零开始写一个 RPC 框架》**（已更新完）、**《Kafka 常见面试题/知识点总结》** 等多个优质专栏。 -![](https://oss.javaguide.cn/xingqiu/image-20220211231206733.png) +![星球专属专栏](https://oss.javaguide.cn/xingqiu/image-20220211231206733.png) 《Java 面试指北》内容概览： @@ -137,7 +137,7 @@ JavaGuide 知识星球优质主题汇总传送门： PATH 决定了 shell 将到哪些目录中寻找命令或程序 -> HOME 当前用户主目录 -> HISTSIZE 　历史记录数 -> LOGNAME 当前用户的登录名 -> HOSTNAME 　指主机的名称 -> SHELL 当前用户 Shell 类型 -> LANGUAGE 　语言相关的环境变量，多语言可以修改此环境变量 -> MAIL 　当前用户的邮件存放目录 +> PATH 决定了 shell 将到哪些目录中寻找命令或程序 +> HOME 当前用户主目录 +> HISTSIZE 　历史记录数 +> LOGNAME 当前用户的登录名 +> HOSTNAME 　指主机的名称 +> SHELL 当前用户 Shell 类型 +> LANGUAGE 　语言相关的环境变量，多语言可以修改此环境变量 +> MAIL 　当前用户的邮件存放目录 > PS1 　基本提示符，对于 root 用户是#，对于普通用户是\$ **使用 Linux 已定义的环境变量：** @@ -111,7 +135,17 @@ echo "helloworld!" 字符串是 shell 编程中最常用最有用的数据类型（除了数字和字符串，也没啥其它类型好用了），字符串可以用单引号，也可以用双引号。这点和 Java 中有所不同。 -在单引号中所有的特殊符号，如$和反引号都没有特殊含义。在双引号中，除了"$"、"\\"、反引号和感叹号（需开启 `history expansion`），其他的字符没有特殊含义。 +在单引号中，所有特殊字符（如 `$`、反引号、`\` 等）都失去特殊含义，被视为字面量。 + +在双引号中，以下字符保留特殊含义： + +- `$`：变量扩展（如 `$var`）和命令替换（如 `$(cmd)` 或 `` `cmd` ``） +- `\`：转义字符 +- `` ` `` 或 `$()`：命令替换（推荐使用 `$()` 语法） +- `!`：历史扩展（仅在交互式 Shell 中默认开启） +- `${}`：参数扩展 + +**注意**：单引号中的字符串是**完全字面量**，双引号中的字符串会进行变量和命令替换。 **单引号字符串：** @@ -168,33 +202,42 @@ echo $greeting_2 $greeting_3 ```shell #!/bin/bash -#获取字符串长度 +# 获取字符串长度 name="SnailClimb" -# 第一种方式 -echo ${#name} #输出 10 -# 第二种方式 -expr length "$name"; +# 第一种方式（推荐）：bash 内置 +echo ${#name} # 输出 10 +# 第二种方式：外部命令（性能较差） +expr length "$name" ``` -输出结果: +输出结果： ```plain 10 10 ``` -使用 expr 命令时，表达式中的运算符左右必须包含空格，如果不包含空格，将会输出表达式本身: +**说明**： + +- 推荐使用 `${#var}` 语法，这是 bash 内置功能，性能更好 +- `expr` 是外部命令，需要 fork 进程，性能较差 +- **`expr length` 是 GNU 扩展**，非 POSIX 标准。在 macOS 的 BSD expr 或其他系统上可能不支持 +- 如需可移植性，推荐使用 `${#var}` 或 `expr "$var" : '.*'`（POSIX 兼容） + +使用 expr 命令时，表达式中的运算符左右必须包含空格： ```shell -expr 5+6 // 直接输出 5+6 -expr 5 + 6 // 输出 11 +expr 5+6 # 直接输出 5+6（无空格） +expr 5 + 6 # 输出 11（有空格） +# 更推荐使用 bash 算术扩展： +echo $((5 + 6)) # 输出 11 ``` -对于某些运算符，还需要我们使用符号`\`进行转义，否则就会提示语法错误。 +对于某些运算符，还需要我们使用符号 `\` 进行转义： ```shell -expr 5 * 6 // 输出错误 -expr 5 \* 6 // 输出30 +expr 5 * 6 # 输出错误（未转义） +expr 5 \* 6 # 输出 30（正确转义） ``` **截取子字符串:** @@ -202,7 +245,7 @@ expr 5 \* 6 // 输出30 简单的字符串截取： ```shell -#从字符串第 1 个字符开始往后截取 10 个字符 +#从字符串第 0 个字符开始往后截取 10 个字符（索引从 0 开始） str="SnailClimb is a great man" echo ${str:0:10} #输出:SnailClimb ``` @@ -210,8 +253,8 @@ echo ${str:0:10} #输出:SnailClimb 根据表达式截取： ```shell -#!bin/bash -#author:amau +#!/bin/bash +# author: amau var="https://www.runoob.com/linux/linux-shell-variable.html" # %表示删除从后匹配, 最短结果 @@ -228,7 +271,11 @@ s5=${var##*/} #linux-shell-variable.html ### Shell 数组 -bash 支持一维数组（不支持多维数组），并且没有限定数组的大小。我下面给了大家一个关于数组操作的 Shell 代码示例，通过该示例大家可以知道如何创建数组、获取数组长度、获取/删除特定位置的数组元素、删除整个数组以及遍历数组。 +**bash 2.0+** 支持一维数组（不支持多维数组），并且没有限定数组的大小。 + +**重要提示**：数组是 bash 的**非 POSIX 扩展特性**，纯 POSIX sh（如 dash）不支持数组。若需编写可移植脚本，应避免使用数组。 + +下面是一个关于数组操作的 Shell 代码示例，通过该示例大家可以知道如何创建数组、获取数组长度、获取/删除特定位置的数组元素、删除整个数组以及遍历数组。 ```shell #!/bin/bash @@ -248,9 +295,35 @@ unset array; # 删除数组中的所有元素 for i in ${array[@]};do echo $i ;done # 遍历数组，数组元素为空，没有任何输出内容 ``` -## Shell 基本运算符 +**重要说明：数组索引空洞**： + +使用 `unset array[1]` 删除元素后，数组会产生**索引空洞**： + +```shell +#!/bin/bash +array=(1 2 3 4 5) +echo "删除前: ${array[@]}" # 输出: 1 2 3 4 5 +echo "索引1的值: ${array[1]}" # 输出: 2 + +unset array[1] # 删除索引1的元素 +echo "删除后: ${array[@]}" # 输出: 1 3 4 5 +echo "索引1的值: ${array[1]}" # 输出: (空值) +echo "索引2的值: ${array[2]}" # 输出: 3 (索引2仍在) + +# 遍历时索引不连续 +for index in "${!array[@]}"; do + echo "索引[$index] = ${array[$index]}" +done +# 输出: +# 索引[0] = 1 +# 索引[2] = 3 +# 索引[3] = 4 +# 索引[4] = 5 +``` + +**注意**：删除元素后，如果使用 `${array[1]}` 访问会得到空值。遍历数组时建议使用 `"${!array[@]}"` 获取有效索引，或使用 `"${array[@]}"` 直接遍历值。 -> 说明：图片来自《菜鸟教程》 +## Shell 基本运算符 Shell 编程支持下面几种运算符 @@ -262,23 +335,51 @@ Shell 编程支持下面几种运算符 ### 算数运算符 -![算数运算符](https://oss.javaguide.cn/github/javaguide/cs-basics/shell/4937342.jpg) +| **运算符** | **说明** | **举例** | +| ---------- | -------- | ------------------------------------------ | +| **+** | 加法 | `expr $a + $b` | +| **-** | 减法 | `expr $a - $b` | +| **\*** | 乘法 | `expr $a \* $b` (注意星号需要转义) | +| **/** | 除法 | `expr $b / $a` | +| **%** | 取余 | `expr $b % $a` | +| **=** | 赋值 | `a=$b` 将变量 b 的值赋给 a | +| **==** | 相等 | `[ $a == $b ]` 用于数字比较，相同返回 true | +| **!=** | 不相等 | `[ $a != $b ]` 用于数字比较，不同返回 true | -我以加法运算符做一个简单的示例（注意：不是单引号，是反引号）： +**推荐使用 bash 内置算术扩展**： ```shell #!/bin/bash -a=3;b=3; -val=`expr $a + $b` -#输出：Total value : 6 -echo "Total value : $val" +a=3; b=3 +val=$((a + b)) # bash 算术扩展（推荐） +# 输出：Total value: 6 +echo "Total value: $val" +``` + +**说明**： + +- `$((...))` 是 bash 内置功能，无需 fork 外部进程，性能更好 +- **不推荐**使用 `expr` 命令（需 fork 进程，且运算符两边必须有空格） +- **不推荐**使用反引号 `` `...` ``（已过时），应使用 `$(...)` 语法 + +**如果需要兼容 POSIX sh**，可以使用： + +```shell +val=$(expr "$a" + "$b") # POSIX 兼容，但性能较差 ``` ### 关系运算符 关系运算符只支持数字，不支持字符串，除非字符串的值是数字。 -![shell关系运算符](https://oss.javaguide.cn/github/javaguide/cs-basics/shell/64391380.jpg) +| **运算符** | **说明** | **对应英文** | +| ---------- | ---------------------------------- | ------------- | +| **-eq** | 检测两个数是否**相等** | equal | +| **-ne** | 检测两个数是否**不相等** | not equal | +| **-gt** | 检测左边的数是否**大于**右边的 | greater than | +| **-lt** | 检测左边的数是否**小于**右边的 | less than | +| **-ge** | 检测左边的数是否**大于等于**右边的 | greater equal | +| **-le** | 检测左边的数是否**小于等于**右边的 | less equal | 通过一个简单的示例演示关系运算符的使用，下面 shell 程序的作用是当 score=100 的时候输出 A 否则输出 B。 @@ -286,7 +387,7 @@ echo "Total value : $val" #!/bin/bash score=90; maxscore=100; -if [ $score -eq $maxscore ] +if [[ $score -eq $maxscore ]] then echo "A" else @@ -302,9 +403,12 @@ B ### 逻辑运算符 -![逻辑运算符](https://oss.javaguide.cn/github/javaguide/cs-basics/shell/60545848.jpg) +| **运算符** | **说明** | **举例** | +| ---------- | -------------- | --------------------------------------------- | --- | --------------------------- | +| **&&** | 逻辑的 **AND** | `[[ $a -lt 100 && $b -gt 100 ]]` (全真才为真) | +| **\|\|** | 逻辑的 **OR** | `[[ $a -lt 100 | | $b -gt 100 ]]` (一真即为真) | -示例： +**算术扩展中的逻辑运算**： ```shell #!/bin/bash @@ -313,15 +417,71 @@ a=$(( 1 && 0)) echo $a; ``` -### 布尔运算符 +**命令短路执行（生产环境常用）**： -![布尔运算符](https://oss.javaguide.cn/github/javaguide/cs-basics/shell/93961425.jpg) +在运维自动化和 CI/CD 管道中，经常使用 `&&` 和 `||` 来控制命令链路的执行流程，这称为**短路执行**： -这里就不做演示了，应该挺简单的。 +```shell +#!/bin/bash +set -euo pipefail + +# &&：前一个命令成功（返回 0）时才执行后一个命令 +mkdir -p "/tmp/app_data" && echo "目录就绪" + +# ||：前一个命令失败（返回非 0）时才执行后一个命令 +mkdir -p "/tmp/app_data" || echo "目录创建失败" + +# 组合使用：生产环境典型的防御姿势 +mkdir -p "/tmp/app_data" && echo "目录就绪" || exit 1 + +# 实际场景示例 +# 1. 检查文件存在后再删除 +[ -f "/tmp/old_file.log" ] && rm "/tmp/old_file.log" + +# 2. 命令失败时输出错误信息并退出 +cd /app/config || { echo "无法进入配置目录"; exit 1; } + +# 3. 条件执行命令 +command1 && command2 || command3 +# ⚠️ 注意：此写法有陷阱！ +# - 当 command1 成功时，执行 command2 +# - 当 command1 失败时，执行 command3 +# - 但如果 command1 成功但 command2 失败，command3 仍会执行！ +# +# ✅ 更安全的写法（推荐）： +if command1; then + command2 +else + command3 +fi +# +# 或明确知道 command2 不会失败时才使用 && || 组合 +``` + +**重要提示**： + +- 短路执行依赖命令的**退出码（Exit Code）**：成功返回 0，失败返回非 0 +- 这与 `[[ ]]` 内部的 `&&` 和 `||` 不同，后者用于条件测试 +- `command1 && command2 || command3` 存在陷阱：若 command1 成功但 command2 失败，command3 仍会执行 +- 生产环境中强烈建议使用 if-then-else 结构，确保逻辑清晰 + +### 布尔运算符 + +| **运算符** | **说明** | **举例** | +| ---------- | -------------------------------------------------------------------- | ------------------------------------------ | +| **!** | 将表达式的结果取反。如果表达式为 true，则返回 false；否则返回 true。 | `[ ! false ]` 返回 true。 | +| **-o** | 有一个表达式为 true，则返回 true。 | `[ $a -lt 20 -o $b -gt 100 ]` 返回 true。 | +| **-a** | 两个表达式都为 true 才会返回 true。 | `[ $a -lt 20 -a $b -gt 100 ]` 返回 false。 | ### 字符串运算符 -![ 字符串运算符](https://oss.javaguide.cn/github/javaguide/cs-basics/shell/309094.jpg) +| **运算符** | **说明** | **举例** | +| ---------- | --------------------------------- | ----------------------------- | +| **=** | 检测两个字符串是否**相等** | `[ $a = $b ]` | +| **!=** | 检测两个字符串是否**不相等** | `[ $a != $b ]` | +| **-z** | 检测字符串长度是否为 **0** (zero) | `[ -z $a ]` 为空返回 true | +| **-n** | 检测字符串长度是否**不为 0** | `[ -n "$a" ]` 不为空返回 true | +| **str** | 直接检测字符串是否为空 | `[ $a ]` 不为空返回 true | 简单示例： @@ -329,7 +489,7 @@ echo $a; #!/bin/bash a="abc"; b="efg"; -if [ $a = $b ] +if [[ $a = $b ]] then echo "a 等于 b" else @@ -345,7 +505,20 @@ a 不等于 b ### 文件相关运算符 -![文件相关运算符](https://oss.javaguide.cn/github/javaguide/cs-basics/shell/60359774.jpg) +用于检测 Unix/Linux 文件的各种属性（如权限、类型等）。 + +- **存在与类型检测：** + - **-e file**: 检测文件（包括目录）是否存在。 + - **-f file**: 检测是否为普通文件（既不是目录也不是设备文件）。 + - **-d file**: 检测是否为目录。 + - **-s file**: 检测文件是否为空（文件大小大于 0 返回 true）。 + - **-b/-c/-p**: 分别检测是否为块设备、字符设备、有名管道。 +- **权限检测：** + - **-r file**: 检测文件是否可读。 + - **-w file**: 检测文件是否可写。 + - **-x file**: 检测文件是否可执行。 +- **特殊标识检测：** + - **-u / -g / -k**: 分别检测文件是否设置了 SUID、SGID 或粘着位 (Sticky Bit)。 使用方式很简单，比如我们定义好了一个文件路径`file="/usr/learnshell/test.sh"` 如果我们想判断这个文件是否可读，可以这样`if [ -r $file ]` 如果想判断这个文件是否可写，可以这样`-w $file`，是不是很简单。 @@ -359,10 +532,10 @@ a 不等于 b #!/bin/bash a=3; b=9; -if [ $a -eq $b ] +if [[ $a -eq $b ]] then echo "a 等于 b" -elif [ $a -gt $b ] +elif [[ $a -gt $b ]] then echo "a 大于 b" else @@ -376,7 +549,22 @@ fi a 小于 b ``` -相信大家通过上面的示例就已经掌握了 shell 编程中的 if 条件语句。不过，还要提到的一点是，不同于我们常见的 Java 以及 PHP 中的 if 条件语句，shell if 条件语句中不能包含空语句也就是什么都不做的语句。 +相信大家通过上面的示例就已经掌握了 shell 编程中的 if 条件语句。 + +**空语句的处理**：Shell 中空语句可以使用 `:`（冒号命令）或 `true` 命令实现： + +```shell +if [[ condition ]]; then + : # 空语句（什么都不做） +fi + +# 或 +if [[ condition ]]; then + true # 空语句 +fi +``` + +这在某些场景下很有用，例如在 while 循环中作为占位符。 ### for 循环语句 @@ -420,10 +608,10 @@ done; ```shell #!/bin/bash int=1 -while(( $int<=5 )) +while (( int <= 5 )) # 算术上下文内变量无需 $ do echo $int - let "int++" + (( int++ )) # 推荐使用 (( )) 替代 let done ``` @@ -432,7 +620,7 @@ done ```shell echo '按下 退出' echo -n '输入你最喜欢的电影: ' -while read FILM +while read -r FILM # -r 选项禁止反斜杠转义，提高安全性 do echo "是的！$FILM 是一个好电影" done @@ -483,18 +671,34 @@ echo "-----函数执行完毕-----" ```shell #!/bin/bash +set -euo pipefail + funWithReturn(){ + local aNum + local anotherNum echo "输入第一个数字: " - read aNum + read -r aNum echo "输入第二个数字: " - read anotherNum + read -r anotherNum echo "两个数字分别为 $aNum 和 $anotherNum !" - return $(($aNum+$anotherNum)) + return $((aNum + anotherNum)) } funWithReturn echo "输入的两个数字之和为 $?" ``` +**重要说明**： + +- **`local` 关键字**：将变量限制在函数作用域内，避免污染全局命名空间 +- **`read -r`**：`-r` 选项禁止反斜杠转义，提高安全性 +- **函数返回值**：Shell 函数只能返回 0-255 的退出码，如需返回复杂数据应使用 `echo` 或全局变量 + +**为什么使用 local？** + +- 在复杂脚本或引入多个外部脚本时，非 local 变量可能被意外覆盖 +- 全局变量污染会导致难以排查的配置漂移或逻辑越权 +- 使用 `local` 是函数编程的最佳实践，类似于其他编程语言的局部变量概念 + 输出结果： ```plain @@ -511,13 +715,14 @@ echo "输入的两个数字之和为 $?" ```shell #!/bin/bash funWithParam(){ - echo "第一个参数为 $1 !" - echo "第二个参数为 $2 !" - echo "第十个参数为 $10 !" - echo "第十个参数为 ${10} !" - echo "第十一个参数为 ${11} !" - echo "参数总数有 $# 个!" - echo "作为一个字符串输出所有参数 $* !" + echo "第一个参数为 $1" + echo "第二个参数为 $2" + echo "脚本名称为 $0" + echo "第十个参数为 ${10}" # 注意：参数 ≥ 10 时必须用 ${n} + echo "第十一个参数为 ${11}" + echo "参数总数有 $# 个" + echo "所有参数为 $*" # 作为单个字符串输出 + echo "所有参数为 $@" # 作为独立的参数输出（推荐） } funWithParam 1 2 3 4 5 6 7 8 9 34 73 ``` @@ -525,13 +730,679 @@ funWithParam 1 2 3 4 5 6 7 8 9 34 73 输出结果： ```plain -第一个参数为 1 ! -第二个参数为 2 ! -第十个参数为 10 ! -第十个参数为 34 ! -第十一个参数为 73 ! -参数总数有 11 个! -作为一个字符串输出所有参数 1 2 3 4 5 6 7 8 9 34 73 ! +第一个参数为 1 +第二个参数为 2 +脚本名称为 ./script.sh +第十个参数为 34 +第十一个参数为 73 +参数总数有 11 个 +所有参数为 1 2 3 4 5 6 7 8 9 34 73 +所有参数为 1 2 3 4 5 6 7 8 9 34 73 +``` + +**重要提示**： + +- **位置参数 `$n` 当 `n ≥ 10` 时必须使用 `${n}` 语法** +- 例如：`$10` 会被解析为 `$1` 和字面量 `0` 的拼接，而非第十个参数 +- `$0` 表示脚本本身的名称 +- `$#` 表示参数总数 + +**`$*` 与 `$@` 的核心区别**： + +| 表达式 | 未引用 | 双引号包裹 | +| ------ | -------------- | ---------------------------------------- | +| `$*` | 展开为所有参数 | 展开为**单个字符串**（所有参数合并） | +| `$@` | 展开为所有参数 | 展开为**独立的参数**（每个参数保持独立） | + +**示例对比**： + +```shell +#!/bin/bash +test_args() { + echo "--- 使用 \$* （无引号）---" + for arg in $*; do + echo "参数: [$arg]" + done + + echo -e "\n--- 使用 \$@ （无引号）---" + for arg in $@; do + echo "参数: [$arg]" + done + + echo -e "\n--- 使用 \"\$*\" （双引号）---" + for arg in "$*"; do + echo "参数: [$arg]" + done + + echo -e "\n--- 使用 \"\$@\" （双引号，推荐）---" + for arg in "$@"; do + echo "参数: [$arg]" + done +} + +# 调用函数，传递包含空格的参数 +test_args "hello world" "foo bar" +``` + +**输出结果**： + +```plain +--- 使用 $* （无引号）--- +参数: [hello] +参数: [world] +参数: [foo] +参数: [bar] + +--- 使用 $@ （无引号）--- +参数: [hello] +参数: [world] +参数: [foo] +参数: [bar] + +--- 使用 "$*" （双引号）--- +参数: [hello world foo bar] # 所有参数合并为一个字符串 + +--- 使用 "$@" （双引号，推荐）--- +参数: [hello world] # 每个参数保持独立 +参数: [foo bar] +``` + +**结论**：在传递参数时，**始终使用 `"$@"`** 以确保每个参数的独立性（特别是当参数包含空格时）。 + +## Shell 编程最佳实践 + +在掌握了 Shell 编程的基础知识后，了解一些最佳实践能帮助你编写更安全、更高效的脚本。 + +### 脚本基础规范 + +**1. Shebang 规范**： + +```shell +#!/usr/bin/env bash # 更可移植（自动查找 bash） +set -euo pipefail # 严格模式：遇错退出、未定义变量报错、管道失败报错 +``` + +**Shebang 两种写法**： + +- `#!/bin/bash`：直接指定 bash 路径，适用于你知道 bash 位置的固定环境 +- `#!/usr/bin/env bash`：通过 env 查找 bash，更可移植，适合不同系统（如 macOS / Linux） + +**本文示例选择**： + +- 教程示例使用 `#!/bin/bash`：简洁明了，适合初学者理解 +- 生产级示例使用 `#!/usr/bin/env bash`：强调可移植性 + +**2. 变量引用**： + +```shell +# 始终用双引号包裹变量 +echo "$var" # 推荐 +echo $var # 可能导致 word splitting 和 globbing 问题 +``` + +**3. 使用 shellcheck**： + +```bash +shellcheck your_script.sh # 静态分析，发现常见问题 +``` + +**4. 推荐语法**： + +- 使用 `[[ ]]` 而非 `[ ]`（更安全、支持模式匹配） +- 使用 `$((...))` 而非 `expr`（性能更好） +- 使用 `$(...)` 而非反引号（可嵌套、更清晰） +- 使用 `${n}` 访问位置参数 n ≥ 10 + +### pipefail 工作原理 + +默认情况下，管道命令的返回值只取决于最后一个命令。启用 `pipefail` 后，管道的返回值将是最后一个失败命令的返回值，这能避免隐藏中间步骤的错误。 + +**示例对比**： + +```shell +# 默认模式（危险） +cat huge_file.txt | grep "pattern" | head -n 10 +# 即使 cat 失败（文件不存在），只要 head 成功，返回码就是 0 + +# pipefail 模式（安全） +set -o pipefail +cat huge_file.txt | grep "pattern" | head -n 10 +# cat 失败会立即返回错误码，不会被忽略 +``` + +## 生产环境最佳实践 + +### 脚本安全性 + +**1. 始终使用严格模式**： + +```shell +#!/usr/bin/env bash +set -euo pipefail # 遇错退出、未定义变量报错、管道失败报错 +``` + +**2. 变量引用安全**： + +```shell +# 始终用双引号包裹变量，防止 word splitting 和 globbing +rm -rf "$temp_dir" # 推荐 +rm -rf $temp_dir # 危险：如果 temp_dir 包含空格会导致误删 +``` + +**3. 使用 local 限制变量作用域**： + +```shell +process_data() { + local input_file="$1" + local output_file="$2" + # ... 处理逻辑 +} +``` + +### 监控指标建议 + +**关键指标**： + +- **脚本执行返回码（Exit Code）**：非 0 必须触发告警 +- **命令执行超时时间**：防御网络阻塞或 read 死锁（使用 `timeout` 命令） +- **关键资源的并发争用**：临时文件、锁文件、网络连接等 +- **单机文件描述符（FD）使用率**：防止后台并发启动导致 FD 耗尽 +- **PID 饱和度**：监控进程数量，防止 PID 耗尽 +- **网络请求 P99 延迟**：监控 API 请求的尾延迟 + +**超时控制示例**： + +```shell +# 为整个脚本设置超时（5 分钟） +timeout 300 ./your_script.sh || { echo "脚本执行超时"; exit 1; } + +# 为单个命令设置超时 +timeout 10 curl -s https://api.example.com/data || { echo "API 请求超时"; exit 1; } +``` + +**生产级 API 请求（带重试和退避）**： + +```shell +# ⚠️ 重要：单纯拦截超时不够，必须考虑重试风暴 +# 下面的配置包含连接超时、总超时、重试机制和指数退避 + +curl -s \ + --connect-timeout 3 \ # 连接超时 3 秒 + --max-time 10 \ # 总超时 10 秒 + --retry 3 \ # 失败时重试 3 次 + --retry-delay 2 \ # 重试间隔 2 秒 + --retry-max-time 30 \ # 重试总时长不超过 30 秒 + --retry-connrefused \ # 连接被拒绝时也重试 + --retry-all-errors \ # 所有错误都重试 + https://api.example.com/data || { echo "API 请求彻底失败"; exit 1; } +``` + +**重试风暴防护**： + +```shell +# ❌ 危险：无节制的重试会导致级联雪崩 +for i in {1..10}; do + curl -s https://api.example.com/data && break || sleep 1 +done + +# ✅ 安全：带抖动（Jitter）的指数退避重试 +retry_with_backoff() { + local max_attempts=5 + local base_delay=1 + local max_delay=32 + local attempt=1 + + while (( attempt <= max_attempts )); do + if curl -s --connect-timeout 3 --max-time 10 \ + --retry 3 --retry-delay 2 --retry-max-time 30 \ + "$@"; then + return 0 + fi + + if (( attempt < max_attempts )); then + # 指数退避 + 随机抖动（防止重试风暴） + local delay=$(( base_delay * (1 << (attempt - 1)) )) + delay=$(( delay > max_delay ? max_delay : delay )) + local jitter=$((RANDOM % 1000)) # 0-999ms 随机抖动 + delay=$(( delay * 1000 + jitter )) + echo "请求失败，${delay}ms 后重试 (第 $attempt 次)" >&2 + sleep "${delay}e-6" + fi + + ((attempt++)) + done + + return 1 +} + +# 使用 +retry_with_backoff https://api.example.com/data +``` + +**重要提示**： + +- **重试风暴**：网络分区恢复后，无节制的重试会瞬间打满下游服务 +- **指数退避**：每次重试间隔呈指数增长（1s → 2s → 4s → 8s...） +- **随机抖动**：添加随机延迟避免多个客户端同时重试（惊群效应） +- **监控指标**：需监控超时丢包率与 P99 请求耗时 + +### 压测建议 + +**并发安全测试**： + +```shell +# ❌ 危险：无限制并发可能导致 PID 耗尽或 OOM +for i in {1..100}; do + ./your_script.sh & +done +wait + +# ✅ 安全：使用 xargs 控制并发度（推荐） +# 限制最大并行数为 10，防止系统资源耗尽 +seq 1 100 | xargs -n 1 -P 10 -I {} ./your_script.sh + +# 或使用 GNU parallel（功能更强大） +seq 1 100 | parallel -j 10 ./your_script.sh +``` + +**重要提示**： + +- **并发度控制**：生产环境的单机压测应使用 `xargs -P` 或 GNU parallel 限制并发进程数 +- **资源监控**：压测时监控文件描述符（FD）使用率和 PID 饱和度 +- **失败模式**：无限制的 `&` 会引发数百个进程在 D 状态挂起，导致节点内核级假死 + +**常见问题检测**： + +- **固定路径冲突**：避免使用 `/tmp/test.log` 等固定路径，应使用 `$$` 引入进程 PID： + + ```shell + temp_file="/tmp/myapp_$$/temp.log" + mkdir -p "$(dirname "$temp_file")" + ``` + +- **锁机制**：使用 `flock` 防止并发执行： + + ```shell + # ⚠️ 重要：flock 仅在本地文件系统（Ext4/XFS）保证强一致性 + # 若锁文件位于 NFS 等网络存储，flock 可能静默失效（脑裂风险） + + # 单机场景：确保同一时间只有一个实例在运行 + exec 200>/var/lock/myapp.lock + flock -n 200 || { echo "脚本已在运行"; exit 1; } + + # 分布式场景：需要使用分布式锁服务（如 Redis、etcd、ZooKeeper） + # 或通过数据库唯一索引、消息队列等机制实现互斥 + ``` + + **flock 脑裂风险可视化**： + + ```mermaid + sequenceDiagram + participant CronA as 节点A (定时任务) + participant CronB as 节点B (定时任务) + participant Storage as 存储层 + + CronA->>Storage: 请求 flock 互斥锁 (非阻塞) + Storage-->>CronA: 授予锁 (成功) + CronA->>CronA: 执行核心自动化逻辑 + + CronB->>Storage: 并发请求 flock 互斥锁 (非阻塞) + alt 本地文件系统 (Ext4/XFS) + Storage-->>CronB: 拒绝加锁 (返回非0) + CronB->>CronB: 安全退出，防御并发成功 ✓ + else 网络文件系统 (NFS/配置异常) + Storage-->>CronB: 错误地授予锁 (静默失效) + CronB->>CronB: 🚨 执行核心逻辑，发生并发写与数据踩踏！ + end + ``` + + **分布式锁方案建议**： + + - **Redis**：使用 `SET key value NX PX timeout` 实现分布式锁 + - **etcd**：使用事务 API 和租约机制 + - **数据库**：使用 `UNIQUE INDEX` 约束 + - **消息队列**：使用单消费者模式保证互斥 + +**后台进程退出码捕获**： + +```shell +# ❌ 问题：wait 默认不检查退出码，后台任务失败会被静默吃掉 +for i in {1..10}; do + ./task.sh & +done +wait # 只等待所有后台进程结束，不检查退出码 + +# ✅ 正确：逐个检查后台进程的退出码 +pids=() +for i in {1..10}; do + ./task.sh & + pids+=($!) +done + +# 等待所有后台进程并检查退出码 +for pid in "${pids[@]}"; do + if ! wait "$pid"; then + echo "进程 $pid 执行失败" >&2 + exit_code=1 + fi +done + +# 或使用 wait -n（bash 4.3+）等待任一进程并检查退出码 +while wait -n; do + : # 检查 $? 是否为 0 +done +``` + +### 常见误区 + +**1. 吞掉错误上下文**： + +```shell +# ❌ 错误：滥用 > /dev/null 2>&1 +command > /dev/null 2>&1 + +# ✅ 正确：只屏蔽不需要的输出，保留错误信息 +command > /dev/null # 或 +command 2>/tmp/error.log ``` - +**2. 环境依赖假定**： + +```shell +# ❌ 危险：依赖特定的 PATH 顺序，未验证命令是否存在 +curl -s https://api.example.com/data + +# ✅ 安全：验证命令存在后再使用 +command -v curl >/dev/null 2>&1 || { echo "curl 未安装"; exit 1; } +curl -s https://api.example.com/data + +# 或者：明确指定完整路径（适用于关键生产环境） +CURL_PATH="/usr/bin/curl" +[[ -x "$CURL_PATH" ]] || { echo "curl 不存在或不可执行"; exit 1; } +"$CURL_PATH" -s https://api.example.com/data +``` + +**说明**：验证命令存在可以防止因环境差异导致的运行时错误。若需更高安全性，可指定完整路径。 + +**3. 未处理管道失败**： + +```shell +# ❌ 问题：默认模式下管道只看最后一个命令的返回码 +cat huge_file.txt | grep "pattern" | head -n 10 +# 即使 cat 失败，只要 head 成功，整体返回码就是 0 + +# ✅ 安全：使用 pipefail 确保任何命令失败都能被捕获 +set -o pipefail +cat huge_file.txt | grep "pattern" | head -n 10 +``` + +**4. 未清理临时资源**： + +```shell +# ❌ 问题：脚本异常退出时临时文件未被清理 +temp_file="/tmp/data_$$" +process_data "$temp_file" + +# ✅ 安全：使用 trap 确保清理 +temp_file="/tmp/data_$$" +trap 'rm -f "$temp_file"' EXIT +process_data "$temp_file" +``` + +### 错误处理模式 + +**防御式编程模板**： + +```shell +#!/usr/bin/env bash +set -euo pipefail + +# 错误处理函数 +error_exit() { + echo "错误: $1" >&2 + exit "${2:-1}" +} + +# 验证依赖 +command -v curl >/dev/null 2>&1 || error_exit "curl 未安装" +command -v jq >/dev/null 2>&1 || error_exit "jq 未安装" + +# 验证参数 +[[ $# -eq 1 ]] || error_exit "用法: $0 " + +# 验证文件存在 +[[ -f "$1" ]] || error_exit "配置文件不存在: $1" + +# 设置超时和清理 +temp_file="/tmp/process_$$" +trap 'rm -f "$temp_file"' EXIT + +# 主要逻辑（带超时） +timeout 300 process_data "$1" "$temp_file" || error_exit "数据处理失败或超时" + +echo "处理完成：$temp_file" +``` + +### 故障演练建议 + +生产环境的脚本需要经过充分的故障测试，确保在各种异常情况下都能正确处理。以下是推荐的故障演练场景： + +**1. 网络分区测试** + +```shell +# 使用 iptables 模拟 50% 丢包率 +sudo iptables -A OUTPUT -p tcp --dport 443 -m statistic --mode random --probability 0.5 -j DROP + +# 测试带有重试机制的 curl 是否引发雪崩 +retry_with_backoff https://api.example.com/data + +# 恢复网络 +sudo iptables -D OUTPUT -p tcp --dport 443 -m statistic --mode random --probability 0.5 -j DROP +``` + +**测试要点**： + +- 验证重试机制是否正常工作 +- 检查是否有指数退避和随机抖动 +- 确认不会因重试风暴导致级联失败 + +**2. 慢响应拖垮测试** + +```shell +# 模拟下游 API 长时间不返回（但不断开连接） +# 使用 nc 监听端口但不发送数据 +nc -l 8080 & + +# 测试 timeout 是否能准确切断连接 +timeout 5 curl -s http://localhost:8080/data || echo "超时触发" + +# 清理 +pkill nc +``` + +**测试要点**： + +- 验证 `--max-time` 是否生效 +- 检查是否有资源泄漏（连接、内存） +- 确认超时后脚本能正确退出 + +**3. 时钟漂移测试** + +```shell +# 模拟系统时钟回拨（需要 root 权限） +sudo date -s "2 hours ago" + +# 测试基于 $PID 生成的临时文件是否有重复覆盖风险 +temp_file="/tmp/test_$$/data.txt" +mkdir -p "$(dirname "$temp_file")" +echo "data" > "$temp_file" +echo "Created: $temp_file" + +# 恢复系统时钟 +sudo ntpdate -u time.nist.gov +``` + +**测试要点**： + +- 验证 PID 循环后临时文件是否会被覆盖 +- 检查是否需要添加时间戳或 UUID 增强唯一性 +- 确认脚本对时钟变化的鲁棒性 + +**4. NFS 延迟测试** + +```shell +# 模拟 NFS 存储高延迟（使用 tc 延迟网络） +# 挂载测试用的 NFS 共享 +sudo mount -t nfs nfs-server:/share /mnt/nfs-test + +# 监控 I/O 延迟（P90 / P99） +iostat -x 1 10 | grep dm-0 + +# 在 NFS 共享上执行脚本，验证 flock 是否正常 +LOCK_FILE="/mnt/nfs-test/myapp.lock" +exec 200>"$LOCK_FILE" +flock -n 200 || { echo "获取锁失败"; exit 1; } + +# 清理 +sudo umount /mnt/nfs-test +``` + +**测试要点**： + +- 验证 flock 在网络存储上是否有效（预期可能失效） +- 检查是否有脑裂风险（多个节点同时获取锁） +- 确认是否需要使用分布式锁替代 + +**5. 文件描述符耗尽测试** + +```shell +# 查看当前进程的 FD 限制 +ulimit -n + +# 模拟大量并发连接，测试 FD 耗尽场景 +for i in {1..1000}; do + exec {fd}>"/tmp/file_$i" 2>/dev/null || break +done + +# 检查 FD 使用情况 +ls -l /proc/$$/fd | wc -l + +# 清理 +for i in {1..1000}; do + eval "exec $fd>&-" 2>/dev/null +done +``` + +**测试要点**： + +- 验证脚本在 FD 不足时的行为 +- 检查是否有资源泄漏 +- 确认并发度限制是否有效 + +**6. 压测数据一致性测试** + +```shell +# 在 NFS 共享存储目录下，由多个机器节点同时高频执行脚本 +# 验证数据恢复与幂等性边界 + +# 节点 A +for i in {1..100}; do + echo "nodeA_data_$i" >> /mnt/shared/data.txt + sleep 0.1 +done & + +# 节点 B（在另一台机器上同时执行） +for i in {1..100}; do + echo "nodeB_data_$i" >> /mnt/shared/data.txt + sleep 0.1 +done & + +# 检查数据是否完整 +wait +wc -l /mnt/shared/data.txt +sort /mnt/shared/data.txt | uniq -c +``` + +**测试要点**： + +- 验证并发写入是否会导致数据混乱 +- 检查是否需要使用锁机制 +- 确认数据恢复策略是否有效 + +## 总结 + +Shell 编程是后端开发和运维人员必备的核心技能之一，掌握它能显著提升工作效率，实现自动化运维和系统管理。本文从入门到生产实践，系统介绍了 Shell 编程的核心知识点。 + +### 核心知识点回顾 + +| 知识模块 | 关键要点 | +| ------------ | --------------------------------------------------------------------------------- | --- | ---------------- | +| **变量** | 区分局部变量、环境变量和特殊变量；使用 `local` 避免全局污染；始终用双引号包裹变量 | +| **字符串** | 推荐使用双引号；理解单引号和双引号的区别；掌握 `${#var}` 获取长度 | +| **数组** | bash 2.0+ 支持数组（非 POSIX）；注意删除元素后的索引空洞 | +| **运算符** | 优先使用 `$((...))` 进行算术运算；`[[ ]]` 比 `[ ]` 更安全 | +| **流程控制** | 使用 `[[ ]]` 进行条件测试；避免 `command1 && command2 | | command3` 的陷阱 | +| **函数** | 使用 `local` 限制变量作用域；函数只能返回 0-255 的退出码 | +| **命令替换** | 使用 `$(...)` 替代反引号；使用 `read -r` 提高安全性 | + +### 生产级脚本编写要点 + +编写生产环境的 Shell 脚本时，务必遵循以下原则： + +**1. 严格模式** + +```shell +#!/usr/bin/env bash +set -euo pipefail # 遇错退出、未定义变量报错、管道失败报错 +``` + +**2. 防御式编程** + +- 验证依赖：`command -v` 检查命令是否存在 +- 验证参数：检查参数数量和类型 +- 验证文件：确认文件存在且可访问 +- 超时控制：使用 `timeout` 防止死锁 +- 资源清理：使用 `trap` 确保临时资源被释放 + +**3. 避免常见陷阱** + +- 不吞掉错误上下文（避免滥用 `>/dev/null 2>&1`） +- 不依赖特定 PATH 顺序（验证或指定完整路径） +- 不忽略管道失败（使用 `set -o pipefail`） +- 不遗漏临时资源清理（使用 `trap`） + +**4. 并发安全** + +- 使用 `$$` 引入 PID 隔离临时文件 +- 使用 `flock` 防止脚本并发执行 +- 避免使用固定的临时文件路径 + +### 学习建议 + +**初学者**： + +1. 从简单的命令别名和脚本开始 +2. 重点掌握变量、条件判断和循环 +3. 使用 `shellcheck` 检查脚本错误 +4. 多练习，从实际场景出发（如日志分析、文件处理） + +**进阶学习**： + +1. 深入学习进程管理、信号处理 +2. 掌握 `sed`、`awk`、`grep` 等文本处理工具 +3. 学习正则表达式和文本处理技巧 +4. 了解性能优化和并发处理 + +**生产实践**： + +1. 阅读 Google Shell Style Guide +2. 研究开源项目的 Shell 脚本 +3. 在测试环境充分验证后再部署 +4. 建立完善的监控和告警机制 + +### 参考资源 + +- **官方文档**：Bash Reference Manual (GNU) +- **代码检查**：ShellCheck - Shell Script Analysis Tool +- **编码规范**：Google Shell Style Guide +- **常见陷阱**：Bash Pitfalls (http://mywiki.wooledge.org/BashPitfalls) diff --git a/docs/database/basis.md b/docs/database/basis.md index 868435d38e8..154d59a0be5 100644 --- a/docs/database/basis.md +++ b/docs/database/basis.md @@ -280,7 +280,7 @@ erDiagram 从定义和属性上看，它们的区别是： - **主键 (Primary Key):** 它的核心作用是唯一标识表中的每一行数据。因此，主键列的值必须是唯一的 (Unique) 且不能为空 (Not Null)。一张表只能有一个主键。主键保证了实体完整性。 -- **外键 (Foreign Key):** 它的核心作用是建立并强制两张表之间的关联关系。一张表中的外键列，其值必须对应另一张表中某行的主键值（或者是一个 NULL 值）。因此，外键的值可以重复，也可以为空。一张表可以有多个外键，分别关联到不同的表。外键保证了引用完整性。 +- **外键 (Foreign Key):** 它的核心作用是建立并强制两张表之间的关联关系。一张表中的外键列，其值必须对应另一张表中某行的候选键值（通常是主键，也可以是唯一键），或者是一个 NULL 值。因此，外键的值可以重复，也可以为空。一张表可以有多个外键，分别关联到不同的表。外键保证了引用完整性。 用一个简单的电商例子来说明：假设我们有两张表：`users` (用户表) 和 `orders` (订单表)。 diff --git a/docs/database/mysql/how-sql-executed-in-mysql.md b/docs/database/mysql/how-sql-executed-in-mysql.md index 1452aef7aef..45a1d8d79ef 100644 --- a/docs/database/mysql/how-sql-executed-in-mysql.md +++ b/docs/database/mysql/how-sql-executed-in-mysql.md @@ -120,11 +120,12 @@ update tb_student A set A.age='19' where A.name=' 张三 '; - **先写 redo log 直接提交，然后写 binlog**，假设写完 redo log 后，机器挂了，binlog 日志没有被写入，那么机器重启后，这台机器会通过 redo log 恢复数据，但是这个时候 binlog 并没有记录该数据，后续进行机器备份的时候，就会丢失这一条数据，同时主从同步也会丢失这一条数据。 - **先写 binlog，然后写 redo log**，假设写完了 binlog，机器异常重启了，由于没有 redo log，本机是无法恢复这一条记录的，但是 binlog 又有记录，那么和上面同样的道理，就会产生数据不一致的情况。 -如果采用 redo log 两阶段提交的方式就不一样了，写完 binlog 后，然后再提交 redo log 就会防止出现上述的问题，从而保证了数据的一致性。那么问题来了，有没有一个极端的情况呢？假设 redo log 处于预提交状态，binlog 也已经写完了，这个时候发生了异常重启会怎么样呢？ +如果采用 redo log 两阶段提交的方式就不一样了，先写完 redo log，标记为 prepare，紧接着写完 binlog 后，然后再将 redo log 标记为 commit 就可以防止出现上述的问题，从而保证了数据的一致性。 +那么问题来了，有没有一个极端的情况呢？假设 redo log 处于 prepare 状态，binlog 也已经写完了，这个时候发生了异常重启会怎么样呢？ 这个就要依赖于 MySQL 的处理机制了，MySQL 的处理过程如下： -- 判断 redo log 是否完整，如果判断是完整的，就立即提交。 -- 如果 redo log 只是预提交但不是 commit 状态，这个时候就会去判断 binlog 是否完整，如果完整就提交 redo log, 不完整就回滚事务。 +- 判断 redo log 是否为 commit 状态，如果是，说明 binlog 一定已完成刷盘，就立即提交。 +- 如果 redo log 只是 prepare 状态但不是 commit 状态，这个时候就会拿着事物的XID，去 binlog 判断该事物是否完成刷盘，如果是就提交 redo log, 否则就回滚事务。 这样就解决了数据一致性的问题。 diff --git a/docs/database/mysql/mysql-index-invalidation.md b/docs/database/mysql/mysql-index-invalidation.md new file mode 100644 index 00000000000..e181d0ffc51 --- /dev/null +++ b/docs/database/mysql/mysql-index-invalidation.md @@ -0,0 +1,217 @@ +--- +title: MySQL索引失效场景总结 +description: 全面总结MySQL索引失效的常见场景，包括SELECT *查询、违背最左前缀原则、索引列计算函数转换、LIKE模糊查询、OR连接、IN/NOT IN使用不当、隐式类型转换以及ORDER BY排序优化陷阱，帮助你避免索引失效导致的性能问题。 +category: 数据库 +tag: + - MySQL + - 性能优化 +head: + - - meta + - name: keywords + - content: MySQL索引失效,索引失效场景,最左前缀原则,覆盖索引,索引下推,隐式类型转换,SQL优化,MySQL性能优化,全表扫描,回表查询 +--- + +在数据库性能优化中，索引是最直接有效的优化手段之一。然而，**建了索引并不等于一定能用上索引**。实际开发中，我们经常遇到这样的困惑：明明在字段上建立了索引，查询却依然慢如蜗牛，通过 `EXPLAIN` 分析发现居然是全表扫描。 + +导致索引失效的原因多种多样，既有 SQL 语句写法问题，也有索引设计不当的因素。有些失效场景是显性的（如违背最左前缀原则），有些则非常隐蔽（如隐式类型转换）。如果不深入了解这些失效场景，很容易在生产环境中埋下性能隐患。 + +本文将系统总结 MySQL 索引失效的常见场景，分析失效背后的原理机制，并提供相应的优化建议，帮助你在日常开发和排查问题中快速定位并解决索引失效问题。 + +### SELECT \* 查询（成本权衡） + +- **核心定义**：`SELECT *` 本身**不会直接导致索引失效**。它是一种”非覆盖索引”查询，如果 `WHERE` 条件命中了索引，索引依然会被初步考虑。 +- **回表成本决策**：当查询需要的字段不在索引树中时，MySQL 必须拿着主键回聚簇索引查找整行数据（回表）。优化器会对比”索引扫描 + 回表”与”直接全表扫描”的成本。如果查询结果占总数据量的比例较高（通常阈值在 20%~30%），优化器会认为全表扫描的顺序 IO 效率高于回表的随机 IO，从而**主动放弃索引**。 +- **场景权衡**： + - **覆盖索引场景**：如果查询只需索引覆盖的字段，使用覆盖索引可以避免回表，性能最优。 + - **回表不可避免时**：如果业务确实需要多个非索引字段，直接 `SELECT 需要的字段` 即可。当需要大部分字段时，代码可读性可能比”省几个字段”的微优化更重要，此时用 `SELECT *` 也无妨。 +- **落地建议**：优先 `SELECT 需要的字段`，能覆盖索引最好；如果需要大量字段且回表不可避免，不必教条地”省字段”。 + +### 违背最左前缀原则 + +- **核心定义**：最左前缀匹配原则指的是在使用联合索引时，MySQL 会根据索引中的字段顺序，从左到右依次匹配查询条件中的字段。如果查询条件与索引中的最左侧字段相匹配，那么 MySQL 就会使用索引来过滤数据。 +- **范围查询的中断效应**：在联合索引中，如果某个字段使用了范围查询（例如 >、<、BETWEEN、前缀匹配 LIKE "abc%"），该字段本身以及其之前的列可以正常匹配并用于索引的精确定位，但该字段之后的列将无法利用 + 索引进行快速定位（即无法使用 ref 类型的二分查找）。这是因为在 B+Tree 索引结构中，只有当前导列完全相等时，后续列才是有序的。一旦前导列变成一个范围，后续列在整个扫描区间内就呈现相对无序状态，从而中断了精准定位能力。不过，在 MySQL 5.6 及以上版本中，这些后续列并未完全失效，而是降级为使用**索引下推（Index Condition Pushdown, ICP）机制**，在范围扫描的过程中直接进行条件过滤，以此来减少回表次数。 +- **索引跳跃扫描 (ISS)**：MySQL 8.0.13 引入了**索引跳跃扫描（Index Skip Scan）**，允许在缺失最左前缀时，通过枚举前导列的所有 Distinct 值来跳跃扫描后续索引树。 + - **版本避坑指南**：在 **MySQL 8.0.31** 中，ISS 存在严重 Bug（[[Bug #109145]](https://bugs.mysql.com/bug.php?id=109145)），在跨 Range 读取时未清理陈旧的边界值，会导致查询直接**丢失数据**。 + - **落地建议**：ISS 在前导列基数（Cardinality）极低（如性别、状态枚举）时性能最优，因为优化器需要枚举前导列的所有 distinct 值逐一跳跃扫描——distinct 值越少，跳跃次数越少。但"基数低"本身并非官方限制条件，优化器会综合评估成本决定是否触发 ISS。在生产环境中，**严禁依赖 ISS 来弥补糟糕的索引设计**，必须通过调整联合索引顺序或补齐前导列条件来满足最左前缀。 + +**Index Skip Scan 失败路径图：** + +```mermaid +sequenceDiagram + participant Executor + participant InnoDB_Index + + Note over Executor, InnoDB_Index: MySQL 8.0.31 触发 ISS Bug 场景 + Executor->>InnoDB_Index: Read Range 1 (Prefix A) + InnoDB_Index-->>Executor: Return Rows, Set End-of-Range = X + Executor->>InnoDB_Index: Read Range 2 (Prefix B) + Note right of InnoDB_Index: [BUG] 未清理上一个 Range 的 End-of-Range X + InnoDB_Index-->>Executor: 发现当前值 > X，错误判定越界，提前终止！ + Note over Executor: 导致结果集丢失 (Incorrect Result) +``` + +失效示例： + +```sql +-- 索引：(sname, s_code, address) +SELECT * FROM students WHERE s_code = 1; -- 跳过最左列 sname，索引失效 +SELECT * FROM students WHERE sname = 'A' AND address = 'Shanghai'; -- 跳过中间列，仅 sname 走索引（索引下推 ICP 可优化过滤） +SELECT * FROM students WHERE sname = 'A' AND s_code > 1 AND address = 'Shanghai'; -- 范围查询后，address 无法用于定位，仅用于过滤 +``` + +### 在索引列上进行计算、函数或类型转换 + +- **核心定义**：索引 B+Tree 存储的是字段的**原始值**。一旦在 `WHERE` 条件中对索引列应用了函数（如 `ABS()`、`DATE()`）或算术运算，该列的值在逻辑上发生了改变。 +- **有序性破坏效应**：由于 B+Tree 是基于原始值排序的，经过函数处理后的结果在索引树中是**无序**的。数据库无法利用二分查找快速定位，只能被迫进行全表扫描。 +- **函数索引**：MySQL 8.0 支持**函数索引**（Functional Index），可针对计算后的值建索引，但使用场景有限，首选还是优化 SQL 写法。 + +失效示例： + +```sql +SELECT * FROM students WHERE height + 1 = 170; -- 对索引列进行计算 +SELECT * FROM students WHERE DATE(create_time) = '2022-01-01'; -- 对索引列使用函数 +``` + +优化建议： + +```sql +SELECT * FROM students WHERE height = 169; -- 将计算移到等号右边 +SELECT * FROM students WHERE create_time BETWEEN '2022-01-01 00:00:00' AND '2022-01-01 23:59:59'; +``` + +### LIKE 模糊查询以通配符开头 + +- **核心定义**：`LIKE` 查询必须以具体字符开头才能利用索引有序性，例如 `WHERE sname LIKE 'Guide%';`。这是因为 B+ 树是从左到右排序的。前缀通配符（`%`）破坏了有序性，无法定位起始点。 +- **前缀通配符的失效机制**：如果以 `%` 开头（如 `'%abc'`），由于索引是按字符从左到右排序的，前缀不确定意味着可能出现在索引树的任何位置，导致无法定位搜索区间的起始点。 +- **落地建议**： + - 如果必须进行全模糊查询，尽量只查询索引覆盖的列，此时 `EXPLAIN` 会显示 `type: index`（**Index Full Scan**），虽然扫描了整棵树，但无需回表，性能仍优于 `ALL`。 + - 核心业务的大规模模糊搜索应通过 **ElasticSearch** 或其他搜索引擎实现。 + +失效示例： + +```sql +SELECT * FROM students WHERE sname LIKE '%Guide'; -- 前缀模糊，全表扫描 +SELECT * FROM students WHERE sname LIKE '%Guide%'; -- 前后模糊，全表扫描 +``` + +### OR 连接与 Index Merge + +- **核心定义**：在 `OR` 连接的多个条件中，只要有**任意一列没有索引**，MySQL 就会放弃所有索引转而执行全表扫描。 +- **Index Merge 机制**：若 `OR` 两侧都有索引，MySQL 5.1+ 可能会触发**索引合并（Index Merge）**优化，分别扫描两个索引后取并集。不过，如果两个索引过滤后的数据量都很大，合并结果集的成本可能高于全表扫描，依然会放弃索引。 +- **落地建议**： + - 优先将 `OR` 改写为 `UNION ALL`。`UNION ALL` 可以让每一段查询独立使用索引，且规避了优化器对 `OR` 成本估算不准的问题。 + - 注意：只有当确定结果集不重复时才用 `UNION ALL`，否则需用 `UNION`（涉及临时表去重，有额外开销）。 + +失效示例： + +```sql +-- 假设 sname 和 address 都有索引，但各匹配 30%+ 数据 +SELECT * FROM students WHERE sname = '学生 1' OR address = '上海'; -- 可能放弃索引，全表扫描 + +-- 建议改写为 +SELECT * FROM students WHERE sname = '学生 1' +UNION ALL +SELECT * FROM students WHERE address = '上海'; -- 各自走索引 +``` + +**验证方式**：`EXPLAIN` 中若出现 `type: index_merge` 和 `Extra: Using union; Using where`，说明使用了 Index Merge。 + +### IN / NOT IN 使用不当 + +**`IN` 列表长度**： + +- `eq_range_index_dive_limit`（默认 **200**）并不直接导致索引失效，而是影响**行数估算策略**： + - **<= 200**：MySQL 使用 **Index Dive**（深入索引树探测）精确估算行数，成本估算准确，索引大概率有效。 + - **> 200**：当 `IN` 列表长度超过 `eq_range_index_dive_limit`（MySQL 5.7.4+ 默认为 200）时，优化器从精确的 Index Dive 切换为基于 `index_statistics` 的估算。若表数据的基数（Cardinality）统计陈旧，可能导致估算成本异常，从而放弃走范围扫描（Range Scan）而选择全表扫描。 +- 可通过调大 `eq_range_index_dive_limit` 或改写为 `JOIN` 临时表来规避。 + +**`NOT IN`** ： + +- **常量列表**（如 `NOT IN (1,2,3)`）：通常全表扫描，因需遍历整个 B+ 树证明"不在集合中"。 +- **子查询关联索引列**：`WHERE id NOT IN (SELECT user_id FROM orders WHERE user_id > 1000)` 可用 `orders` 表的 `user_id` 索引。 +- **推荐替代**：优先使用 `NOT EXISTS` 或 `LEFT JOIN / IS NULL`，性能更优且语义更清晰。 + +失效示例： + +```sql +SELECT * FROM students WHERE s_code IN (1, 2, 3, ..., 500); -- 列表过长，可能改用统计估算导致误判 +SELECT * FROM students WHERE s_code NOT IN (1, 2, 3); -- 常量列表，全表扫描 +``` + +### 隐式类型转换 + +这是开发中最隐蔽的坑，**转换的方向决定了索引的生死**。 + +| 场景 | 示例 | 转换方向 | 索引是否有效 | +| --------------------- | ------------------- | ---------------------------- | ------------ | +| **字符串列 + 数字值** | `varchar_col = 123` | 字符串转数字（发生在索引列） | ❌ 失效 | +| **数字列 + 字符串值** | `int_col = '123'` | 字符串转数字（发生在常量） | ✅ 有效 | + +**关键点**： + +- 只有当**转换发生在索引列上**时，索引才会失效。 +- 当字符串与数字进行比较时，MySQL 默认将字符串转换为**浮点数（DOUBLE）**进行比较（详见 [MySQL 官方文档规则 7](https://dev.mysql.com/doc/refman/8.0/en/type-conversion.html)）。对索引列发生隐式类型转换等同于在索引列上应用了不可逆的转换函数，破坏了 B+ 树的有序性，导致只能走全表扫描。 +- `int_col = '123'` 会被转换为 `int_col = CAST('123' AS DOUBLE)`，转换发生在常量侧，不影响索引使用。 + +**详细介绍**：[MySQL隐式转换造成索引失效](https://javaguide.cn/database/mysql/index-invalidation-caused-by-implicit-conversion.html) + +### ORDER BY 排序优化陷阱 + +即使 `WHERE` 条件精准，如果 `ORDER BY` 处理不好，依然会出现慢查询。 + +**触发 `Using filesort` 的条件**： + +- 排序字段不在索引中 +- 索引顺序与 `ORDER BY` 不一致（如索引 `(a,b)` 但 `ORDER BY b,a`） +- `WHERE` 与 `ORDER BY` 分别使用不同索引 +- 排序列包含 `SELECT *` 中非索引列（需回表排序） + +**优化方案**： + +- 利用**覆盖索引**同时满足 `WHERE` 和 `ORDER BY`。例如索引为 `(name, age)`，查询 `SELECT name, age FROM users WHERE name = 'A' ORDER BY age`。 +- 调整索引顺序以匹配 `ORDER BY`。 + +**验证方式**：`EXPLAIN` 中 `Extra` 列出现 `Using filesort` 即表示触发了排序。 + +### 总结 + +本文系统梳理了 MySQL 索引失效的常见场景，从底层机制上可归纳为以下两大核心类： + +**1. SQL 写法与底层逻辑冲突（破坏 B+Tree 有序性）** + +此类问题最为常见，本质是查询条件让底层的 B+Tree 失去了“二分查找”的快速定位能力。 + +- **违背最左前缀原则**：跳过联合索引前导列，或遇到范围查询（如 `>`、`<`、`BETWEEN`、`LIKE "abc%"`）导致后续列中断精确定位，降级为范围扫描加过滤。 +- **对索引列进行加工**：在 `WHERE` 左侧对索引列进行数学计算或应用函数，导致原始数据发生逻辑改变，在索引树中呈现无序状态。 +- **隐式类型转换（隐蔽且致命）**：当“字符串类型的列”去比较“数字类型的值”时，MySQL 会默认在列上套用转换函数，直接破坏树的有序性。 +- **LIKE 模糊查询前置通配符**：如 `LIKE "%abc"`，前缀字符的不确定性使得优化器无法锁定扫描区间的起始点。 +- **ORDER BY 排序陷阱**：排序列未命中索引、排序方向与索引结构不一致等触发额外的内存或磁盘排序（`Using filesort`）。 + +**2. 优化器的成本决策（基于 I/O 成本妥协）** + +此类问题并非索引本身不可用，而是 MySQL 优化器经过计算后，认为”不走普通索引”整体开销反而更小。**需要特别说明的是：优化器选择全表扫描或回表查询，往往是正确的成本决策，而非”性能问题”**。 + +- **回表查询是正常现象**：当查询需要非索引覆盖的字段时，回表是不可避免的正常操作。索引过滤 + 回表获取业务字段是标准查询模式，并非”性能不佳”的表现。只有当回表次数过多（如命中数据量超过 20%~30%）且存在更优的全表扫描方案时，才需要关注。 +- **全表扫描可能是最优选择**：优化器选择全表扫描通常是基于成本计算的理性决策。当索引选择率低（命中数据量大）时，顺序 IO 的全表扫描往往比随机 IO 的索引回表更高效。这不是索引”失效”，而是优化器选择了更优的执行路径。 +- **`SELECT *` 的场景权衡**：优先 `SELECT 需要的字段`，能命中覆盖索引最好。如果需要大量非索引字段且回表不可避免，不必教条地"省字段"——当需要大部分字段时，代码可读性可能比"少传几个字段"的微优化更重要。 +- **`OR` 条件导致全表扫描**：只要 `OR` 连接的任意一侧条件没有对应索引，就会触发全表扫描。即使两侧都有索引，若 Index Merge（索引合并）的预期成本过高，依然会被放弃。 +- **`IN` 列表过长引发估算失真**：当 `IN` 列表长度超过系统阈值（默认 200）时，优化器会从精准的深入探测（Index Dive）切换为粗略的统计估算，极易因统计信息陈旧而产生执行成本的误判。 + +**实战建议**： + +1. **养成 `EXPLAIN` 分析习惯**：在编写复杂 SQL 后，务必使用 `EXPLAIN` 分析执行计划，重点关注 `type`、`key`、`rows`、`Extra` 字段。**注意**：`type: ALL` 不一定是问题，可能是优化器的正确决策。 +2. **根据场景选择查询策略**： + - 如果查询字段能被索引覆盖，优先使用覆盖索引避免回表 + - 如果必须获取多个非索引字段，避免为了"省字段"而拆分多次查询，减少网络往返 +3. **规范数据类型使用**：保持查询条件与字段类型一致，避免隐式类型转换。 +4. **合理设计联合索引**：按照查询频率和选择性安排字段顺序，优先满足高频查询场景。 +5. **大规模模糊搜索考虑 ES**：对于前后模糊查询（`%keyword%`），建议使用 Elasticsearch 等搜索引擎。 + +索引优化是数据库性能优化的基本功，但也需要结合实际业务场景和数据分布进行权衡。理解索引失效的根本原因，才能在遇到性能问题时快速定位并解决。 + +**延伸阅读**： + +- [MySQL 索引详解](https://javaguide.cn/database/mysql/mysql-index.html) +- [MySQL 执行计划分析](https://javaguide.cn/database/mysql/mysql-query-execution-plan.html) +- [MySQL 隐式转换造成索引失效](https://javaguide.cn/database/mysql/index-invalidation-caused-by-implicit-conversion.html) diff --git a/docs/database/mysql/mysql-index.md b/docs/database/mysql/mysql-index.md index e321f59744c..dfdf5aa0330 100644 --- a/docs/database/mysql/mysql-index.md +++ b/docs/database/mysql/mysql-index.md @@ -478,105 +478,27 @@ MySQL 可以简单分为 Server 层和存储引擎层这两层。Server 层处 ### 避免索引失效 -索引失效也是慢查询的主要原因之一，常见的导致索引失效的情况有下面这些： +索引失效也是慢查询的主要原因之一，常见的导致索引失效的情况有下面这两类： -**`SELECT *` 查询（成本权衡）** +**1. SQL 写法与底层逻辑冲突（破坏 B+Tree 有序性）** -- `SELECT *` **不会直接导致索引失效**。如果 `WHERE` 条件符合索引规则，索引依然会被使用。 -- 它会导致**回表成本增加**。如果查询需要的字段不在索引中（非覆盖索引），数据库需要拿着主键回聚簇索引查数据。当数据量较大时，优化器会对比“索引查找 + 回表”与“直接全表扫描”的成本，若前者成本过高，优化器会**主动放弃索引**选择全表扫描。 -- `SELECT *` 还会网络传输和数据处理的浪费。尽量只查询需要的字段，利用**覆盖索引**减少回表。 +此类问题最为常见，本质是查询条件让底层的 B+Tree 失去了“二分查找”的快速定位能力。 -**违背最左前缀原则** +- **违背最左前缀原则**：跳过联合索引前导列，或遇到范围查询（如 `>`、`<`、`BETWEEN`、`LIKE "abc%"`）导致后续列中断精确定位，降级为范围扫描加过滤。 +- **对索引列进行加工**：在 `WHERE` 左侧对索引列进行数学计算或应用函数，导致原始数据发生逻辑改变，在索引树中呈现无序状态。 +- **隐式类型转换（隐蔽且致命）**：当“字符串类型的列”去比较“数字类型的值”时，MySQL 会默认在列上套用转换函数，直接破坏树的有序性。 +- **LIKE 模糊查询前置通配符**：如 `LIKE "%abc"`，前缀字符的不确定性使得优化器无法锁定扫描区间的起始点。 +- **ORDER BY 排序陷阱**：排序列未命中索引、排序方向与索引结构不一致等触发额外的内存或磁盘排序（`Using filesort`）。 -- 最左前缀匹配原则指的是在使用联合索引时，MySQL 会根据索引中的字段顺序，从左到右依次匹配查询条件中的字段。如果查询条件与索引中的最左侧字段相匹配，那么 MySQL 就会使用索引来过滤数据，这样可以提高查询效率。 -- 最左匹配原则会一直向右匹配，直到遇到范围查询（如 >、<）为止。对于 >=、<=、BETWEEN 以及前缀匹配 LIKE 的范围查询，不会停止匹配。 -- MySQL 8.0.13 版本引入了索引跳跃扫描（Index Skip Scan，简称 ISS），它可以在某些索引查询场景下提高查询效率。在没有 ISS 之前，不满足最左前缀匹配原则的联合索引查询中会执行全表扫描。而 ISS 允许 MySQL 在某些情况下避免全表扫描，即使查询条件不符合最左前缀。不过，这个功能比较鸡肋， 和 Oracle 中的没法比，MySQL 8.0.31 还报告了一个 bug：[Bug #109145 Using index for skip scan cause incorrect result](https://bugs.mysql.com/bug.php?id=109145)（后续版本已经修复）。个人建议知道有这个东西就好，不需要深究，实际项目也不一定能用上。 +**2. 优化器的成本决策（基于 I/O 成本妥协）** -失效示例： +此类问题并非索引本身不可用，而是 MySQL 优化器经过计算后，认为“不走普通索引”整体开销反而更小。 -```sql --- 索引：(sname, s_code, address) -WHERE s_code = 1; -- 跳过最左列 sname，失效 -WHERE sname = 'A' AND address = 'Shanghai'; -- 跳过中间列 s_code，仅 sname 走索引 -WHERE sname = 'A' AND s_code > 1 AND address = 'Shanghai'; -- 范围查询后，address 失效 -``` - -**在索引列上进行计算、函数或类型转换** - -- 索引存储的是字段的**原始值**。对字段进行操作后，数据库无法利用索引树的有序性，只能全表扫描后计算。 -- MySQL 8.0 支持**函数索引**，可针对计算后的值建索引，但使用场景有限，首选还是优化 SQL 写法。 - -失效示例： - -```sql -WHERE height + 1 = 170; -- 对索引列进行计算 -WHERE DATE(create_time) = '2022-01-01'; -- 对索引列使用函数 -``` - -优化建议： - -```sql -WHERE height = 169; -- 将计算移到等号右边 -WHERE create_time BETWEEN '2022-01-01 00:00:00' AND '2022-01-01 23:59:59'; -``` - -**`LIKE` 模糊查询以通配符开头** - -- `LIKE` 查询必须以具体字符开头才能利用索引有序性，例如 `WHERE sname LIKE 'Guide%'; `。 -- 这是因为B+ 树是从左到右排序的。前缀通配符（`%`）破坏了有序性，无法定位起始点。 - -失效示例： - -```sql -WHERE sname LIKE '%Guide'; -- 前缀模糊，全表扫描 -WHERE sname LIKE '%Guide%'; -- 前后模糊，全表扫描 -``` - -**`OR` 连接条件使用不当** - -- 如果 `OR` 两边的列中**有一列没有索引**，通常会导致整个查询放弃索引，走全表扫描。 -- 确保 `OR` 两边的列都建有索引，或改写为 `UNION ALL`。 - -失效示例： - -```sql --- 假设 sname 有索引，address 无索引 -WHERE sname = '学生 1' OR address = '上海'; -- 索引失效，全表扫描 -``` - -**`N` / `NOT IN` 使用不当** - -- **`IN`**：当 `IN` 列表中的值太多（通常超过 200 个，由 `eq_range_index_dive_limit` 参数决定）或查询范围覆盖了太多行，会导致索引失效。 -- **`NOT IN`**：在大多数情况下会引发全表扫描，因为它需要证明“不属于”某个集合，这在 B+ 树中通常需要遍历所有叶子节点。 - -失效示例： - -```sql -WHERE s_code IN (1, 2, 3 ... 500); -- 列表过长可能失效 -WHERE s_code NOT IN (1, 2, 3); -- 通常失效 -``` - -**隐式类型转换** - -这是开发中最隐蔽的坑，转换的方向决定了索引的生死。 - -- 字段类型为字符串，查询条件未加引号（如 `varchar` 字段查 `WHERE col = 123`）；或字段类型为数字，查询条件加了引号且字符集不匹配。 -- MySQL 会自动进行类型转换，导致索引列值发生变化，无法匹配索引树。 -- 详细介绍：[MySQL隐式转换造成索引失效](https://javaguide.cn/database/mysql/index-invalidation-caused-by-implicit-conversion.html) 。 - -**`ORDER BY` 排序优化陷阱** - -即使 `WHERE` 条件精准，如果 `ORDER BY` 处理不好，依然会出现慢查询。 - -- 如果查询走了索引 A，但排序要求字段 B，或者需要回表的数据量太大导致优化器放弃索引排序，就会触发 `Using filesort`（内存/磁盘排序）。 -- 利用**覆盖索引**同时满足 `WHERE` 和 `ORDER BY`。例如索引为 `(name, age)`，查询 `SELECT name, age FROM users WHERE name = 'A' ORDER BY age` 是极其高效的。 - -**最后，总结一个口诀** +- **无脑 `SELECT \*` 导致回表成本超载**：查询大量非索引覆盖列时，若命中数据量较大（通常超 20%~30%），优化器会判定全表扫描的顺序 I/O 优于频繁回表的随机 I/O，从而主动放弃索引。 +- **`OR` 条件导致全表扫描**：只要 `OR` 连接的任意一侧条件没有对应索引，就会触发全表扫描。即使两侧都有索引，若 Index Merge（索引合并）的预期成本过高，依然会被放弃。 +- **`IN` 列表过长引发估算失真**：当 `IN` 列表长度超过系统阈值（默认 200）时，优化器会从精准的深入探测（Index Dive）切换为粗略的统计估算，极易因统计信息陈旧而产生执行成本的误判。 -- 全值匹配我最爱，最左前缀不能改。 -- 范围之后全失效，函数计算索引败。 -- 模糊首位莫加百分号，类型转换要避开。 -- OR 连接需谨慎，覆盖索引避回表。 +详细介绍：[MySQL索引失效场景总结](https://javaguide.cn/database/mysql/mysql-index-invalidation.html)。 ### 被频繁更新的字段应该慎重建立索引 diff --git a/docs/database/mysql/mysql-query-cache.md b/docs/database/mysql/mysql-query-cache.md index c98c5bdaf81..f1241aef69e 100644 --- a/docs/database/mysql/mysql-query-cache.md +++ b/docs/database/mysql/mysql-query-cache.md @@ -10,7 +10,7 @@ head: content: MySQL查询缓存,Query Cache,MySQL缓存机制,缓存失效,MySQL 8.0,查询性能优化,MySQL内存管理 --- -缓存是一个有效且实用的系统性能优化的手段，不论是操作系统还是各种软件和网站或多或少都用到了缓存。 +缓存是一个有效且实用的系统性能优化手段，无论是操作系统，还是各类应用软件与 Web 服务，均广泛采用了缓存机制。 然而，有经验的 DBA 都建议生产环境中把 MySQL 自带的 Query Cache（查询缓存）给关掉。而且，从 MySQL 5.7.20 开始，就已经默认弃用查询缓存了。在 MySQL 8.0 及之后，更是直接删除了查询缓存的功能。 @@ -73,14 +73,14 @@ mysql> show variables like '%query_cache%'; 我们这里对 8.0 版本之前`show variables like '%query_cache%';`命令打印出来的信息进行解释。 -- **`have_query_cache`：** 该 MySQL Server 是否支持查询缓存，如果是 YES 表示支持，否则则是不支持。 +- **`have_query_cache`：** 该 MySQL Server 是否支持查询缓存，如果是 YES 表示支持，否则表示不支持。 - **`query_cache_limit`：** MySQL 查询缓存的最大查询结果，查询结果大于该值时不会被缓存。 -- **`query_cache_min_res_unit`：** 查询缓存分配的最小块的大小(字节)。当查询进行的时候，MySQL 把查询结果保存在查询缓存中，但如果要保存的结果比较大，超过 `query_cache_min_res_unit` 的值 ，这时候 MySQL 将一边检索结果，一边进行保存结果，也就是说，有可能在一次查询中，MySQL 要进行多次内存分配的操作。适当的调节 `query_cache_min_res_unit` 可以优化内存。 -- **`query_cache_size`：** 为缓存查询结果分配的内存的数量，单位是字节，且数值必须是 1024 的整数倍。默认值是 0，即禁用查询缓存。 +- **`query_cache_min_res_unit`：** 查询缓存分配的最小块的大小(字节)。当查询进行的时候，MySQL 把查询结果保存在查询缓存中，但如果要保存的结果比较大，超过 `query_cache_min_res_unit` 的值，此时 MySQL 将在检索结果的同时保存数据，也就是说，有可能在一次查询中，MySQL 要进行多次内存分配的操作。适当的调节 `query_cache_min_res_unit` 可以优化内存。 +- **`query_cache_size`：** 为缓存查询结果分配的内存的数量，单位是字节，且数值必须是 1024 的整数倍。MySQL 5.7 官方文档显示默认值为 `1048576`（1 MB），设置为 0 时禁用查询缓存。不同小版本的默认值存在差异，建议在配置文件中显式指定，不依赖默认行为。 - **`query_cache_type`：** 设置查询缓存类型，默认为 ON。设置 GLOBAL 值可以设置后面的所有客户端连接的类型。客户端可以设置 SESSION 值以影响他们自己对查询缓存的使用。 -- **`query_cache_wlock_invalidate`**：如果某个表被锁住，是否返回缓存中的数据，默认关闭，也是建议的。 +- **`query_cache_wlock_invalidate`**：如果某个表被锁住，是否返回缓存中的数据，默认处于关闭状态，生产环境通常建议保持此默认配置。 -`query_cache_type` 可能的值(修改 `query_cache_type` 需要重启 MySQL Server)： +`query_cache_type` 可能的值（`query_cache_type` 在 MySQL 5.6/5.7 中是动态变量，**但有前提**：若实例启动时 `query_cache_type=0`，服务器会跳过查询缓存互斥锁的分配，此时通过 `SET GLOBAL` 动态修改将报错，必须修改配置文件并重启；若启动时非 0，则可通过 `SET GLOBAL query_cache_type=N` 在线生效，无需重启）： - 0 或 OFF：关闭查询功能。 - 1 或 ON：开启查询缓存功能，但不缓存 `Select SQL_NO_CACHE` 开头的查询。 @@ -88,43 +88,43 @@ mysql> show variables like '%query_cache%'; **建议**： -- `query_cache_size`不建议设置的过大。过大的空间不但挤占实例其他内存结构的空间，而且会增加在缓存中搜索的开销。建议根据实例规格，初始值设置为 10MB 到 100MB 之间的值，而后根据运行使用情况调整。 -- 建议通过调整 `query_cache_size` 的值来开启、关闭查询缓存，因为修改`query_cache_type` 参数需要重启 MySQL Server 生效。 +- `query_cache_size` 不建议设置得过大。过大的空间不但挤占实例其他内存结构的空间，而且会增加在缓存中搜索的开销。建议根据实例规格，初始值设置为 10MB 到 100MB 之间的值，而后根据运行使用情况调整。 +- 建议通过将 `query_cache_size` 设置为 0 来禁用查询缓存，而非仅依赖 `query_cache_type`。两者虽都是动态变量，但 `query_cache_size=0` 会完全跳过缓存内存分配和检查路径，禁用更彻底。 8.0 版本之前，`my.cnf` 加入以下配置，重启 MySQL 开启查询缓存 ```properties query_cache_type=1 -query_cache_size=600000 +query_cache_size=614400 ``` -或者，MySQL 执行以下命令也可以开启查询缓存 +或者，当实例启动时 `query_cache_type` 非 0 的情况下，也可以通过以下命令在线开启查询缓存（若启动值为 0 则该命令会报错，需修改配置文件后重启）： -```properties -set global query_cache_type=1; -set global query_cache_size=600000; +```sql +set global query_cache_type=1; +set global query_cache_size=614400; ``` 手动清理缓存可以使用下面三个 SQL： - `flush query cache;`：清理查询缓存内存碎片。 - `reset query cache;`：从查询缓存中移除所有查询。 -- `flush tables；` 关闭所有打开的表，同时该操作会清空查询缓存中的内容。 +- `flush tables;` 关闭所有打开的表，同时该操作会清空查询缓存中的内容。 ## MySQL 缓存机制 ### 缓存规则 -- 查询缓存会将查询语句和结果集保存到内存（一般是 key-value 的形式，key 是查询语句，value 是查询的结果集），下次再查直接从内存中取。 +- 查询缓存会将查询语句和结果集保存到内存（一般是 key-value 的形式，其中 Key 是由查询语句文本、当前所在的 Database、客户端字符集以及协议版本等环境参数共同计算生成的 Hash 值，Value 则是查询的结果集），下次再查直接从内存中取。 - 缓存的结果是通过 sessions 共享的，所以一个 client 查询的缓存结果，另一个 client 也可以使用。 -- SQL 必须完全一致才会导致查询缓存命中（大小写、空格、使用的数据库、协议版本、字符集等必须一致）。检查查询缓存时，MySQL Server 不会对 SQL 做任何处理，它精确的使用客户端传来的查询。 +- SQL 必须完全一致才会导致查询缓存命中（大小写、空格、使用的数据库、协议版本、字符集等必须一致）。检查查询缓存时，MySQL Server 不会对 SQL 做任何处理，它精确地使用客户端传来的查询。 - 不缓存查询中的子查询结果集，仅缓存查询最终结果集。 - 不确定的函数将永远不会被缓存, 比如 `now()`、`curdate()`、`last_insert_id()`、`rand()` 等。 - 不缓存产生告警（Warnings）的查询。 -- 太大的结果集不会被缓存 (< query_cache_limit)。 +- 结果集超过 `query_cache_limit`（默认 1 MB）时不会被缓存。 - 如果查询中包含任何用户自定义函数、存储函数、用户变量、临时表、MySQL 库中的系统表，其查询结果也不会被缓存。 - 缓存建立之后，MySQL 的查询缓存系统会跟踪查询中涉及的每张表，如果这些表（数据或结构）发生变化，那么和这张表相关的所有缓存数据都将失效。 -- MySQL 缓存在分库分表环境下是不起作用的。 +- MySQL 缓存在分库分表环境下几乎不起作用。原因在于：查询通常经由中间件（如 ShardingSphere、MyCat）路由到不同的 MySQL 实例，各实例维护各自独立的 Query Cache；中间件在路由时往往会改写 SQL（添加分片键条件等），导致改写后的语句与原始语句 Hash 值不一致，缓存无法命中。 - 不缓存使用 `SQL_NO_CACHE` 的查询。 - …… @@ -141,22 +141,22 @@ SELECT SQL_NO_CACHE id, name FROM customer;# 不会缓存 MySQL 查询缓存使用内存池技术，自己管理内存释放和分配，而不是通过操作系统。内存池使用的基本单位是变长的 block, 用来存储类型、大小、数据等信息。一个结果集的缓存通过链表把这些 block 串起来。block 最短长度为 `query_cache_min_res_unit`。 -当服务器启动的时候，会初始化缓存需要的内存，是一个完整的空闲块。当查询结果需要缓存的时候，先从空闲块中申请一个数据块为参数 `query_cache_min_res_unit` 配置的空间，即使缓存数据很小，申请数据块也是这个，因为查询开始返回结果的时候就分配空间，此时无法预知结果多大。 +当服务器启动的时候，会初始化缓存需要的内存，是一个完整的空闲块。当查询开始返回结果时，由于此时无法预知完整的结果集有多大，MySQL 会先向内存池申请一个大小为 `query_cache_min_res_unit` 的基础数据块。如果结果集超出该块容量，则会在生成结果的过程中持续按需申请新的数据块，并将其通过链表拼接起来。 分配内存块需要先锁住空间块，所以操作很慢，MySQL 会尽量避免这个操作，选择尽可能小的内存块，如果不够，继续申请，如果存储完时有空余则释放多余的。 -但是如果并发的操作，余下的需要回收的空间很小，小于 `query_cache_min_res_unit`，不能再次被使用，就会产生碎片。 +随着并发读写的进行，不同大小的缓存块被无序且随机地释放，加上分配时剩余的微小空间（小于 `query_cache_min_res_unit`）无法被复用，内存池中会迅速产生大量不连续的空闲内存块（类似操作系统层面的外部碎片），进而触发更频繁的内存整理消耗。 ## MySQL 查询缓存的优缺点 **优点：** - 查询缓存的查询，发生在 MySQL 接收到客户端的查询请求、查询权限验证之后和查询 SQL 解析之前。也就是说，当 MySQL 接收到客户端的查询 SQL 之后，仅仅只需要对其进行相应的权限验证之后，就会通过查询缓存来查找结果，甚至都不需要经过 Optimizer 模块进行执行计划的分析优化，更不需要发生任何存储引擎的交互。 -- 由于查询缓存是基于内存的，直接从内存中返回相应的查询结果，因此减少了大量的磁盘 I/O 和 CPU 计算，导致效率非常高。 +- 由于查询缓存是基于内存的，直接从内存中返回相应的查询结果，因此减少了大量的磁盘 I/O 和 CPU 计算。**但此优势仅在低并发且读多写少的静态场景下成立**；在多核高并发环境下，`LOCK_query_cache` 全局互斥锁的激烈竞争会导致大量线程处于等锁状态（可通过 `SHOW PROCESSLIST` 看到 `Waiting for query cache lock`），实际 TPS/QPS 反而大幅下降。 **缺点：** -- MySQL 会对每条接收到的 SELECT 类型的查询进行 Hash 计算，然后查找这个查询的缓存结果是否存在。虽然 Hash 计算和查找的效率已经足够高了，一条查询语句所带来的开销可以忽略，但一旦涉及到高并发，有成千上万条查询语句时，hash 计算和查找所带来的开销就必须重视了。 +- MySQL 会对每条接收到的 SELECT 类型的查询进行 Hash 计算，然后查找这个查询的缓存结果是否存在。虽然 Hash 计算和查找本身的 CPU 开销微乎其微，但 Query Cache 底层依赖单一全局互斥锁（`LOCK_query_cache`）来保证并发安全。一旦涉及到高并发，成千上万条查询语句同时争抢该互斥锁进行缓存检查或写入，极其激烈的锁冲突和线程上下文切换开销将成为致命的性能瓶颈。 - 查询缓存的失效问题。如果表的变更比较频繁，则会造成查询缓存的失效率非常高。表的变更不仅仅指表中的数据发生变化，还包括表结构或者索引的任何变化。 - 查询语句不同，但查询结果相同的查询都会被缓存，这样便会造成内存资源的过度消耗。查询语句的字符大小写、空格或者注释的不同，查询缓存都会认为是不同的查询（因为他们的 Hash 值会不同）。 - 相关系统变量设置不合理会造成大量的内存碎片，这样便会导致查询缓存频繁清理内存。 @@ -165,14 +165,38 @@ MySQL 查询缓存使用内存池技术，自己管理内存释放和分配， 在 MySQL Server 中打开查询缓存对数据库的读和写都会带来额外的消耗: -- 读查询开始之前必须检查是否命中缓存。 -- 如果读查询可以缓存，那么执行完查询操作后，会查询结果和查询语句写入缓存。 -- 当向某个表写入数据的时候，必须将这个表所有的缓存设置为失效，如果缓存空间很大，则消耗也会很大，可能使系统僵死一段时间，因为这个操作是靠全局锁操作来保护的。 -- 对 InnoDB 表，当修改一个表时，设置了缓存失效，但是多版本特性会暂时将这修改对其他事务屏蔽，在这个事务提交之前，所有查询都无法使用缓存，直到这个事务被提交，所以长时间的事务，会大大降低查询缓存的命中。 +- **读操作需持锁检查**：读查询开始前必须检查缓存命中，这需要获取 `LOCK_query_cache` 共享锁。高并发下，大量读请求同时争抢锁会形成排队。 +- **缓存写入开销**：若读查询可缓存，执行后需将结果写入缓存，涉及内存分配和链表拼接操作，同样需要持有锁。 +- **写操作触发全局失效**：向表写入数据时，必须使该表所有缓存失效。这需要获取独占锁扫描整个缓存区，`query_cache_size` 越大持锁时间越长。Query Cache 的单一全局互斥锁设计导致写操作会阻塞所有其他读写请求，这也是 MySQL 8.0 移除它的首要原因。 +- **InnoDB 长事务加剧问题**：MVCC 特性下，事务提交前相关缓存无法使用。长事务不仅降低缓存命中率，写操作触发的独占锁还会阻塞对**其他不相关表**的缓存读取。 + +可以通过以下命令查看查询缓存的使用情况，判断是否值得开启： + +```sql +SHOW STATUS LIKE 'Qcache%'; +``` + +关键指标说明： + +| 状态变量 | 含义 | +| :--------------------- | :----------------------------------------------------------------- | +| `Qcache_hits` | 缓存命中次数 | +| `Qcache_inserts` | 写入缓存的查询次数 | +| `Qcache_not_cached` | 未被缓存的查询次数（不可缓存或未命中） | +| `Qcache_lowmem_prunes` | 因内存不足而被淘汰的缓存条目数，持续升高说明缓存空间不足或碎片严重 | +| `Qcache_free_memory` | 缓存剩余空闲内存（字节） | + +命中率参考公式： + +``` +命中率 = Qcache_hits / (Qcache_hits + Qcache_inserts + Qcache_not_cached) +``` + +若命中率长期低于 50%，说明工作负载不适合 Query Cache，建议关闭。此外，还需关注 `Qcache_lowmem_prunes` 与 `Qcache_inserts` 的比值：若比值极高，意味着刚写入缓存的数据很快因内存碎片或空间不足被剔除，此时开启缓存是纯负收益。`Qcache_lowmem_prunes` 持续增长时，可执行 `FLUSH QUERY CACHE` 整理内存碎片，或适当降低 `query_cache_min_res_unit` 的值。 ## 总结 -MySQL 中的查询缓存虽然能够提升数据库的查询性能，但是查询同时也带来了额外的开销，每次查询后都要做一次缓存操作，失效后还要销毁。 +MySQL 中的查询缓存虽然能够提升数据库的查询性能，但查询缓存机制本身也引入了额外的管理开销，每次查询后都要做一次缓存操作，失效后还要销毁。 查询缓存是一个适用较少情况的缓存机制。如果你的应用对数据库的更新很少，那么查询缓存将会作用显著。比较典型的如博客系统，一般博客更新相对较慢，数据表相对稳定不变，这时候查询缓存的作用会比较明显。 @@ -182,7 +206,7 @@ MySQL 中的查询缓存虽然能够提升数据库的查询性能，但是查 - 查询（Select）重复度高。 - 查询结果集小于 1 MB。 -对于一个更新频繁的系统来说，查询缓存缓存的作用是很微小的，在某些情况下开启查询缓存会带来性能的下降。 +对于一个更新频繁的系统来说，查询缓存的作用是很微小的，在某些情况下开启查询缓存会带来性能的下降。 简单总结一下查询缓存不适用的场景： diff --git a/docs/database/mysql/mysql-query-execution-plan.md b/docs/database/mysql/mysql-query-execution-plan.md index 6357163badd..522b39516b1 100644 --- a/docs/database/mysql/mysql-query-execution-plan.md +++ b/docs/database/mysql/mysql-query-execution-plan.md @@ -10,10 +10,10 @@ head: content: MySQL执行计划,EXPLAIN,查询优化器,SQL性能分析,索引命中,type访问类型,Extra字段,慢查询优化 --- -> 本文来自公号 MySQL 技术，JavaGuide 对其做了补充完善。原文地址： - 优化 SQL 的第一步应该是读懂 SQL 的执行计划。本篇文章，我们一起来学习下 MySQL `EXPLAIN` 执行计划相关知识。 +> **版本说明**：本文内容基于 MySQL 5.7+ 和 8.0+ 版本。`filtered` 和 `partitions` 列在 MySQL 5.7+ 可用，`EXPLAIN ANALYZE` 和 Hash Join 特性需要 MySQL 8.0.18+ 和 8.0.20+。 + ## 什么是执行计划？ **执行计划** 是指一条 SQL 语句在经过 **MySQL 查询优化器** 的优化后，具体的执行方式。 @@ -24,24 +24,71 @@ head: MySQL 为我们提供了 `EXPLAIN` 命令，来获取执行计划的相关信息。 -需要注意的是，`EXPLAIN` 语句并不会真的去执行相关的语句，而是通过查询优化器对语句进行分析，找出最优的查询方案，并显示对应的信息。 +需要注意的是，标准 `EXPLAIN` 语句并不会真的去执行相关的语句，而是通过查询优化器对语句进行分析，找出最优的查询方案，并显示对应的信息。 + +MySQL 8.0.18 引入了 `EXPLAIN ANALYZE`，它会**真正执行**查询并输出每个步骤的实际耗时与行数，比标准 `EXPLAIN` 的估算数据更可靠，适合在测试环境深度排查慢查询： + +```sql +mysql> EXPLAIN ANALYZE SELECT * FROM users WHERE age = 25\G +*************************** 1. row *************************** +EXPLAIN: -> Covering index lookup on users using idx_age_score_name (age=25) +(cost=1.52 rows=12) (actual time=0.0272..0.0344 rows=12 loops=1) +``` + +此外，`EXPLAIN FORMAT=JSON` 可以输出优化器的成本模型数据（`query_cost`），比表格形式更能反映各步骤的实际代价，在多表 JOIN 或子查询调优时尤为有用： + +```sql +mysql> EXPLAIN FORMAT=JSON SELECT * FROM users WHERE age = 25\G +*************************** 1. row *************************** +EXPLAIN: { + "query_block": { + "select_id": 1, + "cost_info": { + "query_cost": "1.52" + }, + "table": { + "table_name": "users", + "access_type": "ref", + "key": "idx_age_score_name", + "rows_examined_per_scan": 12, + "filtered": "100.00", + "using_index": true + } + } +} +``` `EXPLAIN` 执行计划支持 `SELECT`、`DELETE`、`INSERT`、`REPLACE` 以及 `UPDATE` 语句。我们一般多用于分析 `SELECT` 查询语句，使用起来非常简单，语法如下： ```sql -EXPLAIN + SELECT 查询语句； +EXPLAIN SELECT 查询语句； ``` 我们简单来看下一条查询语句的执行计划： +**示例 1：单表查询（使用索引）** + ```sql -mysql> explain SELECT * FROM dept_emp WHERE emp_no IN (SELECT emp_no FROM dept_emp GROUP BY emp_no HAVING COUNT(emp_no)>1); -+----+-------------+----------+------------+-------+-----------------+---------+---------+------+--------+----------+-------------+ -| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | -+----+-------------+----------+------------+-------+-----------------+---------+---------+------+--------+----------+-------------+ -| 1 | PRIMARY | dept_emp | NULL | ALL | NULL | NULL | NULL | NULL | 331143 | 100.00 | Using where | -| 2 | SUBQUERY | dept_emp | NULL | index | PRIMARY,dept_no | PRIMARY | 16 | NULL | 331143 | 100.00 | Using index | -+----+-------------+----------+------------+-------+-----------------+---------+---------+------+--------+----------+-------------+ +-- 表结构：users(id, age, score, name, address)，联合索引 idx_age_score_name(age, score, name) +mysql> EXPLAIN SELECT * FROM users WHERE age = 25; ++----+-------------+-------+------------+------+---------------------+---------------------+---------+-------+------+----------+-------------+ +| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | ++----+-------------+-------+------------+------+---------------------+---------------------+---------+-------+------+----------+-------------+ +| 1 | SIMPLE | users | NULL | ref | idx_age_score_name | idx_age_score_name | 5 | const | 12 | 100.00 | Using index | ++----+-------------+-------+------------+------+---------------------+---------------------+---------+-------+------+----------+-------------+ +``` + +**示例 2：UNION 查询（id 为 NULL 的场景）** + +```sql +mysql> EXPLAIN SELECT * FROM users WHERE id = 1 UNION SELECT * FROM users WHERE id = 2; ++----+--------------+------------+------------+-------+---------------+---------+---------+-------+------+----------+-------+ +| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra | ++----+--------------+------------+------------+-------+---------------+---------+---------+-------+------+----------+-------+ +| 1 | PRIMARY | users | NULL | const | PRIMARY | PRIMARY | 4 | const | 1 | 100.00 | NULL | +| 2 | UNION | users | NULL | const | PRIMARY | PRIMARY | 4 | const | 1 | 100.00 | NULL | +| 3 | UNION RESULT | | NULL | ALL | NULL | NULL | NULL | NULL | NULL | NULL | Using temporary | ++----+--------------+------------+------------+-------+---------------+---------+---------+-------+------+----------+-------+ ``` 可以看到，执行计划结果中共有 12 列，各列代表的含义总结如下表： @@ -69,7 +116,37 @@ mysql> explain SELECT * FROM dept_emp WHERE emp_no IN (SELECT emp_no FROM dept_e `SELECT` 标识符，用于标识每个 `SELECT` 语句的执行顺序。 -id 如果相同，从上往下依次执行。id 不同，id 值越大，执行优先级越高，如果行引用其他行的并集结果，则该值可以为 NULL。 +`id` 列的解读规则： + +- **id 相同**：从上往下依次执行（通常出现在多表 JOIN 场景） +- **id 不同**：id 值越大，执行优先级越高（子查询先于外层查询执行） +- **id 为 NULL**：表示这是 UNION RESULT 或 DERIVED 表的结果集，不需要单独执行查询 + +**示例**： + +```sql +mysql> EXPLAIN SELECT * FROM users WHERE id = 1 + -> UNION + -> SELECT * FROM users WHERE id = 2\G +*************************** 1. row *************************** + id: 1 + select_type: PRIMARY + table: users + type: const +*************************** 2. row *************************** + id: 2 + select_type: UNION + table: users + type: const +*************************** 3. row *************************** + id: NULL + select_type: UNION RESULT + table: + type: ALL + Extra: Using temporary +``` + +第三行的 `id = NULL`，table = ``，表示这是前两个查询结果的合并。 ### select_type @@ -92,19 +169,40 @@ id 如果相同，从上往下依次执行。id 不同，id 值越大，执行 ### type（重要） -查询执行的类型，描述了查询是如何执行的。所有值的顺序从最优到最差排序为： +查询执行的类型，描述了查询是如何执行的。**从最优到最差的排序为**： -system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL +`system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL` + +**性能判断经验法则**： + +- **优秀**（至少达到）：`system`、`const`、`eq_ref`、`ref`、`range` +- **需关注**：`index_merge`、`index`（全索引扫描，大数据量下仍有性能风险） +- **需优化**：`ALL`（全表扫描） + +**注意**：此排序反映的是**单表访问效率**，不代表整体查询性能。例如 `type=ref` 配合大量回表，可能比 `type=index` 的覆盖索引更慢。 常见的几种类型具体含义如下： -- **system**：如果表使用的引擎对于表行数统计是精确的（如：MyISAM），且表中只有一行记录的情况下，访问方法是 system ，是 const 的一种特例。 +- **system**：表中只有一行记录（或者是空表），且存储引擎能够精确统计行数。适用于 MyISAM、Memory、InnoDB（当表只有 1 行时，InnoDB 会优化为 const）等引擎。是 const 访问类型的特例。 - **const**：表中最多只有一行匹配的记录，一次查询就可以找到，常用于使用主键或唯一索引的所有字段作为查询条件。 -- **eq_ref**：当连表查询时，前一张表的行在当前这张表中只有一行与之对应。是除了 system 与 const 之外最好的 join 方式，常用于使用主键或唯一索引的所有字段作为连表条件。 -- **ref**：使用普通索引作为查询条件，查询结果可能找到多个符合条件的行。 -- **index_merge**：当查询条件使用了多个索引时，表示开启了 Index Merge 优化，此时执行计划中的 key 列列出了使用到的索引。 +- **eq_ref**：当连表查询时，前一张表的行在当前这张表中只有一行与之对应。是除了 system 与 const 之外最好的 join 方式，常用于使用主键或唯一非空索引的所有字段作为连表条件（严格保证一对一匹配）。 +- **ref**：使用普通索引作为查询条件，查询结果可能找到多个符合条件的行（与 eq_ref 的区别：一个驱动行可能匹配多个被驱动行）。 +- **index_merge**：当 WHERE 子句包含多个范围条件，且每个条件可以使用不同索引时，MySQL 会合并多个索引的扫描结果。key 列列出使用的索引，Extra 列显示合并算法： + + - `Using union(...)`：对多个索引结果取并集（OR 条件） + - `Using sort_union(...)`：先对索引结果排序再取并集（OR 条件，索引列非有序） + - `Using intersection(...)`：对多个索引结果取交集（AND 条件） + + **示例**： + + ```sql + -- OR 条件触发 index merge union + EXPLAIN SELECT * FROM employees WHERE emp_no = 10001 OR dept_no = 'd001'; + -- Extra: Using union(PRIMARY,dept_no_index) + ``` + - **range**：对索引列进行范围查询，执行计划中的 key 列表示哪个索引被使用了。 -- **index**：查询遍历了整棵索引树，与 ALL 类似，只不过扫描的是索引，而索引一般在内存中，速度更快。 +- **index**：Full Index Scan，查询遍历了整棵索引树。与 ALL（全表扫描）类似，但通常开销更低：索引记录的体积远小于完整行数据，读取相同行数所需的 I/O 页数更少；若同时满足覆盖索引条件，还可避免回表。但在超大表（亿级以上）上，全索引扫描同样可能产生大量 I/O，不可因 type 级别高于 ALL 就忽视其代价。 - **ALL**：全表扫描。 ### possible_keys @@ -121,24 +219,68 @@ key_len 列表示 MySQL 实际使用的索引的最大长度；当使用到联 ### rows -rows 列表示根据表统计信息及选用情况，大致估算出找到所需的记录或所需读取的行数，数值越小越好。 +rows 列表示根据表统计信息及索引选用情况，**估算**出找到所需记录需要读取的行数，数值越小越好。 + +需要注意的是，该值是估算值而非精确值。InnoDB 的统计信息基于对索引页的随机采样： + +- 采样页数由 `innodb_stats_persistent_sample_pages` 控制（默认 20 页） +- 在表数据频繁变动或批量导入后，估算值与真实行数的偏差可能达到 10%～50% 甚至更大 +- **小表陷阱**：当表行数极少（如 < 100 行）时，优化器可能忽略索引而选择全表扫描，因为全表扫描的成本估算更低 + +**验证方法**： + +```sql +-- 执行计划估算行数 +mysql> EXPLAIN SELECT * FROM users WHERE age = 25\G +rows: 12 + +-- 实际行数（注意：在大表上慎用 COUNT(*)） +mysql> SELECT COUNT(*) FROM users WHERE age = 25; ++----------+ +| COUNT(*) | ++----------+ +| 12 | ++----------+ +``` + +遇到执行计划与实际性能不符时，可以执行 `ANALYZE TABLE` 重新采样，再观察执行计划的变化。 + +### filtered + +filtered 列表示存储引擎返回的数据在 Server 层经 WHERE 条件过滤后，**估算**留存的记录占比（百分比，0～100）。计算公式为：`filtered = (条件过滤后的行数 / 存储引擎返回的行数) × 100`。 + +**解读规则**： + +- 当 `filtered = 100`：存储引擎返回的所有行都满足 WHERE 条件（理想情况） +- 当 `filtered < 100`：部分行被 Server 层过滤掉，说明索引未能覆盖所有查询条件 +- **JOIN 场景**：优化器用 `rows × (filtered / 100)` 估算当前表传递给下一张表的行数（扇出） + +该字段在多表 JOIN 场景中尤为重要：扇出越大，驱动表需要匹配的被驱动表行数就越多。因此当 `filtered` 值很低时，说明过滤效率较好；而当 `rows` 很大且 `filtered` 又不高时，则是潜在性能瓶颈的信号，应优先考虑通过索引下推（ICP）或更合适的索引来减少扇出。 ### Extra（重要） 这列包含了 MySQL 解析查询的额外信息，通过这些信息，可以更准确的理解 MySQL 到底是如何执行查询的。常见的值如下： -- **Using filesort**：在排序时使用了外部的索引排序，没有用到表内索引进行排序。 +- **Using filesort**：MySQL 无法利用索引完成 ORDER BY 或 GROUP BY 的排序要求，需要在返回结果集后额外执行一次排序操作。当结果集大小在 `sort_buffer_size` 以内时，排序在内存中完成；超出则借助临时磁盘文件。"filesort" 是历史遗留名称，并不代表一定产生磁盘 I/O。 - **Using temporary**：MySQL 需要创建临时表来存储查询的结果，常见于 ORDER BY 和 GROUP BY。 - **Using index**：表明查询使用了覆盖索引，不用回表，查询效率非常高。 - **Using index condition**：表示查询优化器选择使用了索引条件下推这个特性。 -- **Using where**：表明查询使用了 WHERE 子句进行条件过滤。一般在没有使用到索引的时候会出现。 -- **Using join buffer (Block Nested Loop)**：连表查询的方式，表示当被驱动表的没有使用索引的时候，MySQL 会先将驱动表读出来放到 join buffer 中，再遍历被驱动表与驱动表进行查询。 +- **Using where**：MySQL Server 层对存储引擎返回的行应用了额外的 WHERE 条件过滤。即使已命中索引（如 `type=ref`），若索引只能满足部分查询条件，剩余条件仍需在 Server 层过滤，此时同样会出现 `Using where`。 +- **Using join buffer (Block Nested Loop)**：连表查询时，被驱动表未使用索引，MySQL 会先将驱动表数据读入 join buffer，再遍历被驱动表进行匹配（复杂度 O(N×M)）。 +- **Using join buffer (hash join)**：MySQL 8.0.18 引入了 Hash Join 算法，**仅用于等值 JOIN**（如 `t1.id = t2.id`），8.0.20 起默认替代 BNL。Hash Join 复杂度为构建阶段 O(N) + 探测阶段 O(M)，比 BNL 的 O(N×M) 更高效。 + + **例外场景**（仍会退回 BNL）： + + - 非等值 JOIN（如 `t1.id > t2.id`） + - JOIN 条件包含函数或表达式 + - 被驱动表上有索引可用时（此时会使用 Index Nested Loop） 这里提醒下，当 Extra 列包含 Using filesort 或 Using temporary 时，MySQL 的性能可能会存在问题，需要尽可能避免。 ## 参考 -- +- +- - diff --git a/docs/database/mysql/mysql-questions-01.md b/docs/database/mysql/mysql-questions-01.md index 0f7ecc08942..d02d378a409 100644 --- a/docs/database/mysql/mysql-questions-01.md +++ b/docs/database/mysql/mysql-questions-01.md @@ -450,7 +450,7 @@ MySQL 索引相关的问题比较多，也非常重要，更详细的介绍可 ### 为什么 InnoDB 没有使用哈希作为索引的数据结构？ -> 我发现很多求职者甚至是面试官对这个问题都有误解，他们相当然的认为 MySQL 底层并没有使用哈希或者 B 树作为索引的数据结构。 +> 我发现很多求职者甚至是面试官对这个问题都有误解，他们想当然的认为 MySQL 底层并没有使用哈希或者 B 树作为索引的数据结构。 > > 实际上，不论是提问还是回答这个问题都要区分好存储引擎。像 MEMORY 引擎就同时支持哈希和 B 树。 diff --git a/docs/database/redis/redis-persistence.md b/docs/database/redis/redis-persistence.md index e15e3d0d16c..bad0e37ef76 100644 --- a/docs/database/redis/redis-persistence.md +++ b/docs/database/redis/redis-persistence.md @@ -18,10 +18,35 @@ Redis 不同于 Memcached 的很重要一点就是，Redis 支持持久化，而 - 只追加文件（append-only file, AOF） - RDB 和 AOF 的混合持久化(Redis 4.0 新增) -官方文档地址： 。 +官方文档地址： 。 ![](https://oss.javaguide.cn/github/javaguide/database/redis/redis4.0-persitence.png) +**本文基于 Redis 7.0+ 版本**。不同版本的持久化机制有重要差异，使用前请确认你的 Redis 版本： + +| 版本 | 持久化默认方式 | 重要特性 | +| -------------- | -------------- | ----------------------- | +| **Redis 4.0** | RDB | 引入 RDB+AOF 混合持久化 | +| **Redis 6.0** | RDB | AOF 仍需手动开启 | +| **Redis 7.0** | RDB | 引入 Multi-Part AOF | +| **Redis 7.2+** | RDB | 进一步优化持久化性能 | + +**关键行为差异**： + +- **AOF rewrite 内存占用**：Redis 7.0 之前重写期间增量数据需在内存中保留，7.0+ 使用 Multi-Part AOF 解决 +- **混合持久化**：Redis 4.0-6.x 需手动开启，Redis 7.0+ 默认启用。 + +检查你的 Redis 版本： + +```bash +redis-cli INFO server | grep redis_version +# 输出示例：redis_version:7.0.12 +``` + +下面这张图展示了 Redis 持久化机制的完整流程，包含了本文的核心内容： + +![Redis 持久化机制完整流程](https://oss.javaguide.cn/github/javaguide/database/redis/redis-persistence-flow.png) + ## RDB 持久化 ### 什么是 RDB 持久化？ @@ -31,11 +56,18 @@ Redis 可以通过创建快照来获得存储在内存里面的数据在 **某 快照持久化是 Redis 默认采用的持久化方式，在 `redis.conf` 配置文件中默认有此下配置： ```clojure -save 900 1 #在900秒(15分钟)之后，如果至少有1个key发生变化，Redis就会自动触发bgsave命令创建快照。 - -save 300 10 #在300秒(5分钟)之后，如果至少有10个key发生变化，Redis就会自动触发bgsave命令创建快照。 - -save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生变化，Redis就会自动触发bgsave命令创建快照。 +# Redis 7.0 默认配置（单行格式） +save 3600 1 300 100 60 10000 + +# 各条件含义： +# - 3600 秒（1 小时）内至少有 1 个 key 变化 +# - 300 秒（5 分钟）内至少有 100 个 key 变化 +# - 60 秒（1 分钟）内至少有 10000 个 key 变化 + +# 等价于旧版多行格式： +# save 3600 1 +# save 300 100 +# save 60 10000 ``` ### RDB 创建快照时会阻塞主线程吗？ @@ -43,15 +75,85 @@ save 60 10000 #在60秒(1分钟)之后，如果至少有10000个key发生 Redis 提供了两个命令来生成 RDB 快照文件： - `save` : 同步保存操作，会阻塞 Redis 主线程； -- `bgsave` : fork 出一个子进程，子进程执行，不会阻塞 Redis 主线程，默认选项。 +- `bgsave` : fork 出一个子进程，子进程执行。 > 这里说 Redis 主线程而不是主进程的主要是因为 Redis 启动之后主要是通过单线程的方式完成主要的工作。如果你想将其描述为 Redis 主进程，也没毛病。 +#### fork 性能开销分析 + +虽然 `bgsave` 在子进程中执行，不会阻塞主线程处理命令请求，但 **fork 操作本身是阻塞的**，且会带来额外的内存开销（下表中的为参考值，实际数值受到 CPU 性能、内存碎片率、系统负载等因素影响）： + +| 数据集大小 | fork 延迟 | 额外内存占用 | 风险等级 | +| ---------- | --------- | ---------------- | -------- | +| < 1GB | < 10ms | ~10MB (页表复制) | 低 | +| 1-10GB | 10-100ms | 10-100MB | 中 | +| 10-50GB | 100ms-1s | 100-500MB | 高 | +| > 50GB | > 1s | > 500MB | 极高 | + +> 本文以 RDB 的 `bgsave` 为例说明 fork 性能影响，但**同样的机制也适用于 AOF 重写（`BGREWRITEAOF` 命令）**。AOF 重写同样需要 fork 子进程，同样面临 fork 延迟、COW 内存开销和 THP 风险。生产环境中，无论是 RDB 还是 AOF 重写，都需要关注 fork 相关的性能指标。 + +#### Copy-on-Write (COW) 机制 + +- fork 后，子进程共享父进程的内存页（标准页 4KB） +- 当父进程或子进程修改内存页时，内核复制该页（Copy-on-Write） +- 大数据集 + 高写负载时，会导致大量页面复制，影响性能 + +#### THP（透明大页）导致的内存雪崩问题 + +Linux 发行版默认开启 **THP（Transparent Huge Pages，透明大页）**，大小为 2MB。THP 会增加大页被 COW 的概率，**最坏情况下**，如果内存被合并为 2MB 大页，即使客户端仅修改 10 字节的数据，内核也会复制完整的 2MB 内存页，导致 COW 的内存开销**放大 512 倍**（2MB / 4KB = 512）。 + +**实际行为**：内核不会强制所有内存都使用 2MB 大页，而是根据情况动态决定是否合并。只有在 THP 成功合并为大页后，修改才会触发 2MB 的 COW。但在高并发写入场景下，这仍会显著增加内存消耗，可能瞬间吸干宿主机内存，触发 **OOM Killer 强杀 Redis 进程**。 + +**验证方式**： + +```bash +cat /sys/kernel/mm/transparent_hugepage/enabled +# 输出 [always] madvise never 表示已开启（危险！） +# 应该输出 always madvise [never] +``` + +**解决方案**：在 Redis 启动脚本中添加 `echo never > /sys/kernel/mm/transparent_hugepage/enabled`，或使用 `redis-server --disable-thp yes`（Redis 6.0+ 支持）。 + +**启动警告**：Redis 检测到 THP 开启时会在启动日志中打印 `WARNING you have Transparent Huge Pages (THP) support enabled in your kernel`，必须立即处理。 + +#### 生产环境建议 + +```bash +# 1. 监控 fork 风险指标 +redis-cli INFO memory | grep -E "(used_memory|used_memory_rss)" + +# 输出示例： +# used_memory:1073741824 +# used_memory_rss:1226833920 +# used_memory_rss_human:1.14G + +# 计算 RSS/USED 比值，fork 时应 < 2 +# 如果接近或超过 2，说明 fork 风险高 + +# 2. 设置 maxmemory 限制 Redis 内存占用，为 fork 预留空间 +# 在 redis.conf 中设置： +# maxmemory 8gb +# maxmemory-policy allkeys-lru + +# 3. 避免在高峰期手动触发 BGSAVE +# 让 Redis 根据配置规则自动触发 + +# 4. 考虑主从复制 + 从节点持久化架构 +# 将持久化操作转移到从节点，避免主节点 fork 开销 +``` + +**监控告警**： + +- `rdb_last_bgsave_time_sec`：上次 bgsave 耗时，应 < 5s +- `rdb_last_cow_size`：上次 fork 的 COW 内存大小，应 < 10% `used_memory` + ## AOF 持久化 ### 什么是 AOF 持久化？ -与快照持久化相比，AOF 持久化的实时性更好。默认情况下 Redis 没有开启 AOF（append only file）方式的持久化（Redis 6.0 之后已经默认是开启了），可以通过 `appendonly` 参数开启： +与快照持久化相比，AOF 持久化的实时性更好。默认情况下 Redis 没有开启 AOF（append only file）方式的持久化，可以通过 `appendonly` 参数开启： + +> **版本说明**：Redis 默认使用 RDB 持久化方式。若需使用 AOF，需要手动设置 `appendonly yes`。Redis 7.0 引入了 Multi-Part AOF 机制优化 AOF 性能，但并未改变默认持久化方式。 ```bash appendonly yes @@ -77,8 +179,12 @@ AOF 持久化功能的实现可以简单分为 5 步： 这里对上面提到的一些 Linux 系统调用再做一遍解释： -- `write`：写入系统内核缓冲区之后直接返回（仅仅是写到缓冲区），不会立即同步到硬盘。虽然提高了效率，但也带来了数据丢失的风险。同步硬盘操作通常依赖于系统调度机制，Linux 内核通常为 30s 同步一次，具体值取决于写出的数据量和 I/O 缓冲区的状态。 -- `fsync`：`fsync`用于强制刷新系统内核缓冲区（同步到到磁盘），确保写磁盘操作结束才会返回。 +- `write`：写入系统内核缓冲区之后直接返回（仅仅是写到缓冲区），不会立即同步到硬盘。虽然提高了效率，但也带来了数据丢失的风险。**同步硬盘操作取决于 Linux 内核的脏页回写策略（Dirty Page Writeback）**，主要受以下参数影响： + - `/proc/sys/vm/dirty_expire_centisecs`：脏页过期时间（默认 30 秒） + - `/proc/sys/vm/dirty_writeback_centisecs`：内核回写线程的唤醒间隔（默认 5 秒） + - 系统内存压力：内存不足时会更积极触发同步 +- **这意味着 `appendfsync no` 模式下宕机时，可能丢失的数据量是不可控且不可预测的**，取决于上次内核同步的时间点。 +- `fsync`：`fsync`用于强制刷新系统内核缓冲区（同步到磁盘），确保写磁盘操作结束才会返回。 AOF 工作流程图如下： @@ -89,12 +195,23 @@ AOF 工作流程图如下： 在 Redis 的配置文件中存在三种不同的 AOF 持久化方式（ `fsync`策略），它们分别是： 1. `appendfsync always`：主线程调用 `write` 执行写操作后，会立刻调用 `fsync` 函数同步 AOF 文件（刷盘）。主线程会阻塞，直到 `fsync` 将数据完全刷到磁盘后才会返回。这种方式数据最安全，理论上不会有任何数据丢失。但因为每个写操作都会同步阻塞主线程，所以性能极差。 -2. `appendfsync everysec`：主线程调用 `write` 执行写操作后立即返回，由后台线程（ `aof_fsync` 线程）每秒钟调用 `fsync` 函数（系统调用）同步一次 AOF 文件（`write`+`fsync`，`fsync`间隔为 1 秒）。这种方式主线程的性能基本不受影响。在性能和数据安全之间做出了绝佳的平衡。不过，在 Redis 异常宕机时，最多可能丢失最近 1 秒内的数据。 +2. `appendfsync everysec`：主线程调用 `write` 执行写操作后立即返回，由后台线程（ `aof_fsync` 线程）每秒钟调用 `fsync` 函数（系统调用）同步一次 AOF 文件（`write`+`fsync`，`fsync`间隔为 1 秒）。这种方式主线程的性能基本不受影响。在性能和数据安全之间做出了绝佳的平衡。不过，在 Redis 异常宕机时，通常可能丢失最近 1 秒内的数据。 + +> **生产级真相（2 秒丢失与阻塞风险）**： +> +> "最多丢失 1 秒"是理想情况。当磁盘 I/O 繁忙时，后台 fsync 执行时间过长，主线程在执行写命令时会检查上一次 fsync 的完成时间。如果距离上次成功 fsync 超过 2 秒，主线程将被**强制阻塞**以保护内存不被撑爆（Redis 源码 `aof.c` 中的 `aof_background_fsync` 阻塞判断逻辑）。 +> +> 因此，**极端宕机情况下，可能会丢失最多 2 秒的数据**，且磁盘抖动会直接导致 Redis P99 延迟飙升。 +> +> **必须监控指标**：`redis-cli INFO persistence | grep aof_delayed_fsync`（记录主线程被 fsync 阻塞的累计次数，只有启用了 AOF 才有这个字段）。 + 3. `appendfsync no`：主线程调用 `write` 执行写操作后立即返回，让操作系统决定何时进行同步，Linux 下一般为 30 秒一次（`write`但不`fsync`，`fsync` 的时机由操作系统决定）。 这种方式性能最好，因为避免了 `fsync` 的阻塞。但数据安全性最差，宕机时丢失的数据量不可控，取决于操作系统上一次同步的时间点。 可以看出：**这 3 种持久化方式的主要区别在于 `fsync` 同步 AOF 文件的时机（刷盘）**。 -为了兼顾数据和写入性能，可以考虑 `appendfsync everysec` 选项 ，让 Redis 每秒同步一次 AOF 文件，Redis 性能受到的影响较小。而且这样即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。 +为了兼顾数据和写入性能，可以考虑 `appendfsync everysec` 选项 ，让 Redis 每秒同步一次 AOF 文件，Redis 性能受到的影响较小。通常情况下，即使出现系统崩溃，用户最多只会丢失一秒之内产生的数据。当硬盘忙于执行写入操作的时候，Redis 还会优雅的放慢自己的速度以便适应硬盘的最大写入速度。 + +> ⚠️ **注意**：当磁盘 I/O 瓶颈严重时，Redis 主线程可能因等待 fsync 而阻塞长达 2 秒，期间数据丢失窗口扩大至 2 秒。生产环境应监控 `aof_delayed_fsync` 指标来评估磁盘健康度。 从 Redis 7.0.0 开始，Redis 使用了 **Multi Part AOF** 机制。顾名思义，Multi Part AOF 就是将原来的单个 AOF 文件拆分成多个 AOF 文件。在 Multi Part AOF 中，AOF 文件被分为三种类型，分别为： @@ -139,6 +256,36 @@ AOF 文件重写期间，Redis 还会维护一个 **AOF 重写缓冲区**，该 - `auto-aof-rewrite-min-size`：如果 AOF 文件大小小于该值，则不会触发 AOF 重写。默认值为 64 MB; - `auto-aof-rewrite-percentage`：执行 AOF 重写时，当前 AOF 大小（aof_current_size）和上一次重写时 AOF 大小（aof_base_size）的比值。如果当前 AOF 文件大小增加了这个百分比值，将触发 AOF 重写。将此值设置为 0 将禁用自动 AOF 重写。默认值为 100。 +**AOF rewrite 的失败边界与风险场景**： + +虽然 AOF rewrite 放在子进程执行，但仍存在以下风险需要了解： + +| 风险场景 | 影响 | 触发条件 | 应对措施 | +| ---------------- | --------------------------- | ------------------------ | ------------------------------------------- | +| **fork 失败** | 无法创建 rewrite 子进程 | 内存不足、系统限制 | 监控内存使用率，设置 `maxmemory` | +| **磁盘满** | 新 AOF 文件写入失败 | rewrite 期间数据量增长快 | 监控磁盘使用率（`df -h`），设置告警阈值 70% | +| **inode 耗尽** | 无法创建新文件 | 小文件过多的系统 | 监控 inode 使用率（`df -i`），清理临时文件 | +| **时间戳回拨** | Multi-Part AOF 文件管理混乱 | 虚拟机时钟同步问题 | 配置 NTP 服务，设置 `aof-timestamp-enabled` | +| **SIGTERM 信号** | rewrite 被中断 | 运维人员手动重启 | 配置优雅关闭（`shutdown-timeout`） | + +**生产环境监控建议**： + +```bash +# 监控 AOF rewrite 状态 +redis-cli INFO persistence | grep aof_rewrite_in_progress + +# 监控 AOF 文件大小增长 +redis-cli INFO persistence | grep aof_current_size +redis-cli INFO persistence | grep aof_base_size + +# 检查磁盘和 inode 使用率 +df -h /var/lib/redis +df -i /var/lib/redis + +# 设置 AOF rewrite 期间增量 fsync 策略（Redis 7.0+） +# aof-rewrite-incremental-sync yes +``` + Redis 7.0 版本之前，如果在重写期间有写入命令，AOF 可能会使用大量内存，重写期间到达的所有写入命令都会写入磁盘两次。 Redis 7.0 版本之后，AOF 重写机制得到了优化改进。下面这段内容摘自阿里开发者的[从 Redis7.0 发布看 Redis 的过去与未来](https://mp.weixin.qq.com/s/RnoPPL7jiFSKkx3G4p57Pg) 这篇文章。 @@ -149,60 +296,448 @@ Redis 7.0 版本之后，AOF 重写机制得到了优化改进。下面这段内 **相关 issue**：[Redis AOF 重写描述不准确 #1439](https://github.com/Snailclimb/JavaGuide/issues/1439)。 -### AOF 校验机制了解吗？ +### AOF 文件如何验证数据完整性？ + +**核心结论**：纯 AOF 文件**没有**校验和机制，仅通过逐条命令解析验证；CRC64 校验和仅存在于混合持久化文件的 **RDB 部分**。 + +#### 纯 AOF 模式：无校验和，仅语法解析 + +纯 AOF 文件不会对整体或单条命令计算 CRC64 校验和，而是通过逐条解析文件中的命令来验证有效性。 + +**为什么没有校验和？** + +AOF 是高频追加写入的文本日志。如果每次追加命令都要重新计算整个文件的 CRC64 校验和，会对主线程的 CPU 和磁盘 I/O 造成严重拖累。因此 Redis 选择了更轻量的方式：重启加载时逐条读取并解析命令语法。 + +如果解析过程中发现语法错误（如命令不完整、格式错误），Redis 会终止加载并报错。 + +> **尾部截断容灾（自动恢复）**： +> +> 在遭遇意外断电或 `kill -9` 强制终止时，AOF 文件的最后一条命令极可能写入不完整（只写了一半）。此时的恢复行为由 **`aof-load-truncated`** 配置决定： +> +> | 配置值 | 行为 | 适用场景 | +> | ------------- | ------------------------------------------------------------------------------- | ---------------------------------------- | +> | `yes`（默认） | Redis 自动丢弃文件尾部不完整的命令，继续完成启动并在日志中打印警告信息 | 生产环境推荐，允许少量数据丢失换取可用性 | +> | `no` | Redis 拒绝启动并直接报错，强制要求人工使用 `redis-check-aof` 工具确认并修复数据 | 金融等对数据完整性要求极高的场景 | +> +> **验证截断恢复**： +> +> ```bash +> # 模拟断电场景：向 AOF 文件追加无意义的乱码 +> echo "truncated garbage data" >> /var/lib/redis/appendonly.aof +> +> # 重启 Redis（aof-load-truncated=yes 时会自动恢复） +> redis-server /path/to/redis.conf +> # 日志输出：# Bad file format reading the append only file: make a backup of your AOF file, then use ./redis-check-aof --fix +> ``` +> +> **失败模式**：如果 AOF 文件的**中间部分**（而非尾部）因为磁盘静默损坏出现乱码，自动截断机制无效，Redis 将直接宕机拒绝服务。此时需要使用 `redis-check-aof --fix` 工具修复。 + +**redis-check-aof 工作原理**： + +- **检测阶段**：根据 AOF 文件格式逐一读取命令，判断命令参数个数、参数字符串长度等，提供错误/不完整命令的文件位置 +- **修复阶段**：从错误位置截断后续文件内容（**注意：会丢失截断点之后的所有数据**），原文件会被备份为 `appendonly.aof.broken` + +#### 混合持久化模式：分段校验策略 + +在 **混合持久化模式**（Redis 4.0 引入）下，AOF 文件采用"分段治理"的校验策略： + +``` +┌─────────────────────────────────────────────────────────┐ +│ 混合持久化文件结构 │ +├─────────────────────────────────────────────────────────┤ +│ RDB 快照部分（二进制） ← CRC64 校验和保护这部分 │ +│ ├── "REDIS" 头部 │ +│ ├── 数据库编号、键值对... │ +│ ├── EOF 标志 │ +│ └── CRC64 校验和（8 字节） ← 校验边界在这里 │ +├─────────────────────────────────────────────────────────┤ +│ AOF 增量部分（文本） ← 无校验和，仅语法解析 │ +│ ├── *3\r\n$3\r\nSET\r\n... │ +│ └── ... │ +└─────────────────────────────────────────────────────────┘ +``` + +- **RDB 快照部分**：以固定的 `REDIS` 字符开头，存储某一时刻的内存数据快照，并在快照数据末尾附带一个 CRC64 校验和。这个校验和**严格卡在 RDB 数据块的末尾**，仅保障这部分二进制快照的完整性。 +- **AOF 增量部分**：紧随 RDB 快照之后，记录增量写命令。这部分**依然没有校验和**，采用与纯 AOF 相同的逐条语法解析验证。 + +**加载时的校验流程**： + +1. Redis 首先校验 RDB 快照部分：计算该部分数据的 CRC64 校验和，与存储的校验和值比较。如果不匹配，Redis 拒绝启动。 +2. RDB 部分校验通过后，逐条解析 AOF 增量命令。解析出错则停止加载后续命令（但此时 RDB 快照数据已成功加载）。 + +#### 配置项说明 + +| 配置项 | 作用域 | 说明 | +| -------------------- | -------------------------------------- | -------------------------------------------------- | +| `rdbchecksum` | RDB 文件、混合持久化的 RDB 部分 | 控制是否计算 CRC64 校验和，对纯 AOF 增量部分不生效 | +| `aof-load-truncated` | 纯 AOF 文件、混合持久化的 AOF 增量部分 | 控制尾部截断时是否自动丢弃并继续启动 | + +**人工修补**（高级用户）： + +- 如果不想通过截断来修复 AOF 文件，可以尝试人工修补 +- 使用文本编辑器打开 AOF 文件（纯文本格式），手动删除或修复错误命令 +- 适用于明确知道错误位置的特定场景 + +## 新版本优化 + +### Redis 4.0 对于持久化机制做了什么优化？ -纯 AOF 模式下，Redis 不会对整个 AOF 文件使用校验和（如 CRC64），而是通过逐条解析文件中的命令来验证文件的有效性。如果解析过程中发现语法错误（如命令不完整、格式错误），Redis 会终止加载并报错，从而避免错误数据载入内存。 +由于 RDB 和 AOF 各有优势，于是，Redis 4.0 开始支持 RDB 和 AOF 的混合持久化。 -在 **混合持久化模式**（Redis 4.0 引入）下，AOF 文件由两部分组成： +#### 配置说明 -- **RDB 快照部分**：文件以固定的 `REDIS` 字符开头，存储某一时刻的内存数据快照，并在快照数据末尾附带一个 CRC64 校验和（位于 RDB 数据块尾部、AOF 增量部分之前）。 -- **AOF 增量部分**：紧随 RDB 快照部分之后，记录 RDB 快照生成后的增量写命令。这部分增量命令以 Redis 协议格式逐条记录，无整体或全局校验和。 +```bash +# 开启 AOF +appendonly yes + +# 开启混合持久化（Redis 7.0+ 默认启用） +aof-use-rdb-preamble yes + +# 优化重写触发条件 +auto-aof-rewrite-percentage 100 # AOF 文件大小比上次重写后增长 100% 时触发 +auto-aof-rewrite-min-size 64mb # AOF 文件至少达到 64MB 才触发重写 +``` + +**版本差异**： + +- **Redis 4.0-6.x**：混合持久化默认关闭，需手动配置 `aof-use-rdb-preamble yes` +- **Redis 7.0+**：混合持久化**默认启用**，无需额外配置 + +#### 工作原理 + +如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。 + +**混合持久化文件结构**： + +``` +┌───────────────────┐ +│ RDB Header │ ← 二进制快照（压缩格式） +│ REDIS0009 │ +│ ... │ +├───────────────────┤ +│ AOF Log Entries │ ← 文本格式命令 +│ *3\r\n$3\r\nSET\r\n$5\r\nkey01\r\n... +│ INCR counter │ +│ ... │ +└───────────────────┘ +``` + +**核心工作流程**： + +1. **写处理阶段**： + + - 客户端执行写命令（`SET/INCR` 等） + - Redis 立即更新内存数据 + - 将命令追加到 AOF 缓冲区（文本格式） + +2. **持久化触发阶段**： + + - AOF 文件大小达到阈值（默认 64MB）或增长 100% + - 触发 AOF 重写（`BGREWRITEAOF`） + +3. **文件构建阶段**： + + - 子进程将当前内存数据以 RDB 格式写入新 AOF 文件开头 + - 父进程继续处理写命令，增量数据记录到重写缓冲区 + - 重写完成后，将重写缓冲区的增量命令追加到新 AOF 文件末尾 + +4. **数据恢复阶段**： + - Redis 启动时优先加载 RDB 部分（快速恢复基础数据） + - 然后顺序重放 AOF 增量命令（恢复最新数据） -RDB 文件结构的核心部分如下： +#### 优势对比 -| **字段** | **解释** | -| ----------------- | ---------------------------------------------- | -| `"REDIS"` | 固定以该字符串开始 | -| `RDB_VERSION` | RDB 文件的版本号 | -| `DB_NUM` | Redis 数据库编号，指明数据需要存放到哪个数据库 | -| `KEY_VALUE_PAIRS` | Redis 中具体键值对的存储 | -| `EOF` | RDB 文件结束标志 | -| `CHECK_SUM` | 8 字节确保 RDB 完整性的校验和 | +| 指标 | 纯 RDB | 纯 AOF | 混合持久化 | +| ---------------- | ------------ | -------------- | -------------- | +| **恢复速度** | 快（秒级） | 慢（分钟级） | 快（秒级） | +| **数据丢失窗口** | 分钟级 | ≤2 秒 | ≤2 秒 | +| **文件大小** | 小（压缩） | 大（文本日志） | 中等 | +| **写入影响** | 低 | 高 | 中等 | +| **可读性** | 差（二进制） | 好（文本） | 差（RDB 部分） | -Redis 启动并加载 AOF 文件时，首先会校验文件开头 RDB 快照部分的数据完整性，即计算该部分数据的 CRC64 校验和，并与紧随 RDB 数据之后、AOF 增量部分之前存储的 CRC64 校验和值进行比较。如果 CRC64 校验和不匹配，Redis 将拒绝启动并报告错误。 +**基准数据**（1GB 数据集，SSD）： -RDB 部分校验通过后，Redis 随后逐条解析 AOF 部分的增量命令。如果解析过程中出现错误（如不完整的命令或格式错误），Redis 会停止继续加载后续命令，并报告错误，但此时 Redis 已经成功加载了 RDB 快照部分的数据。 +- 纯 AOF 恢复：30-60 秒 +- 混合持久化恢复：2-5 秒（**快 5-10 倍**） -## Redis 4.0 对于持久化机制做了什么优化？ +**混合持久化缺点**： -由于 RDB 和 AOF 各有优势，于是，Redis 4.0 开始支持 RDB 和 AOF 的混合持久化（默认关闭，可以通过配置项 `aof-use-rdb-preamble` 开启）。 +- AOF 文件里面的 RDB 部分是压缩格式，不再是 AOF 格式，可读性较差。 +- 需要额外消耗 CPU 进行 RDB 压缩和解压。 -如果把混合持久化打开，AOF 重写的时候就直接把 RDB 的内容写到 AOF 文件开头。这样做的好处是可以结合 RDB 和 AOF 的优点, 快速加载同时避免丢失过多的数据。当然缺点也是有的， AOF 里面的 RDB 部分是压缩格式不再是 AOF 格式，可读性较差。 +#### 常见问题及解决方案 + +**1. 配置验证**： + +```bash +# 方法 1：检查文件头（输出 REDIS 表示启用了混合持久化） +head -c 5 appendonly.aof + +# 方法 2：CLI 验证 +redis-cli CONFIG GET aof-use-rdb-preamble +# 输出：1) "aof-use-rdb-preamble" +# 2) "yes" +``` + +**2. 文件损坏恢复**： + +**工具说明**： + +| 工具 | 工作原理 | 错误检测 | 修复功能 | +| ------------------- | ----------------------------------------------------------------- | ------------------------------------ | --------------------------------------------------- | +| **redis-check-aof** | 根据 AOF 文件格式逐一读取命令，判断命令参数个数、参数字符串长度等 | 检测命令正确性和完整性，提供错误位置 | ✅ **支持修复**：从错误位置截断后续内容，或人工修补 | +| **redis-check-rdb** | 按照 RDB 文件格式依次读取文件头、数据部分、文件尾 | 在读取过程中判断内容是否正确并报错 | ❌ **不支持修复**：仅检测问题，需人工修复 | + +**恢复步骤**： + +```bash +# 步骤 1：检测 AOF 文件问题 +redis-check-aof appendonly.aof +# 输出错误位置和原因 + +# 步骤 2：修复 AOF 文件（从错误位置截断） +redis-check-aof --fix appendonly.aof +# 原 AOF 文件会被备份为 appendonly.aof.broken + +# 步骤 3：检测 RDB 部分 +redis-check-rdb appendonly.aof +# 仅检测，不支持 --fix 参数 + +# 步骤 4：如果 RDB 部分有问题，需人工修复或丢弃整个文件 +# 选项 A：人工修复（需了解 RDB 二进制格式） +# 选项 B：删除混合持久化文件，仅使用纯 RDB 或纯 AOF 恢复 + +# 步骤 5：启动 Redis +redis-server --appendonly yes --appendfilename appendonly.aof +``` + +> **⚠️ 重要提示**： +> +> - **AOF 文件**：`redis-check-aof --fix` 会从错误位置截断文件，**丢失截断点之后的所有数据** +> - **RDB 文件**：`redis-check-rdb` **不支持修复**，如果 RDB 部分损坏，整个混合持久化文件无法恢复，只能依赖备份或纯 AOF 文件 +> - **人工修复**：对于 RDB 部分，如果必须修复，需要使用十六进制编辑器（如 `hexdump`、`xxd`）手动修改二进制格式 + +#### 生产配置建议 + +```bash +# 完整生产配置示例 +appendonly yes +aof-use-rdb-preamble yes + +# 性能优化 +aof-rewrite-incremental-fsync yes # 增量 fsync，减少磁盘 I/O 峰值 +# 延迟敏感场景（推荐 yes） +no-appendfsync-on-rewrite yes # 重写期间暂停 fsync，避免阻塞 +# 数据安全场景（推荐 no） +no-appendfsync-on-rewrite no # 重写期间仍执行 fsync，可能阻塞但更安全 + +# 容量规划建议： +# - 预留 2x 内存作为磁盘空间 +# - 保持单个 AOF 文件 < 16GB +# - 监控 aof_delayed_fsync 指标 +``` -官方文档地址： +官方文档地址： ![](https://oss.javaguide.cn/github/javaguide/database/redis/redis4.0-persitence.png) +### Redis 7.0 对于持久化机制做了什么优化？ + +由于 AOF 重写过程中存在内存缓冲增量数据和磁盘双写的问题，于是，Redis 7.0 开始支持 Multi-Part AOF（默认启用，可以通过配置项 `appenddirname` 指定目录）。 + +如果把 Multi-Part AOF 启用，AOF 文件将被拆分为 base 文件（最多一个，初始全量快照，可为 RDB 或 AOF 格式）和多个 incr 文件（增量命令日志），重写期间新增命令直接写入新的 incr 文件，由 manifest 文件跟踪所有部分。这样做的好处是可以消除重写时的内存缓冲开销和双重 I/O 写入，提高性能并减少潜在的 fsync 阻塞。由于文件结构分离，INCR 文件在重写前保持只读，单文件拷贝相对安全；但跨文件的一致性备份仍需暂停重写，整体备份流程比单文件 AOF 更复杂，且在极大数据集下仍可能需监控资源。 + +> **核心单点故障风险：manifest 文件损坏** +> +> Multi-Part AOF 依赖 **manifest 文件**来跟踪和管理所有 `base/incr/history` 文件，这是整个增量日志体系的核心元数据。如果 manifest 文件损坏或丢失： +> +> | 风险场景 | 影响 | 恢复难度 | +> | ------------------------------ | ------------------------------------------------------- | --------------------------- | +> | **manifest 静默损坏** | Redis 启动时无法正确识别和加载 AOF 文件，数据库无法恢复 | 极高（需手动重建 manifest） | +> | **磁盘故障导致 manifest 丢失** | 即使 base/incr 文件完整，Redis 也无法重构文件依赖关系 | 极高（需人工干预） | +> +> **缓解措施**： +> +> ```bash +> # 1. 备份 manifest 文件（与数据文件同等重要） +> cp /var/lib/redis/appendonlydir/appendonly.aof.manifest /backup/ +> +> # 2. 监控磁盘健康度（提前发现故障） +> smartctl -a /dev/sda | grep -E "SMART overall-health self-assessment|Media_Errors" +> +> # 3. 定期验证 manifest 完整性（Redis 启动时会自动校验） +> redis-check-aof /var/lib/redis/appendonlydir/appendonly.aof.manifest +> ``` +> +> **官方未提供自动化修复工具**，生产环境必须将 manifest 文件纳入备份策略，其重要性等同于 RDB/AOF 数据文件本身。 + +## 生产环境监控指标 + +### 持久化性能指标 + +```bash +# RDB 相关指标 +redis-cli INFO persistence | grep rdb_last_bgsave_time_sec +# 建议：< 5s。超过 5s 说明数据集过大或 I/O 性能瓶颈 + +redis-cli INFO persistence | grep rdb_last_cow_size +# 建议：< 10% used_memory。超过说明 fork 的 Copy-on-Write 内存开销大 + +redis-cli INFO memory | grep used_memory_rss +redis-cli INFO memory | grep used_memory +# 计算：used_memory_rss / used_memory，fork 时应 < 2 + +# AOF 相关指标 +redis-cli INFO persistence | grep aof_rewrite_in_progress +# 期望：0（未在重写）或 1（正在重写） + +redis-cli INFO persistence | grep aof_current_size +redis-cli INFO persistence | grep aof_base_size +# 监控增长率，避免 rewrite 过于频繁 + +redis-cli INFO persistence | grep aof_buffer_length +# 建议：< 4MB。过大说明主线程写入速度快于 fsync 速度 +``` + +### 系统资源监控 + +```bash +# 磁盘使用率和 I/O 等待 +iostat -x 1 5 | grep dm-0 +# 关注：%util（I/O 使用率）、await（平均等待时间） + +# 磁盘空间（预留空间给 rewrite 生成新文件） +df -h /var/lib/redis +# 建议：使用率 < 70% + +# inode 使用率（小文件多的场景） +df -i /var/lib/redis +# 建议：使用率 < 90% + +# 内存使用率 +free -h +# 建议：为 fork 预留至少 20% 空闲内存 +``` + +### 告警规则建议 + +> **指标来源说明**： +> +> - **Redis 指标**：通过 `redis-cli INFO` 或 Redis exporter 获取（如 `redis_rss_memory`、`aof_current_size`） +> - **节点级指标**：通过 node_exporter 或系统命令获取（如 `disk_usage`、系统内存、CPU 使用率） +> +> 以下告警规则假设使用 Prometheus + Redis exporter + node_exporter 监控体系。 + +```yaml +alert_rules: + # ── Redis 持久化相关告警 ──────────────────────────────────────── + - name: "RedisHighMemFragmentation" + expr: redis_memory_rss_bytes / redis_memory_used_bytes > 2 + for: 5m + labels: + severity: warning + annotations: + summary: "Redis 内存碎片率过高，fork COW 风险上升" + description: > + 实例 {{ $labels.instance }} 的 mem_fragmentation_ratio = {{ $value | humanize }}， + 超过阈值 2。碎片率过高意味着 OS 实际分配的物理页远多于 Redis 自身统计， + 执行 BGSAVE / BGREWRITEAOF 触发 fork 后，COW 需复制的页数会显著增加， + 在高写入负载下可能导致内存暴涨，OOM 风险上升。 + 建议执行 MEMORY PURGE 或在低峰期重启实例整理碎片。 + + - name: "RedisAofGrowthTooFast" + expr: deriv(redis_aof_current_size_bytes[5m]) * 60 > 10485760 + for: 5m + labels: + severity: warning + annotations: + summary: "Redis AOF 文件写入速率过高" + description: > + 实例 {{ $labels.instance }} 的 AOF 增长速率超过 10 MB/min + （当前约 {{ $value | humanize1024 }}B/min）。 + 高速写入会持续触发 auto-aof-rewrite，加剧磁盘 I/O 压力， + 并可能产生写入放大。建议检查业务是否存在大量小命令风暴或 KEYS 类全量扫描。 + + - name: "RedisAofFsyncDelayed" + expr: rate(redis_aof_delayed_fsync_total[5m]) > 0 + for: 2m + labels: + severity: critical + annotations: + summary: "Redis AOF fsync 延迟，主线程响应受阻" + description: > + 实例 {{ $labels.instance }} 持续出现 aof_delayed_fsync 增长， + 主线程因等待 AOF fsync 完成而被阻塞，直接导致命令响应 P99 劣化。 + 常见原因：① 磁盘 I/O 带宽饱和；② appendfsync 设置为 always； + ③ 与其他高 I/O 进程共用磁盘。建议切换为 everysec 策略或迁移至独立磁盘。 + + # ── 节点级资源告警 ───────────────────────────────────────────── + - name: "RedisDiskUsageHigh" + expr: > + (1 - node_filesystem_avail_bytes{mountpoint="/var/lib/redis"} + / node_filesystem_size_bytes{mountpoint="/var/lib/redis"}) * 100 > 70 + for: 5m + labels: + severity: warning + annotations: + summary: "Redis 数据盘使用率超过 70%" + description: > + 挂载点 /var/lib/redis 当前使用率为 {{ $value | humanize }}%。 + AOF rewrite 期间会临时生成新文件，需预留约 1.5x 当前 AOF 大小的空间， + 磁盘不足将导致 rewrite 失败并触发 Redis 错误日志 "MISCONF"。 + RDB bgsave 同理。 + remediation: > + 1. 清理过期 RDB 快照与历史 AOF 文件； + 2. 调高 auto-aof-rewrite-min-size 降低 rewrite 频率； + 3. 磁盘扩容或将数据目录迁移至更大分区。 +``` + ## 如何选择 RDB 和 AOF？ 关于 RDB 和 AOF 的优缺点，官网上面也给了比较详细的说明[Redis persistence](https://redis.io/docs/manual/persistence/)，这里结合自己的理解简单总结一下。 **RDB 比 AOF 优秀的地方**： -- RDB 文件存储的内容是经过压缩的二进制数据， 保存着某个时间点的数据集，文件很小，适合做数据的备份，灾难恢复。AOF 文件存储的是每一次写命令，类似于 MySQL 的 binlog 日志，通常会比 RDB 文件大很多。当 AOF 变得太大时，Redis 能够在后台自动重写 AOF。新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样，但体积更小。不过， Redis 7.0 版本之前，如果在重写期间有写入命令，AOF 可能会使用大量内存，重写期间到达的所有写入命令都会写入磁盘两次。 -- 使用 RDB 文件恢复数据，直接解析还原数据即可，不需要一条一条地执行命令，速度非常快。而 AOF 则需要依次执行每个写命令，速度非常慢。也就是说，与 AOF 相比，恢复大数据集的时候，RDB 速度更快。 +- **文件紧凑，适合备份和灾难恢复**：RDB 文件存储的内容是经过压缩的二进制数据，保存着某个时间点的数据集，文件很小，非常适合做数据的备份和灾难恢复。AOF 文件存储的是每一次写命令，类似于 MySQL 的 binlog 日志，通常会比 RDB 文件大很多。当 AOF 变得太大时，Redis 能够在后台自动重写 AOF，新的 AOF 文件和原有的 AOF 文件所保存的数据库状态一样，但体积更小。不过，Redis 7.0 版本之前，如果在重写期间有写入命令，AOF 可能会使用大量内存，重写期间到达的所有写入命令都会写入磁盘两次。 +- **恢复速度快**：使用 RDB 文件恢复数据，直接解析还原数据即可，不需要一条一条地执行命令，速度非常快。而 AOF 则需要依次执行每个写命令，速度非常慢。也就是说，与 AOF 相比，恢复大数据集的时候，RDB 速度更快。 +- **主从复制优势**：在副本（replica）上，RDB 支持重启和故障转移后的**部分重新同步**（Partial Resynchronization）。副本可以使用 RDB 快照快速同步到主节点的某个时间点状态，而不需要全量同步。 +- **性能开销小**：RDB 最大化 Redis 性能，因为 Redis 父进程需要做的唯一持久化工作就是 fork 子进程，子进程将完成所有其余工作。父进程永远不会执行磁盘 I/O 或类似操作。 **AOF 比 RDB 优秀的地方**： -- RDB 的数据安全性不如 AOF，没有办法实时或者秒级持久化数据。生成 RDB 文件的过程是比较繁重的， 虽然 BGSAVE 子进程写入 RDB 文件的工作不会阻塞主线程，但会对机器的 CPU 资源和内存资源产生影响，严重的情况下甚至会直接把 Redis 服务干宕机。AOF 支持秒级数据丢失（取决 fsync 策略，如果是 everysec，最多丢失 1 秒的数据），仅仅是追加命令到 AOF 文件，操作轻量。 -- RDB 文件是以特定的二进制格式保存的，并且在 Redis 版本演进中有多个版本的 RDB，所以存在老版本的 Redis 服务不兼容新版本的 RDB 格式的问题。 -- AOF 以一种易于理解和解析的格式包含所有操作的日志。你可以轻松地导出 AOF 文件进行分析，你也可以直接操作 AOF 文件来解决一些问题。比如，如果执行`FLUSHALL`命令意外地刷新了所有内容后，只要 AOF 文件没有被重写，删除最新命令并重启即可恢复之前的状态。 +- **数据安全性更高，支持秒级持久化**：RDB 的数据安全性不如 AOF，没有办法实时或者秒级持久化数据。生成 RDB 文件的过程是比较繁重的，虽然 BGSAVE 子进程写入 RDB 文件的工作不会阻塞主线程，但会对机器的 CPU 资源和内存资源产生影响，严重的情况下甚至会直接把 Redis 服务干宕机。AOF 支持秒级数据丢失（取决于 `fsync` 策略，如果是 `everysec`，通常最多丢失 1 秒的数据；但磁盘 I/O 繁忙时可能丢失 2 秒且主线程会阻塞），仅仅是追加命令到 AOF 文件，操作轻量。 +- **版本兼容性好**：RDB 文件是以特定的二进制格式保存的，并且在 Redis 版本演进中有多个版本的 RDB，所以存在老版本的 Redis 服务不兼容新版本的 RDB 格式的问题。 +- **可读性和可操作性强**：AOF 以一种易于理解和解析的格式包含所有操作的日志。你可以轻松地导出 AOF 文件进行分析，也可以直接操作 AOF 文件来解决一些问题。比如，如果执行`FLUSHALL`命令意外地刷新了所有内容后，只要 AOF 文件没有被重写，删除最新命令并重启即可恢复之前的状态。 +- **追加日志无损坏风险**：AOF 日志是追加日志，没有寻道，也没有断电损坏问题。即使日志由于某种原因（磁盘已满或其他原因）以半写入命令结尾，`redis-check-aof` 工具也能轻松修复。 + +**版本演进对选型的影响**： + +| 版本 | 关键改进 | 对 AOF 的影响 | 对选型的意义 | +| ------------- | ---------------------------------------- | ------------------------------------------------------- | -------------------------------------------------------------- | +| **Redis 4.0** | 引入混合持久化（`aof-use-rdb-preamble`） | AOF 重写时 base 文件使用 RDB 格式，恢复速度提升 5-10 倍 | 缓解了纯 AOF 加载慢的问题，但仍需关注重写期间的内存和 I/O 开销 | +| **Redis 7.0** | 引入 Multi-Part AOF | 彻底消除重写期间的双写问题，内存和 I/O 开销大幅降低 | 单独使用 AOF 在生产环境更具可行性，但 fork 阻塞问题仍未解决 | + +**未解决的核心问题**： + +- **fork 阻塞**：无论是 RDB bgsave 还是 AOF 重写，fork 操作本身都会阻塞主线程（数据集越大，阻塞时间越长） +- **官方建议**：Redis 官方文档至今仍建议**同时开启 RDB 和 AOF**，RDB 作为额外的冷备手段，应对 AOF 文件损坏或写入错误等极端场景 + +**AOF 和 RDB 的交互**： + +当 AOF 和 RDB 持久化同时启用时： + +- **避免同时进行重 I/O 操作**：Redis 2.4+ 确保避免在 RDB 快照进行时触发 AOF 重写，或允许在 AOF 重写期间进行 BGSAVE。这防止两个 Redis 后台进程同时进行繁重的磁盘 I/O。 +- **AOF 重写调度**：当快照正在进行且用户显式请求日志重写操作（使用 BGREWRITEAOF）时，服务器将返回 OK 状态码，告诉用户操作已调度，重写将在快照完成后开始。 +- **重启恢复优先级**：如果 AOF 和 RDB 持久化都启用且 Redis 重启，**AOF 文件将用于重建原始数据集**，因为它被保证是最完整的。 -**综上**： +**选型建议**： -- Redis 保存的数据丢失一些也没什么影响的话，可以选择使用 RDB。 -- 不建议单独使用 AOF，因为时不时地创建一个 RDB 快照可以进行数据库备份、更快的重启以及解决 AOF 引擎错误。 -- 如果保存的数据要求安全性比较高的话，建议同时开启 RDB 和 AOF 持久化或者开启 RDB 和 AOF 混合持久化。 +| 场景 | 推荐方案 | 说明 | +| -------------------------------- | -------------------------------------------------------------------- | ----------------------------------------------------------- | +| **纯缓存（可丢失）** | **关闭持久化** 或仅 RDB（低频） | 完全关闭开销最小；若需冷备则保留低频 RDB | +| **数据重要性中等**（会话、配置） | **RDB + AOF 混合持久化**（Redis 4.0+） | RDB 加速恢复，AOF 增量补充，`everysec` 最多丢 1s | +| **数据重要性高**（业务核心数据） | **RDB + AOF（MP-AOF，Redis 7.0+）**，且 Redis 作为缓存层而非唯一存储 | MP-AOF 降低重写开销；真正的持久化由主数据库（MySQL 等）负责 | +| **主从架构** | **主节点关闭持久化，从节点开启 AOF** | 主节点禁止配置自动重启，防止空数据集覆盖从节点 | ## 参考 diff --git a/docs/distributed-system/api-gateway.md b/docs/distributed-system/api-gateway.md index 091bd1b079f..0a4486db0a0 100644 --- a/docs/distributed-system/api-gateway.md +++ b/docs/distributed-system/api-gateway.md @@ -1,7 +1,13 @@ --- title: API网关基础知识总结 -description: API网关基础知识详解，涵盖网关核心功能、请求转发、安全认证、流量控制及常见网关选型对比。 category: 分布式 +description: API网关基础知识详解，涵盖网关核心功能（路由转发、身份认证、限流熔断、负载均衡）、工作原理及Zuul、Spring Cloud Gateway、Nginx等常见网关选型对比。 +tag: + - API网关 +head: + - - meta + - name: keywords + content: API网关,网关,微服务网关,Spring Cloud Gateway,Zuul,限流熔断,负载均衡,网关面试题 --- ## 什么是网关？ diff --git a/docs/distributed-system/distributed-configuration-center.md b/docs/distributed-system/distributed-configuration-center.md index 0c71c519cdb..1991628d953 100644 --- a/docs/distributed-system/distributed-configuration-center.md +++ b/docs/distributed-system/distributed-configuration-center.md @@ -1,11 +1,205 @@ --- -title: 分布式配置中心常见问题总结(付费) -description: 分布式配置中心核心概念与面试题解析，涵盖Apollo、Nacos等主流配置中心原理与实践要点。 +title: 分布式配置中心面试题总结 +description: 深入解析分布式配置中心核心原理与面试高频考点，涵盖 Apollo、Nacos、Spring Cloud Config 对比选型、配置推送机制（长轮询/gRPC）、灰度发布、高可用设计等知识点。 category: 分布式 +keywords: + - 配置中心 +head: + - - meta + - name: keywords + content: 配置中心,分布式配置中心,Apollo,Nacos,Spring Cloud Config,配置中心面试题,灰度发布,长轮询 --- -**分布式配置中心** 相关的面试题为我的[知识星球](https://javaguide.cn/about-the-author/zhishixingqiu-two-years.html)（点击链接即可查看详细介绍以及加入方法）专属内容，已经整理到了《Java 面试指北》中。 + -![](https://oss.javaguide.cn/javamianshizhibei/distributed-system.png) +## 为什么要用配置中心？ + +微服务架构下，业务发展通常会导致服务数量增加，进而导致程序配置（服务地址、数据库参数、功能开关等）增多。传统配置文件方式存在以下问题： + +- **无法动态更新**：配置放在代码库中，每次修改都需要重新发布新版本才能生效。 +- **安全性不足**：敏感配置（数据库密码、API Key）直接写在代码库中容易泄露。 +- **时效性差**：即使能修改配置文件，通常也需要重启服务才能生效。 +- **缺乏权限控制**：无法对配置的查看、修改、发布等操作进行细粒度权限管控。 +- **配置分散难管理**：多环境（开发/测试/生产）、多集群的配置分散在各处，难以统一维护。 + +此外，配置中心通常提供以下增强能力： + +- **版本管理**：记录每次配置变更的修改人、修改时间、修改内容，支持一键回滚。 +- **灰度发布**：先将配置推送给部分实例验证，降低变更风险（Apollo、Nacos 1.1.0+ 支持）。 + +![Applo 配置中心](https://oss.javaguide.cn/github/javaguide/config-center/view-release-history.png) + +## 常见的配置中心有哪些？如何选择？ + +| 方案 | 状态 | 特点 | +| ---------------------------------------------------------------------------------- | -------- | ----------------------------------- | +| [Spring Cloud Config](https://cloud.spring.io/spring-cloud-config/reference/html/) | 活跃 | Spring 生态原生支持，基于 Git 存储 | +| [Nacos](https://github.com/alibaba/nacos) | 活跃 | 阿里开源，配置中心 + 服务发现二合一 | +| [Apollo](https://github.com/apolloconfig/apollo) | 活跃 | 携程开源，配置管理功能最完善 | +| K8s ConfigMap | 活跃 | Kubernetes 原生方案 | +| Disconf / Qconf | 停止维护 | 不建议使用 | + +**选型建议**： + +- 只需配置中心 → **Apollo**（功能最完善）或 **Nacos**（上手更简单） +- 需要配置中心 + 服务发现 → **Nacos** +- Spring Cloud 体系且追求简单 → **Spring Cloud Config** +- Kubernetes 环境 → **K8s ConfigMap 挂载 + 应用层文件监听**（由于 Kubelet 同步 Volume 存在 1~2 分钟延迟，需引入 inotify 或 Spring Cloud Kubernetes 实现热重载） + +**Apollo vs Nacos vs Spring Cloud Config** + +> **版本说明**：以下对比基于 Apollo 2.x、Nacos 2.x、Spring Cloud Config 3.x + +| 功能点 | Apollo | Nacos | Spring Cloud Config | +| ------------ | --------------------- | ------------------------------ | ------------------------------------ | +| 配置界面 | 支持（功能完善） | 支持 | 无（通过 Git 操作） | +| 配置实时生效 | 支持（长轮询，1s 内） | 支持（gRPC 长连接，1s 内） | 半实时（需触发 refresh 或 Bus 广播） | +| 版本管理 | 原生支持 | 原生支持 | 依赖 Git | +| 权限管理 | 支持（细粒度） | 支持 | 依赖 Git 平台 | +| 灰度发布 | 支持（完善） | 支持（1.1.0+，基础） | 不支持 | +| 配置回滚 | 支持 | 支持 | 依赖 Git | +| 告警通知 | 支持 | 支持 | 不支持 | +| 多语言 | 支持（Open API） | 支持（Open API） | 仅 Spring 应用 | +| 多环境 | 支持 | 支持 | 需配合多 Git 仓库 | +| 依赖组件 | MySQL + Eureka | 内置存储（Derby/MySQL）+ JRaft | Git + 可选消息队列 | + +**深度对比**： + +1. **Apollo**：配置管理功能最完善（灰度发布、权限控制、审计日志），但部署复杂度较高。多环境（FAT/UAT/PROD）物理隔离场景下，需独立部署 Portal、Admin Service、Config Service 及独立数据库集群，运维门槛中等偏高 +2. **Nacos**：配置 + 注册中心二合一，部署简单（单机模式仅一个 Jar 包），但灰度等功能相对基础 +3. **Spring Cloud Config**：架构最简单（基于 Git），但实时性差，需要额外组件实现自动刷新 + +## 配置中心核心设计要点 + +设计或选型配置中心时，需关注以下能力： + +### 1. 配置推送机制 + +| 模式 | 实时性 | 服务端压力 | 实现复杂度 | 适用场景 | +| ---------- | --------------- | ---------------------------- | ---------- | ------------ | +| **推模式** | 高（毫秒级） | 高（需维护连接） | 高 | 强实时性要求 | +| **拉模式** | 低（秒~分钟级） | 高（无效轮询） | 低 | 配置变更极少 | +| **长轮询** | 中高（1~30s） | 中等（海量连接时内存压力大） | 中 | **主流方案** | + +> **推送机制说明**： +> +> - **Apollo**：采用 HTTP 长轮询。客户端发起请求，服务端若有变更立即返回；无变更则挂起请求（默认 30s），期间一旦有变更立即响应。 +> - **Nacos 2.x**：采用 gRPC 长连接双向流。相比 1.x 的 HTTP 长轮询，gRPC 连接更轻量，配置变更可毫秒级主动 Push 至客户端。 +> +> **注意**：长轮询虽然比短轮询节省 CPU 和网络开销，但当客户端规模达到十万级时，服务端需维持海量挂起的 HTTP 请求（依赖 Servlet AsyncContext），对内存和连接数上限仍有较大压力。 + +### 2. 必备功能清单 + +- **权限控制**：配置的查看、修改、发布需分级授权 +- **审计日志**：完整记录配置变更的操作人、时间、内容 +- **版本管理**：每次发布生成版本号，支持回滚到任意历史版本 +- **灰度发布**：配置先推送到部分实例，验证通过后全量发布 +- **多环境隔离**：开发、测试、生产环境配置独立管理 +- **高可用部署**：配置中心自身需要集群化部署，避免单点故障 + +## 以 Apollo 为例介绍配置中心的设计 + +### Apollo 介绍 + +根据 Apollo 官方介绍： + +> [Apollo](https://github.com/ctripcorp/apollo)（阿波罗）是携程框架部门研发的分布式配置中心，能够集中化管理应用不同环境、不同集群的配置，配置修改后能够实时推送到应用端，并且具备规范的权限、流程治理等特性，适用于微服务配置管理场景。 +> +> 服务端基于 Spring Boot 和 Spring Cloud 开发，打包后可以直接运行，不需要额外安装 Tomcat 等应用容器。 +> +> Java 客户端不依赖任何框架，能够运行于所有 Java 运行时环境，同时对 Spring/Spring Boot 环境也有较好的支持。 + +Apollo 核心特性： + +- **配置修改实时生效（热发布）**：基于长轮询，1s 内即可接收到最新配置 +- **灰度发布**：配置只推给部分应用，降低变更风险 +- **部署简单**：单环境仅依赖 MySQL（Eureka 可使用内置模式），但多环境隔离部署复杂度较高 +- **跨语言**：提供了 HTTP 接口，不限制编程语言 + +关于如何使用 Apollo 可以查看 [Apollo 官方使用指南](https://www.apolloconfig.com/#/zh/)。 + +### Apollo 架构解析 + +官方给出的 Apollo 基础模型： + +![](https://img-blog.csdnimg.cn/a75ccb863e4a401d947c87bb14af7dc3.png) + +1. 用户在 Apollo 配置中心修改/发布配置 +2. Apollo 配置中心通知应用配置已更改 +3. 应用访问 Apollo 配置中心获取最新配置 + +官方架构图： + +![](https://img-blog.csdnimg.cn/79c7445f9dbc45adb45699d40ef50f44.png) + +### 组件说明 + +| 组件 | 作用 | 默认端口 | +| ------------------ | --------------------------------------------- | -------- | +| **Portal** | Web 管理界面，提供配置的可视化管理 | 8070 | +| **Client** | 客户端 SDK，提供配置获取和变更监听能力 | - | +| **Meta Server** | Eureka 的 HTTP 代理，与 Config Service 同进程 | 8080 | +| **Config Service** | 提供配置读取和推送接口，供 Client 调用 | 8080 | +| **Admin Service** | 提供配置管理接口，供 Portal 调用 | 8090 | +| **Eureka** | 服务注册中心，Config/Admin Service 注册于此 | 8761 | +| **MySQL** | 存储配置数据和元数据 | 3306 | + +### 核心流程 + +**Client 端（获取配置）**： + +1. Client 启动时访问 Meta Server 获取 Config Service 地址列表 +2. Client 本地缓存服务地址（Eureka 故障时仍可用） +3. Client 发起长轮询请求获取配置 +4. Config Service 检测到配置变更后立即响应 +5. Client 更新内存缓存、触发变更回调，并**异步持久化到本地文件系统**（默认位于 `/opt/data/` 或 `/opt/logs/`） + +> **灾备机制**：即使 Config Service 全部宕机且应用重启，Client 仍可从本地磁盘读取缓存的配置完成启动，确保应用可用性不强依赖配置中心。 + +**Portal 端（发布配置）**： + +1. 用户在 Portal 修改配置并点击发布 +2. Portal 调用 Admin Service 发布接口 +3. Admin Service 将配置写入 MySQL 并生成发布版本 +4. Config Service 通过长轮询通知 Client 配置已变更 +5. Client 重新拉取最新配置 + +### Client 使用示例 + +获取配置： + +```java +Config config = ConfigService.getAppConfig(); +String someKey = "someKeyFromDefaultNamespace"; +String someDefaultValue = "someDefaultValueForTheKey"; +String value = config.getProperty(someKey, someDefaultValue); +``` + +监听配置变化： + +```java +Config config = ConfigService.getAppConfig(); +config.addChangeListener(new ConfigChangeListener() { + @Override + public void onChange(ConfigChangeEvent changeEvent) { + // 处理配置变更 + for (String key : changeEvent.changedKeys()) { + ConfigChange change = changeEvent.getChange(key); + System.out.println(String.format( + "Key: %s, Old: %s, New: %s", + key, change.getOldValue(), change.getNewValue())); + } + } +}); +``` + +## 参考 + +- [Nacos 官方文档](https://nacos.io/zh-cn/docs/what-is-nacos.html) +- [Apollo 官方文档](https://www.apolloconfig.com/#/zh/README) +- [Spring Cloud Config 官方文档](https://cloud.spring.io/spring-cloud-config/reference/html/) +- [Nacos 1.1.0 发布，支持灰度配置](https://nacos.io/zh-cn/blog/nacos%201.1.0.html) +- [Apollo 在有赞的实践](https://mp.weixin.qq.com/s/Ge14UeY9Gm2Hrk--E47eJQ) +- [微服务配置中心选型比较](https://www.itshangxp.com/spring-cloud/spring-cloud-config-center/) diff --git a/docs/distributed-system/distributed-id-design.md b/docs/distributed-system/distributed-id-design.md index 57077904251..b47319430a0 100644 --- a/docs/distributed-system/distributed-id-design.md +++ b/docs/distributed-system/distributed-id-design.md @@ -1,7 +1,13 @@ --- -title: 分布式ID设计指南 -description: 分布式ID设计实战指南，结合订单系统、优惠券等业务场景讲解分布式ID的设计要点与技术选型。 +title: 分布式ID设计实战指南 category: 分布式 +description: 分布式ID设计实战指南，结合订单系统、一码付、优惠券等业务场景讲解分布式ID的设计要点、技术选型及不同场景下的ID生成策略。 +tag: + - 分布式ID +head: + - - meta + - name: keywords + content: 分布式ID,分布式ID设计,订单ID生成,优惠券ID,一码付,ID生成策略,分布式系统设计 --- ::: tip diff --git a/docs/distributed-system/distributed-id.md b/docs/distributed-system/distributed-id.md index fd117f94e2c..794f6fcc3b8 100644 --- a/docs/distributed-system/distributed-id.md +++ b/docs/distributed-system/distributed-id.md @@ -1,7 +1,13 @@ --- -title: 分布式ID介绍&实现方案总结 -description: 分布式ID生成方案详解，涵盖UUID、数据库自增、号段模式、雪花算法等主流方案的原理与优缺点对比。 +title: 分布式ID生成方案总结 category: 分布式 +description: 分布式ID生成方案详解，涵盖UUID、数据库自增ID、号段模式、雪花算法（Snowflake）、Leaf等主流方案的原理、优缺点对比及适用场景分析。 +tag: + - 分布式ID +head: + - - meta + - name: keywords + content: 分布式ID,雪花算法,Snowflake,UUID,号段模式,Leaf,分布式ID生成,全局唯一ID,分布式ID面试题 --- diff --git a/docs/distributed-system/distributed-lock-implementations.md b/docs/distributed-system/distributed-lock-implementations.md index d38726a4d63..b3ea0c265e8 100644 --- a/docs/distributed-system/distributed-lock-implementations.md +++ b/docs/distributed-system/distributed-lock-implementations.md @@ -1,7 +1,13 @@ --- title: 分布式锁常见实现方案总结 -description: 分布式锁常见实现方案详解，包括基于Redis、ZooKeeper实现分布式锁的原理、优缺点及最佳实践。 category: 分布式 +description: 分布式锁常见实现方案详解，包括基于Redis SETNX、Redlock、ZooKeeper临时节点实现分布式锁的原理、优缺点对比及最佳实践。 +tag: + - 分布式锁 +head: + - - meta + - name: keywords + content: 分布式锁,Redis分布式锁,ZooKeeper分布式锁,SETNX,Redlock,分布式锁实现,分布式锁面试题 --- diff --git a/docs/distributed-system/distributed-lock.md b/docs/distributed-system/distributed-lock.md index 1f48e5dc071..f093658e864 100644 --- a/docs/distributed-system/distributed-lock.md +++ b/docs/distributed-system/distributed-lock.md @@ -1,7 +1,13 @@ --- -title: 分布式锁介绍 -description: 分布式锁基础概念详解，讲解为什么需要分布式锁、分布式锁的核心特性及常见应用场景分析。 +title: 分布式锁入门介绍 category: 分布式 +description: 分布式锁基础概念详解，讲解为什么需要分布式锁、分布式锁的核心特性（互斥性、防死锁、可重入）、常见应用场景（秒杀、库存扣减）分析。 +tag: + - 分布式锁 +head: + - - meta + - name: keywords + content: 分布式锁,分布式锁介绍,为什么需要分布式锁,分布式锁应用场景,秒杀超卖,分布式锁面试题 --- diff --git a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-in-action.md b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-in-action.md index 06389b2986d..18182f11977 100644 --- a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-in-action.md +++ b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-in-action.md @@ -1,9 +1,13 @@ --- -title: ZooKeeper 实战 -description: ZooKeeper实战教程，涵盖Docker安装部署、常用命令操作及Curator客户端的使用方法详解。 +title: ZooKeeper实战教程 category: 分布式 +description: ZooKeeper实战教程，涵盖Docker安装部署、zkCli常用命令操作（create/get/set/delete/ls）、四字命令（stat/srvr/dump）及Curator Java客户端的CRUD操作与分布式锁实现。 tag: - ZooKeeper +head: + - - meta + - name: keywords + content: ZooKeeper,ZooKeeper安装,ZooKeeper命令,Curator,zkCli,分布式锁,Docker部署,四字命令,ZooKeeper实战 --- diff --git a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md index 1f7dc37ea26..52226a1bd67 100644 --- a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md +++ b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-intro.md @@ -1,9 +1,13 @@ --- -title: ZooKeeper相关概念总结(入门) -description: ZooKeeper入门指南，讲解ZooKeeper核心概念、数据模型、Watcher机制及作为注册中心和分布式锁的应用。 +title: ZooKeeper入门指南 category: 分布式 +description: ZooKeeper入门指南，讲解ZooKeeper核心概念、数据模型（ZNode/节点类型）、Watcher监听机制、ACL权限控制及作为注册中心、分布式锁、配置中心的典型应用场景。 tag: - ZooKeeper +head: + - - meta + - name: keywords + content: ZooKeeper,ZooKeeper入门,ZNode,Watcher,分布式锁,注册中心,分布式协调,ZAB,临时节点,持久节点 --- @@ -272,7 +276,7 @@ ZAB 协议包括两种基本的模式，分别是 关于 **ZAB 协议&Paxos 算法** 需要讲和理解的东西太多了，具体可以看下面这几篇文章： - [Paxos 算法详解](https://javaguide.cn/distributed-system/protocol/paxos-algorithm.html) -- [ZooKeeper 与 Zab 协议 · Analyze](https://wingsxdu.com/posts/database/zookeeper/) +- [Zab 协议详解](https://javaguide.cn/distributed-system/protocol/zab.html) - [Raft 算法详解](https://javaguide.cn/distributed-system/protocol/raft-algorithm.html) ## ZooKeeper VS ETCD diff --git a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md index a2c70bf827d..5c88bf8e7b2 100644 --- a/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md +++ b/docs/distributed-system/distributed-process-coordination/zookeeper/zookeeper-plus.md @@ -1,9 +1,13 @@ --- -title: ZooKeeper相关概念总结(进阶) -description: ZooKeeper进阶详解，深入讲解ZAB协议、Leader选举机制、集群部署及与Eureka等注册中心的对比。 +title: ZooKeeper进阶详解 category: 分布式 +description: ZooKeeper进阶详解，深入讲解ZAB协议原理、Leader选举机制（FastLeaderElection）、集群部署策略（奇数节点）、会话管理及与Eureka、Nacos等注册中心的对比分析。 tag: - ZooKeeper +head: + - - meta + - name: keywords + content: ZooKeeper,ZAB协议,Leader选举,集群部署,会话管理,Eureka对比,Nacos对比,分布式协调,CP系统 --- > [FrancisQ](https://juejin.im/user/5c33853851882525ea106810) 投稿。 diff --git a/docs/distributed-system/distributed-transaction.md b/docs/distributed-system/distributed-transaction.md index cfb8ac6bde5..9f5e72800f8 100644 --- a/docs/distributed-system/distributed-transaction.md +++ b/docs/distributed-system/distributed-transaction.md @@ -1,7 +1,13 @@ --- -title: 分布式事务常见解决方案总结(付费) -description: 分布式事务常见解决方案详解，包括2PC、3PC、TCC、Saga、本地消息表等方案的原理与适用场景分析。 +title: 分布式事务解决方案总结 category: 分布式 +description: 分布式事务常见解决方案详解，包括2PC两阶段提交、3PC三阶段提交、TCC补偿事务、Saga编排模式、本地消息表、事务消息等方案的原理、优缺点及适用场景分析。 +tag: + - 分布式事务 +head: + - - meta + - name: keywords + content: 分布式事务,2PC,TCC,Saga,本地消息表,事务消息,分布式系统,最终一致性,补偿事务,分布式事务面试题 --- **分布式事务** 相关的面试题为我的[知识星球](https://javaguide.cn/about-the-author/zhishixingqiu-two-years.html)（点击链接即可查看详细介绍以及加入方法）专属内容，已经整理到了《Java 面试指北》中。 diff --git a/docs/distributed-system/protocol/cap-and-base-theorem.md b/docs/distributed-system/protocol/cap-and-base-theorem.md index 3611c58ea78..fad717998a5 100644 --- a/docs/distributed-system/protocol/cap-and-base-theorem.md +++ b/docs/distributed-system/protocol/cap-and-base-theorem.md @@ -1,9 +1,13 @@ --- -title: CAP & BASE理论详解 -description: CAP定理与BASE理论详解，深入讲解分布式系统一致性、可用性、分区容错性的权衡与实际应用。 +title: CAP定理与BASE理论详解 category: 分布式 +description: CAP定理与BASE理论详解，深入讲解分布式系统一致性（Consistency）、可用性（Availability）、分区容错性（Partition Tolerance）的权衡取舍及BASE理论的基本可用、软状态、最终一致性在实际系统中的应用。 tag: - 分布式理论 +head: + - - meta + - name: keywords + content: CAP定理,BASE理论,分布式系统,一致性,可用性,分区容错,最终一致性,分布式理论,分布式面试题 --- @@ -132,7 +136,7 @@ flowchart TB | 更贴近 CAP 讨论模型 | 需要拆分到分片/对象/操作级别分析 | | ------------------- | ------------------------------------ | -| Redis 主从/哨兵集群 | 业务系统（无状态服务）\* | +| Redis 主从/哨兵集群 | 业务系统（无状态服务） | | MySQL 主从/多主集群 | Redis-Cluster（每个 shard 仍有副本） | | MongoDB 副本集 | MongoDB-Cluster（分片 + 副本并存） | | ZooKeeper、etcd | 分库分表（跨分片事务需额外协调） | @@ -449,7 +453,7 @@ flowchart LR - **读时修复（Read Repair）**：在读取数据时，检测数据的不一致，进行修复。适合读多写少场景。 - **写时修复（Hinted Handoff）**：在写入数据时，如果目标节点不可用，将数据缓存下来，待节点恢复后重传。**写时修复** 优化了写入延迟，但增加了读取时的不一致风险（数据可能还在缓存队列中未落盘到目标节点）。 -- **异步修复（Anti-Entropy/反熵）**：通过后台比对副本数据差异并修复。工程实现中关键挑战是**高效检测数据差异**——暴力逐条比对（O(n)）在大规模数据集下不可行，生产系统采用**默克尔树（Merkle Tree）**实现低开销差异定位： +- **异步修复（Anti-Entropy/反熵）**：通过后台比对副本数据差异并修复。工程实现中关键挑战是**高效检测数据差异**——暴力逐条比对（O(n)）在大规模数据集下不可行，生产系统采用**默克尔树（Merkle Tree）**实现低开销差异定位。 **选择建议**： @@ -521,48 +525,4 @@ flowchart TB > - **BASE 的可用性** = 分片式集群的可用性（部分节点故障只影响部分用户） > - **CAP 与 BASE 的关系**：选择 AP 架构后，BASE 理论指导如何在工程实践中通过最终一致性达到系统收敛 -## 生产落地建议 - -### 选择 CP 还是 AP 的决策框架 - -> **重要提示**：简单给系统贴「CP/AP」标签是有风险的。在网络分区下： -> -> - **X 的写更倾向于优先保持线性一致**（可能拒绝服务/降级） -> - **Y 更倾向于优先保持可用**（允许短时间读到旧数据） -> 具体取决于操作类型与配置。 - -| 场景特征 | 倾向选择 | 典型系统说明 | -| ------------------------------ | -------------- | ----------------------------------------------------------- | -| 强一致性要求（金融转账） | 倾向线性一致写 | ZooKeeper（写入需 Quorum 确认）、etcd、Consul（CP 模式） | -| 高可用优先（服务发现） | 倾向可用性 | Eureka（允许读到旧实例）、Consul（可切换模式） | -| 可调一致性（根据业务动态选择） | 可配置 | Nacos（支持 CP/AP 切换）、Cassandra（可调节读写一致性级别） | -| 写多读少 | 倾向异步写优化 | Cassandra（可配置 QUORUM 写）、HBase | -| 读多写少 | 倾向低延迟读 | DynamoDB（可调节最终一致性级别） | - -### 监控指标 - -- **分区检测时间**：多久发现网络分区 -- **收敛时间（Convergence Time）**：副本从不一致到一致的时间 -- **读写延迟 P99**：CAP 权衡的直接体现 -- **不一致窗口**：业务可接受的数据延迟 - -### 常见误区 - -#### CAP 相关误区 - -- ❌ 「选择了 AP 就永远放弃一致性」→ ✅ AP 系统可通过 Read Repair、Anti-Entropy（Merkle Tree）达到最终一致 -- ❌ 「ZooKeeper 是强一致的」→ ✅ ZooKeeper 提供**线性化写入** + **顺序一致性读取**（非最终一致性），读取存在滞后但保证全局顺序 -- ❌ 「顺序一致性 = 最终一致性」→ ✅ 顺序一致性保证全局更新顺序，最终一致性不保证顺序；ZooKeeper 普通读取是前者而非后者 -- ❌ 「银行系统必须 CP」→ ✅ 实际银行采用 BASE + 补偿事务（Saga），核心账务强一致，查询服务可最终一致 -- ❌ 「业务系统不需要考虑 CAP」→ ✅ 业务系统虽不直接实践 CAP，但 RPC 路由、限流熔断、分布式锁等均受底层组件 CAP 属性影响，忽视会导致级联雪崩 -- ❌ 「分库分表不需要考虑 CAP」→ ✅ 分片式存储通常仍然需要为每个 shard 做副本复制，因此仍需面对 CAP 的权衡 -- ❌ 「CAP 的 A 等于低延迟/高 SLA」→ ✅ CAP 的可用性定义不包含延迟要求，只要求非故障节点必须返回响应（可以很慢） - -#### BASE 相关误区 - -- ❌ 「BASE 是 CAP 的补充/延伸」→ ✅ BASE 首先是 ACID 的替代品；同时 BASE 是 AP 架构的工程实践指南（AP 选择了放弃强一致性，BASE 告诉你如何达到最终一致） -- ❌ 「BASE 的一致性 = CAP 的一致性」→ ✅ BASE 的一致性是状态一致性（= ACID 一致性），CAP 的一致性是数据一致性 -- ❌ 「BASE 只适用于主从集群」→ ✅ BASE 适用于所有分布式系统；其「基本可用」概念在分片式集群中表现更明显（部分节点故障只影响部分用户） -- ❌ 「最终一致性是弱一致性」→ ✅ 最终一致性是弱一致性的升级版，保证系统最终会达到一致状态，而弱一致性不提供此保证 - diff --git a/docs/distributed-system/protocol/consistent-hashing.md b/docs/distributed-system/protocol/consistent-hashing.md index 10bebe8197c..5f219da0138 100644 --- a/docs/distributed-system/protocol/consistent-hashing.md +++ b/docs/distributed-system/protocol/consistent-hashing.md @@ -1,10 +1,14 @@ --- title: 一致性哈希算法详解 -description: 一致性哈希算法原理详解，讲解哈希环、虚拟节点机制及在分布式缓存、负载均衡中的应用场景。 category: 分布式 +description: 一致性哈希算法原理详解，讲解哈希环、虚拟节点机制、数据倾斜问题解决方案，以及在分布式缓存（Redis/Memcached）、负载均衡、分库分表中的应用场景。 tag: - 分布式协议&算法 - 哈希算法 +head: + - - meta + - name: keywords + content: 一致性哈希,哈希环,虚拟节点,分布式缓存,负载均衡,数据倾斜,哈希算法,分布式算法,分库分表 --- 开始之前，先说两个常见的场景： @@ -111,7 +115,7 @@ hash（服务器ip）% 2^32 如下图所示，Node1、Node2、Node3、Node4 这 4 个节点都对应 3 个虚拟节点（下图只是为了演示，实际情况节点分布不会这么有规律）。 -![](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/consistent-hashing/consistent-hashing-circle-virtual-node.png) +![虚拟节点](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/consistent-hashing/consistent-hashing-circle-virtual-node.png) 对于上图来说，每个节点最终负责的数据情况如下： diff --git a/docs/distributed-system/protocol/gossip-protocol.md b/docs/distributed-system/protocol/gossip-protocol.md index e03af2e583d..cb231b4c68c 100644 --- a/docs/distributed-system/protocol/gossip-protocol.md +++ b/docs/distributed-system/protocol/gossip-protocol.md @@ -1,11 +1,15 @@ --- -title: Gossip 协议详解 -description: Gossip协议原理详解，讲解去中心化信息传播机制、两种典型传播模式（反熵与谣言传播）及在Redis Cluster等系统中的应用。 +title: Gossip协议详解 category: 分布式 +description: Gossip协议原理详解，讲解去中心化信息传播机制、两种典型传播模式（反熵Anti-Entropy与谣言传播Rumor-Mongering）、SWIM协议及在Redis Cluster、Cassandra等分布式系统中的应用。 tag: - 分布式协议&算法 - 数据复制协议 - 最终一致性 +head: + - - meta + - name: keywords + content: Gossip协议,反熵,谣言传播,去中心化,Redis Cluster,SWIM,分布式通信,最终一致性,分布式协议 --- ## 背景 diff --git a/docs/distributed-system/protocol/paxos-algorithm.md b/docs/distributed-system/protocol/paxos-algorithm.md index 6a35f5557f3..6484c9470d1 100644 --- a/docs/distributed-system/protocol/paxos-algorithm.md +++ b/docs/distributed-system/protocol/paxos-algorithm.md @@ -1,10 +1,14 @@ --- -title: Paxos 算法详解 -description: Paxos 共识算法原理详解，涵盖 Basic Paxos 两阶段提交流程、Multi-Paxos 优化思想及与 Raft 的对比分析。 +title: Paxos算法详解 category: 分布式 -tags: +description: Paxos共识算法原理详解，涵盖Basic Paxos两阶段提交（Prepare/Accept）流程、Proposer/Proposer/Acceptor角色、Multi-Paxos优化思想以及与Raft算法的对比分析。 +tag: - 分布式协议&算法 - 共识算法 +head: + - - meta + - name: keywords + content: Paxos算法,Paxos,Basic Paxos,Multi-Paxos,共识算法,两阶段提交,分布式共识,Raft,Leslie Lamport,分布式算法 --- ## 背景 @@ -58,7 +62,7 @@ Basic Paxos 中存在 3 个重要的角色： 2. **接受者（Acceptor）**：也可以叫做投票员（voter），负责对提案进行投票，同时需要记住自己的投票历史。 3. **学习者（Learner）**：负责学习（learn）已被选定的值。在复制状态机（RSM）实现中，该值通常对应一条待执行的命令，由状态机按序 apply 后再由对外服务层返回结果。 -![](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/up-890fa3212e8bf72886a595a34654918486c.png) +![Basic Paxos中的角色](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/up-890fa3212e8bf72886a595a34654918486c.png) **角色交互关系图**： @@ -204,17 +208,17 @@ sequenceDiagram 为防止多个 Proposer 竞争导致活锁，生产级实现通常引入随机退避： -``` 当 Proposer 的 Prepare 请求被拒绝（编号过小）时： -1. 等待随机时间：base_delay * random(1, 2^attempt) -2. 选择更大的提案编号（如：n = n + k，k > 0） + +1. 等待随机时间：`base_delay * random(1, 2^attempt)` +2. 选择更大的提案编号（如：`n = n + k`，`k > 0`） 3. 重试 Prepare 阶段 参数示例： -- base_delay: 10ms -- attempt: 重试次数（1, 2, 3...） -- 最大退避时间：max(1s, base_delay * 2^10) -``` + +- `base_delay`: 10ms +- `attempt`: 重试次数（1, 2, 3...） +- 最大退避时间：`max(1s, base_delay * 2^10)` 这种机制确保竞争者不会同时重试，最终某个 Proposer 能成功完成 Phase 1。 diff --git a/docs/distributed-system/protocol/raft-algorithm.md b/docs/distributed-system/protocol/raft-algorithm.md index 75d88908b7f..b5302516306 100644 --- a/docs/distributed-system/protocol/raft-algorithm.md +++ b/docs/distributed-system/protocol/raft-algorithm.md @@ -1,21 +1,23 @@ --- -title: Raft 算法详解 -description: Raft共识算法原理详解，涵盖Leader选举、日志复制、安全性保证等核心机制及与Paxos的对比分析。 +title: Raft算法详解 category: 分布式 +description: Raft共识算法原理详解，涵盖Leader选举（随机超时机制）、日志复制（Log Replication）、安全性保证（选举限制/日志匹配）、成员变更等核心机制，以及与Paxos算法的对比分析。etcd、Consul均采用Raft实现。 tag: - 分布式协议&算法 - 共识算法 +head: + - - meta + - name: keywords + content: Raft算法,Raft,共识算法,Leader选举,日志复制,etcd,Consul,分布式共识,Paxos,分布式算法 --- > 本文由 [SnailClimb](https://github.com/Snailclimb) 和 [Xieqijun](https://github.com/jun0315) 共同完成。 ## 1 背景 -当今的数据中心和应用程序在高度动态的环境中运行，为了应对高度动态的环境，它们通过额外的服务器进行横向扩展，并且根据需求进行扩展和收缩。同时，服务器和网络故障也很常见。 +在如今的互联网架构中，为了扛住海量流量，系统往往需要横向堆机器。机器一多，宕机、断网这些破事就成了家常便饭。怎么让这群随时可能掉线的服务器保持步调一致，不对外提供错乱的数据？这就轮到**分布式共识算法**出场了。 -Raft 算法由 Diego Ongaro 和 John Ousterhout 于 2014 年在 Usenix ATC 会议论文《In Search of an Understandable Consensus Algorithm》中提出。Raft 通过复制日志来保证副本状态机的一致性与安全性；在配套正确的客户端交互与读实现（如 ReadIndex / Lease Read、请求去重）后，可实现线性一致（linearizable）的读写语义，旨在作为 Paxos 的更易理解替代。 - -相比 Paxos，Raft 通过分解为相对独立的子问题降低复杂度： +2014年，Diego Ongaro 等人发表了 Raft 算法。它的诞生有一个很明确的使命：**拯救被 Paxos 算法折磨的程序员**。Raft 主打一个“易于理解”，它将复杂的共识问题拆解成了几个独立的模块： - **Leader 选举**：使用随机化选举超时（工程上常见如 150–300ms 或更大范围，具体取决于网络与故障模型）。 - **日志复制**：Leader 通过 AppendEntries RPC 广播日志。 @@ -34,43 +36,29 @@ Raft 在实际生产中得到了广泛应用，基于 Raft 的实现如 etcd、C ### 1.1 非拜占庭条件下的"选主"类比 -Raft 工作在非拜占庭（Crash Fault Tolerance, CFT）假设下：节点可能宕机、重启、网络延迟或分区，但不会恶意伪造/篡改消息。下面用"多方通过投票选出指挥者"的类比，仅用于帮助理解 Leader 选举与重试机制，不涉及拜占庭容错（BFT）。 - -> 假设多位将军需要选出一位指挥官，信使的信息可靠但有可能被暗杀（网络故障），将军们如何达成一致？ +Raft 有一个前提假设：**非拜占庭容错（CFT）**。说白了就是，兄弟们可能会死机、会断网，但绝对不会出内鬼传递假情报。 -解决方案大致可以理解成：先在所有的将军中选出一个大将军，用来做出所有的决定。 +我们可以用“将军选帅”来粗略理解这个过程： 假设有 A、B、C 三个将军，目前群龙无首。每个人心里都有个随机的倒计时（选举超时）。谁的倒计时先结束，谁就站出来大喊：“我要当大将军，请给我投票！” 如果其他将军还没开始竞选，也没把票投给别人，就会顺水推舟同意他。当这位将军拿到**过半数**的赞成票，他就成了大当家（Leader）。以后打不打仗，全听他的。如果信使半路阵亡，大家都没收到回音，那就重置倒计时，再来一轮。 -举例如下：假如现在一共有 3 个将军 A，B 和 C，每个将军都有一个随机时间的倒计时器，倒计时一结束，这个将军就把自己当成大将军候选人，然后派信使传递选举投票的信息给将军 B 和 C，如果将军 B 和 C 还没有把自己当作候选人（自己的倒计时还没有结束），并且没有把选举票投给其他人，它们就会把票投给将军 A，信使回到将军 A 时，将军 A 知道自己收到了足够的票数，成为大将军。在有了大将军之后，是否需要进攻就由大将军 A 决定，然后再去派信使通知另外两个将军，自己已经成为了大将军。如果一段时间还没收到将军 B 和 C 的回复（信使可能会被暗杀），那就再重派一个信使，直到收到回复。 +### 1.2 到底什么是共识算法？ -### 1.2 共识算法 +共识算法的核心目标，就是**让一群机器看起来像一台机器**。只要集群里超过半数的机器还活着，整个系统就能正常接客。 -共识是可容错系统中的一个基本问题：即使面对故障，服务器也可以在共享状态上达成一致。 - -共识算法允许一组节点像一个整体一样一起工作，即使其中的一些节点出现故障也能够继续工作下去，其正确性主要是源于复制状态机的性质：一组`Server`的状态机计算相同状态的副本，即使有一部分的`Server`宕机了它们仍然能够继续运行。 +这通常是通过**复制状态机**来实现的：给每个节点发一本一模一样的账本（日志）。只要大家按照同样的顺序去执行账本上的命令，最后得到的结果自然完全一样。所以，共识算法本质上干的就是一件事——**保证所有节点的账本绝对一致**。共识是可容错系统中的一个基本问题：即使面对故障，服务器也可以在共享状态上达成一致。 ![共识算法架构](https://oss.javaguide.cn/github/javaguide/paxos-rsm-architecture.png) -一般通过使用复制日志来实现复制状态机。每个`Server`存储着一份包括命令序列的日志文件，状态机会按顺序执行这些命令。因为每个日志包含相同的命令，并且顺序也相同，所以每个状态机处理相同的命令序列。由于状态机是确定性的，所以处理相同的状态，得到相同的输出。 - -因此共识算法的工作就是保持复制日志的一致性。服务器上的共识模块从客户端接收命令并将它们添加到日志中。它与其他服务器上的共识模块通信，以确保即使某些服务器发生故障，系统仍能在日志顺序上达成一致；最终每个日志都包含相同顺序的请求。一旦命令被正确地复制，它们就被称为已提交。每个服务器的状态机按照日志顺序处理已提交的命令，并将输出返回给客户端，因此，这些服务器形成了一个单一的、高度可靠的状态机。 - -适用于实际系统的共识算法通常具有以下特性： - -- 安全。确保在非拜占庭条件（也就是上文中提到的简易版拜占庭）下的安全性，包括网络延迟、分区、包丢失、复制和重新排序。 -- 高可用。只要大多数服务器都是可操作的，并且可以相互通信，也可以与客户端进行通信，那么这些服务器就可以看作完全功能可用的。因此，一个典型的由五台服务器组成的集群可以容忍任何两台服务器端故障。假设服务器因停止而发生故障；它们稍后可能会从稳定存储上的状态中恢复并重新加入集群。 -- 一致性不依赖时序。错误的时钟和极端的消息延迟，在最坏的情况下也只会造成可用性问题，而不会产生一致性问题。 - -- 在集群中大多数服务器响应，命令就可以完成，不会被少数运行缓慢的服务器来影响整体系统性能。 +## 2 基础概念 -## 2 基础 +在深入 Raft 之前，我们得先认识里面的三大核心角色、任期机制和日志结构。 ### 2.1 节点类型 一个 Raft 集群包括若干服务器，以典型的 5 服务器集群举例。在任意的时间，每个服务器一定会处于以下三个状态中的一个： -- `Leader`：负责发起心跳，响应客户端，创建日志，同步日志。 -- `Candidate`：Leader 选举过程中的临时角色，由 Follower 转化而来，发起投票参与竞选。 -- `Follower`：接受 Leader 的心跳和日志同步数据，投票给 Candidate。 +- **Leader（领导者）**：大当家。全权负责接待客户端、写账本、并把账本同步给小弟。为了防止别人篡位，他必须不断地向全员发送心跳，宣告“我还活着”。 +- **Follower（跟随者）**：安分守己的小弟。平时绝对不主动发起请求，只被动接收老大的心跳和账本同步。 +- **Candidate（候选人）**：临时状态。如果小弟迟迟等不到老大的心跳，就会觉得自己行了，变身候选人开始拉票。 在正常的情况下，只有一个服务器是 Leader，剩下的服务器是 Follower。Follower 是被动的，它们不会发送任何请求，只是响应来自 Leader 和 Candidate 的请求。 @@ -90,13 +78,12 @@ Raft 算法将时间划分为任意长度的任期（term），任期用连续 ### 2.3 日志 -- `entry`：每一个事件成为 entry，只有 Leader 可以创建 entry。entry 的内容为``其中 cmd 是可以应用到状态机的操作。 -- `log`：由 entry 构成的数组，每一个 entry 都有一个表明自己在 log 中的 index。只有 Leader 才可以改变其他节点的 log。entry 总是先被 Leader 添加到自己的 log 数组中，然后再发起共识请求，获得同意后才会被 Leader 提交给状态机。Follower 只能从 Leader 获取新日志和当前的 commitIndex，然后把对应的 entry 应用到自己的状态机中。 +只有 Leader 有资格往账本里追加记录（Entry）。一条日志包含三个核心要素：`<当前任期, 索引号, 具体操作指令>`。 -补充两个常用指针： +这里有两个非常关键的进度指针： -- `commitIndex`：已提交（committed）的最大日志索引；表示哪些日志已经被集群确认并可以安全地应用到状态机。 -- `lastApplied`：已被状态机应用（applied）的最大日志索引；通常 lastApplied ≤ commitIndex。 +- **commitIndex**：大家公认已经安全落地的日志进度（已经被复制到过半数节点）。 +- **lastApplied**：这台机器本地真正执行完的日志进度。 ## 3 领导人选举 @@ -189,17 +176,18 @@ entry[0] 一致 → entry[1] 一致 → entry[2] 一致 → ... → entry[N] 一 ### 4.2 日志不一致的恢复 -一般情况下，Leader 和 Follower 的日志保持一致，但 Leader 的崩溃会导致日志出现差异。此时 AppendEntries 的一致性检查会失败，Leader 通过强制 Follower 复制自己的日志来处理日志的不一致。这就意味着，在 Follower 上的冲突日志会被领导者的日志覆盖。 +正常运作时，大当家（Leader）和小弟（Follower）的账本是完全同步的。然而，一旦老 Leader 突然宕机，新老交替之际往往会在集群中遗留大量未对齐的脏数据。 -为了使得 Follower 的日志和自己的日志一致，Leader 需要找到 Follower 与它日志一致的地方，然后删除 Follower 在该位置之后的日志，接着把这之后的日志发送给 Follower。 +这时，新 Leader 发起 AppendEntries 同步请求就会触发“一致性检查报错”。Raft 解决数据冲突的逻辑非常霸道：**一切以现任 Leader 的账本为最高准则**，Follower 本地任何不一致的记录都必须被无情抹除并强行覆盖。 -`Leader` 给每一个`Follower` 维护了一个 `nextIndex`，它表示 `Leader` 将要发送给该追随者的下一条日志条目的索引。当一个 `Leader` 开始掌权时，它会将 `nextIndex` 初始化为它的最新的日志条目索引数+1。如果一个 `Follower` 的日志和 `Leader` 的不一致，`AppendEntries` 一致性检查会在下一次 `AppendEntries RPC` 时返回失败。 +具体怎么做呢？Leader 会像“拉链”一样顺藤摸瓜，往前倒推寻找双方最后一次完美吻合的历史节点。找到这个“分叉点”后，Follower 会把分叉点之后的烂摊子全部咔嚓掉，老老实实地拷贝 Leader 提供的最新日志。 -**（朴素实现）**在失败之后，`Leader` 会将 `nextIndex` 递减然后重试 `AppendEntries RPC`，直到找到 Leader 与 Follower 日志一致的位置。 +在代码层面，Leader 会在内存里给每个 Follower 单独记一本账，核心指针叫 `nextIndex`（预估要发给该小弟的下一条日志位置）。新官上任三把火，Leader 刚接盘时，会盲目自信地把所有小弟的 `nextIndex` 都预设为自己最新日志的索引加一。如果小弟的数据其实比较落后或者有冲突，第一发 AppendEntries 必然惨遭拒绝。接下来就是找分叉点的两种流派： -**（工程优化）**实际生产实现通常会加入快速回退（Fast Backup）：Follower 在拒绝 AppendEntries 时返回冲突日志对应的任期（term）以及该任期的边界索引，Leader 据此一次性跳过整段冲突区间，显著减少重试次数。 +- **传统的朴素做法（逐条试探）**：撞了南墙就退一步。Leader 会把 `nextIndex` 减一，再发一次 RPC 试探。如果还不行，就继续减一，犹如乌龟漫步般逐条往前回退，直到彻底对上暗号。 +- **工业级提速优化（Fast Backup 快速回退）**：在真实的生产环境中，逐条回退绝对是性能灾难。因此，工业界引入了快速回退机制。小弟在拒绝同步时不再是单纯地摇摇头，而是直接亮出底牌：“我这批错乱日志属于哪个历史任期（term），以及这个任期的头尾边界在哪里”。Leader 拿到这份情报，直接大刀阔斧地一次性跨越整段错误任期，极大地削减了冗余的网络重试次数。 -最终 `nextIndex` 会达到一个 `Leader` 和 `Follower` 日志一致的地方。这时，`AppendEntries` 会返回成功，`Follower` 中冲突的日志条目都被移除了，并且添加所缺少的上了 `Leader` 的日志条目。一旦 `AppendEntries` 返回成功，`Follower` 和 `Leader` 的日志就一致了，这样的状态会保持到该任期结束。 +经过这番拉扯，`nextIndex` 终将精准锚定双方的共识起点。此时，AppendEntries 终于收获成功回执，Follower 上的冲突数据被彻底清空，缺失的正统日志被严丝合缝地填补。一旦跨过这个坎，双方的账本就能在整个任期内保持如影随形、高度一致。 ## 5 安全性 diff --git a/docs/distributed-system/protocol/zab.md b/docs/distributed-system/protocol/zab.md new file mode 100644 index 00000000000..85f6908ee94 --- /dev/null +++ b/docs/distributed-system/protocol/zab.md @@ -0,0 +1,110 @@ +--- +title: ZAB协议详解 +category: 分布式 +description: ZooKeeper的核心共识协议ZAB（ZooKeeper Atomic Broadcast，原子广播协议）详解，包括消息广播模式、崩溃恢复模式、Leader选举机制（ZXID/epoch）、数据恢复机制及Follower/Observer角色解析。 +tag: + - 分布式协议&算法 + - 共识算法 +head: + - - meta + - name: keywords + content: ZAB协议,ZooKeeper,原子广播,分布式一致性,Leader选举,崩溃恢复,ZXID,epoch,ZooKeeper原理 +--- + +作为一款极其优秀的分布式协调框架，ZooKeeper 的高可用和数据一致性备受业界推崇。很多人误以为 ZooKeeper 使用的是大名鼎鼎的 Paxos 算法，但实际上，它的"灵魂"是一个专门为其定制的共识协议——**ZAB（ZooKeeper Atomic Broadcast，原子广播协议）**。 + +ZAB 并非像 Paxos 那样是通用的分布式一致性算法，它是一种**特别为 ZooKeeper 设计的、支持崩溃可恢复的原子消息广播算法**。基于 ZAB 协议，ZooKeeper 实现了一种主备模式的架构，来保持集群中各个副本之间的数据一致性。 + +## ZAB 集群的核心角色与状态 + +在深入协议运作之前，我们需要先了解 ZooKeeper 集群中的三个主要角色： + +- **Leader（领导者）：** 集群中**唯一**的写请求处理者。它负责发起投票和协调事务，所有的写操作都必须经过 Leader。 +- **Follower（跟随者）：** 可以直接处理客户端的读请求。收到写请求时，会将其转发给 Leader。在 Leader 选举过程中，Follower 拥有选举权和被选举权。 +- **Observer（观察者）：** 功能与 Follower 类似，但**没有**选举权和被选举权。它的存在是为了在不影响集群共识性能（即不增加需要等待的投票数）的前提下，横向扩展集群的读性能。 + +对应的，集群中的节点通常处于以下四种状态之一： + +- `LOOKING`：寻找 Leader 状态（正在进行选举）。 +- `LEADING`：当前节点是 Leader，正在领导集群。 +- `FOLLOWING`：当前节点是 Follower，服从 Leader 领导。 +- `OBSERVING`：当前节点是 Observer。 + +## 核心标识：ZXID 与 Epoch + +为了保证分布式环境下消息的绝对顺序性，ZAB 协议引入了一个全局单调递增的事务 ID——**ZXID**。 + +ZXID 是一个 64 位的长整型（long）： + +- **高 32 位（Epoch 纪元）：** 代表当前 Leader 的任期年代。当选出一个新的 Leader 时，Epoch 就会在前一个的基础上加 1。这相当于朝代更替。 +- **低 32 位（事务 ID）：** 一个简单的递增计数器。针对客户端的每一个写请求，计数器都会加 1。新 Leader 上位时，这个低 32 位会被清零重置。 + +![ZXID 结构](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/zab-zxid-structure.png) + +## ZAB 的两种基本模式 + +ZAB 协议的运作可以精简为两种基本模式的交替：**消息广播**（正常工作状态）和**崩溃恢复**（异常或启动状态）。 + +### 1. 消息广播模式（正常处理写请求） + +![ZAB 消息广播模式](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/zab-message-broadcast-flow.png) + +当集群拥有健康的 Leader，且过半的节点完成了状态同步后，就会进入消息广播模式。这个过程类似于一个简化的“两阶段提交（2PC）”： + +1. **生成提案：** Leader 接收到写请求后，将其转化为一个带有 ZXID 的提案（Proposal）。 +2. **顺序发送：** Leader 为每个 Follower 维护了一个先进先出（FIFO）的网络队列（基于 TCP 协议），确保提案按生成顺序发送给 Follower。 +3. **写入与反馈（WAL 强制落盘）：** Follower 收到提案后，必须将其追加到本地的事务日志（TxnLog）中，并强制执行系统调用 `fsync` 将内核缓冲区的数据物理刷入磁盘。只有确认数据切实落盘，才会向 Leader 响应 `ACK`。这一过程是 ZAB 抵御断电丢失数据的核心防线。因此，在物理部署上，强烈建议将 ZooKeeper 的事务日志目录（`dataLogDir`）挂载到独立且无锁的 SSD 上，避免与其他高 I/O 进程争用磁盘，从而规避因 `fsync` 阻塞导致的 P99 响应时间恶化。生产环境中必须重点监控节点的 `fsynctime` 指标，若平均刷盘耗时经常超过 100ms，集群随时可能崩溃。 +4. **广播提交：** 当 Leader 收到**过半数** 节点的 `ACK` 响应后，就会认为该写操作成功。Leader 在本地写日志时会更新内部的 quorum 计数器（而非显式向自己发送 ACK），确认过半后向客户端返回成功响应，并向所有节点广播 `Commit` 消息。Follower 收到 `Commit` 后，正式将数据应用到内存中。 + +### 2. 崩溃恢复模式（Leader 宕机或网络异常） + +当系统刚启动，或者 Leader 服务器崩溃、与过半 Follower 失去联系时，整个集群就会暂停对外服务，进入 `LOOKING` 状态，触发崩溃恢复模式。崩溃恢复主要包含两个阶段：**Leader 选举**和**数据恢复**。 + +![zab-crash-recovery-flow](https://oss.javaguide.cn/github/javaguide/distributed-system/protocol/zab-crash-recovery-flow.png) + +#### 阶段一：Leader 选举 + +选举的核心原则是：**拥有最新数据的节点优先当选**。 每个节点都会先投自己一票，投票信息包含 `(Epoch, ZXID, myid)`。随后节点会交换选票，并按照以下顺序进行 PK： + +1. **比较 Epoch：** 纪元大的优先。 +2. **比较 ZXID：** 如果 Epoch 相同，ZXID 大的优先（代表数据越新）。 +3. **比较 myid：** 如果前两者都相同，服务器唯一标识 `myid` 大的优先。 + +一旦某个节点获得了**过半数**的选票，它就会成为新的 Leader。_(这也是为什么 ZooKeeper 推荐部署奇数台服务器的原因，能以最低的成本实现半数以上的容错。)_ + +#### 阶段二：数据恢复 + +选出新 Leader 只是第一步，为了保证数据一致性，ZAB 必须在数据同步阶段实现两个极其重要的保证： + +1. **确保已经在旧 Leader 上提交的事务，最终被所有节点提交。** （防止数据丢失） +2. **丢弃那些只在旧 Leader 上提出，但还没来得及提交的事务。** （防止脏数据干扰） + +新 Leader 会找到当前最大的 `Epoch` 并加 1 作为新纪元，随后与所有 Follower 进行比对。Follower 会发送自己事务日志中最新记录的 `lastZxid`（包含已提议但尚未提交的提案），Leader 根据这个值采取多态同步策略：**差异化增量同步（DIFF）**、**强制丢弃未提交日志（TRUNC）** 或 **全量快照传输（SNAP）**。 + +这一设计至关重要：Leader 需要准确识别 Follower 日志中是否残留着旧 Leader 未完成提交的"幽灵提案"，才能正确下发 TRUNC 指令让其截断回滚。如果只上报已提交的 ZXID，这些未提交的脏数据将无法被感知，TRUNC 分支就永远不会被触发。 + +更关键的是，此时新的 Epoch 已经生效。若原 Leader 因 JVM 触发长达数十秒的 Full GC 而发生"假死"，当其苏醒并试图向集群下发旧 Epoch 的提案时，由于过半节点已记录了更高的新 Epoch 且已向新 Leader 提交 quorum，这些幽灵提案将被节点无情拒绝并抛弃。ZAB 正是通过 **Epoch 机制 + 多数派 quorum** 的组合，从根本上免疫了网络环境下的脑裂现象——单靠 Epoch 拒绝还不够，必须有过半节点已经连上新 Leader，旧 Leader 才真正失去写入能力。 + +当过半的机器与新 Leader 完成了状态和数据同步，ZAB 协议就会平滑退出崩溃恢复模式，重新进入消息广播模式。 + +## 与 Raft 对比 + +**ZAB 与 Raft 的高度相似性：** 如果你了解过 Raft 算法，会发现它们非常相似。它们都有唯一的主节点，都使用 Epoch/Term 来标识任期，并且都采用了只要半数以上节点确认即可提交的策略。这说明在现代分布式共识领域，这种基于主备和多数派选举的架构已经成为了事实上的标准。 + +在当前的分布式系统实践中，Raft 算法通常被视为比 ZAB 更实用和受欢迎的选择。 这是因为 Raft 从设计之初就强调易懂性和可实现性，它将领导者选举、日志复制和安全性明确分离，这使得开发者更容易正确实施和调试，而 ZAB 作为 ZooKeeper 的专有协议，更侧重于原子广播的特定需求，导致其通用性较差。 + +Raft 已广泛应用于现代系统，如 Kubernetes 的 etcd、Hashicorp Consul、Apache Kafka（在其 KIP-500 版本中去除 ZooKeeper 依赖，转向 Raft-based KRaft）、TiKV 等，这极大“民主化”了分布式共识的开发。 + +相比之下，ZAB 主要绑定在 ZooKeeper 上，虽然 ZooKeeper 仍是经典的协调服务，但许多新项目倾向于选择 Raft 以避免 ZooKeeper 的额外复杂性和潜在瓶颈（如在大规模下共识开销）。 + +此外，Raft 的社区支持更活跃，衍生出多种优化变体（如用于区块链的改进版本），使其在效率和适用场景上更具优势。 然而，如果你的系统已深度集成 ZooKeeper，ZAB 仍是最优化的选择；否则，对于新设计或通用共识需求，Raft 是当前更实用的标准。 + +## 总结 + +ZAB 协议通过精心设计的 Leader 选举和多数派确认机制，在分布式系统的分区容错性（P）和一致性（C）之间做出了选择（满足 CP 属性）。当出现网络分区时，ZAB 宁愿牺牲短暂的可用性（A）进行选举，也要保证数据的一致性。 + +需要特别强调的是，**ZAB 协议默认不保证严格的强一致性（线性一致性），而是提供顺序一致性（Sequential Consistency）**。 + +由于 Follower 可以直接处理客户端的读请求且不强求数据绝对同步，客户端完全可能读取到落后于 Leader 的陈旧数据（Stale Read）。在生产环境中，若业务涉及如分布式锁等对数据新鲜度要求极高的场景，必须在执行 `read()` 操作前显式调用 `sync()` 原语，强制要求连接的 Follower 追平 Leader 的事务状态机。 + +当发生网络分区时，客户端若连接至被隔离的少数派 Follower，虽然写操作会失败，但仍可读出过期数据，这是使用 ZAB 协议时必须考虑的边界场景。 diff --git a/docs/distributed-system/rpc/dubbo.md b/docs/distributed-system/rpc/dubbo.md index 02cc37a8c0c..b0a5cd9bced 100644 --- a/docs/distributed-system/rpc/dubbo.md +++ b/docs/distributed-system/rpc/dubbo.md @@ -1,9 +1,14 @@ --- -title: Dubbo常见问题总结 -description: Dubbo核心知识与面试题详解，涵盖Dubbo架构原理、SPI机制、负载均衡策略及服务治理等核心内容。 +title: Dubbo面试题总结 category: 分布式 +description: Dubbo核心知识与面试题详解，涵盖Dubbo架构原理、SPI扩展机制、负载均衡策略（随机/轮询/一致性哈希）、服务注册发现、集群容错、服务治理等核心内容。 tag: - - rpc + - RPC + - Dubbo +head: + - - meta + - name: keywords + content: Dubbo,Dubbo面试题,Dubbo原理,SPI机制,负载均衡,服务注册,集群容错,服务治理,RPC框架 --- ::: tip diff --git a/docs/distributed-system/rpc/http&rpc.md b/docs/distributed-system/rpc/http&rpc.md index e3ac8ad5b7f..c4d26f1ae25 100644 --- a/docs/distributed-system/rpc/http&rpc.md +++ b/docs/distributed-system/rpc/http&rpc.md @@ -1,9 +1,13 @@ --- -title: 有了 HTTP 协议，为什么还要有 RPC ？ -description: HTTP与RPC对比详解，讲解两种通信方式的本质区别、性能差异及在微服务架构中的选型建议。 +title: HTTP与RPC对比 category: 分布式 +description: HTTP与RPC对比详解，从TCP层出发讲解两种通信方式的本质区别、性能差异（序列化/连接复用）、传输协议对比及在微服务架构中的选型建议。 tag: - - rpc + - RPC +head: + - - meta + - name: keywords + content: HTTP,RPC,HTTP vs RPC,微服务通信,RPC协议,TCP通信,序列化,RESTful,服务调用 --- > 本文来自[小白 debug](https://juejin.cn/user/4001878057422087)投稿，原文： 。 diff --git a/docs/distributed-system/rpc/rpc-intro.md b/docs/distributed-system/rpc/rpc-intro.md index 1c2de76ef6a..bca27412df4 100644 --- a/docs/distributed-system/rpc/rpc-intro.md +++ b/docs/distributed-system/rpc/rpc-intro.md @@ -1,9 +1,13 @@ --- title: RPC基础知识总结 -description: RPC远程过程调用基础详解，讲解RPC核心原理、调用流程、序列化协议及常见RPC框架对比分析。 category: 分布式 +description: RPC远程过程调用基础详解，讲解RPC核心原理、调用流程（客户端Stub/服务端Stub/网络传输）、序列化协议（Protobuf/Hessian/Kryo）及Dubbo/gRPC/Thrift等常见RPC框架对比分析。 tag: - - rpc + - RPC +head: + - - meta + - name: keywords + content: RPC,远程过程调用,RPC原理,RPC框架,Dubbo,gRPC,序列化,Stub,动态代理,RPC面试题 --- 这篇文章会简单介绍一下 RPC 相关的基础概念。 diff --git a/docs/distributed-system/spring-cloud-gateway-questions.md b/docs/distributed-system/spring-cloud-gateway-questions.md index 75c4ba50812..00105e41239 100644 --- a/docs/distributed-system/spring-cloud-gateway-questions.md +++ b/docs/distributed-system/spring-cloud-gateway-questions.md @@ -1,7 +1,14 @@ --- -title: Spring Cloud Gateway常见问题总结 -description: Spring Cloud Gateway核心原理详解，包括路由配置、过滤器机制、限流熔断等常见面试题与实践要点。 +title: Spring Cloud Gateway面试题总结 category: 分布式 +description: Spring Cloud Gateway核心原理详解，包括路由配置、Predicate断言、Filter过滤器机制、限流熔断、工作流程等常见面试题与实践要点。 +tag: + - API网关 + - Spring Cloud +head: + - - meta + - name: keywords + content: Spring Cloud Gateway,网关,Gateway,路由配置,Filter,限流熔断,Predicate,网关面试题 --- > 本文重构完善自[6000 字 | 16 图 | 深入理解 Spring Cloud Gateway 的原理 - 悟空聊架构](https://mp.weixin.qq.com/s/XjFYsP1IUqNzWqXZdJn-Aw)这篇文章。 diff --git a/docs/high-performance/cdn.md b/docs/high-performance/cdn.md index d16d2f0e46b..1b992be715e 100644 --- a/docs/high-performance/cdn.md +++ b/docs/high-performance/cdn.md @@ -8,6 +8,8 @@ head: content: CDN,内容分发网络,GSLB,CDN缓存,CDN回源,CDN预热,防盗链,时间戳防盗链,静态资源加速 --- + + ## 什么是 CDN ？ **CDN** 全称是 Content Delivery Network/Content Distribution Network，翻译过的意思是 **内容分发网络** 。 @@ -33,7 +35,7 @@ head: 绝大部分公司都会在项目开发中使用 CDN 服务，但很少会有自建 CDN 服务的公司。基于成本、稳定性和易用性考虑，建议直接选择专业的云厂商（比如阿里云、腾讯云、华为云、青云）或者 CDN 厂商（比如网宿、蓝汛）提供的开箱即用的 CDN 服务。 -### 为什么不直接将服务部署在多个不同的地方？ +## 为什么不直接将服务部署在多个不同的地方？ 很多朋友可能要问了：**既然是就近访问，为什么不直接将服务部署在多个不同的地方呢？** @@ -68,7 +70,7 @@ CDN 缓存的完整生命周期如下图所示： ![CDN 缓存的完整生命周期](https://oss.javaguide.cn/github/javaguide/high-performance/cdn/cdn-full-life-cycle-of-cdn-cache.png) -如果资源有更新，可以对其进行**刷新（Purge）**操作，删除 CDN 节点上缓存的旧资源，并强制 CDN 节点在下次请求时回源获取最新资源。 +如果资源有更新，可以对其进行**刷新**操作，删除 CDN 节点上缓存的旧资源，并强制 CDN 节点在下次请求时回源获取最新资源。 几乎所有云厂商提供的 CDN 服务都具备缓存的刷新和预热功能（下图是阿里云 CDN 服务提供的相应功能）： @@ -170,6 +172,54 @@ http://cdn.example.com/video/123.mp4?wsSecret=79aead3bd7b5db4adeffb93a010298b5&w > **推荐实践**：生产环境建议采用 **Referer 防盗链 + 时间戳防盗链**的组合方案，兼顾安全性与实现成本。对于安全性要求极高的场景（如付费内容），可进一步引入 Token 鉴权机制。 +## CDN 如何加速动态资源？ + +传统的 CDN 主要针对静态资源（如图片、CSS、JS）进行缓存加速，而对于**动态资源**（如 API 接口、实时查询、支付请求、`.jsp`/`.asp`/`.php` 等动态页面），内容实时变化无法缓存，传统 CDN 往往直接回源，加速效果有限。 + +**动态加速（Dynamic Content Acceleration）** 正是为了解决这一问题而设计。它不缓存内容，而是通过智能路由、协议优化等技术，提升动态请求的传输速度和稳定性。 + +动态加速主要通过以下三种技术手段实现： + +1. **智能路由选路（最优链路探测）**：动态请求从用户端发出后，先到达离用户最近的 CDN 边缘节点。CDN 内部通过**实时网络监测技术**，探测全网链路质量（包括延迟、丢包率、带宽负载），避开公网中的拥堵或质量较差的节点，选择一条最优的传输路径到达源站。 + +2. **传输协议优化**： + + - **TCP 优化**：优化 TCP 慢启动、拥塞控制算法，在高延迟或丢包环境下提升传输效率。 + - **连接复用**：边缘节点与源站之间保持长连接（Keep-Alive），减少频繁握手带来的延迟。 + +3. **动静态混合加速**：现代 CDN（如阿里云 DCDN、腾讯云 ECDN）能够自动识别用户请求的资源类型： + - **静态资源**：直接从边缘节点缓存返回。 + - **动态资源**：通过智能路由回源获取。 + +> **一句话总结**：动态加速 = 智能探测 + 动态选路 + 协议优化，让动态请求跑得又快又稳。 + +## CDN 如何优化 HTTPS 访问速度？ + +HTTPS 虽然安全，但 TLS 握手和加解密过程会增加延迟。CDN 通过多种技术手段对 HTTPS 进行加速优化，在保障安全的同时提升访问速度。 + +| 优化技术 | 原理说明 | 效果 | +| ----------------- | -------------------------------------------------------------------------------------- | ------------------------------ | +| **会话复用** | 用户首次建立 HTTPS 连接后，节点缓存会话信息；再次访问时复用会话参数，减少完整 TLS 握手 | 减少握手延迟 | +| **OCSP Stapling** | 由 CDN 节点定期缓存证书状态，在 TLS 握手时一并发给浏览器，避免浏览器单独查询 CA 机构 | 提升握手效率 | +| **False Start** | 在 TLS 握手尚未完全完成时就开始传输加密数据 | 减少一个 RTT 开销 | +| **HTTP/2** | 支持多路复用、头部压缩 | 减少连接数和传输延迟 | +| **QUIC** | 基于 UDP 的传输协议，0-RTT 建立连接 | 减少连接建立时间，改善弱网体验 | + +**CDN 证书托管的优势**： + +CDN 服务商（如腾讯云、阿里云）通常提供**免费 SSL 证书**和**自动续期**服务，具有以下优势： + +- **免运维**：用户无需手动更新证书，避免因证书过期导致的访问失败。 +- **灵活配置**：支持在 CDN 控制台上传证书，或一键申请免费证书。 +- **多种加密模式**：可选择”**半程加密**”（用户到 CDN 为 HTTPS，CDN 到源站为 HTTP）或”**全程加密**”（两端均为 HTTPS）。 + +**HTTPS 加速的配置建议**： + +1. **基础配置**：在 CDN 控制台开启 HTTPS，并配置证书。 +2. **性能优化**：开启 **OCSP Stapling** 和 **HTTP/2**。 +3. **安全增强**：如需更高安全等级，可开启 **HSTS**（强制浏览器使用 HTTPS 访问）。 +4. **弱网优化**：开启 **QUIC** 协议支持，改善移动端弱网环境下的访问体验。 + ## 总结 - **CDN 的核心价值**：将静态资源分发到多个不同的地方以实现**就近访问**，加快静态资源的访问速度，减轻源站服务器及带宽的负担。 @@ -177,6 +227,8 @@ http://cdn.example.com/video/123.mp4?wsSecret=79aead3bd7b5db4adeffb93a010298b5&w - **GSLB 的作用**：GSLB（全局负载均衡）是 CDN 的大脑，负责根据用户位置、节点状态等因素，将用户请求调度到**最优的 CDN 节点**。 - **核心指标**：**命中率**越高越好，**回源率**越低越好。 - **防盗链机制**：推荐采用 **Referer 防盗链 + 时间戳防盗链**的组合方案，平衡安全性与实现成本。 +- **动态加速**：通过**智能路由选路**、**传输协议优化**、**动静态混合加速**三种技术手段，提升动态请求（API 接口、实时查询等）的传输速度和稳定性。 +- **HTTPS 加速**：通过**会话复用**、**OCSP Stapling**、**False Start**、**HTTP/2**、**QUIC** 等技术优化 TLS 握手和传输过程，在保障安全的同时提升访问速度。 ## 参考 diff --git a/docs/high-performance/data-cold-hot-separation.md b/docs/high-performance/data-cold-hot-separation.md index 7fa47c7501f..3cb7dedef1a 100644 --- a/docs/high-performance/data-cold-hot-separation.md +++ b/docs/high-performance/data-cold-hot-separation.md @@ -1,13 +1,15 @@ --- title: 数据冷热分离详解 -description: 本文详解数据冷热分离的核心原理与实践方案，涵盖冷热数据的判定策略（时间维度/访问频率）、三种主流迁移方案对比（任务调度/Binlog监听）、冷数据存储选型（HBase/TiDB/对象存储），以及 TiDB Placement Rules 实现自动化冷热分离。 +description: 本文详解数据冷热分离的核心原理与实践方案，涵盖冷热数据判定策略、多级分层设计、数据迁移一致性保障、冷数据查询优化、存储选型（HBase/TiDB/对象存储），以及订单/日志/内容系统的典型落地案例。 category: 高性能 head: - - meta - name: keywords - content: 数据冷热分离,冷数据迁移,冷数据存储,分层存储,TiDB冷热分离,HBase,数据归档,存储成本优化 + content: 数据冷热分离,冷数据迁移,冷数据存储,分层存储,TiDB冷热分离,HBase,数据归档,存储成本优化,数据一致性 --- + + ## 什么是数据冷热分离？ 数据冷热分离是指根据数据的**访问频率**和**业务重要性**，将数据划分为冷数据和热数据，并分别存储在不同性能和成本的存储介质中的架构策略。 @@ -24,7 +26,7 @@ head: 冷热数据的区分方法主要有两种： -1. **时间维度区分**：按照数据的创建时间、更新时间或过期时间划分。例如，订单系统将 **1 年前**的订单数据标记为冷数据，1 年内的订单数据作为热数据。该方法适用于**数据访问频率与时间强相关**的场景，实现简单、成本低。 +1. **时间维度区分**：按照数据的创建时间、更新时间或过期时间划分。例如，订单系统将一段时间前（如 90 天或 1 年）的订单数据标记为冷数据。该方法适用于**数据访问频率与时间强相关**的场景，实现简单、成本低。 2. **访问频率区分**：将高频访问的数据视为热数据，低频访问的数据视为冷数据。例如，内容系统将**浏览量低于阈值**的文章标记为冷数据。该方法需要额外记录访问频率，适用于**访问频率与数据本身特性强相关**的场景。 **如何选择区分策略？** @@ -33,6 +35,33 @@ head: - 若数据价值与时间无关（如文章、商品、用户画像），需结合**访问频率**进行判定。 - 实际项目中，可将两者结合使用：以时间维度为主、访问频率为辅，覆盖更多业务场景。 +### 冷热分离的多级分层策略 + +实际落地时，"冷"与"热"往往不是非此即彼的二分法，而是**渐进式多级分层**： + +| 层级 | 数据特性 | 判定规则示例 | 存储策略 | +| ------------ | -------------------- | --------------------------- | ---------------------- | +| **热数据** | 高频访问、实时响应 | 最近 30 天 + 所有未完成订单 | MySQL 热库（SSD） | +| **温数据** | 中频访问、可能被查询 | 30~90 天前的订单 | MySQL 温库（HDD） | +| **冷数据** | 低频访问、偶发查询 | 90 天~3 年的历史订单 | 独立冷库或对象存储 | +| **归档数据** | 极少访问、仅合规留存 | 超过 3 年的订单 | 对象存储（仅保留汇总） | + +**实践建议**：判定规则应通过**配置中心**动态管理，避免因业务变化导致频繁修改代码。 + +### 冷数据被访问后如何处理？ + +如果冷数据突然被访问（如用户查询 3 年前的订单），是否需要"热升级"？ + +| 策略 | 适用场景 | 优点 | 缺点 | +| ------------ | ---------------------- | -------------------- | ---------------------------- | +| **不回迁** | 偶发查询、查询频率极低 | 实现简单 | 查询速度慢 | +| **缓存层** | 中等频率查询 | 加速查询、不改变存储 | 需要额外缓存组件 | +| **异步回迁** | 高频查询、需要持续访问 | 彻底解决性能问题 | 实现复杂、可能产生一致性问题 | + +**推荐做法**：绝大多数场景采用"**不回迁 + 缓存层**"的组合方案。冷数据查询时，先查缓存，命中则直接返回；未命中则查冷库并将结果写入缓存（针对偶发查询，设置 5~15 分钟的短暂 TTL 即可）。 + +**⚠️注意**：为防止恶意攻击者利用随机参数频繁查询不存在的数据导致冷库被击穿，可以在缓存层前置**布隆过滤器（Bloom Filter）**或在缓存中设置**空值占位符**，避免恶意请求穿透到冷库。详细介绍参考 [Redis 常见面试题总结(下)](https://javaguide.cn/database/redis/redis-questions-02.html)（Redis 事务、性能优化、生产问题、集群、使用规范等）。 + ### 冷热分离的思想 冷热分离的核心思想是**分层存储（Tiered Storage）**，根据数据的访问特性将其分配到不同层级的存储介质中。在企业级存储架构中，通常划分为以下层级： @@ -60,23 +89,89 @@ head: - **跨库查询效率低**：若业务需要同时查询冷热数据（如年度统计报表），需进行跨库关联或数据聚合，查询性能和开发成本均会上升。 - **迁移策略维护成本**：冷热数据的判定规则需要持续调优，避免误判导致热数据被错误迁移。 -## 冷数据如何迁移？ +## 冷数据迁移 + +### 冷数据如何迁移？ 冷数据迁移是冷热分离的核心环节，主流方案有以下三种： | 方案 | 实现原理 | 优点 | 缺点 | 适用场景 | | ------------------- | ---------------------------------------- | ---------------------- | -------------------------------------------- | ---------------------------- | | **业务层代码实现** | 写操作时判断冷热，直接路由到对应库 | 实时性高 | 侵入业务代码、判定逻辑复杂 | 几乎不使用 | -| **任务调度迁移** | 定时任务扫描热库，批量迁移符合条件的数据 | 实现简单、对业务无侵入 | 存在迁移延迟、扫描大表有性能压力 | **时间维度区分场景（推荐）** | -| **Binlog 监听迁移** | 监听数据库变更日志，实时或准实时迁移 | 实时性好、对业务无侵入 | 需要额外组件（如 Canal）、不适合时间维度判定 | 访问频率区分场景 | +| **任务调度迁移** | 定时任务扫描热库，批量迁移符合条件的数据 | 实现简单 | 存在迁移延迟、扫表可能污染 Buffer Pool | 时间维度区分场景 | +| **Binlog 监听迁移** | 监听数据库变更日志，实时或准实时迁移 | 实时性好、对业务无侵入 | 需要额外组件（如 Canal）、不适合时间维度判定 | **访问频率区分场景（推荐）** | **任务调度迁移**是最常用的方案，可借助 XXL-Job、Elastic-Job 等分布式任务调度平台实现。关于任务调度的方案，我也写过文章详细介绍，可以查看这篇文章：[Java 定时任务详解](https://javaguide.cn/system-design/schedule-task.html) 。 +> ⚠️ **风险提示**：任务调度迁移在大数据量下存在性能隐患。大范围的扫表操作（如 `SELECT * FROM orders WHERE create_time < 'xxx' LIMIT 10000`）会严重污染 InnoDB Buffer Pool，将真正的业务热数据挤出内存。**生产环境建议**： +> +> - 使用**基于主键的范围查询**，避免全表扫描； +> - 控制**单次迁移批量大小**，分批执行； +> - 在**业务低峰期**执行迁移任务； +> - 对于海量数据，优先考虑 **Binlog 监听**方案，将对热库的冲击降到最低。 + 典型流程如下： ![冷热分离 - 冷数据迁移](https://oss.javaguide.cn/github/javaguide/high-performance/data-cold-hot-separation.png) -> **实践建议**：若公司有 DBA 支持，可先进行一次**存量冷数据的人工迁移**，将历史数据批量导入冷库；后续再通过任务调度实现**增量迁移**的自动化。 +**实践建议**：若公司有 DBA 支持，可先进行一次**存量冷数据的人工迁移**，将历史数据批量导入冷库；后续再通过任务调度实现**增量迁移**的自动化。 + +### 迁移过程中如何保证数据一致性？ + +数据迁移过程中，最棘手的问题是：**如果数据在迁移过程中被更新，如何处理？** + +#### 常见解决方案 + +| 方案 | 实现方式 | 优点 | 缺点 | +| ------------------- | -------------------------------------- | ---------------- | ------------------------------------ | +| **迁移前锁定** | 迁移前对记录加写锁，迁移完成后释放 | 一致性强 | 影响业务写入、吞吐量下降 | +| **版本号乐观锁** | 迁移时记录版本，删除前校验版本是否变化 | 无锁、性能好 | 需要业务表增加版本字段、冲突时需重试 | +| **状态标记 + 幂等** | 热库增加迁移状态字段，先标记再迁移 | 可追溯、支持回滚 | 需要改造业务表 | + +> **注意**：冷热库通常是**不同的数据库实例**，`INSERT`（冷库）和 `DELETE`（热库）无法放在同一个本地事务中，需要特殊处理跨库原子性问题。 + +#### 推荐方案：状态标记 + 幂等迁移 + +在热库表中增加 `migrate_status` 字段，通过状态机保证迁移的原子性和可追溯性： + +```sql +-- 1. 热库表增加迁移状态字段 +ALTER TABLE orders ADD COLUMN migrate_status TINYINT DEFAULT 0 + COMMENT '0-未迁移 1-迁移中 2-已迁移'; +``` + +```java +// 2. 迁移流程（伪代码，独立冷库场景需在应用层分步执行） + +// Step 1: 标记为迁移中（热库事务） +hotDb.execute("UPDATE orders SET migrate_status = 1 WHERE id = ? AND migrate_status = 0", id); + +// Step 2: 读取热库数据并写入冷库（需切换数据库连接） +Order order = hotDb.query("SELECT * FROM orders WHERE id = ?", id); +coldDb.execute("INSERT IGNORE INTO orders_cold VALUES (?, ?, ...)", order.id, order.data...); + +// Step 3: 标记为已迁移（热库事务） +hotDb.execute("UPDATE orders SET migrate_status = 2 WHERE id = ? AND migrate_status = 1", id); + +// Step 4: 延迟删除热库数据（可选，确认冷库数据无误后执行） +hotDb.execute("DELETE FROM orders WHERE id = ? AND migrate_status = 2", id); +``` + +> **注意**：独立冷库场景下，标准 MySQL 无法直接执行跨库 `INSERT ... SELECT`，必须在应用层拆分为"读取热库 → 写入冷库"两步。 + +**方案优势**： + +- **幂等性**：`INSERT IGNORE` 保证冷库写入幂等，`migrate_status` 状态流转保证热库更新幂等。 +- **可追溯**：通过状态字段可以查询迁移进度，异常时可以人工介入。 +- **可回滚**：迁移失败时可以将状态重置为 0，重新迁移。 +- **渐进式删除**：不立即删除热库数据，确认冷库无误后再清理，降低风险。 + +> **空间回收**：InnoDB 执行 `DELETE` 后仅将数据页标记为删除，物理空间不会立即释放给操作系统。需在**业务低峰期**执行 `OPTIMIZE TABLE` 或 `ALTER TABLE ENGINE=InnoDB` 重建表，才能真正回收磁盘空间。 + +**兜底机制**： + +- **定时对账**：定期扫描 `migrate_status = 1` 超过阈值的记录，自动重置或告警。**注意**：`migrate_status` 字段区分度极低，必须配合联合索引（如 `idx_create_time_migrate_status`）限定扫描区间，避免全表扫描。 +- **高频更新兜底**：对于因频繁更新导致多次跳过的记录，设置最大重试次数，超过后强制迁移或人工介入。 ## 冷数据如何存储？ @@ -89,7 +184,7 @@ head: - **同库分表**：在同一数据库中新增冷数据表（如 `order_history`），通过表名区分冷热数据。 - **独立冷库**：部署单独的数据库实例作为冷库，热库与冷库通过应用层路由访问。 -> **注意**：独立冷库方案涉及**跨库查询**，若业务存在冷热数据联合查询需求，需评估是否引入数据同步或聚合层。 +**⚠️注意**：独立冷库方案涉及**跨库查询**，若业务存在冷热数据联合查询需求，需评估是否引入数据同步或聚合层。 ### 大厂方案 @@ -97,7 +192,7 @@ head: | 存储方案 | 特点 | 适用场景 | | ---------------------- | -------------------------------- | -------------------------------- | -| **HBase** | 列式存储、高吞吐、支持 PB 级数据 | 日志、用户行为、IoT 数据归档 | +| **HBase** | 列族存储、高吞吐、支持 PB 级数据 | 日志、用户行为、IoT 数据归档 | | **RocksDB** | 高性能 KV 存储、LSM-Tree 结构 | 嵌入式场景、作为其他系统底层存储 | | **Doris/ClickHouse** | OLAP 引擎、支持实时分析 | 冷数据需要进行聚合分析的场景 | | **Cassandra** | 分布式、高可用、无单点故障 | 跨地域部署、高可用要求的归档场景 | @@ -128,6 +223,100 @@ ALTER TABLE orders PARTITION p2022 PLACEMENT POLICY = cold_data; 这种方案的优势在于：**业务无需感知冷热分离逻辑**，数据路由由 TiDB 自动完成，大幅降低了应用层的复杂度。 +> **完整实践**：`Placement Rules` 指定了数据存放的介质类型，但数据如何从"热分区"流转到"冷分区"仍需结合**分区表（Range Partitioning）**。按时间跨度创建分区，为历史分区绑定 HDD 放置策略，为当前活跃分区绑定 SSD 放置策略。随着时间推移，只需维护分区的创建与销毁，底层数据即可在不同介质间自然流转。 + +## 冷数据如何查询？ + +冷数据虽然访问频率低，但一旦需要查询（如审计、对账、年度报表），如何保证查询效率？ + +### 冷数据查询需求分析 + +首先需要明确：**业务是否真的需要查询冷数据？** + +- **不需要**：可将冷数据完全移出业务库，仅保留归档（如对象存储），需要时人工提取。 +- **需要**：需设计合理的查询方案，平衡性能与成本。 + +### 冷数据查询优化方案 + +| 优化手段 | 实现方式 | 适用场景 | +| -------------------- | --------------------------------------------------- | -------------- | +| **冷库独立只读实例** | 冷库部署只读副本，避免冷查询影响热库 | 高频冷查询场景 | +| **查询路由** | 应用层根据时间范围自动路由到热库或冷库 | 跨冷热查询场景 | +| **预聚合** | 定期对冷数据生成月度/季度报表，查询时直接查聚合结果 | 统计分析场景 | +| **列式存储** | 冷库采用 ClickHouse、Doris 等 OLAP 引擎 | 大规模分析查询 | + +**跨冷热查询的处理**： + +若查询范围同时涉及冷热数据（如"查询近 2 年的订单"），有两种处理方式： + +1. **拆分查询**：分别查询热库和冷库，应用层合并结果。 +2. **限制范围**：提示用户缩小查询范围，避免跨库查询。 + +> **防雪崩预警**：若业务包含**全局分页排序**（如 `ORDER BY create_time LIMIT 10000, 20`），应用层必须从冷热库各拉取 `10000 + 20` 条记录进行内存归并，偏移量较大时极易引发 **OOM**。**强制要求**： +> +> - 限制查询时间范围，避免大跨度跨库查询； +> - 或引流至底层同步的宽表（如 ClickHouse）进行计算； +> - 严禁在应用层执行大深度的归并分页。 + +### 应用层如何路由冷热数据？ + +| 方案 | 实现方式 | 优点 | 缺点 | +| ------------ | ---------------------------------------- | ------------------ | ---------------------------- | +| **硬编码** | 代码中直接判断路由 | 实现简单 | 维护成本高、规则变更需改代码 | +| **配置中心** | 路由规则存入配置中心（如 Nacos、Apollo） | 动态调整、无需重启 | 需要额外组件支持 | +| **Proxy 层** | 引入 ShardingSphere、ProxySQL 等中间件 | 业务无感知 | 架构复杂度高 | + +**推荐做法**：中小规模采用**配置中心**方案，大规模采用**Proxy 层**方案。 + +> ⚠️ **风险提示**：引入 Proxy 层后，所有跨冷热库的聚合计算（如全局排序、`GROUP BY` 归并分页）都会压在 Proxy 节点的内存与 CPU 上。需严格限制此类操作的最大返回行数，否则极易导致 Proxy 节点 **OOM（内存溢出）**。 + +## 冷热分离 vs 数据归档 vs 分区表 + +这三个概念容易混淆，需要区分清楚： + +| 对比维度 | 冷热分离 | 数据归档 | 分区表 | +| ------------------ | -------------------------- | ---------------------- | -------------------------- | +| **数据是否可访问** | 冷数据仍在业务访问路径上 | 归档数据通常移出业务库 | 所有分区均可访问 | +| **存储介质** | 冷热数据可跨实例、跨存储 | 通常迁移到低成本存储 | 同一实例内 | +| **实现复杂度** | 中等 | 低 | 低 | +| **典型场景** | 订单、日志等有时效性的数据 | 合规留存、数据备份 | 单表数据量大但无需分离存储 | + +**分区表的局限性**：MySQL 分区表可以按时间分区，但所有分区仍在同一个实例中，**无法实现存储介质的分离**。如果目标是降低存储成本，分区表无法替代冷热分离。 + +## 典型业务场景 + +> **说明**：以下存储策略仅供参考，实际选型需结合数据量、查询需求、团队技术栈和成本预算综合考虑。 + +### 订单系统 + +| 阶段 | 数据范围 | 存储策略 | 说明 | +| -------- | ----------------------- | ------------------------------- | ---------------------------- | +| 热数据 | 最近 90 天 + 未完成订单 | MySQL 热库（SSD） | 高频访问，保障查询性能 | +| 冷数据 | 90 天~3 年 | MySQL 冷库（HDD）或 TiDB | 可能需要查询，保持关系型存储 | +| 归档数据 | 超过 3 年 | 对象存储 / HBase / 仅保留汇总表 | 极少查询，优先考虑成本 | + +### 日志系统 + +| 阶段 | 数据范围 | 存储策略 | 说明 | +| ------ | --------- | ------------------------------------------------------ | ----------------------------------------- | +| 热数据 | 近 7 天 | Elasticsearch 热节点 | 实时检索、高频查询 | +| 温数据 | 7~30 天 | Elasticsearch 温节点 | 偶发查询，降低存储成本 | +| 冷数据 | 30 天以上 | Elasticsearch 冷节点 / 压缩归档至对象存储 / ClickHouse | 根据查询需求选择，ClickHouse 适合分析场景 | + +### 内容系统 + +| 阶段 | 数据范围 | 存储策略 | 说明 | +| ------ | -------------------------- | ----------------------------- | ------------------------------ | +| 热数据 | 发布后 3 个月内 + 高阅读量 | MySQL 热库 | 频繁被访问 | +| 冷数据 | 3 个月后 + 低阅读量 | MySQL 冷库 / HBase / 对象存储 | 访问频率低，可迁移至低成本存储 | + +**选型建议**： + +- **需要支持事务或复杂查询**：优先选择 MySQL 冷库或 TiDB +- **需要大规模聚合分析**：优先选择 ClickHouse 或 Doris +- **仅需偶尔查询明细**：可选择对象存储（如 OSS/S3），查询时临时加载 +- **数据量极大且访问极低**：HBase 或对象存储是性价比最高的选择 + ## 案例分享 - [如何快速优化几千万数据量的订单表 - 程序员济癫 - 2023](https://www.cnblogs.com/fulongyuanjushi/p/17910420.html) diff --git a/docs/high-performance/deep-pagination-optimization.md b/docs/high-performance/deep-pagination-optimization.md index c43c057b527..4288e67bc88 100644 --- a/docs/high-performance/deep-pagination-optimization.md +++ b/docs/high-performance/deep-pagination-optimization.md @@ -8,7 +8,9 @@ head: content: 深度分页,分页优化,LIMIT优化,MySQL分页,延迟关联,覆盖索引,游标分页 --- -## 深度分页介绍 + + +## 什么是深度分页？怎么导致的？ 查询偏移量过大的场景我们称为深度分页，这会导致查询性能较低，例如： @@ -17,9 +19,9 @@ head: SELECT * FROM t_order ORDER BY id LIMIT 1000000, 10 ``` -## 深度分页问题的原因 +当查询偏移量过大时，MySQL 的查询优化器可能会选择全表扫描而不是利用索引来优化查询。 -当查询偏移量过大时，MySQL 的查询优化器可能会选择全表扫描而不是利用索引来优化查询。这是因为扫描索引和跳过大量记录可能比直接全表扫描更耗费资源。 +**深度分页变慢的根本原因**在于 MySQL 的执行机制：对于 `LIMIT offset, N`，MySQL 并非直接跳到 `offset` 处，而是必须从头扫描 `offset + N` 条记录。如果查询依赖二级索引且不满足覆盖索引，这意味着 MySQL 需要对前 `offset` 条记录执行毫无意义的**回表查询（产生海量的随机 I/O）**，最后再将这些辛苦查出的数据丢弃。即便优化器最终因代价过高退化为全表扫描，顺序扫描百万行的成本依然巨大。 ![深度分页问题](https://oss.javaguide.cn/github/javaguide/mysql/deep-pagination-phenomenon.png) @@ -31,24 +33,26 @@ MySQL 的查询优化器采用基于成本的策略来选择最优的查询执 ## 深度分页优化建议 -这里以 MySQL 数据库为例介绍一下如何优化深度分页。 +> **本文基于 MySQL 8.0 + InnoDB 存储引擎**，不同版本优化器行为可能存在差异。 -### 范围查询 +### 范围查询（游标分页） -当可以保证 ID 的连续性时，根据 ID 范围进行分页是比较好的解决方案： +通过记录上一页最后一条记录的 ID，使用 `WHERE id > last_id LIMIT n` 获取下一页数据： ```sql -# 查询指定 ID 范围的数据 -SELECT * FROM t_order WHERE id > 100000 AND id <= 100010 ORDER BY id -# 也可以通过记录上次查询结果的最后一条记录的ID进行下一页的查询： -SELECT * FROM t_order WHERE id > 100000 LIMIT 10 +# 通过记录上次查询结果的最后一条记录的 ID 进行下一页的查询 +SELECT * FROM t_order WHERE id > 100000 ORDER BY id LIMIT 10 ``` -这种基于 ID 范围的深度分页优化方式存在很大限制： +**游标分页的核心优势**：**不依赖 ID 的连续性**。MySQL 只需要在 B+ 树上定位到 `last_id` 的位置，然后顺序向后读取 `n` 条记录即可，中间是否有断层（如 ID 被删除）完全不影响结果的准确性和性能。 + +这种方式的限制： -1. **ID 连续性要求高**: 实际项目中，数据库自增 ID 往往因为各种原因（例如删除数据、事务回滚等）导致 ID 不连续，难以保证连续性。 -2. **排序问题**: 如果查询需要按照其他字段（例如创建时间、更新时间等）排序，而不是按照 ID 排序，那么这种方法就不再适用。 -3. **并发场景**: 在高并发场景下，单纯依赖记录上次查询的最后一条记录的 ID 进行分页，容易出现数据重复或遗漏的问题。 +1. **不支持跳页**：无法直接跳转到第 N 页，只能逐页向后（或向前）翻页。 +2. **排序字段受限**：如果查询需要按照其他字段（如创建时间）排序而非 ID 排序，需使用联合游标 `(sort_field, id)` 保证唯一性和顺序。 +3. **并发场景**：当分页查询期间有新数据插入或删除时，可能出现： + - **数据遗漏**：查询第二页时，有新数据插入到第一页范围内，导致该数据被"挤"到第二页，但第二页查询已基于旧的最后 ID 跳过它。 + - **数据重复**：查询第二页时，第一页末尾有数据被删除，原第二页的第一条数据"升"到第一页末尾，导致第二页查询再次返回它。 ### 子查询 @@ -62,15 +66,20 @@ SELECT * FROM t_order WHERE id > 100000 LIMIT 10 ```sql -- 先通过子查询在主键索引上进行偏移，快速找到起始ID -SELECT * FROM t_order WHERE id >= (SELECT id FROM t_order LIMIT 1000000, 1) LIMIT 10; +SELECT * FROM t_order +WHERE id >= ( + SELECT id FROM t_order ORDER BY id LIMIT 1000000, 1 +) ORDER BY id LIMIT 10; ``` **工作原理**: -1. 子查询 `(SELECT id FROM t_order where id > 1000000 limit 1)` 会利用主键索引快速定位到第 1000001 条记录，并返回其 ID 值。 -2. 主查询 `SELECT * FROM t_order WHERE id >= ... LIMIT 10` 将子查询返回的起始 ID 作为过滤条件，使用 `id >=` 获取从该 ID 开始的后续 10 条记录。 +1. 子查询 `(SELECT id FROM t_order ORDER BY id LIMIT 1000000, 1)` 利用主键索引扫描并跳过前 1000000 条记录，返回第 1000001 条记录的主键值。 +2. 主查询 `SELECT * FROM t_order WHERE id >= ... ORDER BY id LIMIT 10` 以该主键为起点，获取后续 10 条完整记录。 + +不过，某些情况下子查询可能会产生临时表，影响性能，因此在复杂查询中建议优先考虑延迟关联。 -不过，子查询的结果会产生一张新表，会影响性能，应该尽量避免大量使用子查询。并且，这种方法只适用于 ID 是正序的。在复杂分页场景，往往需要通过过滤条件，筛选到符合条件的 ID，此时的 ID 是离散且不连续的。 +> **复杂过滤场景**：在包含复杂过滤条件的分页场景中（如 `WHERE status = 1 ORDER BY id LIMIT 1000000, 10`），符合条件的 ID 往往是离散的。此时子查询的优势更加明显：通过在子查询中利用联合索引（如 `(status, id)`）实现覆盖索引扫描，可以高效地跳过前 100 万条符合条件的记录，定位到目标 ID 后，主查询只需回表 10 次。 当然，我们也可以利用子查询先去获取目标分页的 ID 集合，然后再根据 ID 集合获取内容，但这种写法非常繁琐，不如使用 INNER JOIN 延迟关联。 @@ -84,13 +93,14 @@ SELECT t1.* FROM t_order t1 INNER JOIN ( -- 这里的子查询可以利用覆盖索引，性能极高 - SELECT id FROM t_order LIMIT 1000000, 10 -) t2 ON t1.id = t2.id; + SELECT id FROM t_order ORDER BY id LIMIT 1000000, 10 +) t2 ON t1.id = t2.id +ORDER BY t1.id; ``` **工作原理**: -1. 子查询 `(SELECT id FROM t_order where id > 1000000 LIMIT 10)` 利用主键索引快速定位目标分页的 10 条记录的 ID。 +1. 子查询 `(SELECT id FROM t_order ORDER BY id LIMIT 1000000, 10)` 利用主键索引扫描并跳过前 1000000 条记录，返回目标分页的 10 条记录的 ID。 2. 通过 `INNER JOIN` 将子查询结果与主表 `t_order` 关联，获取完整的记录数据。 除了使用 INNER JOIN 之外，还可以使用逗号连接子查询。 @@ -98,8 +108,9 @@ INNER JOIN ( ```sql -- 使用逗号进行延迟关联 SELECT t1.* FROM t_order t1, -(SELECT id FROM t_order where id > 1000000 LIMIT 10) t2 -WHERE t1.id = t2.id; +(SELECT id FROM t_order ORDER BY id LIMIT 1000000, 10) t2 +WHERE t1.id = t2.id +ORDER BY t1.id; ``` **注意**: 虽然逗号连接子查询也能实现类似的效果，但为了代码可读性和可维护性，建议使用更规范的 `INNER JOIN` 语法。 @@ -110,11 +121,14 @@ WHERE t1.id = t2.id; **覆盖索引的好处：** -- **避免 InnoDB 表进行索引的二次查询，也就是回表操作:** InnoDB 是以聚集索引的顺序来存储的，对于 InnoDB 来说，二级索引在叶子节点中所保存的是行的主键信息，如果是用二级索引查询数据的话，在查找到相应的键值后，还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中，二级索引的键值中可以获取所有的数据，避免了对主键的二次查询（回表），减少了 IO 操作，提升了查询效率。 -- **可以把随机 IO 变成顺序 IO 加快查询效率:** 由于覆盖索引是按键值的顺序存储的，对于 IO 密集型的范围查找来说，对比随机从磁盘读取每一行的数据 IO 要少的多，因此利用覆盖索引在访问时也可以把磁盘的随机读取的 IO 转变成索引查找的顺序 IO。 +- **避免 InnoDB 表进行索引的二次查询，也就是回表操作**：InnoDB 是以聚集索引的顺序来存储的，对于 InnoDB 来说，二级索引在叶子节点中所保存的是行的主键信息，如果是用二级索引查询数据的话，在查找到相应的键值后，还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中，二级索引的键值中可以获取所有的数据，避免了对主键的二次查询（回表），减少了 IO 操作，提升了查询效率。 +- **减少回表带来的随机 IO**：通过覆盖索引直接返回数据，避免了根据二级索引的主键值回表查询聚簇索引的随机 IO 操作。回表时每次按主键值查找聚簇索引，本质上是随机 IO。 + +假设建立了 `(code, type)` 联合索引，下面的查询即可使用覆盖索引： ```sql -# 如果只需要查询 id, code, type 这三列，可建立 code 和 type 的覆盖索引 +# 在 InnoDB 中，辅助索引天然包含主键 id +# 如果只需要查询 id, code, type 这三列，只需建立 (code, type) 的联合索引即可实现覆盖 SELECT id, code, type FROM t_order ORDER BY code LIMIT 1000000, 10; @@ -125,18 +139,34 @@ LIMIT 1000000, 10; - 当查询的结果集占表的总行数的很大一部分时，MySQL 查询优化器可能选择放弃使用索引，自动转换为全表扫描。 - 虽然可以使用 `FORCE INDEX` 强制查询优化器走索引，但这种方式可能会导致查询优化器无法选择更优的执行计划，效果并不总是理想。 +## 生产落地建议 + +### 监控与告警 + +- **慢查询监控**：监控慢查询日志中 `LIMIT` 偏移量过大的 SQL，及时发现问题。 +- **阈值告警**：设置 `long_query_time` 阈值捕获深度分页查询。 +- **执行计划检查**：使用 `EXPLAIN` 定期检查关键分页 SQL 的执行计划，确保优化器按预期使用索引。 + +### 常见误区 + +| 误区 | 事实 | +| --------------------------------- | ---------------------------------------------------- | +| 认为 `FORCE INDEX` 能解决所有问题 | 强制索引可能阻止优化器选择更优计划，应谨慎使用 | +| 认为覆盖索引适用于所有场景 | 字段过多时索引维护成本高，且大结果集仍可能走全表扫描 | +| 认为游标分页能解决所有问题 | 游标分页不支持跳页，且只能按特定字段顺序翻页 | + ## 总结 深度分页问题的根本原因在于：当 `LIMIT` 的偏移量过大时，MySQL 需要扫描并跳过大量记录才能获取目标数据，查询优化器可能放弃索引而选择全表扫描。此时即使有索引，也无法避免大量的回表操作，导致查询性能急剧下降。 本文介绍了四种常见的深度分页优化方案，各方案的特点及适用场景对比如下： -| 优化方案 | 核心思路 | 适用场景 | 限制 | -| ------------ | ------------------------------------------------------------------- | ----------------------------------- | ------------------------------------------------ | -| **范围查询** | 记录上一页最后一条 ID，通过 `WHERE id > last_id LIMIT n` 获取下一页 | ID 连续、按 ID 排序、允许游标式翻页 | 不支持跳页、ID 不连续时失效、非 ID 排序不适用 | -| **子查询** | 先通过子查询获取起始主键，再根据主键过滤 | 需要支持传统 OFFSET 翻页 | 子查询可能产生临时表、仅适用于 ID 正序 | -| **延迟关联** | 用 `INNER JOIN` 将分页转移到主键索引，减少回表 | 大数据量分页、需要传统翻页逻辑 | SQL 相对复杂 | -| **覆盖索引** | 建立包含查询字段的联合索引，避免回表 | 查询字段固定、可建立合适索引 | 字段较多时索引维护成本高、大结果集可能走全表扫描 | +| 优化方案 | 核心思路 | 适用场景 | 限制 | +| ------------ | ------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------ | +| **范围查询** | 记录上一页最后一条 ID，通过 `WHERE id > last_id LIMIT n` 获取下一页 | 按 ID 排序、允许游标式翻页 | 不支持跳页、非 ID 排序需使用联合游标 | +| **子查询** | 先通过子查询获取起始主键，再根据主键过滤 | 需要支持传统 OFFSET 翻页 | 子查询可能产生临时表、依赖排序字段的索引 | +| **延迟关联** | 用 `INNER JOIN` 将分页转移到主键索引，减少回表 | 大数据量分页、需要传统翻页逻辑 | SQL 相对复杂 | +| **覆盖索引** | 建立包含查询字段的联合索引，避免回表 | 查询字段固定、可建立合适索引 | 字段较多时索引维护成本高、大结果集可能走全表扫描 | **方案选择建议**： diff --git a/docs/high-performance/load-balancing.md b/docs/high-performance/load-balancing.md index a7724eff5e5..a4d2082b2e8 100644 --- a/docs/high-performance/load-balancing.md +++ b/docs/high-performance/load-balancing.md @@ -8,6 +8,8 @@ head: content: 负载均衡,四层负载均衡,七层负载均衡,Nginx负载均衡,LVS,负载均衡算法,轮询,一致性哈希,客户端负载均衡 --- + + ## 什么是负载均衡？ **负载均衡** 指的是将用户请求分摊到不同的服务器上处理，以提高系统整体的并发处理能力以及可靠性。负载均衡服务可以有由专门的软件或者硬件来完成，一般情况下，硬件的性能更好，软件的价格更便宜（后文会详细介绍到）。 diff --git a/docs/high-performance/message-queue/rabbitmq-questions.md b/docs/high-performance/message-queue/rabbitmq-questions.md index 17d213f0121..343e69e17b4 100644 --- a/docs/high-performance/message-queue/rabbitmq-questions.md +++ b/docs/high-performance/message-queue/rabbitmq-questions.md @@ -10,26 +10,26 @@ head: content: RabbitMQ,AMQP协议,Exchange交换机,消息确认,死信队列,延迟队列,优先级队列,RabbitMQ集群,消息队列面试 --- -> 本篇文章由 JavaGuide 收集自网络，原出处不明。 +RabbitMQ 作为老牌消息中间件，凭借其成熟的路由机制、丰富的协议支持和完善的可靠性保障，在企业级应用中占据重要地位。但自 RabbitMQ 3.8 引入 Quorum Queue、3.9 引入 Streams、4.0 移除镜像队列以来，其技术架构发生了重大变化，许多传统的最佳实践已不再适用。 + +本文已针对 RabbitMQ 4.0 进行全面更新，明确标注各特性的版本依赖，特别强调了镜像队列（已移除）、Quorum Queue（推荐）和 Streams（3.9+）的选型差异。 ## RabbitMQ 是什么？ RabbitMQ 是一个在 AMQP（Advanced Message Queuing Protocol ）基础上实现的，可复用的企业消息系统。它可以用于大型软件系统各个模块之间的高效通信，支持高并发，支持可扩展。它支持多种客户端如：Python、Ruby、.NET、Java、JMS、C、PHP、ActionScript、XMPP、STOMP 等，支持 AJAX，持久化，用于在分布式系统中存储转发消息，在易用性、扩展性、高可用性等方面表现不俗。 -RabbitMQ 是使用 Erlang 编写的一个开源的消息队列，本身支持很多的协议：AMQP，XMPP, SMTP, STOMP，也正是如此，使的它变的非常重量级，更适合于企业级的开发。它同时实现了一个 Broker 构架，这意味着消息在发送给客户端时先在中心队列排队，对路由(Routing)、负载均衡(Load balance)或者数据持久化都有很好的支持。 - -PS:也可能直接问什么是消息队列？消息队列就是一个使用队列来通信的组件。 +RabbitMQ 是使用 Erlang 编写的一个开源的消息队列，本身支持很多的协议：AMQP、XMPP、SMTP、STOMP，也正是如此，**使得它变得**非常重量级，更适合于企业级的开发。它同时实现了一个 Broker 构架，这意味着消息在发送给客户端时先在中心队列排队，对路由（Routing）、负载均衡（Load Balance）或者数据持久化都有很好的支持。 -## RabbitMQ 特点? +## RabbitMQ 特点 -- **可靠性**: RabbitMQ 使用一些机制来保证可靠性， 如持久化、传输确认及发布确认等。 -- **灵活的路由** : 在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能， RabbitMQ 己经提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个交换器绑定在一起， 也可以通过插件机制来实现自己的交换器。 -- **扩展性**: 多个 RabbitMQ 节点可以组成一个集群，也可以根据实际业务情况动态地扩展 集群中节点。 -- **高可用性** : 队列可以在集群中的机器上设置镜像，使得在部分节点出现问题的情况下队 列仍然可用。 -- **多种协议**: RabbitMQ 除了原生支持 AMQP 协议，还支持 STOMP， MQTT 等多种消息 中间件协议。 -- **多语言客户端** :RabbitMQ 几乎支持所有常用语言，比如 Java、 Python、 Ruby、 PHP、 C#、 JavaScript 等。 -- **管理界面** : RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息、集 群中的节点等。 -- **插件机制** : RabbitMQ 提供了许多插件 ， 以实现从多方面进行扩展，当然也可以编写自 己的插件。 +- **可靠性**：RabbitMQ 使用一些机制来保证可靠性，如持久化、传输确认及发布确认等。 +- **灵活的路由**：在消息进入队列之前，通过交换器来路由消息。对于典型的路由功能，RabbitMQ **已经**提供了一些内置的交换器来实现。针对更复杂的路由功能，可以将多个交换器绑定在一起，也可以通过插件机制来实现自己的交换器。 +- **扩展性**：多个 RabbitMQ 节点可以组成一个集群，也可以根据实际业务情况动态地扩展集群中的节点。 +- **高可用性**：Quorum Queue 基于 Raft 协议实现数据复制，Streams 支持多节点副本，在部分节点出现问题的情况下队列仍然可用。 +- **多种协议**：RabbitMQ 除了原生支持 AMQP 协议，还支持 STOMP、MQTT 等多种消息中间件协议。 +- **多语言客户端**：RabbitMQ 几乎支持所有常用语言，比如 Java、Python、Ruby、PHP、C#、JavaScript 等。 +- **管理界面**：RabbitMQ 提供了一个易用的用户界面，使得用户可以监控和管理消息、集群中的节点等。 +- **插件机制**：RabbitMQ 提供了许多插件，以实现从多方面进行扩展，当然也可以编写自己的插件。 ## RabbitMQ 核心概念？ @@ -37,7 +37,7 @@ RabbitMQ 整体上是一个生产者与消费者模型，主要负责接收、 RabbitMQ 的整体模型架构如下： -![图1-RabbitMQ 的整体模型架构](https://oss.javaguide.cn/github/javaguide/rabbitmq/96388546.jpg) +![RabbitMQ 4.0 核心架构与消息生命周期流转图](https://oss.javaguide.cn/github/javaguide/high-performance/rabbitmq/rabbitmq-core-architecture-and-message-lifecycle-flow.png) 下面我会一一介绍上图中的一些概念。 @@ -46,7 +46,7 @@ RabbitMQ 的整体模型架构如下： - **Producer(生产者)** :生产消息的一方（邮件投递者） - **Consumer(消费者)** :消费消息的一方（邮件收件人） -消息一般由 2 部分组成：**消息头**（或者说是标签 Label）和 **消息体**。消息体也可以称为 payLoad ,消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括 routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。生产者把消息交由 RabbitMQ 后，RabbitMQ 会根据消息头把消息发送给感兴趣的 Consumer(消费者)。 +消息一般由 2 部分组成：**消息头**（或者说是标签 Label）和 **消息体**。消息体也可以称为 **payload**，消息体是不透明的，而消息头则由一系列的可选属性组成，这些属性包括 routing-key（路由键）、priority（相对于其他消息的优先权）、delivery-mode（指出该消息可能需要持久性存储）等。生产者把消息交由 RabbitMQ 后，RabbitMQ 会根据消息头把消息发送给感兴趣的 Consumer(消费者)。 ### Exchange(交换器) @@ -54,19 +54,13 @@ RabbitMQ 的整体模型架构如下： **Exchange(交换器)** 用来接收生产者发送的消息并将这些消息路由给服务器中的队列中，如果路由不到，或许会返回给 **Producer(生产者)** ，或许会被直接丢弃掉 。这里可以将 RabbitMQ 中的交换器看作一个简单的实体。 -**RabbitMQ 的 Exchange(交换器) 有 4 种类型，不同的类型对应着不同的路由策略**：**direct(默认)**，**fanout**, **topic**, 和 **headers**，不同类型的 Exchange 转发消息的策略有所区别。这个会在介绍 **Exchange Types(交换器类型)** 的时候介绍到。 +**RabbitMQ 的 Exchange(交换器) 有 4 种类型，不同的类型对应着不同的路由策略**：**direct**，**fanout**, **topic**, 和 **headers**，不同类型的 Exchange 转发消息的策略有所区别。这个会在介绍 **Exchange Types(交换器类型)** 的时候介绍到。 -Exchange(交换器) 示意图如下： - -![Exchange(交换器) 示意图](https://oss.javaguide.cn/github/javaguide/rabbitmq/24007899.jpg) +> 注意：AMQP 规范定义了一个默认交换器（Default Exchange），它是一个 pre-declared 的 direct 类型交换器，但创建新交换器时必须显式指定类型，不能省略。 生产者将消息发给交换器的时候，一般会指定一个 **RoutingKey(路由键)**，用来指定这个消息的路由规则，而这个 **RoutingKey 需要与交换器类型和绑定键(BindingKey)联合使用才能最终生效**。 -RabbitMQ 中通过 **Binding(绑定)** 将 **Exchange(交换器)** 与 **Queue(消息队列)** 关联起来，在绑定的时候一般会指定一个 **BindingKey(绑定建)** ,这样 RabbitMQ 就知道如何正确将消息路由到队列了,如下图所示。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。Exchange 和 Queue 的绑定可以是多对多的关系。 - -Binding(绑定) 示意图： - -![Binding(绑定) 示意图](https://oss.javaguide.cn/github/javaguide/rabbitmq/70553134.jpg) +RabbitMQ 中通过 **Binding(绑定)** 将 **Exchange(交换器)** 与 **Queue(消息队列)** 关联起来，在绑定的时候一般会指定一个 **BindingKey(绑定键)** ,这样 RabbitMQ 就知道如何正确将消息路由到队列了,如下图所示。一个绑定就是基于路由键将交换器和消息队列连接起来的路由规则，所以可以将交换器理解成一个由绑定构成的路由表。Exchange 和 Queue 的绑定可以是多对多的关系。 生产者将消息发送给交换器时，需要一个 RoutingKey,当 BindingKey 和 RoutingKey 相匹配时，消息会被路由到对应的队列中。在绑定多个队列到同一个交换器的时候，这些绑定允许使用相同的 BindingKey。BindingKey 并不是在所有的情况下都生效，它依赖于交换器类型，比如 fanout 类型的交换器就会无视，而是将消息路由到所有绑定到该交换器的队列中。 @@ -74,9 +68,19 @@ Binding(绑定) 示意图： **Queue(消息队列)** 用来保存消息直到发送给消费者。它是消息的容器，也是消息的终点。一个消息可投入一个或多个队列。消息一直在队列里面，等待消费者连接到这个队列将其取走。 -**RabbitMQ** 中消息只能存储在 **队列** 中，这一点和 **Kafka** 这种消息中间件相反。Kafka 将消息存储在 **topic（主题）** 这个逻辑层面，而相对应的队列逻辑只是 topic 实际存储文件中的位移标识。 RabbitMQ 的生产者生产消息并最终投递到队列中，消费者可以从队列中获取消息并消费。 +**RabbitMQ** 在经典架构中，消息只能存储在 **队列** 中，这一点和 **Kafka** 这种消息中间件相反。Kafka 将消息存储在 **topic（主题）** 这个逻辑层面，而相对应的队列逻辑只是 topic 实际存储文件中的位移标识。RabbitMQ 的生产者生产消息并最终投递到队列中，消费者可以从队列中获取消息并消费。 + +> **版本说明（3.9+ 重要更新）**：从 RabbitMQ 3.9 版本开始，官方引入了 **Streams** 数据结构。Streams 提供了一种类似 Kafka 的 append-only 日志存储模型，支持非破坏性消费、大规模消息堆积以及基于 Offset 的历史数据重放（Replay）。 +> +> **架构选型建议**： +> +> - **普通队列**：适用于传统消息队列场景，消息被消费后即删除 +> - **Streams**：适用于需要高频重放、海量堆积或事件溯源的场景 +> - **核心瓶颈差异**：使用 Stream 时，磁盘 I/O 吞吐量（MB/s）取代了传统的每秒入队率（msg/s）成为核心瓶颈指标 -**多个消费者可以订阅同一个队列**，这时队列中的消息会被平均分摊（Round-Robin，即轮询）给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理，这样避免消息被重复消费。 +**多个消费者可以订阅同一个队列**，默认情况下队列中的消息会被平均分摊（Round-Robin，即轮询）给多个消费者进行处理，而不是每个消费者都收到所有的消息并处理，这样避免消息被重复消费。 + +> 注意：实际分发策略受 `prefetch_count` 参数影响。默认行为（`prefetch_count=0`）会尽可能多地分发消息给各 Consumer，可能导致负载不均。推荐设置 `prefetch_count=1` 或更高值，让 Consumer 确认后再发送下一条，实现公平分发。 **RabbitMQ** 不支持队列层面的广播消费,如果有广播消费的需求，需要在其上进行二次开发,这样会很麻烦，不建议这样做。 @@ -84,57 +88,72 @@ Binding(绑定) 示意图： 对于 RabbitMQ 来说，一个 RabbitMQ Broker 可以简单地看作一个 RabbitMQ 服务节点，或者 RabbitMQ 服务实例。大多数情况下也可以将一个 RabbitMQ Broker 看作一台 RabbitMQ 服务器。 -下图展示了生产者将消息存入 RabbitMQ Broker,以及消费者从 Broker 中消费数据的整个流程。 - -![消息队列的运转过程](https://oss.javaguide.cn/github/javaguide/rabbitmq/67952922.jpg) - -这样图 1 中的一些关于 RabbitMQ 的基本概念我们就介绍完毕了，下面再来介绍一下 **Exchange Types(交换器类型)** 。 - ### Exchange Types(交换器类型) -RabbitMQ 常用的 Exchange Type 有 **fanout**、**direct**、**topic**、**headers** 这四种（AMQP 规范里还提到两种 Exchange Type，分别为 system 与 自定义，这里不予以描述）。 - -**1、fanout** - -fanout 类型的 Exchange 路由规则非常简单，它会把所有发送到该 Exchange 的消息路由到所有与它绑定的 Queue 中，不需要做任何判断操作，所以 fanout 类型是所有的交换机类型里面速度最快的。fanout 类型常用来广播消息。 +RabbitMQ 常用的 Exchange Type 有 **fanout**、**direct**、**topic**、**headers** 这四种（AMQP 规范里还提到两种 Exchange Type，分别为 system 与自定义，这里不予以描述）。 -**2、direct** +![RabbitMQ Exchange 四种类型对比](https://oss.javaguide.cn/github/javaguide/high-performance/rabbitmq/rabbitmq-exchange-types.png) -direct 类型的 Exchange 路由规则也很简单，它会把消息路由到那些 Bindingkey 与 RoutingKey 完全匹配的 Queue 中。 +**1、fanout（广播模式）** -![direct 类型交换器](https://oss.javaguide.cn/github/javaguide/rabbitmq/37008021.jpg) +- **路由规则**：把所有发送到该 Exchange 的消息路由到所有与它绑定的 Queue 中，**忽略 BindingKey** +- **特点**：不需要做任何判断操作，是所有交换机类型里面速度最快的 +- **典型使用场景**： + - 系统配置更新广播（如配置中心推送） + - 实时排行榜同步（多实例数据同步） + - 缓存失效广播（如 Redis 缓存清理通知） + - 日志分发（将日志同时发送到多个存储系统） -以上图为例，如果发送消息的时候设置路由键为“warning”,那么消息会路由到 Queue1 和 Queue2。如果在发送消息的时候设置路由键为"Info”或者"debug”，消息只会路由到 Queue2。如果以其他的路由键发送消息，则消息不会路由到这两个队列中。 +**2、direct（直连模式）** -direct 类型常用在处理有优先级的任务，根据任务的优先级把消息发送到对应的队列，这样可以指派更多的资源去处理高优先级的队列。 +- **路由规则**：把消息路由到那些 BindingKey 与 RoutingKey **完全匹配**的 Queue 中 +- **特点**：精确匹配，路由效率高 +- **典型使用场景**： + - **基础点对点任务分发**：根据任务级别路由（如 `error`、`warning`、`info`） + - 优先级队列：高优先级任务分配更多资源 + - 按服务类型分发（如 `order-service`、`payment-service`） -**3、topic** +**示例**：以上图为例，如果发送消息时设置路由键为 `"warning"`，消息会路由到 Queue1 和 Queue2；如果设置路由键为 `"info"` 或 `"debug"`，消息只会路由到 Queue2。 -前面讲到 direct 类型的交换器路由规则是完全匹配 BindingKey 和 RoutingKey ，但是这种严格的匹配方式在很多情况下不能满足实际业务的需求。topic 类型的交换器在匹配规则上进行了扩展，它与 direct 类型的交换器相似，也是将消息路由到 BindingKey 和 RoutingKey 相匹配的队列中，但这里的匹配规则有些不同，它约定： +**3、topic（主题模式）** -- RoutingKey 为一个点号“．”分隔的字符串（被点号“．”分隔开的每一段独立的字符串称为一个单词），如 “com.rabbitmq.client”、“java.util.concurrent”、“com.hidden.client”; -- BindingKey 和 RoutingKey 一样也是点号“．”分隔的字符串； -- BindingKey 中可以存在两种特殊字符串“\*”和“#”，用于做模糊匹配，其中“\*”用于匹配一个单词，“#”用于匹配多个单词(可以是零个)。 +- **路由规则**：基于 BindingKey 和 RoutingKey 的**模糊匹配** +- **匹配规则**： + - RoutingKey 为点号 `"."` 分隔的字符串（如 `com.rabbitmq.client`、`order.china.beijing`） + - BindingKey 中可以使用两种通配符： + - `"*"`：匹配**一个单词** + - `"#"`：匹配**零个或多个单词** +- **典型使用场景**： + - **按地域或业务模块过滤**（如 `order.china.*` 匹配中国所有地区订单） + - 多级路由（如 `com.rabbitmq.client`、`java.util.concurrent`） + - 发布订阅系统（分类通知、按标签订阅） -![topic 类型交换器](https://oss.javaguide.cn/github/javaguide/rabbitmq/73843.jpg) +**示例**： -以上图为例： +- 路由键为 `"com.rabbitmq.client"` 的消息会同时路由到绑定 `"*.rabbitmq.*"` 和 `"#.client.#"` 的队列 +- 路由键为 `"order.china.beijing"` 的消息会路由到绑定 `"order.china.*"` 的队列 -- 路由键为 “com.rabbitmq.client” 的消息会同时路由到 Queue1 和 Queue2; -- 路由键为 “com.hidden.client” 的消息只会路由到 Queue2 中； -- 路由键为 “com.hidden.demo” 的消息只会路由到 Queue2 中； -- 路由键为 “java.rabbitmq.demo” 的消息只会路由到 Queue1 中； -- 路由键为 “java.util.concurrent” 的消息将会被丢弃或者返回给生产者（需要设置 mandatory 参数），因为它没有匹配任何路由键。 +**4、headers（不推荐）** -**4、headers(不推荐)** - -headers 类型的交换器不依赖于路由键的匹配规则来路由消息，而是根据发送的消息内容中的 headers 属性进行匹配。在绑定队列和交换器时指定一组键值对，当发送消息到交换器时，RabbitMQ 会获取到该消息的 headers（也是一个键值对的形式)，对比其中的键值对是否完全匹配队列和交换器绑定时指定的键值对，如果完全匹配则消息会路由到该队列，否则不会路由到该队列。headers 类型的交换器性能会很差，而且也不实用，基本上不会看到它的存在。 +- **路由规则**：根据消息内容中的 headers 键值对进行匹配 +- **特点**： + - 不依赖 RoutingKey，支持 `x-match=all`（全部匹配）或 `x-match=any`（任一匹配） + - **性能较差**，匹配效率远低于其他三种类型 +- **典型使用场景**： + - 几乎不使用，面试时可提到"因为匹配性能较差，生产环境建议用 Topic 替代" + - 仅适用于极其复杂的路由规则且消息量极小的场景 ## AMQP 是什么? -RabbitMQ 就是 AMQP 协议的 `Erlang` 的实现(当然 RabbitMQ 还支持 `STOMP2`、 `MQTT3` 等协议 ) AMQP 的模型架构 和 RabbitMQ 的模型架构是一样的，生产者将消息发送给交换器，交换器和队列绑定 。 +RabbitMQ 就是 AMQP 协议的 `Erlang` 的实现(当然 RabbitMQ 还支持 `STOMP`、`MQTT` 等协议)。AMQP 的模型架构 和 RabbitMQ 的模型架构是一样的，生产者将消息发送给交换器，交换器和队列绑定。 + +RabbitMQ 中的交换器、交换器类型、队列、绑定、路由键等都是遵循的 AMQP 协议中**相应**的概念。 -RabbitMQ 中的交换器、交换器类型、队列、绑定、路由键等都是遵循的 AMQP 协议中相 应的概念。目前 RabbitMQ 最新版本默认支持的是 AMQP 0-9-1。 +> **版本说明**： +> +> - **AMQP 0-9-1**：RabbitMQ 的传统协议，广泛使用，功能完整 +> - **AMQP 1.0**：RabbitMQ 4.x 已将其提升为一等公民协议，显著优化了原生 AMQP 1.0 的解析效率，不再需要像旧版本那样通过复杂的插件转换。这提升了与其他消息中间件（如 ActiveMQ、Service Bus）的互操作性，适合需要跨平台集成的场景 +> - 新项目可考虑使用 AMQP 1.0 以获得更好的跨平台兼容性 **AMQP 协议的三层**： @@ -148,12 +167,12 @@ RabbitMQ 中的交换器、交换器类型、队列、绑定、路由键等都 - **队列 (Queue)**：用来存储消息的数据结构，位于硬盘或内存中。 - **绑定 (Binding)**：一套规则，告知交换器消息应该将消息投递给哪个队列。 -## **说说生产者 Producer 和消费者 Consumer?** +## 说说生产者 Producer 和消费者 Consumer -**生产者** : +**生产者**： - 消息生产者，就是投递消息的一方。 -- 消息一般包含两个部分：消息体（`payload`)和标签(`Label`)。 +- 消息一般包含两个部分：**消息体**（payload）和**消息头**（Label/Headers）。 **消费者**： @@ -168,11 +187,11 @@ RabbitMQ 中的交换器、交换器类型、队列、绑定、路由键等都 ## 什么是死信队列？如何导致的？ -DLX，全称为 `Dead-Letter-Exchange`，死信交换器，死信邮箱。当消息在一个队列中变成死信 (`dead message`) 之后，它能被重新发送到另一个交换器中，这个交换器就是 DLX，绑定 DLX 的队列就称之为死信队列。 +DLX，全称为 `Dead-Letter-Exchange`（死信交换器），当消息在一个队列中变成死信（`dead message`）之后，它能被重新发送到另一个交换器中，这个交换器就是 DLX，绑定 DLX 的队列就称之为死信队列。 **导致的死信的几种原因**： -- 消息被拒（`Basic.Reject /Basic.Nack`) 且 `requeue = false`。 +- 消息被拒（`Basic.Reject` 或 `Basic.Nack`）且 `requeue = false`。 - 消息 TTL 过期。 - 队列满了，无法再添加。 @@ -183,7 +202,13 @@ DLX，全称为 `Dead-Letter-Exchange`，死信交换器，死信邮箱。当消 RabbitMQ 本身是没有延迟队列的，要实现延迟消息，一般有两种方式： 1. 通过 RabbitMQ 本身队列的特性来实现，需要使用 RabbitMQ 的死信交换机（Exchange）和消息的存活时间 TTL（Time To Live）。 -2. 在 RabbitMQ 3.5.7 及以上的版本提供了一个插件（rabbitmq-delayed-message-exchange）来实现延迟队列功能。同时，插件依赖 Erlang/OPT 18.0 及以上。 + + - 缺点：消息按队列过期而非单消息级别（除非给每个消息单独队列） + +2. 在 RabbitMQ 3.5.7 及以上的版本提供了一个插件（rabbitmq-delayed-message-exchange）来实现延迟队列功能。同时，插件依赖 Erlang/OTP 18.0 及以上。 + - 原理：将消息暂存在 Mnesia 表中，定时轮询并投递到目标交换器 + - **容量边界警告（严重）**：该插件将延迟消息全部暂存在 Erlang 的 Mnesia 内部数据库中，**不具备良好的磁盘换页（Paging）能力**。如果单节点堆积**数十万到上百万级别**的延迟消息，会导致 Broker 内存剧增甚至触发**内存高水位（Memory Watermark）告警**，进而产生 **全局背压（Global Backpressure）** 阻塞所有生产者的 TCP 连接。 + - **生产建议**：针对海量延迟（千万级以上），必须退化使用外部定时任务（如时间轮、SchedulerX、XXL-JOB）调度或死信链表方案 也就是说，AMQP 协议以及 RabbitMQ 本身没有直接支持延迟队列的功能，但是可以通过 TTL 和 DLX 模拟出延迟队列的功能。 @@ -203,28 +228,167 @@ RabbitMQ 自 V3.5.0 有优先级队列实现，优先级高的队列会先被消 ## RabbitMQ 消息怎么传输？ -由于 TCP 链接的创建和销毁开销较大，且并发数受系统资源限制，会造成性能瓶颈，所以 RabbitMQ 使用信道的方式来传输数据。信道（Channel）是生产者、消费者与 RabbitMQ 通信的渠道，信道是建立在 TCP 链接上的虚拟链接，且每条 TCP 链接上的信道数量没有限制。就是说 RabbitMQ 在一条 TCP 链接上建立成百上千个信道来达到多个线程处理，这个 TCP 被多个线程共享，每个信道在 RabbitMQ 都有唯一的 ID，保证了信道私有性，每个信道对应一个线程使用。 +由于 TCP 链接的创建和销毁开销较大（三次握手、慢启动等），且并发数受系统资源限制，会造成性能瓶颈，所以 RabbitMQ 使用信道的方式来传输数据。信道（Channel）是生产者、消费者与 RabbitMQ 通信的渠道，信道是建立在 TCP 链接上的虚拟链接。 + +> 注意： +> +> - 单个 TCP 连接可承载多个 Channel，但官方建议不超过 100-200 个/连接 +> - 每个 Channel 有独立的编号，但共享同一 TCP 连接的流量控制 +> - **Channel 不是线程安全的**，多线程应使用不同 Channel 实例 + +## 如何保证消息的可靠性？ + +![RabbitMQ 4.0 消息可靠性与队列架构全景图](https://oss.javaguide.cn/github/javaguide/high-performance/rabbitmq/rabbitmq-message-reliability-and-queue-architecture-overview.png) + +消息可能在三个环节丢失：生产者 → Broker、Broker 存储期间、Broker → 消费者 + +**1. 生产者 → Broker** + +保证生产者端零丢失需要**双重机制兜底**： + +- **Publisher Confirms**（异步确认）：确认消息是否到达 Broker + + ```java + channel.confirmSelect(); + channel.addConfirmListener((sequenceNumber, multiple) -> { + // 消息已到达 Broker 并落盘/同步到镜像 + }, (sequenceNumber, multiple) -> { + // 消息未到达 Broker，记录日志并重试 + }); + ``` + +- **Mandatory + Return Listener**（路由失败处理）：捕获消息到达 Exchange 但无法路由到 Queue 的情况 + + ```java + // 开启 mandatory 模式 + channel.basicPublish("exchange", "routingKey", + true, // mandatory=true + null, + messageBody); + + // 配置 Return Listener + channel.addReturnListener((replyCode, replyText, exchange, routingKey, properties, body) -> { + // 消息到达 Exchange 但路由失败，记录日志或发送到备用交换器 + log.error("Message returned: {}", replyText); + }); + ``` + +> **关键警告**：若仅开启 Confirm 未处理 Return，配置漂移（如误删队列或绑定）会导致生产者认为发送成功，但消息在 Broker 内部被静默丢弃，形成**消息黑洞**。 + +- **事务机制**（不推荐）：同步阻塞，**性能显著下降（官方文档未给出具体倍数，实际影响取决于消息大小和网络延迟）** + - 注意：事务机制和 Confirm 机制是互斥的，两者不能共存 + +**2. Broker 存储期间** + +- **消息持久化**：`delivery_mode=2`，消息写入磁盘 +- **队列持久化**：`durable=true`，重启后队列重建 +- **集群模式**： + - **镜像队列**（Classic Queue Mirroring，已于 4.0 移除）：主从同步，仅用于老版本维护 + - **Quorum Queue**（3.8+ 推荐，4.0 后为默认）：基于 Raft 协议，支持更严格的仲裁写入（N/2 + 1） + - **Streams**（3.9+）：适用于事件溯源和高频重放场景 + +**3. Broker → 消费者** -## **如何保证消息的可靠性？** +- **手动 Ack**：`basicAck(deliveryTag, multiple)`，确保消费成功后再确认 +- **重试机制**：消费失败时 `basicNack` 或 `basicReject` 并 `requeue=true` +- **死信队列**：达到最大重试次数后路由到 DLQ 人工介入 +- **幂等性保障**：业务层实现，避免重复消费导致的数据不一致。幂等性具体实现方案参考这篇文章：[接口幂等方案总结](https://javaguide.cn/high-availability/idempotency.html)。 -消息到 MQ 的过程中搞丢，MQ 自己搞丢，MQ 到消费过程中搞丢。 +以下时序图展示了从生产者到消费者的完整消息流转及各环节的异常处理策略： -- 生产者到 RabbitMQ：事务机制和 Confirm 机制，注意：事务机制和 Confirm 机制是互斥的，两者不能共存，会导致 RabbitMQ 报错。 -- RabbitMQ 自身：持久化、集群、普通模式、镜像模式。 -- RabbitMQ 到消费者：basicAck 机制、死信队列、消息补偿机制。 +```mermaid +sequenceDiagram + participant P as 生产者 (Producer) + participant E as 交换器 (Exchange) + participant DLX as 死信交换器 (DLX) + participant Q as 队列 (Quorum Queue) + participant C as 消费者 (Consumer) + + P->>E: 1. 发送消息 (开启 Confirm & Mandatory) + alt 路由成功 + E->>Q: 2. 消息进入队列 + Q-->>P: 3. Raft 多数派落盘后返回 Confirm Ack + else 路由失败 (无匹配 Queue, mandatory=true) + E-->>P: 2a. 触发 Return Listener 返回消息 + Note over P: 记录日志或告警 + end + + Q->>C: 4. 推送消息 (开启手动 Ack) + + alt 消费成功 + C-->>Q: 5. 发送 basic.ack + Q->>Q: 6. 标记消息可删除 + else 业务异常且可重试 + C-->>Q: 5a. basic.nack (requeue=true) + Q->>Q: 6a. 消息重回队列尾部 (注意：顺序破坏) + else 致命异常 / 重试超限 + C-->>Q: 5b. basic.reject (requeue=false) + Q->>DLX: 6b. 路由至死信交换机 (DLX) + end +``` + +**关键路径说明**： + +- **Confirm + Returns**（互为补充）： + - Confirm 确认消息是否到达 Broker 并落盘/同步 + - Mandatory + Return Listener 捕获路由失败事件（消息到达 Exchange 但无法进入 Queue） +- **Quorum Queue**：Raft 多数派确认后才返回 Ack，保证数据不丢 +- **手动 Ack**：确保消费成功后才删除消息 +- **DLQ 兜底**：重试超限后路由到死信队列，避免消息无限重试 + +> **注意**：Alternate Exchange（备用交换器）是另一种独立的路由失败处理机制，与 Mandatory + Return Listener 互斥。配置 Alternate Exchange 后，路由失败的消息会被转发到备用交换器，生产者收到的是正常的 Confirm Ack 而非 Return。 ## 如何保证 RabbitMQ 消息的顺序性？ -- 拆分多个 queue(消息队列)，每个 queue(消息队列) 一个 consumer(消费者)，就是多一些 queue (消息队列)而已，确实是麻烦点； -- 或者就一个 queue (消息队列)但是对应一个 consumer(消费者)，然后这个 consumer(消费者)内部用内存队列做排队，然后分发给底层不同的 worker 来处理。 +RabbitMQ 仅保证**单个 Queue 内的 FIFO 顺序**，但多消费者场景下可能出现乱序。解决方案： + +**1. 单 Consumer 模式** + +- 一个 Queue 只绑定一个 Consumer +- 优点：保证顺序 +- 缺点：成为瓶颈，吞吐量受限 + +**2. 分区有序**（推荐，但需注意失效模式） + +- 按业务 key（如订单ID）哈希到不同 Queue +- 每个 Queue 独立 Consumer +- 优点：既保证顺序又提高吞吐量 + +> **失效模式警告**： +> +> - **拓扑变更乱序**：当后端队列扩缩容导致哈希环发生变化时，同一个业务 Key 的新老消息可能进入不同队列 +> - **重试乱序**：若消费者内部处理失败执行 Nack 并 Requeue，该消息会被重新推入队列**尾部**，导致后续消息先被消费 +> - **应用层防护**：极端严格顺序场景下，消费者业务表必须设计基于**状态机**或**版本号**的幂等与防并发覆盖机制 + +**3. 内部内存队列**（慎重） + +- 单一 Consumer 内部维护内存队列分发到 Worker 线程池 +- 需处理： + - Consumer 挂掉时内存队列丢失风险 + - 需实现背压机制防止 OOM + - 增加 ack 复杂度（需追踪具体 Worker 处理状态） +- 生产环境慎用此方案 ## 如何保证 RabbitMQ 高可用的？ -RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的，我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现。RabbitMQ 有三种模式：单机模式、普通集群模式、镜像集群模式。 +RabbitMQ 是比较有代表性的，因为是基于主从（非分布式）做高可用性的，我们就以 RabbitMQ 为例子讲解第一种 MQ 的高可用性怎么实现。RabbitMQ 有四种模式：单机模式、普通集群模式、镜像集群模式（已废弃）、Quorum Queue（推荐）。 + +> **版本演进说明**： +> +> - **3.8 前**：镜像队列（Classic Queue Mirroring）是主要高可用方案 +> - **3.8+**：Quorum Queue 作为推荐替代方案，镜像队列被标记为 deprecated +> - **3.13**：镜像队列仍可用但已废弃 +> - **4.0+**：镜像队列**完全移除**，Quorum Queue 成为默认高可用方案 +> +> **网络分区警告（严重）**：无论是普通集群还是早期的镜像集群，均依赖 Erlang 内部的分布式同步机制，对网络抖动极度敏感。在多机房或跨可用区部署时，极易发生**网络分区（Split-brain）**。必须在 `rabbitmq.conf` 中明确配置分区恢复策略： +> +> - `pause_minority`：少数派节点自动暂停服务以防数据分化（推荐） +> - `autoheal`：自动选择一方继续运行（有数据丢失风险） +> - 对于 3.8 以上版本，强烈建议直接使用基于 Raft 一致性算法的 Quorum Queue，从根本上解决网络分区导致的消息丢失与状态不一致问题 **单机模式** -Demo 级别的，一般就是你本地启动了玩玩儿的?，没人生产用单机模式。 +Demo 级别的，一般就是你本地启动了玩玩儿的，没人生产用单机模式。 **普通集群模式** @@ -232,14 +396,276 @@ Demo 级别的，一般就是你本地启动了玩玩儿的?，没人生产用 你消费的时候，实际上如果连接到了另外一个实例，那么那个实例会从 queue 所在实例上拉取数据过来。这方案主要是提高吞吐量的，就是说让集群中多个节点来服务某个 queue 的读写操作。 -**镜像集群模式** +**镜像集群模式**（Classic Queue Mirroring，已废弃） + +> ⚠️ **重要警告**：镜像队列已在 RabbitMQ 4.0 中被**完全移除**。RabbitMQ 3.8 引入 Quorum Queue 作为推荐替代方案，3.13 版本镜像队列仍可用但已废弃，4.0 版本正式移除。新项目请使用 Quorum Queue 或 Streams。 + +这种模式是 RabbitMQ 早期版本的高可用方案。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据。每次写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。 + +**工作原理**： -这种模式，才是所谓的 RabbitMQ 的高可用模式。跟普通集群模式不一样的是，在镜像集群模式下，你创建的 queue，无论元数据还是 queue 里的消息都会存在于多个实例上，就是说，每个 RabbitMQ 节点都有这个 queue 的一个完整镜像，包含 queue 的全部数据的意思。然后每次你写消息到 queue 的时候，都会自动把消息同步到多个实例的 queue 上。RabbitMQ 有很好的管理控制台，就是在后台新增一个策略，这个策略是镜像集群模式的策略，指定的时候是可以要求数据同步到所有节点的，也可以要求同步到指定数量的节点，再次创建 queue 的时候，应用这个策略，就会自动将数据同步到其他的节点上去了。 +- Queue 主节点接收消息，同步到 N 个镜像节点 +- 主节点宕机时，最老的镜像节点升级为主节点 +- 通过管理控制台新增策略，指定数据同步到所有节点或指定数量的节点 -这样的好处在于，你任何一个机器宕机了，没事儿，其它机器（节点）还包含了这个 queue 的完整数据，别的 consumer 都可以到其它节点上去消费数据。坏处在于，第一，这个性能开销也太大了吧，消息需要同步到所有机器上，导致网络带宽压力和消耗很重！RabbitMQ 一个 queue 的数据都是放在一个节点里的，镜像集群下，也是每个节点都放这个 queue 的完整数据。 +**优点**： + +- 任何机器宕机，其他节点包含该 queue 的完整数据 +- Consumer 可以切换到其他节点继续消费 + +**缺点**： + +- 性能开销大，消息需要同步到所有机器上 +- 网络带宽压力和消耗重 +- 不是真正的分布式架构，是主从复制 + +**Quorum Queue**（3.8+ 推荐，4.0 后为默认高可用方案） + +基于 Raft 协议的复制队列，是 RabbitMQ 3.8+ 推荐的高可用方案，4.0 后成为默认选项： + +- **基于 Raft 协议**：通过日志复制和选举实现一致性 +- **仲裁写入**：需要多数节点确认（N/2 + 1）才认为写入成功 +- **更严格的一致性**：避免镜像队列的脑裂风险 +- **适用场景**：对可靠性要求高的场景 + +**声明方式（客户端）**： + +Java： + +```java +// Java 客户端声明 Quorum Queue +Map args = new HashMap<>(); +args.put("x-queue-type", "quorum"); // 关键参数，必须在声明时指定 +channel.queueDeclare("my-queue", true, false, false, args); +``` + +Python： + +```python +# Python (pika) 客户端声明 Quorum Queue +channel.queue_declare( + queue='my-queue', + durable=True, + arguments={'x-queue-type': 'quorum'} # 关键参数 +) +``` + +> **重要提示**：`x-queue-type` 参数必须在队列声明时由客户端提供，**不能通过 Policy 设置或修改**。Policy 只能配置 max-length、delivery-limit 等运行时参数。 ## 如何解决消息队列的延时以及过期失效问题？ -RabbtiMQ 是可以设置过期时间的，也就是 TTL。如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 给清理掉，这个数据就没了。那这就是第二个坑了。这就不是说数据会大量积压在 mq 里，而是大量的数据会直接搞丢。我们可以采取一个方案，就是批量重导，这个我们之前线上也有类似的场景干过。就是大量积压的时候，我们当时就直接丢弃数据了，然后等过了高峰期以后，比如大家一起喝咖啡熬夜到晚上 12 点以后，用户都睡觉了。这个时候我们就开始写程序，将丢失的那批数据，写个临时程序，一点一点的查出来，然后重新灌入 mq 里面去，把白天丢的数据给他补回来。也只能是这样了。假设 1 万个订单积压在 mq 里面，没有处理，其中 1000 个订单都丢了，你只能手动写程序把那 1000 个订单给查出来，手动发到 mq 里去再补一次。 +RabbitMQ 可以设置消息过期时间（TTL）。如果消息在 queue 中积压超过一定的时间就会被 RabbitMQ 清理掉，导致数据丢失。 + +**批量重导方案**（适用于数据可恢复的场景）： + +当大量消息积压或过期时，可采取以下步骤： + +1. **临时丢弃**：高峰期直接丢弃无法及时处理的数据，保证系统可用性 +2. **低峰期恢复**：在业务低峰期（如凌晨），编写临时程序从数据库中查询丢失的数据 +3. **重新投递**：将查询到的数据重新发送到 MQ 中进行补偿 + +**示例场景**： + +- 假设 1 万个订单积压在 MQ 中未处理 +- 其中 1000 个订单因 TTL 过期被丢弃 +- 处理方案：编写临时程序从数据库查询这 1000 个订单，手动重新发送到 MQ 补偿 + +**注意事项**： + +- 确保数据源（如数据库）中有完整的历史数据 +- 补偿过程需要做好幂等性处理，避免重复消费 +- 建议设置监控告警，及时发现消息积压情况 + +## 生产环境最佳实践与监控告警 + +### 核心监控指标 + +**1. 内存水位线告警（严重）** + +- 监控 `rabbitmq_memory_limit` 占比 +- 告警阈值：默认高水位为 0.4（40%） +- **影响**：一旦达到高水位，RabbitMQ 会直接 block 所有生产者的 TCP Socket（全局背压） +- 建议配置： + ```erlang + {rabbit, [ + {vm_memory_high_watermark, 0.4}, % 内存高水位 40% + {vm_memory_high_watermark_paging_ratio, 0.5} % 开始分页的比例 + ]} + ``` + +**2. 文件句柄消耗** + +- 监控 File Descriptors 使用率 +- **风险**：连接数风暴或海量未确认消息会耗尽句柄导致节点 Crash +- 建议值：系统限制至少 100,000+（`ulimit -n 100000`） + +**3. Channel Churn Rate** + +- 监控信道的创建与销毁速率 +- **风险**：高频创建销毁（而非复用）会导致 Erlang 进程抖动，引发 CPU 飙升 +- 生产建议：单连接 Channel 数建议 50-100，避免频繁创建/销毁 + +**4. 消息积压深度** + +- 监控 Queue 消息数量和 Consumer Lag +- 告警阈值：根据业务定义（如 > 10,000 条） +- 工具：RabbitMQ Management UI、Prometheus + Grafana + +**5. 磁盘空间与 I/O** + +- 监控磁盘剩余空间和 IOPS +- **告警阈值**：磁盘剩余 < 20% 触发告警 +- Quorum Queue 对磁盘 I/O 要求较高，建议使用 NVMe SSD + +### 常见生产误区与避坑指南 + +**误区 1：Quorum Queue 是银弹，能解决所有问题** + +- **真相**：Quorum Queue 的 Raft 日志在 flush 时会 fsync，且 Confirm 需等待多数节点 fsync 后才返回。如果底层不是高性能 NVMe SSD，其吞吐量会受到影响 +- **限制**：Quorum Queue 会将所有消息（包括 `delivery_mode=1` 的非持久化消息）强制持久化存储到磁盘 +- **选型建议**： + - 高吞吐量场景：考虑 Classic Queue（非镜像，单节点）或 Streams（3.9+） + - 高可靠性场景：使用 Quorum Queue（3.8+） + +**误区 2：Prefetch Count 设置越大越好** + +- **真相**：客户端批量拉取大量消息但在本地卡死，导致服务端队列看似空闲，实则消息全部处于 Unacked 状态，拖垮客户端本地内存并阻碍其他消费者接盘 +- **生产建议**：核心业务初始值设为 **10 到 50** 之间，根据处理耗时调整 + ```java + channel.basicQos(20); // 推荐起始值 + ``` + +**误区 3：延迟队列插件可以无限制使用** + +- **真相**：延迟插件将所有延迟消息存储在 Mnesia 内存表中，**不支持磁盘换页** +- **风险**：单节点堆积百万级延迟消息会触发 OOM 或全局背压 +- **替代方案**：海量延迟场景使用外部定时任务系统（如 XXL-JOB、SchedulerX） + +**误区 4：网络分区不会发生在我们环境** + +- **真相**：跨机房部署或网络抖动都会触发 Erlang 的网络分区检测 +- **后果**：Split-brain 导致消息丢失、状态不一致 +- **防护**： + - 3.8+ 使用 Quorum Queue（基于 Raft，天然抗分区） + - 配置分区恢复策略：`cluster_partition_handling = pause_minority` + +**误区 5：开启了事务机制就万无一失** + +- **真相**：事务机制是同步阻塞模式，性能显著低于 Publisher Confirms（官方文档未给出具体倍数，实际影响取决于消息大小和网络延迟） +- **替代方案**：使用 Publisher Confirms + Mandatory Returns（异步且高性能） + +### 生产配置参考 + +> **重要说明**：RabbitMQ 3.7+ 使用新的 `rabbitmq.conf` 格式（sysctl 风格），而非旧的 `advanced.config`（Erlang 术语格式）。以下配置适用于 `rabbitmq.conf`： + +```ini +# rabbitmq.conf 生产环境推荐配置 + +# 内存管理 +vm_memory_high_watermark.relative = 0.4 +vm_memory_high_watermark_paging_ratio = 0.5 + +# 磁盘管理 +disk_free_limit.absolute = 5GB + +# 连接与通道 +channel_max = 200 +connection_max = infinity + +# 心跳检测（秒） +heartbeat = 60 + +# 网络分区处理（重要） +cluster_partition_handling = pause_minority + +# 默认用户（生产环境请修改或删除） +default_user = guest +default_pass = guest +loopback_users = none + +# 管理插件监听端口 +management.tcp.port = 15672 +``` + +如需使用 Erlang 术语格式（高级配置），请使用 `advanced.config` 文件，但**不要与 `rabbitmq.conf` 混用**。 + +## 总结 + +本文系统梳理了 RabbitMQ 的核心知识点，从基础概念到生产实践，涵盖了面试和实际应用中最重要的内容。让我们回顾一下关键要点： + +### 核心技术架构演进 + +| 版本里程碑 | 重要变化 | 生产影响 | +| ---------- | --------------------------------------- | -------------------------------------- | +| **3.8 前** | 镜像队列（Classic Queue Mirroring）时代 | 主从复制，脑裂风险 | +| **3.8+** | Quorum Queue 引入 | 基于 Raft，推荐用于高可靠场景 | +| **3.9+** | Streams 引入 | Kafka-like 架构，支持事件溯源 | +| **4.0+** | 镜像队列完全移除 | 新项目必须使用 Quorum Queue 或 Streams | + +### 面试高频考点 + +**必知必会**： + +1. **AMQP 模型**：Exchange、Queue、Binding 三大核心组件 +2. **Exchange 类型及典型场景**： + - **Direct**：点对点任务分发、按优先级路由 + - **Fanout**：广播通知、配置更新、缓存失效 + - **Topic**：按地域/业务模块过滤（如 `order.china.*`） + - **Headers**：几乎不使用，性能差 +3. **消息可靠性**：Publisher Confirms + Mandatory Returns + 手动 Ack + DLQ +4. **幂等性实现**：数据库唯一键、Redis SETNX、状态机判断 +5. **消息顺序性**：单 Queue 内 FIFO，多消费者需分区有序或单 Consumer +6. **高可用方案**：Quorum Queue（3.8+）替代镜像队列（4.0 已移除） + +**常见追问**： + +- 为什么镜像队列被移除？（脑裂问题、主从复制非分布式） +- Quorum Queue 和 Classic Queue 如何选型？（可靠性 vs 吞吐量） +- 如何保证消息不丢失？（三环节：生产者→Broker→消费者） +- 如何保证消息顺序？（单 Queue、分区有序、慎用内存队列） +- **如何实现幂等性？**（数据库唯一键、Redis SETNX、状态机判断，详见[接口幂等方案总结](https://javaguide.cn/high-availability/idempotency.html)） +- **Exchange 类型如何选择？**（Direct 用于精确路由，Topic 用于灵活过滤，Fanout 用于广播，Headers 不推荐） + +### 生产环境关键决策 + +**1. 队列类型选型** + +``` +高可靠性需求 → Quorum Queue（默认推荐） +高吞吐量需求 → Classic Queue（单节点）或 Streams（3.9+） +事件溯源需求 → Streams（支持非破坏性消费） +``` + +**2. 消息可靠性配置** + +```java +// 生产者端：双重保障 +channel.confirmSelect(); // Confirm +channel.basicPublish(exchange, routingKey, true, ...); // Mandatory +channel.addReturnListener(...); // Return Listener + +// 消费者端：手动确认 +channel.basicQos(20); // Fair dispatch +channel.basicConsume(queue, false, ...); // Manual ack +``` + +**3. 高可用配置要点** + +```ini +# 网络分区处理（跨机房部署必配） +cluster_partition_handling = pause_minority + +# 使用 Quorum Queue（客户端声明） +arguments.put("x-queue-type", "quorum"); +``` + +**4. 监控告警指标** + +- **内存水位线**：触发全局背压的阈值（默认 40%） +- **磁盘剩余空间**：低于 20% 触发告警 +- **消息积压深度**：Queue 消息数量和 Consumer Lag +- **Channel Churn Rate**：高频创建销毁会导致 CPU 飙升 + +--- diff --git a/docs/high-performance/read-and-write-separation-and-library-subtable.md b/docs/high-performance/read-and-write-separation-and-library-subtable.md index 1873aaa32fb..922b8887b6c 100644 --- a/docs/high-performance/read-and-write-separation-and-library-subtable.md +++ b/docs/high-performance/read-and-write-separation-and-library-subtable.md @@ -8,11 +8,13 @@ head: content: 读写分离,分库分表,主从复制,水平分表,垂直分库,ShardingSphere,MyCat,分布式ID,跨库查询 --- + + ## 读写分离 ### 什么是读写分离？ -见名思意，根据读写分离的名字，我们就可以知道：**读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。** 这样的话，就能够小幅提升写性能，大幅提升读性能。 +顾名思义，根据读写分离的名字，我们就可以知道：**读写分离主要是为了将对数据库的读写操作分散到不同的数据库节点上。** 这样的话，就能够小幅提升写性能，大幅提升读性能。 我简单画了一张图来帮助不太清楚读写分离的小伙伴理解。 @@ -42,11 +44,11 @@ head: **2. 组件方式** -在这种方式中，我们可以通过引入第三方组件来帮助我们读写请求。 +在这种方式中，我们可以通过引入第三方组件来实现读写请求的路由。 -这也是我比较推荐的一种方式。这种方式目前在各种互联网公司中用的最多的，相关的实际的案例也非常多。如果你要采用这种方式的话，推荐使用 `sharding-jdbc` ，直接引入 jar 包即可使用，非常方便。同时，也节省了很多运维的成本。 +这也是我比较推荐的一种方式。这种方式目前在各种互联网公司中用的最多的，相关的实际的案例也非常多。如果你要采用这种方式的话，推荐使用 **ShardingSphere-JDBC** ，直接引入 jar 包即可使用，非常方便。同时，也节省了很多运维的成本。 -你可以在 shardingsphere 官方找到 [sharding-jdbc 关于读写分离的操作](https://shardingsphere.apache.org/document/legacy/3.x/document/cn/manual/sharding-jdbc/usage/read-write-splitting/)。 +你可以在 ShardingSphere 官方找到 [ShardingSphere-JDBC 读写分离配置](https://shardingsphere.apache.org/document/current/cn/features/readwrite-splitting/)。 ### 主从复制原理是什么？ @@ -87,9 +89,16 @@ MySQL binlog(binary log 即二进制日志文件) 主要记录了 MySQL 数据 #### 强制将读请求路由到主库处理 -既然你从库的数据过期了，那我就直接从主库读取嘛！这种方案虽然会增加主库的压力，但是，实现起来比较简单，也是我了解到的使用最多的一种方式。 +对于极少数必须强一致的业务（如支付后立刻查询余额），可以通过 Hint 强制查主库。 + +```java +// ShardingSphere-JDBC 强制读主库 +HintManager hintManager = HintManager.getInstance(); +hintManager.setMasterRouteOnly(); +// 继续JDBC操作 +``` -比如 `Sharding-JDBC` 就是采用的这种方案。通过使用 Sharding-JDBC 的 `HintManager` 分片键值管理器，我们可以强制使用主库。 +> ⚠️ **注意**：严禁大范围使用此方案！读写分离的初衷就是为了分担主库的读压力，若大量读请求因延迟而回退到主库，在促销、秒杀等高并发场景下极易压垮主库导致全站宕机。**正确的 Trade-off**：仅核心强一致链路读主库，非核心链路必须在业务层容忍最终一致性（如页面提示"数据同步中"）。 ```java HintManager hintManager = HintManager.getInstance(); @@ -128,6 +137,8 @@ MySQL 主从同步延时是指从库的数据落后于主库的数据，这种 2. 从库 I/O 线程接收到 binlog 并写入 relay log 的时刻记为 T2； 3. 从库 SQL 线程读取 relay log 同步数据本地的时刻记为 T3。 +> **注意**：上述描述基于 MySQL 默认的**异步复制**模式。如果在 MySQL 5.7+ 开启了增强半同步复制（`rpl_semi_sync_master_wait_point=AFTER_SYNC`），主库在写入 binlog 后会等待至少一个从库接收并写入 relay log 才向客户端返回提交成功，这在一定程度上将 T2-T1 的网络传输时间算入了主库事务的响应时间中，从而牺牲写性能换取更高的数据安全性。 + 结合我们上面讲到的主从复制原理，可以得出： - T2 和 T1 的差值反映了从库 I/O 线程的性能和网络传输的效率，这个差值越小说明从库 I/O 线程的性能和网络传输效率越高。 @@ -140,12 +151,10 @@ MySQL 主从同步延时是指从库的数据落后于主库的数据，这种 3. **大事务**：运行时间比较长，长时间未提交的事务就可以称为大事务。由于大事务执行时间长，并且从库上的大事务会比主库上的大事务花费更多的时间和资源，因此非常容易造成主从延迟。解决办法是避免大批量修改数据，尽量分批进行。类似的情况还有执行时间较长的慢 SQL ，实际项目遇到慢 SQL 应该进行优化。 4. **从库太多**：主库需要将 binlog 同步到所有的从库，如果从库数量太多，会增加同步的时间和开销（也就是 T2-T1 的值会比较大，但这里是因为主库同步压力大导致的）。解决方案是减少从库的数量，或者将从库分为不同的层级，让上层的从库再同步给下层的从库，减少主库的压力。 5. **网络延迟**：如果主从之间的网络传输速度慢，或者出现丢包、抖动等问题，那么就会影响 binlog 的传输效率，导致从库延迟。解决方法是优化网络环境，比如提升带宽、降低延迟、增加稳定性等。 -6. **单线程复制**：MySQL5.5 及之前，只支持单线程复制。为了优化复制性能，MySQL 5.6 引入了 **多线程复制**，MySQL 5.7 还进一步完善了多线程复制。 +6. **单线程复制**：MySQL 5.5 及之前，只支持单线程复制。为了优化复制性能，MySQL 5.6 引入了 **多线程复制**，但仅支持按库并行（`slave_parallel_type=DATABASE`）。MySQL 5.7 进一步完善，支持按组提交并行（`slave_parallel_type=LOGICAL_CLOCK`），大幅提升并行效率。建议在从库配置 `slave_parallel_workers > 0` 启用并行复制。 7. **复制模式**：MySQL 默认的复制是异步的，必然会存在延迟问题。全同步复制不存在延迟问题，但性能太差了。半同步复制是一种折中方案，相对于异步复制，半同步复制提高了数据的安全性，减少了主从延迟（还是有一定程度的延迟）。MySQL 5.5 开始，MySQL 以插件的形式支持 **semi-sync 半同步复制**。并且，MySQL 5.7 引入了 **增强半同步复制** 。 8. …… -[《MySQL 实战 45 讲》](https://time.geekbang.org/column/intro/100020801?code=ieY8HeRSlDsFbuRtggbBQGxdTh-1jMASqEIeqzHAKrI%3D)这个专栏中的[读写分离有哪些坑？](https://time.geekbang.org/column/article/77636)这篇文章也有对主从延迟解决方案这一话题进行探讨，感兴趣的可以阅读学习一下。 - ## 分库分表 读写分离主要应对的是数据库读并发，没有解决数据库存储问题。试想一下：**如果 MySQL 一张表的数据量过大怎么办?** @@ -190,7 +199,7 @@ MySQL 主从同步延时是指从库的数据落后于主库的数据，这种 遇到下面几种场景可以考虑分库分表： -- 单表的数据达到千万级别以上，数据库读写速度比较缓慢。 +- 单表的数据量达到千万级别以上（具体阈值取决于表结构复杂度、索引数量、硬件配置等），数据库读写速度明显下降。 - 数据库中的数据占用的空间越来越大，备份时间越来越长。 - 应用的并发量太大（应该优先考虑其他性能优化方法，而非分库分表）。 @@ -206,11 +215,12 @@ MySQL 主从同步延时是指从库的数据落后于主库的数据，这种 - **哈希分片**：求指定分片键的哈希，然后根据哈希值确定数据应被放置在哪个表中。哈希分片比较适合随机读写的场景，不太适合经常需要范围查询的场景。哈希分片可以使每个表的数据分布相对均匀，但对动态伸缩（例如新增一个表或者库）不友好。 - **范围分片**：按照特定的范围区间（比如时间区间、ID 区间）来分配数据，比如 将 `id` 为 `1~299999` 的记录分到第一个表， `300000~599999` 的分到第二个表。范围分片适合需要经常进行范围查找且数据分布均匀的场景，不太适合随机读写的场景（数据未被分散，容易出现热点数据的问题）。 -- **映射表分片**：使用一个单独的表（称为映射表）来存储分片键和分片位置的对应关系。映射表分片策略可以支持任何类型的分片算法，如哈希分片、范围分片等。映射表分片策略是可以灵活地调整分片规则，不需要修改应用程序代码或重新分布数据。不过，这种方式需要维护额外的表，还增加了查询的开销和复杂度。 - **一致性哈希分片**：将哈希空间组织成一个环形结构，将分片键和节点（数据库或表）都映射到这个环上，然后根据顺时针的规则确定数据或请求应该分配到哪个节点上，解决了传统哈希对动态伸缩不友好的问题。 -- **地理位置分片**：很多 NewSQL 数据库都支持地理位置分片算法，也就是根据地理位置（如城市、地域）来分配数据。 -- **融合算法分片**：灵活组合多种分片算法，比如将哈希分片和范围分片组合。 -- …… + +在上述基础算法之上，还可以结合业务衍生出更复杂的路由策略： + +- **映射表路由**：维护一张独立的路由表来记录分片键与数据节点的映射关系，极其灵活但存在单点性能瓶颈。 +- **地域路由**：以地理位置作为分片键，结合范围或映射表机制，将数据就近存放在特定机房（常用于 NewSQL 多活架构）。 ### 分片键如何选择？ @@ -233,6 +243,7 @@ MySQL 主从同步延时是指从库的数据落后于主库的数据，这种 - **事务问题**：同一个数据库中的表分布在了不同的数据库中，如果单个操作涉及到多个数据库，那么数据库自带的事务就无法满足我们的要求了。这个时候，我们就需要引入分布式事务了。关于分布式事务常见解决方案总结，网站上也有对应的总结： 。 - **分布式 ID**：分库之后， 数据遍布在不同服务器上的数据库，数据库的自增主键已经没办法满足生成的主键唯一了。我们如何为不同的数据节点生成全局唯一主键呢？这个时候，我们就需要为我们的系统引入分布式 ID 了。关于分布式 ID 的详细介绍&实现方案总结，可以看我写的这篇文章：[分布式 ID 介绍&实现方案总结](https://javaguide.cn/distributed-system/distributed-id.html)。 - **跨库聚合查询问题**：分库分表会导致常规聚合查询操作，如 group by，order by 等变得异常复杂。这是因为这些操作需要在多个分片上进行数据汇总和排序，而不是在单个数据库上进行。为了实现这些操作，需要编写复杂的业务代码，或者使用中间件来协调分片间的通信和数据传输。这样会增加开发和维护的成本，以及影响查询的性能和可扩展性。 +- **动态扩缩容困难（Resharding）**：尤其是采用传统 Hash 取模算法时，一旦现有分片容量打满需要增加新节点，会导致绝大多数数据的 Hash 映射失效，引发极其痛苦的全量数据洗牌与迁移。解决方案包括：预分足够的分片（如 1024 个逻辑分表）、采用一致性哈希、或使用支持自动 Rebalance 的分布式数据库（如 TiDB）。 - …… 另外，引入分库分表之后，一般需要 DBA 的参与，同时还需要更多的数据库服务器，这些都属于成本。 @@ -271,10 +282,18 @@ ShardingSphere 的优势如下（摘自 ShardingSphere 官方文档： **⚠️注意**： +> +> - 双写应尽量保证原子性：可以先写老库成功后再异步写新库，若新库写入失败则记录日志待重试； +> - 数据比对应在业务低峰期进行，避免比对期间新写入导致的数据不一致； +> - 建议借助 Canal 等工具监听 binlog 实现增量同步，降低双写的开发和维护成本。 +> +> **双写并发问题如何解决？** 在存量数据迁移和增量双写并行的阶段，极易发生旧数据覆盖新数据的并发问题。必须在新库表中引入 `update_time` 或 `version` 字段，无论是双写还是脚本补齐，写入新库前必须带上条件 `WHERE new_version < old_version`（乐观锁校验），确保只有较新的数据才能写入。 + 想要在项目中实施双写还是比较麻烦的，很容易会出现问题。我们可以借助上面提到的数据库同步工具 Canal 做增量数据迁移（还是依赖 binlog，开发和维护成本较低）。 ## 总结 diff --git a/docs/high-performance/sql-optimization.md b/docs/high-performance/sql-optimization.md index 706e9034864..872ff5443f9 100644 --- a/docs/high-performance/sql-optimization.md +++ b/docs/high-performance/sql-optimization.md @@ -8,6 +8,8 @@ head: content: SQL优化,慢SQL,EXPLAIN执行计划,索引优化,MySQL优化,查询优化,分页优化,Show Profile --- + + ## 避免使用 SELECT \* - `SELECT *` 会消耗更多的 CPU。 @@ -47,12 +49,12 @@ join 的效率比较低，主要原因是因为其使用嵌套循环（Nested Lo 本文介绍了四种常见的深度分页优化方案，各方案的特点及适用场景对比如下： -| 优化方案 | 核心思路 | 适用场景 | 限制 | -| ------------ | ------------------------------------------------------------------- | ----------------------------------- | ------------------------------------------------ | -| **范围查询** | 记录上一页最后一条 ID，通过 `WHERE id > last_id LIMIT n` 获取下一页 | ID 连续、按 ID 排序、允许游标式翻页 | 不支持跳页、ID 不连续时失效、非 ID 排序不适用 | -| **子查询** | 先通过子查询获取起始主键，再根据主键过滤 | 需要支持传统 OFFSET 翻页 | 子查询可能产生临时表、仅适用于 ID 正序 | -| **延迟关联** | 用 `INNER JOIN` 将分页转移到主键索引，减少回表 | 大数据量分页、需要传统翻页逻辑 | SQL 相对复杂 | -| **覆盖索引** | 建立包含查询字段的联合索引，避免回表 | 查询字段固定、可建立合适索引 | 字段较多时索引维护成本高、大结果集可能走全表扫描 | +| 优化方案 | 核心思路 | 适用场景 | 限制 | +| ------------ | ------------------------------------------------------------------- | ------------------------------ | ------------------------------------------------ | +| **范围查询** | 记录上一页最后一条 ID，通过 `WHERE id > last_id LIMIT n` 获取下一页 | 按 ID 排序、允许游标式翻页 | 不支持跳页、非 ID 排序需使用联合游标 | +| **子查询** | 先通过子查询获取起始主键，再根据主键过滤 | 需要支持传统 OFFSET 翻页 | 子查询可能产生临时表、依赖排序字段的索引 | +| **延迟关联** | 用 `INNER JOIN` 将分页转移到主键索引，减少回表 | 大数据量分页、需要传统翻页逻辑 | SQL 相对复杂 | +| **覆盖索引** | 建立包含查询字段的联合索引，避免回表 | 查询字段固定、可建立合适索引 | 字段较多时索引维护成本高、大结果集可能走全表扫描 | **方案选择建议**： @@ -107,6 +109,8 @@ UNSIGNED INT 0~4294967295 这三种种方式都有各自的优势，根据实际场景选择最合适的才是王道。下面再对这三种方式做一个简单的对比，以供大家实际开发中选择正确的存放时间的数据类型： +> **注意**：以下存储空间基于 MySQL 5.6.4+（支持微秒精度）。5.6.4 之前，DATETIME 固定 8 字节，TIMESTAMP 固定 4 字节。小数秒精度每增加 1 位，额外占用 1 字节（最多 5 字节）。 + | 类型 | 存储空间 | 日期格式 | 日期范围 | 是否带时区信息 | | ------------ | -------- | ------------------------------ | ------------------------------------------------------------ | -------------- | | DATETIME | 5~8 字节 | YYYY-MM-DD hh:mm:ss[.fraction] | 1000-01-01 00:00:00[.000000] ～ 9999-12-31 23:59:59[.999999] | 否 | @@ -125,9 +129,9 @@ decimal 用于存储有精度要求的小数比如与金钱相关的数据，可 **f.尽量使用自增 id 作为主键。** -如果主键为自增 id 的话，每次都会将数据加在 B+树尾部（本质是双向链表），时间复杂度为 O(1)。在写满一个数据页的时候，直接申请另一个新数据页接着写就可以了。 +如果主键为自增 id 的话，新数据会追加到 B+ 树的尾部，避免了中间位置的页分裂，性能相对最优。在写满一个数据页的时候，直接申请另一个新数据页接着写就可以了。 -如果主键是非自增 id 的话，为了让新加入数据后 B+树的叶子节点还能保持有序，它就需要往叶子结点的中间找，查找过程的时间复杂度是 O(lgn)。如果这个也被写满的话，就需要进行页分裂。页分裂操作需要加悲观锁，性能非常低。 +如果主键是非自增 id 的话，为了让新加入数据后 B+ 树的叶子节点还能保持有序，它就需要往叶子结点的中间找位置插入。如果目标页已满，就需要进行**页分裂**——将页一分为二，移动一半数据到新页。页分裂操作需要加悲观锁，涉及大量数据移动，性能较差。 不过， 像分库分表这类场景就不建议使用自增 id 作为主键，应该使用分布式 ID 比如 uuid 。 @@ -181,6 +185,22 @@ MySQL 在 5.0.37 版本之后才支持 Profiling，`select @@have_profiling` 命 ``` > **注意** ：`SHOW PROFILE` 和 `SHOW PROFILES` 已经被弃用，未来的 MySQL 版本中可能会被删除，取而代之的是使用 [Performance Schema](https://dev.mysql.com/doc/refman/8.0/en/performance-schema.html)。在该功能被删除之前，我们简单介绍一下其基本使用方法。 +> +> **推荐替代方案**：MySQL 5.7+ 推荐使用 Performance Schema 的 `events_statements_history_long` 表： +> +> ```sql +> -- 查询最近执行的 SQL 及其耗时 +> SELECT +> EVENT_ID, +> SQL_TEXT, +> TIMER_WAIT/1000000000 AS 'Duration (ms)', +> CPU_USER +> FROM performance_schema.events_statements_history_long +> ORDER BY TIMER_WAIT DESC +> LIMIT 10; +> ``` +> +> 此外，MySQL 8.0.18+ 还支持 `EXPLAIN ANALYZE`，可以直接输出 SQL 的实际执行时间和行数统计。 想要使用 Profiling，请确保你的 `profiling` 是开启（on）的状态。 @@ -328,11 +348,11 @@ mysql> EXPLAIN SELECT `score`,`name` FROM `cus_order` ORDER BY `score` DESC; - `select_type` ：查询的类型，常用的取值有 SIMPLE（普通查询，即没有联合查询、子查询）、PRIMARY（主查询）、UNION（UNION 中后面的查询）、SUBQUERY（子查询）等。 - `table` ：表示查询涉及的表或衍生表。 -- `type` ：执行方式，判断查询是否高效的重要参考指标，结果值从差到好依次是：ALL < index < range ~ index_merge < ref < eq_ref < const < system。 +- `type` ：执行方式，判断查询是否高效的重要参考指标，结果值从差到好依次是：**ALL**（全表扫描）< **index**（索引全扫描）< **range**（索引范围扫描）< **index_merge**（索引合并）< **ref**（非唯一索引查找）< **eq_ref**（唯一索引查找）< **const**（单行常量）< **system**（系统表）。实际性能还需结合 rows、Extra 等字段综合判断。 - `rows` : SQL 要查找到结果集需要扫描读取的数据行数，原则上 rows 越少越好。 - …… -关于 Explain 的详细介绍，请看这篇文章：[MySQL 执行计划分析](https://javaguide.cn/database/mysql/mysql-query-execution-plan.html)。另外，再推荐一下阿里的这篇文章：[慢 SQL 治理经验总结](https://mp.weixin.qq.com/s/LZRSQJufGRpRw6u4h_Uyww)，总结的挺不错。 +> **推荐阅读**：[MySQL 执行计划分析](https://javaguide.cn/database/mysql/mysql-query-execution-plan.html) 详细介绍了 EXPLAIN 各列的含义（id、select_type、type、key、rows、Extra 等），包括 MySQL 8.0.18+ 新增的 `EXPLAIN ANALYZE` 实际执行分析功能。另外，阿里的 [慢 SQL 治理经验总结](https://mp.weixin.qq.com/s/LZRSQJufGRpRw6u4h_Uyww) 也总结得不错。 ## 正确使用索引 @@ -348,105 +368,27 @@ mysql> EXPLAIN SELECT `score`,`name` FROM `cus_order` ORDER BY `score` DESC; ### 避免索引失效 -索引失效也是慢查询的主要原因之一，常见的导致索引失效的情况有下面这些： - -**`SELECT *` 查询（成本权衡）** - -- `SELECT *` **不会直接导致索引失效**。如果 `WHERE` 条件符合索引规则，索引依然会被使用。 -- 它会导致**回表成本增加**。如果查询需要的字段不在索引中（非覆盖索引），数据库需要拿着主键回聚簇索引查数据。当数据量较大时，优化器会对比“索引查找 + 回表”与“直接全表扫描”的成本，若前者成本过高，优化器会**主动放弃索引**选择全表扫描。 -- `SELECT *` 还会网络传输和数据处理的浪费。尽量只查询需要的字段，利用**覆盖索引**减少回表。 - -**违背最左前缀原则** - -- 最左前缀匹配原则指的是在使用联合索引时，MySQL 会根据索引中的字段顺序，从左到右依次匹配查询条件中的字段。如果查询条件与索引中的最左侧字段相匹配，那么 MySQL 就会使用索引来过滤数据，这样可以提高查询效率。 -- 最左匹配原则会一直向右匹配，直到遇到范围查询（如 >、<）为止。对于 >=、<=、BETWEEN 以及前缀匹配 LIKE 的范围查询，不会停止匹配。 -- MySQL 8.0.13 版本引入了索引跳跃扫描（Index Skip Scan，简称 ISS），它可以在某些索引查询场景下提高查询效率。在没有 ISS 之前，不满足最左前缀匹配原则的联合索引查询中会执行全表扫描。而 ISS 允许 MySQL 在某些情况下避免全表扫描，即使查询条件不符合最左前缀。不过，这个功能比较鸡肋， 和 Oracle 中的没法比，MySQL 8.0.31 还报告了一个 bug：[Bug #109145 Using index for skip scan cause incorrect result](https://bugs.mysql.com/bug.php?id=109145)（后续版本已经修复）。个人建议知道有这个东西就好，不需要深究，实际项目也不一定能用上。 - -失效示例： - -```sql --- 索引：(sname, s_code, address) -WHERE s_code = 1; -- 跳过最左列 sname，失效 -WHERE sname = 'A' AND address = 'Shanghai'; -- 跳过中间列 s_code，仅 sname 走索引 -WHERE sname = 'A' AND s_code > 1 AND address = 'Shanghai'; -- 范围查询后，address 失效 -``` - -**在索引列上进行计算、函数或类型转换** - -- 索引存储的是字段的**原始值**。对字段进行操作后，数据库无法利用索引树的有序性，只能全表扫描后计算。 -- MySQL 8.0 支持**函数索引**，可针对计算后的值建索引，但使用场景有限，首选还是优化 SQL 写法。 - -失效示例： - -```sql -WHERE height + 1 = 170; -- 对索引列进行计算 -WHERE DATE(create_time) = '2022-01-01'; -- 对索引列使用函数 -``` - -优化建议： - -```sql -WHERE height = 169; -- 将计算移到等号右边 -WHERE create_time BETWEEN '2022-01-01 00:00:00' AND '2022-01-01 23:59:59'; -``` - -**`LIKE` 模糊查询以通配符开头** - -- `LIKE` 查询必须以具体字符开头才能利用索引有序性，例如 `WHERE sname LIKE 'Guide%'; `。 -- 这是因为B+ 树是从左到右排序的。前缀通配符（`%`）破坏了有序性，无法定位起始点。 - -失效示例： - -```sql -WHERE sname LIKE '%Guide'; -- 前缀模糊，全表扫描 -WHERE sname LIKE '%Guide%'; -- 前后模糊，全表扫描 -``` - -**`OR` 连接条件使用不当** - -- 如果 `OR` 两边的列中**有一列没有索引**，通常会导致整个查询放弃索引，走全表扫描。 -- 确保 `OR` 两边的列都建有索引，或改写为 `UNION ALL`。 - -失效示例： - -```sql --- 假设 sname 有索引，address 无索引 -WHERE sname = '学生 1' OR address = '上海'; -- 索引失效，全表扫描 -``` - -**`N` / `NOT IN` 使用不当** - -- **`IN`**：当 `IN` 列表中的值太多（通常超过 200 个，由 `eq_range_index_dive_limit` 参数决定）或查询范围覆盖了太多行，会导致索引失效。 -- **`NOT IN`**：在大多数情况下会引发全表扫描，因为它需要证明“不属于”某个集合，这在 B+ 树中通常需要遍历所有叶子节点。 - -失效示例： - -```sql -WHERE s_code IN (1, 2, 3 ... 500); -- 列表过长可能失效 -WHERE s_code NOT IN (1, 2, 3); -- 通常失效 -``` - -**隐式类型转换** +索引失效也是慢查询的主要原因之一，常见的导致索引失效的情况有下面这两类： -这是开发中最隐蔽的坑，转换的方向决定了索引的生死。 +**1. SQL 写法与底层逻辑冲突（破坏 B+Tree 有序性）** -- 字段类型为字符串，查询条件未加引号（如 `varchar` 字段查 `WHERE col = 123`）；或字段类型为数字，查询条件加了引号且字符集不匹配。 -- MySQL 会自动进行类型转换，导致索引列值发生变化，无法匹配索引树。 -- 详细介绍：[MySQL隐式转换造成索引失效](https://javaguide.cn/database/mysql/index-invalidation-caused-by-implicit-conversion.html) 。 +此类问题最为常见，本质是查询条件让底层的 B+Tree 失去了“二分查找”的快速定位能力。 -**`ORDER BY` 排序优化陷阱** +- **违背最左前缀原则**：跳过联合索引前导列，或遇到范围查询（如 `>`、`<`、`BETWEEN`、`LIKE "abc%"`）导致后续列中断精确定位，降级为范围扫描加过滤。 +- **对索引列进行加工**：在 `WHERE` 左侧对索引列进行数学计算或应用函数，导致原始数据发生逻辑改变，在索引树中呈现无序状态。 +- **隐式类型转换（隐蔽且致命）**：当“字符串类型的列”去比较“数字类型的值”时，MySQL 会默认在列上套用转换函数，直接破坏树的有序性。 +- **LIKE 模糊查询前置通配符**：如 `LIKE "%abc"`，前缀字符的不确定性使得优化器无法锁定扫描区间的起始点。 +- **ORDER BY 排序陷阱**：排序列未命中索引、排序方向与索引结构不一致等触发额外的内存或磁盘排序（`Using filesort`）。 -即使 `WHERE` 条件精准，如果 `ORDER BY` 处理不好，依然会出现慢查询。 +**2. 优化器的成本决策（基于 I/O 成本妥协）** -- 如果查询走了索引 A，但排序要求字段 B，或者需要回表的数据量太大导致优化器放弃索引排序，就会触发 `Using filesort`（内存/磁盘排序）。 -- 利用**覆盖索引**同时满足 `WHERE` 和 `ORDER BY`。例如索引为 `(name, age)`，查询 `SELECT name, age FROM users WHERE name = 'A' ORDER BY age` 是极其高效的。 +此类问题并非索引本身不可用，而是 MySQL 优化器经过计算后，认为“不走普通索引”整体开销反而更小。 -**最后，总结一个口诀** +- **无脑 `SELECT \*` 导致回表成本超载**：查询大量非索引覆盖列时，若命中数据量较大（通常超 20%~30%），优化器会判定全表扫描的顺序 I/O 优于频繁回表的随机 I/O，从而主动放弃索引。 +- **`OR` 条件导致全表扫描**：只要 `OR` 连接的任意一侧条件没有对应索引，就会触发全表扫描。即使两侧都有索引，若 Index Merge（索引合并）的预期成本过高，依然会被放弃。 +- **`IN` 列表过长引发估算失真**：当 `IN` 列表长度超过系统阈值（默认 200）时，优化器会从精准的深入探测（Index Dive）切换为粗略的统计估算，极易因统计信息陈旧而产生执行成本的误判。 -- 全值匹配我最爱，最左前缀不能改。 -- 范围之后全失效，函数计算索引败。 -- 模糊首位莫加百分号，类型转换要避开。 -- OR 连接需谨慎，覆盖索引避回表。 +详细介绍：[MySQL索引失效场景总结](https://javaguide.cn/database/mysql/mysql-index-invalidation.html)。 ### 被频繁更新的字段应该慎重建立索引 diff --git a/docs/home.md b/docs/home.md index cbeacdde3c8..aea56773889 100644 --- a/docs/home.md +++ b/docs/home.md @@ -16,12 +16,23 @@ head: - **面试资料补充**： - [《Java 面试指北》](https://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html)：四年打磨，和 JavaGuide 开源版的内容互补，带你从零开始系统准备后端面试！ - [《后端面试高频系统设计&场景题》](https://javaguide.cn/zhuanlan/back-end-interview-high-frequency-system-design-and-scenario-questions.html)：30+ 道高频系统设计和场景面试，助你应对当下中大厂面试趋势。 -- **使用建议** ：有水平的面试官都是顺着项目经历挖掘技术问题。一定不要死记硬背技术八股文！详细的学习建议请参考：[JavaGuide 使用建议](https://javaguide.cn/javaguide/use-suggestion.html)。 +- **使用建议** ：如果你想要系统准备 Java 后端面试但又不知道如何开始的，可以参考 [Java 后端面试通关计划（后端通用）](https://javaguide.cn/interview-preparation/backend-interview-plan.html)。 - **求个 Star**：如果觉得 JavaGuide 的内容对你有帮助的话，还请点个免费的 Star，这是对我最大的鼓励，感谢各位一起同行，共勉！传送门：[GitHub](https://github.com/Snailclimb/JavaGuide) | [Gitee](https://gitee.com/SnailClimb/JavaGuide)。 - **转载须知**：以下所有文章如非文首说明为转载皆为 JavaGuide 原创，转载请在文首注明出处。如发现恶意抄袭/搬运，会动用法律武器维护自己的权益。让我们一起维护一个良好的技术创作环境！ ::: +## 面试准备 + +- [⭐Java 后端面试通关计划（涵盖后端通用体系）](./interview-preparation/backend-interview-plan.md) (一定要看 :+1:) +- [如何高效准备 Java 面试？](./interview-preparation/teach-you-how-to-prepare-for-the-interview-hand-in-hand.md) +- [Java 后端面试重点总结](./interview-preparation/key-points-of-interview.md) +- [Java 学习路线（最新版，4w+ 字）](./interview-preparation/java-roadmap.md) +- [程序员简历编写指南](./interview-preparation/resume-guide.md) +- [项目经验指南](./interview-preparation/project-experience-guide.md) +- [面试太紧张怎么办？](./interview-preparation/how-to-handle-interview-nerves.md) +- [校招没有实习经历怎么办？实习经历怎么写？](./interview-preparation/internship-experience.md) + ## Java ### 基础 @@ -206,6 +217,7 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8](https://docs.oracle. **重要知识点：** - [MySQL 索引详解](./database/mysql/mysql-index.md) +- [MySQL 索引失效场景总结](./database/mysql/mysql-index-invalidation.md) - [MySQL 事务隔离级别图文详解)](./database/mysql/transaction-isolation-level.md) - [MySQL 三大日志(binlog、redo log 和 undo log)详解](./database/mysql/mysql-logs.md) - [InnoDB 存储引擎对 MVCC 的实现](./database/mysql/innodb-implementation-of-mvcc.md) @@ -328,11 +340,14 @@ JVM 这部分内容主要参考 [JVM 虚拟机规范-Java8](https://docs.oracle. ## 分布式 +- [⭐分布式高频面试题](https://interview.javaguide.cn/distributed-system/distributed-system.html) + ### 理论&算法&协议 - [CAP 理论和 BASE 理论解读](./distributed-system/protocol/cap-and-base-theorem.md) - [Paxos 算法解读](./distributed-system/protocol/paxos-algorithm.md) - [Raft 算法解读](./distributed-system/protocol/raft-algorithm.md) +- [ZAB 协议解读](./distributed-system/protocol/zab.md) - [Gossip 协议详解](./distributed-system/protocol/gossip-protocol.md) - [一致性哈希算法详解](./distributed-system/protocol/consistent-hashing.md) diff --git a/docs/interview-preparation/backend-interview-plan.md b/docs/interview-preparation/backend-interview-plan.md new file mode 100644 index 00000000000..ce6f21cdda8 --- /dev/null +++ b/docs/interview-preparation/backend-interview-plan.md @@ -0,0 +1,212 @@ +--- +title: Java 后端面试通关计划（涵盖后端通用体系） +description: Java 后端面试通关计划：严格按照面试考察真实优先级编排，涵盖项目经历、Java核心、MySQL/Redis、框架、系统设计、计算机基础、分布式与JVM，适合校招/社招准备。 +category: 面试准备 +icon: star +head: + - - meta + - name: keywords + content: Java后端面试,面试准备计划,面试指南,八股文,校招,社招,项目经验,Java面试 +--- + +本计划严格按照面试考察的**真实优先级**进行编排，顺序为： +**「 项目经历与简历深挖 → Java核心/MySQL/Redis → 框架应用 → 系统设计与场景题 → 计算机基础 → 分布式/高并发 → JVM」** + +每一阶段都对应了本站具体的精选文章，方便你按图索骥，逐个击破。 + +- **建议总周期**：4～8 周（请根据目标公司是中小厂还是大厂，以及自身的脱产时间灵活压缩或拉长）。 +- **适用人群**：准备秋招/春招的计算机专业学生，以及 0-5 年经验准备跳槽的 Java 开发者。 +- **面试突击**：下文中推荐的技术文章以 [JavaGuide](https://javaguide.cn/) 为主，非常全面且详细，如果突击面试，可以选择阅读 [JavaGuide 面试突击版](https://interview.javaguide.cn/) 中对应的文章。 + +### 计划总览 + +| 阶段 | 建议时长 | 核心产出 | 自测标准 | +| ---------------------------------- | --------------------- | ---------------------------------------------- | ----------------------------------------------------------------------------- | +| **第 0 步** 前期准备 | 1～2 天 | 简历定稿、复习节奏、心态准备 | 任选一项目，30 秒内讲清业务+你的角色，不卡壳、有重点 | +| **第一阶段** 项目与简历深挖 | 约 1 周 | 项目卡片、必会题清单、1/3 分钟话术稿 | 脱稿讲清每项目背景+难点+你的贡献；必会题清单随机抽 3 题能答出要点 | +| **第二阶段** Java + MySQL + Redis | 2～3 周 | 八股理解与关键词记忆（基础+集合+并发+库） | 本站文章随机抽题，能用自己的话讲清原理与关键词，不依赖逐字背 | +| **第三阶段** 框架 | 1～2 周 | Spring/IoC/AOP/事务、设计模式、权限与安全 | 能说清项目对框架的使用、吃透IoC 和 AOP、事务失效场景等等 | +| **系统设计与场景题**（接在框架后） | 按需 0.5～1 周 | 系统设计题与场景题思路（短链/秒杀/海量数据等） | 无提示口述经典设计（如短链/秒杀）的整体流程与关键取舍（存储、限流、一致性等） | +| **第四阶段** 计算机基础 | 按需 0.5～2 周 | 计网、OS、数据结构；面中大厂等加算法 | 能手写常见算法/手写题；本站文章随机抽题能答出核心机制 | +| **第五阶段** 分布式与高并发 | 按需 1～2 周 | 分布式理论、RPC、MQ、高可用 | 能讲清项目里用到的分布式方案（锁/ID/MQ 等）及选型理由 | +| **第六阶段** JVM | 大厂/部分中厂 3～5 天 | 内存、GC、类加载、调优与排查 | 能说清内存区域、GC 过程、类加载；能口述一次 GC 调优或 OOM 排查思路 | +| **面试前冲刺** | 1～2 天 | 必会题过一遍、项目话术再练、心态与设备 | 必会题清单过一遍能复述要点；每项目 1 分钟版话术练一遍不卡壳 | + +**📌 阶段调整说明：** + +- 标「按需」的阶段可根据目标公司调整：面字节、快手、腾讯等**重算法厂**，请务必加强第四阶段（算法与数据结构）； +- 如果你的简历或应聘岗位明确涉及**分布式/微服务**，请系统性死磕第五阶段； +- 如果目标是阿里、美团、京东等**大厂核心部门**，请重点攻克第六阶段（JVM 底层与线上排查）。 + +### 第 0 步：前期准备（建议 1～2 天） + +在系统刷八股前，先把「怎么准备、怎么写简历、怎么稳住心态」搞定，避免方向跑偏。 + +| 事项 | 说明 | 对应文章 | +| ---------- | --------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 准备方法 | 明确复习节奏、自测方式、时间分配 | [如何高效准备 Java 面试？](https://javaguide.cn/interview-preparation/teach-you-how-to-prepare-for-the-interview-hand-in-hand.html)
[Java后端面试重点总结](https://javaguide.cn/interview-preparation/key-points-of-interview.html) | +| 简历 | 一到两页纸、项目 STAR、技术栈与岗位匹配 | [程序员简历编写指南](https://javaguide.cn/interview-preparation/resume-guide.html) | +| 学习路线 | 查漏补缺，确定自己当前所处阶段 | [Java 学习路线（最新版，4w+ 字）](https://javaguide.cn/interview-preparation/java-roadmap.html) | +| 项目与经历 | 没有项目/实习时如何包装、怎么讲 | [项目经验指南](https://javaguide.cn/interview-preparation/project-experience-guide.html)
[校招没有实习经历怎么办？实习经历怎么写？](https://javaguide.cn/interview-preparation/internship-experience.html) | +| 心态 | 减少紧张、发挥更稳 | [面试太紧张怎么办？](https://javaguide.cn/interview-preparation/how-to-handle-interview-nerves.html) | + +**核心要点**： + +- **技术好≠面试能过**，必须系统准备——尽早以求职为导向学习，根据招聘要求制定技能清单。 +- **掌握投递简历的黄金时间**：秋招 7-9 月，春招 3-4 月；多渠道获取招聘信息（官网、招聘网站、牛客网、内推等）。 +- **花 2-3 天完善简历**，重视项目经历描述；**校招简历不超过 2 页，社招不超过 3 页**。一定要把包装润色，但也要避免简历夸大事实，面试时易被深挖暴露。 +- **八股文很有意义**，日常开发也会用到；不要抱侥幸心理，打铁还需自身硬。 +- **提前准备 1-2 分钟自我介绍话术**，能流畅讲出个人背景、技术栈和求职意向。 +- **多多自测**，可以用 AI 辅助模拟面试，找同学朋友互相模拟面试。 + +### 第一阶段：项目与简历深挖（约 1 周） + +**目标**：能清晰讲出每个项目的背景、你的角色、技术选型与难点，并能推导出「可能被问的面试题」。 + +**产出物**： + +- **项目卡片**：按简历逐条过项目，为每个项目写清——业务背景、技术栈、你负责的模块、1～2 个难点与解决方式、可量化的成果（如 QPS、耗时、节省成本）。 +- **必会题清单**：根据项目用到的技术，列出「必会题」（例如：用了 Redis 缓存→ Redis 常见数据结构、持久化机制、线程模型等；用了 MySQL → 索引、事务、慢 SQL 优化等）。可参考 [JavaGuide](https://javaguide.cn/) 网站中的面试题总结按项目拓展。 +- **话术稿**：每个项目准备 1～2 分钟版本（自我介绍用）和 3～5 分钟版本（深挖用），能流畅讲出「为什么这么选、遇到什么问题、怎么解决的」。 + +**每日建议**：每天至少梳理 1 个项目 + 对应必会题，周末做一次脱稿自测（录音或对着镜子讲）。 + +**自测**：能脱稿讲清每个项目的背景、难点和你的贡献；必会题清单里的题能答出要点，对于大厂面试要能抗住深挖，做到举一反三。 + +**没有项目经验怎么办？** + +1. **实战项目视频/专栏**：慕课网、哔哩哔哩、拉勾、极客时间等；选择适合自己能力的项目，不必强求微服务项目。[JavaGuide 官方知识星球](https://javaguide.cn/about-the-author/zhishixingqiu-two-years.html)已经推出[⭐AI 智能面试辅助平台 + RAG 知识库](https://javaguide.cn/zhuanlan/interview-guide.html)和[手写 RPC 框架](https://javaguide.cn/zhuanlan/handwritten-rpc-framework.html)。并且，还分享了很多高频项目经历（如博客、外卖、线程池、短连接）的优化版介绍和面试准备。 +2. **实战类开源项目**：JavaGuide 推荐的[优质开源实战项目](https://javaguide.cn/open-source-project/practical-project.html)；在理解基础上改进或增加功能。 +3. **参加大公司组织的比赛**：阿里云天池大赛等；获奖项目含金量高。 + +**项目经历写作要点（STAR 法则）**： + +- **Situation（情景）**：项目背景是什么？要解决什么问题？ +- **Task（任务）**：你在项目中负责什么？你的角色是什么？ +- **Action（行动）**：你具体做了什么？用了什么技术？遇到了什么问题？如何解决的？ +- **Result（结果）**：取得了什么成果？最好量化（QPS 从 xxx 提高到 xxx，响应时间降低 xx%） + +**项目介绍高频问题**： + +- 技术架构直接写技术名词，不需要解释。 +- 减少纯业务描述，多挖掘技术亮点，结合具体业务场景描述。 +- 优化成果要量化（QPS、响应时间、成本节省等），非真实项目包装合理数值即可。 +- 工作内容介绍控制在 6~8 条左右比较好，多了少了都有影响，一定要至少有 3-4 条是有技术亮点的，能吸引到面试官。 +- 避免模糊性描述（如"负责开发"），要具体（技术+场景+效果）。 +- 一定要包装项目，但也不要过度包装，准备时多想“如果面试官问为什么”，确保逻辑自洽。 + +### 第二阶段：Java 核心 + MySQL + Redis （约 2～3 周） + +**优先级**：最重要的部分，面试高频考点，MySQL + Redis ≥ Java 基础/集合/并发 > 框架知识，大厂会深挖并发与底层。 + +**Java 基础** + +- [Java 基础常见面试题总结（上）](https://javaguide.cn/java/basis/java-basic-questions-01.html)、[（中）](https://javaguide.cn/java/basis/java-basic-questions-02.html)、[（下）](https://javaguide.cn/java/basis/java-basic-questions-03.html)：语法与面向对象、字符串与拷贝、异常/泛型/反射/SPI/序列化/注解 + +**Java 集合** + +- [Java 集合常见面试题（上）](https://javaguide.cn/java/collection/java-collection-questions-01.html)、[（下）](https://javaguide.cn/java/collection/java-collection-questions-02.html)：List/Set/Queue、HashMap、ConcurrentHashMap + +**Java 并发**（大厂必深挖） + +- [Java 并发常见面试题（上）](https://javaguide.cn/java/concurrent/java-concurrent-questions-01.html)、[（中）](https://javaguide.cn/java/concurrent/java-concurrent-questions-02.html)、[（下）](https://javaguide.cn/java/concurrent/java-concurrent-questions-03.html)：线程与锁、synchronized/ReentrantLock、ThreadLocal/线程池/Future/AQS/虚拟线程 +- [JMM](https://javaguide.cn/java/concurrent/jmm.html)、[线程池详解](https://javaguide.cn/java/concurrent/java-thread-pool-summary.html)与[最佳实践](https://javaguide.cn/java/concurrent/java-thread-pool-best-practices.html) +- [ThreadLocal](https://javaguide.cn/java/concurrent/threadlocal.html)、[AQS](https://javaguide.cn/java/concurrent/aqs.html)、[CompletableFuture](https://javaguide.cn/java/concurrent/completablefuture-intro.html)、[常见并发容器](https://javaguide.cn/java/concurrent/java-concurrent-collections.html) + +**MySQL**（必看） + +- [MySQL 常见面试题总结](https://javaguide.cn/database/mysql/mysql-questions-01.html)（基础、引擎、事务、索引、锁、优化） +- [MySQL 索引详解](https://javaguide.cn/database/mysql/mysql-index.html)、[三大日志](https://javaguide.cn/database/mysql/mysql-logs.html)、[事务隔离级别](https://javaguide.cn/database/mysql/transaction-isolation-level.html) +- [InnoDB 对 MVCC 的实现](https://javaguide.cn/database/mysql/innodb-implementation-of-mvcc.html)、[SQL 执行过程](https://javaguide.cn/database/mysql/how-sql-executed-in-mysql.html) + +**Redis**（必看） + +- [Redis 常见面试题总结（上）](https://javaguide.cn/database/redis/redis-questions-01.html)、[Redis 常见面试题总结（下）](https://javaguide.cn/database/redis/redis-questions-02.html) +- [Redis 延时任务](https://javaguide.cn/database/redis/redis-delayed-task.html)、[Redis 做消息队列](https://javaguide.cn/database/redis/redis-stream-mq.html) +- [5 种基本数据类型](https://javaguide.cn/database/redis/redis-data-structures-01.html)、[3 种特殊类型](https://javaguide.cn/database/redis/redis-data-structures-02.html)、[跳表实现有序集合](https://javaguide.cn/database/redis/redis-skiplist.html) +- [持久化](https://javaguide.cn/database/redis/redis-persistence.html)、[内存碎片](https://javaguide.cn/database/redis/redis-memory-fragmentation.html)、[常见阻塞原因](https://javaguide.cn/database/redis/redis-common-blocking-problems-summary.html) + +**自测**：随机抽题，能用自己的话讲出来，不死记硬背，理解记忆，重点记关键词。尤其是要重点测试 MySQL 和 Redis 部分，面试考察重点中的重点。 + +### 第三阶段：框架和系统设计（约 1～3 周） + +#### 设计模式 + +- [设计模式常见面试题总结](https://interview.javaguide.cn/system-design/design-pattern.html) + +**自测**：掌握单例模式至少两种常见写法；代理模式、责任链模式、策略模式一定要搞懂，最好能够结合你的项目经历或者开源框架中的运用讲出来。 + +#### 框架 + +**Spring / Spring Boot** + +- [Spring 常见面试题](https://javaguide.cn/system-design/framework/spring/spring-knowledge-and-questions-summary.html)、[SpringBoot 常见面试题](https://javaguide.cn/system-design/framework/spring/springboot-knowledge-and-questions-summary.html) +- [常用注解](https://javaguide.cn/system-design/framework/spring/spring-common-annotations.html)、[IoC 与 AOP](https://javaguide.cn/system-design/framework/spring/ioc-and-aop.html)、[Spring 事务](https://javaguide.cn/system-design/framework/spring/spring-transaction.html) +- [Spring 中的设计模式](https://javaguide.cn/system-design/framework/spring/spring-design-patterns-summary.html)、[SpringBoot 自动装配](https://javaguide.cn/system-design/framework/spring/spring-boot-auto-assembly-principles.html)、[Async 原理](https://javaguide.cn/system-design/framework/spring/async.html)（原理性知识，时间不够可跳过） +- [MyBatis 常见面试题](https://javaguide.cn/system-design/framework/mybatis/mybatis-interview.html)（不重要，可跳过，考查不多）、[Netty 常见面试题](https://javaguide.cn/system-design/framework/netty.html)（用到才需要准备） + +**自测**：能说清项目里用到的 Spring 注解、IoC/AOP 在项目中的体现、事务失效场景。 + +**权限与安全** + +- [认证授权基础](https://javaguide.cn/system-design/security/basis-of-authority-certification.html)、[JWT](https://javaguide.cn/system-design/security/jwt-intro.html) 与[优缺点](https://javaguide.cn/system-design/security/advantages-and-disadvantages-of-jwt.html)、[权限系统设计](https://javaguide.cn/system-design/security/design-of-authority-system.html)、[SSO](https://javaguide.cn/system-design/security/sso-intro.html)、[常见加密算法](https://javaguide.cn/system-design/security/encryption-algorithms.html) + +#### 系统设计与场景题 + +面试官常会穿插一两道系统设计或场景题，考察整体思路和方案权衡。 + +- **系统设计 / 场景题汇总**：[系统设计常见面试题总结](https://javaguide.cn/system-design/system-design-questions.html)（付费内容在 [《后端面试高频系统设计&场景题》](https://javaguide.cn/zhuanlan/back-end-interview-high-frequency-system-design-and-scenario-questions.html) 专栏，含短链、秒杀、海量数据处理等 30+ 道）。 +- **本站可参考的设计类文章**（思路可迁移到面试口述）：[定时任务](https://javaguide.cn/system-design/schedule-task.html)、[Web 实时消息推送](https://javaguide.cn/system-design/web-real-time-message-push.html)。 + +![《后端面试高频系统设计&场景题》](https://oss.javaguide.cn/xingqiu/back-end-interview-high-frequency-system-design-and-scenario-questions-fengmian.png) + +**自测**：能口述 1～2 个经典系统设计（如短链、秒杀、限流）的整体思路与关键取舍；场景题（如海量数据去重、第三方登录）能说出常见方案。 + +### 第四阶段：计算机基础（按目标公司安排） + +**目标字节、腾讯等重算法/基础的厂**：适当多留时间，算法与代码题要单独刷（LeetCode 热题、剑指 Offer 等等）；**目标中小厂**：可压缩或后置。 + +- **算法与代码题**（面字节、快手等必留时间）：[剑指 Offer 题解](https://javaguide.cn/cs-basics/algorithms/the-sword-refers-to-offer.html)、LeetCode 热题 100、常见手写（如 LRU、生产者消费者、单例等）。建议每天至少 1 道，保持手感。 +- **网络**：[计网常见面试题（上）](https://javaguide.cn/cs-basics/network/other-network-questions.html)、[（下）](https://javaguide.cn/cs-basics/network/other-network-questions2.html)、[访问网页全过程](https://javaguide.cn/cs-basics/network/the-whole-process-of-accessing-web-pages.html)、[应用层常见协议](https://javaguide.cn/cs-basics/network/application-layer-protocol.html)、[HTTP/HTTPS](https://javaguide.cn/cs-basics/network/http-vs-https.html)、[HTTP 1.0 vs 1.1](https://javaguide.cn/cs-basics/network/http1.0-vs-http1.1.html)、[DNS](https://javaguide.cn/cs-basics/network/dns.html)、[TCP 三次握手与四次挥手](https://javaguide.cn/cs-basics/network/tcp-connection-and-disconnection.html)、[TCP 可靠性](https://javaguide.cn/cs-basics/network/tcp-reliability-guarantee.html)、[ARP](https://javaguide.cn/cs-basics/network/arp.html) +- **操作系统**：[操作系统常见面试题（上）](https://javaguide.cn/cs-basics/operating-system/operating-system-basic-questions-01.html)、[（下）](https://javaguide.cn/cs-basics/operating-system/operating-system-basic-questions-02.html)、[Linux 基础](https://javaguide.cn/cs-basics/operating-system/linux-intro.html) +- **数据结构**：[数组/链表/栈/队列](https://javaguide.cn/cs-basics/data-structure/linear-data-structure.html)、[图](https://javaguide.cn/cs-basics/data-structure/graph.html)、[堆](https://javaguide.cn/cs-basics/data-structure/heap.html)、[树](https://javaguide.cn/cs-basics/data-structure/tree.html)、[红黑树](https://javaguide.cn/cs-basics/data-structure/red-black-tree.html)、[布隆过滤器](https://javaguide.cn/cs-basics/data-structure/bloom-filter.html) + +**自测**：能画访问网页全过程、TCP 握手挥手等等；算法题能手写常见套路；OS 进程/线程、内存、死锁能说清概念与例子。 + +### 第五阶段：分布式与高并发（按简历与岗位） + +若简历或岗位涉及分布式/微服务/高并发，再系统过一遍；否则可只过「项目会用到的点」。 + +- **分布式理论**：[CAP 与 BASE](https://javaguide.cn/distributed-system/protocol/cap-and-base-theorem.html)、[Paxos](https://javaguide.cn/distributed-system/protocol/paxos-algorithm.html)、[Raft](https://javaguide.cn/distributed-system/protocol/raft-algorithm.html)、[ZAB](https://javaguide.cn/distributed-system/protocol/zab.html)、[Gossip](https://javaguide.cn/distributed-system/protocol/gossip-protocol.html)、[一致性哈希](https://javaguide.cn/distributed-system/protocol/consistent-hashing.html) +- **RPC**：[RPC 基础](https://javaguide.cn/distributed-system/rpc/rpc-intro.html)、[Dubbo](https://javaguide.cn/distributed-system/rpc/dubbo.html)（目前问的很少，可跳过） +- **分布式 ID / 网关 / 锁 / 事务**（项目涉及再重点看）：[分布式 ID](https://javaguide.cn/distributed-system/distributed-id.html)、[设计指南](https://javaguide.cn/distributed-system/distributed-id-design.html)、[API 网关](https://javaguide.cn/distributed-system/api-gateway.html)、[Spring Cloud Gateway](https://javaguide.cn/distributed-system/spring-cloud-gateway-questions.html)、[分布式锁](https://javaguide.cn/distributed-system/distributed-lock-implementations.html)、[分布式事务](https://javaguide.cn/distributed-system/distributed-transaction.html) +- **高并发**（项目涉及再重点看）：[CDN](https://javaguide.cn/high-performance/cdn.html)、[读写分离与分库分表](https://javaguide.cn/high-performance/read-and-write-separation-and-library-subtable.html)、[冷热分离](https://javaguide.cn/high-performance/data-cold-hot-separation.html)、[SQL 优化](https://javaguide.cn/high-performance/sql-optimization.html)、[深度分页](https://javaguide.cn/high-performance/deep-pagination-optimization.html)、[负载均衡](https://javaguide.cn/high-performance/load-balancing.html) +- **高可用**（项目涉及再重点看）：[高可用系统设计](https://javaguide.cn/high-availability/high-availability-system-design.html)、[限流](https://javaguide.cn/high-availability/limit-request.html)、[熔断与降级](https://javaguide.cn/high-availability/fallback-and-circuit-breaker.html)、[超时与重试](https://javaguide.cn/high-availability/timeout-and-retry.html)、[幂等设计](https://javaguide.cn/high-availability/idempotency.html)、[冗余设计](https://javaguide.cn/high-availability/redundancy.html) +- **消息队列**（项目涉及再重点看）：[MQ 基础](https://javaguide.cn/high-performance/message-queue/message-queue.html)、[Disruptor](https://javaguide.cn/high-performance/message-queue/disruptor-questions.html)、[RabbitMQ](https://javaguide.cn/high-performance/message-queue/rabbitmq-questions.html)、[RocketMQ](https://javaguide.cn/high-performance/message-queue/rocketmq-questions.html)、[Kafka](https://javaguide.cn/high-performance/message-queue/kafka-questions-01.html) + +**自测**：能讲清项目里用到的分布式方案（如分布式锁、ID、MQ）及选型理由；CAP/BASE、一致性哈希等能举例说明。 + +### 第六阶段：JVM（大厂 / 部分中厂） + +目标阿里、美团、携程、顺丰、招银等可重点看；面国企或小厂可跳过。 + +- [Java 内存区域](https://javaguide.cn/java/jvm/memory-area.html)、[JVM 垃圾回收](https://javaguide.cn/java/jvm/jvm-garbage-collection.html) +- [类文件结构](https://javaguide.cn/java/jvm/class-file-structure.html)、[类加载过程](https://javaguide.cn/java/jvm/class-loading-process.html)、[类加载器](https://javaguide.cn/java/jvm/classloader.html) +- 结合[星球](https://javaguide.cn/about-the-author/zhishixingqiu-two-years.html)的 [常见线上问题案例](https://t.zsxq.com/0bsAac47U) 理解调优与排查（也可以参考这篇 [JVM 线上问题排查和性能调优案例](https://javaguide.cn/java/jvm/jvm-in-action.html)） + +**自测**：能说清内存区域、常见 GC 器与回收过程、类加载与双亲委派；能结合项目或案例讲一次 GC 调优或 OOM 排查思路。 + +**Java 新特性**（按岗位要求选读）：[Java 11](https://javaguide.cn/java/new-features/java11.html)、[Java 17](https://javaguide.cn/java/new-features/java17.html)、[Java 21](https://javaguide.cn/java/new-features/java21.html) + +### 面试前 1～2 天冲刺清单 + +临近面试时优先做这几件事，避免临时抱佛脚方向散乱： + +| 事项 | 说明 | +| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | +| 过一遍必会题 | 重点看你第一阶段整理的「项目相关必会题」+ 简历上写的「熟练掌握」对应的考点，能口头复述要点即可。 | +| 练一遍项目话术 | 每个项目 1 分钟版、3 分钟版各讲一遍，卡壳的地方记下来再顺一遍。 | +| 目标公司/岗位倾向 | 翻一下该公司或同类型岗位的面经，看有没有偏重（如算法、计网、项目深挖），针对性过一眼。 | +| 心态与状态 | 早睡、准备好设备（线上面试）或路线（现场），可看 [面试太紧张怎么办？](https://javaguide.cn/interview-preparation/how-to-handle-interview-nerves.html)。 | + +面试结束后建议做一次简短复盘：哪些题答得不好、哪些没准备到，补充进必会题清单，下一场前重点过一遍。 diff --git a/docs/interview-preparation/how-to-handle-interview-nerves.md b/docs/interview-preparation/how-to-handle-interview-nerves.md index c58fba1b0a3..d46a28716f2 100644 --- a/docs/interview-preparation/how-to-handle-interview-nerves.md +++ b/docs/interview-preparation/how-to-handle-interview-nerves.md @@ -11,9 +11,11 @@ head: -很多小伙伴在第一次技术面试时都会感到紧张甚至害怕，面试结束后还会有种“懵懵的”感觉。我也经历过类似的状况，可以说是深有体会。其实，**紧张是很正常的**——它代表你对面试的重视，也来自于对未知结果的担忧。但如果过度紧张，反而会影响你的临场发挥。 +很多小伙伴在第一次技术面试时都会感到紧张甚至害怕，遇到稍微刁钻的问题大脑就一片空白，面试结束后还会有种“懵懵的”感觉。我也经历过类似的状况，对这种手心出汗、语无伦次的窘境深有体会。 -下面，我就分享一些自己的心得，帮大家更好地应对面试中的紧张情绪。 +其实，**紧张是非常正常的生理和心理反应**——它代表你对这次机会的重视，也源于人类对未知结果的天然担忧。但如果任由过度紧张蔓延，绝对会大幅折损你的临场发挥水平。 + +下面，我将结合自己的实战经验，从**心态重塑、战术准备、临场应对、面后复盘**四个维度，分享一套可落地的“抗紧张”指南。 ## 试着接受紧张情绪，调整心态 @@ -29,13 +31,13 @@ head: ### 认真准备技术面试 -- **优先梳理核心知识点**：比如计算基础、数据库、Java 基础、Java 集合、并发编程、SpringBoot（这里以 Java 后端方向为例）等。如果时间不够，可以分轻重缓急，有重点地复习。强烈推荐阅读一下 [Java 面试重点总结(重要)](https://javaguide.cn/interview-preparation/key-points-of-interview.html)这篇文章。 +- **优先梳理核心知识点**：比如计算基础、数据库、Java 基础、Java 集合、并发编程、SpringBoot（这里以 Java 后端方向为例）等。如果时间不够，可以分轻重缓急，有重点地复习。如果你想要系统准备 Java 后端面试但又不知道如何开始的，可以参考 [Java 后端面试通关计划（后端通用）](https://javaguide.cn/interview-preparation/backend-interview-plan.html)。 - **精心准备项目经历**：认真思考你简历上最重要的项目（面试以前两个项目为主，尤其是第一个），它们的技术难点、业务逻辑、架构设计，以及可能被面试官深挖的点。把你的思考总结成可能出现的面试问题，并尝试回答。 ### 模拟面试和自测 - **约朋友或同学互相提问**：以真实的面试场景来进行演练，并及时对回答进行诊断和反馈。 -- **线上练习**：很多平台都提供 AI 模拟面试，能比较真实地模拟面试官提问情境。 +- **线上练习**：直接利用 AI 来进行模拟面试即可，免费且高效。把自己的简历投喂给它，让它根据你的简历，尤其是项目经历生成面试问题。 - **面经**：平时可以多看一些前辈整理的面经，尤其是目标岗位或目标公司的面经，总结高频考点和常见问题。 - **技术面试题自测**：在 [《Java 面试指北》](https://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html) 的 「技术面试题自测篇」 ，我总结了 Java 面试中最重要的知识点的最常见的面试题并按照面试提问的方式展现出来。其中，每一个问题都有提示和重要程度说明，非常适合用来自测。 diff --git a/docs/interview-preparation/internship-experience.md b/docs/interview-preparation/internship-experience.md index da6fb344a67..719c0e5c31f 100644 --- a/docs/interview-preparation/internship-experience.md +++ b/docs/interview-preparation/internship-experience.md @@ -1,5 +1,5 @@ --- -title: 校招没有实习经历怎么办？ +title: 校招没有实习经历怎么办？实习经历怎么写？ description: 校招没有实习经历也能上岸：从补强项目经验、持续优化简历到系统准备技术面试，给出可执行的提升路径与注意事项，帮助你在没有大厂实习的情况下提高面试通过率。 category: 面试准备 icon: experience @@ -13,7 +13,9 @@ head: 由于目前的面试太卷，对于犹豫是否要找实习的同学来说，个人建议不论是本科生还是研究生都应该在参加校招面试之前，争取一下不错的实习机会，尤其是大厂的实习机会，日常实习或者暑期实习都可以。当然，如果大厂实习面不上，中小厂实习也是可以接受的。 -不过，现在的实习是真难找，今年有非常多的同学没有找到实习，有一部分甚至是 211/985 名校的同学。 +不过，现在的实习是真难找，这两年有非常多的同学没有找到实习，有一部分甚至是 211/985 名校的同学。实习难找是一方面原因，国内很多学校的导师压根不放实习，这也是很棘手的问题。 + +## 没有实习经历怎么办？ 如果实在是找不到合适的实习的话，那也没办法，我们应该多花时间去把下面这三件事情给做好： @@ -21,7 +23,7 @@ head: 2. 持续完善简历 3. 准备技术面试 -## 补强项目经历 +### 补强项目经历 校招没有实习经历的话，找工作比较吃亏（没办法，太卷了），需要在项目经历部分多发力弥补一下。 @@ -31,7 +33,7 @@ head: 推荐阅读一下网站的这篇文章：[项目经验指南](https://javaguide.cn/interview-preparation/project-experience-guide.html)。 -## **完善简历** +### 完善简历 一定一定一定要重视简历啊！建议至少花 2~3 天时间来专门完善自己的简历。并且，后续还要持续完善。 @@ -47,17 +49,46 @@ head: 详细的程序员简历编写指南可以参考这篇文章：[程序员简历编写指南(重要)](https://javaguide.cn/interview-preparation/resume-guide.html)。 -## **准备技术面试** +### 准备技术面试 面试之前一定要提前准备一下常见的面试题也就是八股文： - 自己面试中可能涉及哪些知识点、那些知识点是重点。 - 面试中哪些问题会被经常问到、面试中自己该如何回答。(强烈不推荐死记硬背，第一：通过背这种方式你能记住多少？能记住多久？第二：背题的方式的学习很难坚持下去！) -Java 后端面试复习的重点请看这篇文章：[Java 后端的面试重点是什么?](https://javaguide.cn/interview-preparation/key-points-of-interview.html)。 - 不同类型的公司对于技能的要求侧重点是不同的比如腾讯、字节可能更重视计算机基础比如网络、操作系统这方面的内容。阿里、美团这种可能更重视你的项目经历、实战能力。 一定不要抱着一种思想，觉得八股文或者基础问题的考查意义不大。如果你抱着这种思想复习的话，那效果可能不会太好。实际上，个人认为还是很有意义的，八股文或者基础性的知识在日常开发中也会需要经常用到。例如，线程池这块的拒绝策略、核心参数配置什么的，如果你不了解，实际项目中使用线程池可能就用的不是很明白，容易出现问题。而且，其实这种基础性的问题是最容易准备的，像各种底层原理、系统设计、场景题以及深挖你的项目这类才是最难的！ 八股文资料首推我的 [《Java 面试指北》](https://javaguide.cn/zhuanlan/java-mian-shi-zhi-bei.html) 和 [JavaGuide](https://javaguide.cn/home.html) 。里面不仅仅是原创八股文，还有很多对实际开发有帮助的干货。除了我的资料之外，你还可以去网上找一些其他的优质的文章、视频来看。 + +如果你想要系统准备 Java 后端面试但又不知道如何开始的，可以参考 [Java 后端面试通关计划（后端通用）](https://javaguide.cn/interview-preparation/backend-interview-plan.html)。 + +## 实习经历在简历上一般怎么写比较出彩？ + +实习经历的描述一定要避免空谈，尽量列举出你在实习期间取得的成就和具体贡献，使用具体的数据和指标来量化你的工作成果。 + +示例（这里假设项目细节放在实习经历这里介绍，你也可以选择将实习经历参与的项目放到项目经历中）： + +1. 负责订单模块核心流程开发，实现订单状态的精确流转，并保障与库存、支付等模块的数据一致性。 +2. 负责行为风控黑名单看板的开发，支持查看拉黑用户、批量拉黑以及取消拉黑。 +3. 基于 Redisson + AOP 封装限流组件，实现对核心接口（如付费、课程搜索）的限流，有效防止恶意请求冲击。 +4. 优化用户统计模块性能，利用 CompletableFuture 并行加载多维度数据（如用户增长、课程活跃度），，平均相应时间从 3.5s 降低到 1s。 +5. 封装通用数据脱敏组件，通过自定义 Jackson 注解实现对手机号、邮箱等敏感信息的自动、无侵入式脱敏。 +6. 优化文件上传模块，基于 MinIO 实现了文件的分片上传、断点续传以及极速秒传功能。 +7. 排查并解决扣费模块由于扣费父任务和反作弊子任务使用同一个线程池导致的死锁问题，通过线程池隔离策略根除该隐患。 +8. 实习期间独立负责 7 个功能需求与 3 个线上问题修复，代码均一次性通过评审与测试。 + +下面是[星球](https://javaguide.cn/about-the-author/zhishixingqiu-two-years.html)一位球友分享的实习经历介绍，整体写的还是非常不错的： + +![实习经历模板](https://oss.javaguide.cn/github/javaguide/interview-preparation/qiuyou-shixijingli-demo.png) + +📌关于实习经历这块再多提一点：很多同学实习期间可能接触不到什么实际的开发任务，大部分时间可能都是在熟悉和维护项目。 + +对于这种情况，应对思路是一套组合拳：首先，你肯定是要和 mentor 沟通继续争取做一些有价值的工作，这样你的实习经历才更有价值，简历上自然就能够有东西可写。记得找一个 mentor 不那么忙的时候沟通，放低姿态，真诚一些，表明自己现有的工作已经认真完成，想要承担更多责任的意愿。其次，不管是否能够争取到这种机会，你都要自己有意识地寻找项目中适合自己研究的功能点（比如同组其他实习生干的活），进行深度挖掘。重点关注以下几个方面： + +1. **这个功能是干嘛的？** 它解决了什么业务痛点？给哪个业务方用的？整个流程是怎样的？ +2. **它是怎么实现的？** 用了哪些关键技术、框架或者设计模式？核心代码的逻辑是怎样的？ +3. **为什么要这么设计？** 当初设计的时候有没有别的方案？现在这个方案好在哪，又有什么潜在的坑？如果让你来做，你会怎么设计？ + +只要你把具体的功能点彻底搞懂，那就可以在简历上合理包装成自己的成果。除了功能点开发之外，也可以包装一些合适的问题排查解决经历，这样能够体现你解决问题的能力。 面试时也不用太担心自己“露馅”，只要你选择的内容不属于那些显然不会交给实习生完成的高难度任务，并且能清晰地讲明白，就不会有问题。 diff --git a/docs/interview-preparation/key-points-of-interview.md b/docs/interview-preparation/key-points-of-interview.md index 90dfa11851d..db3ffd91c89 100644 --- a/docs/interview-preparation/key-points-of-interview.md +++ b/docs/interview-preparation/key-points-of-interview.md @@ -19,7 +19,7 @@ head: **准备面试的时候，具体哪些知识点是重点呢？如何把握重点？** -先来一张图（后续会详细解读）： +先看下面这张全局图（后续会详细解读）： ![Java 后端面试重点](https://oss.javaguide.cn/github/javaguide/interview-preparation/back-end-interview-focus.png) @@ -55,156 +55,6 @@ head: 最后，准备技术面试的同学一定要定期复习（自测的方式非常好），不然确实会遗忘的。 -## 详细面试准备计划 +## 详细面试准备计划（后端通用） -以下计划按**「项目经历 → 简历技术 → MySQL/Redis/Java → 框架 → 系统设计与场景题 → 计算机基础 → 分布式/高并发 → JVM」**的优先级编排，每阶段都对应到本站具体文章，便于按图索骥。 - -建议总周期 **4～8 周**，可根据目标公司（中小厂 / 大厂）和基础情况压缩或拉长。 - -### 计划总览 - -| 阶段 | 建议时长 | 核心产出 | 自测建议 | -| ----------------------------- | --------------------- | ----------------------------------- | -------------------------------------- | -| 第 0 步 前期准备 | 1～2 天 | 简历定稿、复习节奏确定 | 简历能否 30 秒讲清项目 | -| 第一阶段 项目与简历深挖 | 约 1 周 | 项目卡片、必会题清单、话术稿 | 能脱稿讲清每个项目背景+难点+你的贡献 | -| 第二阶段 Java + MySQL + Redis | 2～3 周 | 八股理解+关键词记忆 | 根据网站文章自测 | -| 第三阶段 框架 | 1～2 周 | Spring/IoC/AOP/事务、设计模式、安全 | 能说清项目里用到的注解与设计思路 | -| 系统设计与场景题 | 按需 0.5～1 周 | 系统设计题、场景题思路与案例 | 能口述 1～2 个经典设计（如短链、秒杀） | -| 第四阶段 计算机基础 | 按需 0.5～2 周 | 计网/OS/数据结构；目标字节等加算法 | 手写经典题、能画 TCP/HTTP 过程 | -| 第五阶段 分布式与高并发 | 按需 1～2 周 | 分布式理论、RPC、MQ、高可用 | 能讲清项目中的分布式方案选型理由 | -| 第六阶段 JVM | 大厂/部分中厂 3～5 天 | 内存、GC、类加载、调优排查 | 能结合项目说一次 GC 或 OOM 排查 | -| 面试前冲刺 | 1～2 天 | 总复习清单、心态稳定 | 过一遍必会题+项目话术 | - -### 第 0 步：前期准备（建议 1～2 天） - -在系统刷八股前，先把「怎么准备、怎么写简历、怎么稳住心态」搞定，避免方向跑偏。 - -| 事项 | 说明 | 对应文章 | -| ---------- | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 准备方法 | 明确复习节奏、自测方式、时间分配 | [如何高效准备 Java 面试？](https://javaguide.cn/interview-preparation/teach-you-how-to-prepare-for-the-interview-hand-in-hand.html) | -| 简历 | 一页纸、项目 STAR、技术栈与岗位匹配 | [程序员简历编写指南](https://javaguide.cn/interview-preparation/resume-guide.html) | -| 学习路线 | 查漏补缺，确定自己当前所处阶段 | [Java 学习路线（最新版，4w+ 字）](https://javaguide.cn/interview-preparation/java-roadmap.html) | -| 项目与经历 | 没有项目/实习时如何包装、怎么讲 | [项目经验指南](https://javaguide.cn/interview-preparation/project-experience-guide.html)、[校招没有实习经历怎么办？](https://javaguide.cn/interview-preparation/internship-experience.html) | -| 心态 | 减少紧张、发挥更稳 | [面试太紧张怎么办？](https://javaguide.cn/interview-preparation/how-to-handle-interview-nerves.html) | - -### 第一阶段：项目与简历深挖（约 1 周） - -**目标**：能清晰讲出每个项目的背景、你的角色、技术选型与难点，并能推导出「可能被问的面试题」。 - -**产出物**： - -- **项目卡片**：按简历逐条过项目，为每个项目写清——业务背景、技术栈、你负责的模块、1～2 个难点与解决方式、可量化的成果（如 QPS、耗时、节省成本）。 -- **必会题清单**：根据项目用到的技术，列出「必会题」（例如：用了 Redis 限流 → Redis 常见数据结构 + 限流算法；用了 MySQL → 索引、事务、慢 SQL 优化）。可参考 [Java 面试常见问题总结](https://t.zsxq.com/0eRq7EJPy) 按项目拓展。 -- **话术稿**：每个项目准备 1～2 分钟版本（自我介绍用）和 3～5 分钟版本（深挖用），能流畅讲出「为什么这么选、遇到什么问题、怎么解决的」。 - -**每日建议**：每天至少梳理 1 个项目 + 对应必会题，周末做一次脱稿自测（录音或对着镜子讲）。 - -**自测**：能脱稿讲清每个项目的背景、难点和你的贡献；必会题清单里的题能答出要点。 - -### 第二阶段：Java 核心 + MySQL + Redis （约 2～3 周） - -**优先级**：最重要的部分，面试高频考点，MySQL + Redis ≥ Java 基础/集合/并发 > 框架知识，大厂会深挖并发与底层。 - -**Java 基础** - -- [Java 基础常见面试题总结（上）](https://javaguide.cn/java/basis/java-basic-questions-01.html)、[（中）](https://javaguide.cn/java/basis/java-basic-questions-02.html)、[（下）](https://javaguide.cn/java/basis/java-basic-questions-03.html)：语法与面向对象、字符串与拷贝、异常/泛型/反射/SPI/序列化/注解 - -**Java 集合** - -- [Java 集合常见面试题（上）](https://javaguide.cn/java/collection/java-collection-questions-01.html)、[（下）](https://javaguide.cn/java/collection/java-collection-questions-02.html)：List/Set/Queue、HashMap、ConcurrentHashMap - -**Java 并发**（大厂必深挖） - -- [Java 并发常见面试题（上）](https://javaguide.cn/java/concurrent/java-concurrent-questions-01.html)、[（中）](https://javaguide.cn/java/concurrent/java-concurrent-questions-02.html)、[（下）](https://javaguide.cn/java/concurrent/java-concurrent-questions-03.html)：线程与锁、synchronized/ReentrantLock、ThreadLocal/线程池/Future/AQS/虚拟线程 -- [JMM](https://javaguide.cn/java/concurrent/jmm.html)、[线程池详解](https://javaguide.cn/java/concurrent/java-thread-pool-summary.html)与[最佳实践](https://javaguide.cn/java/concurrent/java-thread-pool-best-practices.html) -- [ThreadLocal](https://javaguide.cn/java/concurrent/threadlocal.html)、[AQS](https://javaguide.cn/java/concurrent/aqs.html)、[CompletableFuture](https://javaguide.cn/java/concurrent/completablefuture-intro.html)、[常见并发容器](https://javaguide.cn/java/concurrent/java-concurrent-collections.html) - -**MySQL**（必看） - -- [MySQL 常见面试题总结](https://javaguide.cn/database/mysql/mysql-questions-01.html)（基础、引擎、事务、索引、锁、优化） -- [MySQL 索引详解](https://javaguide.cn/database/mysql/mysql-index.html)、[三大日志](https://javaguide.cn/database/mysql/mysql-logs.html)、[事务隔离级别](https://javaguide.cn/database/mysql/transaction-isolation-level.html) -- [InnoDB 对 MVCC 的实现](https://javaguide.cn/database/mysql/innodb-implementation-of-mvcc.html)、[SQL 执行过程](https://javaguide.cn/database/mysql/how-sql-executed-in-mysql.html) - -**Redis**（必看） - -- [Redis 常见面试题总结（上）](https://javaguide.cn/database/redis/redis-questions-01.html)、[Redis 常见面试题总结（下）](https://javaguide.cn/database/redis/redis-questions-02.html) -- [Redis 延时任务](https://javaguide.cn/database/redis/redis-delayed-task.html)、[Redis 做消息队列](https://javaguide.cn/database/redis/redis-stream-mq.html) -- [5 种基本数据类型](https://javaguide.cn/database/redis/redis-data-structures-01.html)、[3 种特殊类型](https://javaguide.cn/database/redis/redis-data-structures-02.html)、[跳表实现有序集合](https://javaguide.cn/database/redis/redis-skiplist.html) -- [持久化](https://javaguide.cn/database/redis/redis-persistence.html)、[内存碎片](https://javaguide.cn/database/redis/redis-memory-fragmentation.html)、[常见阻塞原因](https://javaguide.cn/database/redis/redis-common-blocking-problems-summary.html) - -### 第三阶段：框架（约 1～2 周） - -**设计模式** - -- [设计模式常见面试题总结](https://interview.javaguide.cn/system-design/design-pattern.html) - -**Spring / Spring Boot** - -- [Spring 常见面试题](https://javaguide.cn/system-design/framework/spring/spring-knowledge-and-questions-summary.html)、[SpringBoot 常见面试题](https://javaguide.cn/system-design/framework/spring/springboot-knowledge-and-questions-summary.html) -- [常用注解](https://javaguide.cn/system-design/framework/spring/spring-common-annotations.html)、[IoC 与 AOP](https://javaguide.cn/system-design/framework/spring/ioc-and-aop.html)、[Spring 事务](https://javaguide.cn/system-design/framework/spring/spring-transaction.html) -- [Spring 中的设计模式](https://javaguide.cn/system-design/framework/spring/spring-design-patterns-summary.html)、[SpringBoot 自动装配](https://javaguide.cn/system-design/framework/spring/spring-boot-auto-assembly-principles.html)、[Async 原理](https://javaguide.cn/system-design/framework/spring/async.html) -- [MyBatis 常见面试题](https://javaguide.cn/system-design/framework/mybatis/mybatis-interview.html)、[Netty 常见面试题](https://javaguide.cn/system-design/framework/netty.html) - -**自测**：能说清项目里用到的 Spring 注解、IoC/AOP 在项目中的体现、事务失效场景；设计模式能举出项目或框架中的例子。 - -**权限与安全** - -- [认证授权基础](https://javaguide.cn/system-design/security/basis-of-authority-certification.html)、[JWT](https://javaguide.cn/system-design/security/jwt-intro.html) 与[优缺点](https://javaguide.cn/system-design/security/advantages-and-disadvantages-of-jwt.html)、[权限系统设计](https://javaguide.cn/system-design/security/design-of-authority-system.html)、[SSO](https://javaguide.cn/system-design/security/sso-intro.html)、[常见加密算法](https://javaguide.cn/system-design/security/encryption-algorithms.html) - -### 系统设计与场景题（建议放在框架之后） - -面试官常会穿插一两道系统设计或场景题，考察整体思路和方案权衡。本模块与「框架」分开，便于单独安排时间刷题与总结。 - -- **系统设计 / 场景题汇总**：[系统设计常见面试题总结](https://javaguide.cn/system-design/system-design-questions.html)（付费内容在 [《后端面试高频系统设计&场景题》](https://javaguide.cn/zhuanlan/back-end-interview-high-frequency-system-design-and-scenario-questions.html) 专栏，含短链、秒杀、海量数据处理等 30+ 道）。 -- **本站可参考的设计类文章**（思路可迁移到面试口述）：[定时任务](https://javaguide.cn/system-design/schedule-task.html)、[Web 实时消息推送](https://javaguide.cn/system-design/web-real-time-message-push.html)。 - -**自测**：能口述 1～2 个经典系统设计（如短链、秒杀、限流）的整体思路与关键取舍；场景题（如海量数据去重、第三方登录）能说出常见方案。 - -### 第四阶段：计算机基础（按目标公司安排） - -**目标字节等重算法/基础的厂**：适当多留时间，算法与代码题要单独刷（LeetCode 热题、剑指 Offer、手写常见数据结构）；**目标中小厂**：可压缩或后置。 - -- **算法与代码题**（面字节、快手等必留时间）：[剑指 Offer 题解](https://javaguide.cn/cs-basics/algorithms/the-sword-refers-to-offer.html)、LeetCode 热题 100、常见手写（如 LRU、生产者消费者、单例等）。建议每天至少 1 道，保持手感。 -- **网络**：[计网常见面试题（上）](https://javaguide.cn/cs-basics/network/other-network-questions.html)、[（下）](https://javaguide.cn/cs-basics/network/other-network-questions2.html)、[访问网页全过程](https://javaguide.cn/cs-basics/network/the-whole-process-of-accessing-web-pages.html)、[应用层常见协议](https://javaguide.cn/cs-basics/network/application-layer-protocol.html)、[HTTP/HTTPS](https://javaguide.cn/cs-basics/network/http-vs-https.html)、[HTTP 1.0 vs 1.1](https://javaguide.cn/cs-basics/network/http1.0-vs-http1.1.html)、[DNS](https://javaguide.cn/cs-basics/network/dns.html)、[TCP 三次握手与四次挥手](https://javaguide.cn/cs-basics/network/tcp-connection-and-disconnection.html)、[TCP 可靠性](https://javaguide.cn/cs-basics/network/tcp-reliability-guarantee.html)、[ARP](https://javaguide.cn/cs-basics/network/arp.html) -- **操作系统**：[操作系统常见面试题（上）](https://javaguide.cn/cs-basics/operating-system/operating-system-basic-questions-01.html)、[（下）](https://javaguide.cn/cs-basics/operating-system/operating-system-basic-questions-02.html)、[Linux 基础](https://javaguide.cn/cs-basics/operating-system/linux-intro.html) -- **数据结构**：[数组/链表/栈/队列](https://javaguide.cn/cs-basics/data-structure/linear-data-structure.html)、[图](https://javaguide.cn/cs-basics/data-structure/graph.html)、[堆](https://javaguide.cn/cs-basics/data-structure/heap.html)、[树](https://javaguide.cn/cs-basics/data-structure/tree.html)、[红黑树](https://javaguide.cn/cs-basics/data-structure/red-black-tree.html)、[布隆过滤器](https://javaguide.cn/cs-basics/data-structure/bloom-filter.html) - -**自测**：能画访问网页全过程、TCP 握手挥手；算法题能手写常见套路；OS 进程/线程、内存、死锁能说清概念与例子。 - -### 第五阶段：分布式与高并发（按简历与岗位） - -若简历或岗位涉及分布式/微服务/高并发，再系统过一遍；否则可只过「项目会用到的点」。 - -- **分布式理论**：[CAP 与 BASE](https://javaguide.cn/distributed-system/protocol/cap-and-base-theorem.html)、[Paxos](https://javaguide.cn/distributed-system/protocol/paxos-algorithm.html)、[Raft](https://javaguide.cn/distributed-system/protocol/raft-algorithm.html)、[Gossip](https://javaguide.cn/distributed-system/protocol/gossip-protocol.html)、[一致性哈希](https://javaguide.cn/distributed-system/protocol/consistent-hashing.html) -- **RPC**：[RPC 基础](https://javaguide.cn/distributed-system/rpc/rpc-intro.html)、[Dubbo](https://javaguide.cn/distributed-system/rpc/dubbo.html) -- **分布式 ID / 网关 / 锁**：[分布式 ID](https://javaguide.cn/distributed-system/distributed-id.html)、[设计指南](https://javaguide.cn/distributed-system/distributed-id-design.html)、[API 网关](https://javaguide.cn/distributed-system/api-gateway.html)、[Spring Cloud Gateway](https://javaguide.cn/distributed-system/spring-cloud-gateway-questions.html)、[分布式锁](https://javaguide.cn/distributed-system/distributed-lock.html)、[实现方案](https://javaguide.cn/distributed-system/distributed-lock-implementations.html) -- **高并发与 MQ**：[CDN](https://javaguide.cn/high-performance/cdn.html)、[读写分离与分库分表](https://javaguide.cn/high-performance/read-and-write-separation-and-library-subtable.html)、[冷热分离](https://javaguide.cn/high-performance/data-cold-hot-separation.html)、[SQL 优化](https://javaguide.cn/high-performance/sql-optimization.html)、[深度分页](https://javaguide.cn/high-performance/deep-pagination-optimization.html)、[负载均衡](https://javaguide.cn/high-performance/load-balancing.html) -- **高可用**（项目涉及再重点看）：[高可用系统设计](https://javaguide.cn/high-availability/high-availability-system-design.html)、[限流](https://javaguide.cn/high-availability/limit-request.html)、[熔断与降级](https://javaguide.cn/high-availability/fallback-and-circuit-breaker.html)、[超时与重试](https://javaguide.cn/high-availability/timeout-and-retry.html)、[幂等设计](https://javaguide.cn/high-availability/idempotency.html)、[冗余设计](https://javaguide.cn/high-availability/redundancy.html) -- **消息队列**：[MQ 基础](https://javaguide.cn/high-performance/message-queue/message-queue.html)、[Disruptor](https://javaguide.cn/high-performance/message-queue/disruptor-questions.html)、[RabbitMQ](https://javaguide.cn/high-performance/message-queue/rabbitmq-questions.html)、[RocketMQ](https://javaguide.cn/high-performance/message-queue/rocketmq-questions.html)、[Kafka](https://javaguide.cn/high-performance/message-queue/kafka-questions-01.html) - -**自测**：能讲清项目里用到的分布式方案（如分布式锁、ID、MQ）及选型理由；CAP/BASE、一致性哈希等能举例说明。 - -### 第六阶段：JVM（大厂 / 部分中厂） - -目标阿里、美团、携程、顺丰、招银等可重点看；面国企或小厂可跳过。 - -- [Java 内存区域](https://javaguide.cn/java/jvm/memory-area.html)、[JVM 垃圾回收](https://javaguide.cn/java/jvm/jvm-garbage-collection.html) -- [类文件结构](https://javaguide.cn/java/jvm/class-file-structure.html)、[类加载过程](https://javaguide.cn/java/jvm/class-loading-process.html)、[类加载器](https://javaguide.cn/java/jvm/classloader.html) -- 结合 [常见线上问题案例](https://t.zsxq.com/0bsAac47U) 理解调优与排查 - -**自测**：能说清内存区域、常见 GC 器与回收过程、类加载与双亲委派；能结合项目或案例讲一次 GC 调优或 OOM 排查思路。 - -**Java 新特性**（按岗位要求选读）：[Java 11](https://javaguide.cn/java/new-features/java11.html)、[Java 17](https://javaguide.cn/java/new-features/java17.html)、[Java 21](https://javaguide.cn/java/new-features/java21.html) - -### 面试前 1～2 天冲刺清单 - -临近面试时优先做这几件事，避免临时抱佛脚方向散乱： - -| 事项 | 说明 | -| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | -| 过一遍必会题 | 重点看你第一阶段整理的「项目相关必会题」+ 简历上写的「熟练掌握」对应的考点，能口头复述要点即可。 | -| 练一遍项目话术 | 每个项目 1 分钟版、3 分钟版各讲一遍，卡壳的地方记下来再顺一遍。 | -| 目标公司/岗位倾向 | 翻一下该公司或同类型岗位的面经，看有没有偏重（如算法、计网、项目深挖），针对性过一眼。 | -| 心态与状态 | 早睡、准备好设备（线上面试）或路线（现场），可看 [面试太紧张怎么办？](https://javaguide.cn/interview-preparation/how-to-handle-interview-nerves.html)。 | - -面试结束后建议做一次简短复盘：哪些题答得不好、哪些没准备到，补充进必会题清单，下一场前重点过一遍。 +[Java 后端面试重点和详细准备计划](https://javaguide.cn/interview-preparation/backend-interview-plan.html) diff --git a/docs/java/basis/syntactic-sugar.md b/docs/java/basis/syntactic-sugar.md index cc5eef45a45..615b008e43e 100644 --- a/docs/java/basis/syntactic-sugar.md +++ b/docs/java/basis/syntactic-sugar.md @@ -688,36 +688,21 @@ public static transient void main(String args[]) throwable = throwable2; throw throwable2; } - if(br != null) - if(throwable != null) - try - { - br.close(); - } - catch(Throwable throwable1) - { - throwable.addSuppressed(throwable1); - } - else - br.close(); - break MISSING_BLOCK_LABEL_113; //该标签为反编译工具的生成错误，（不是Java语法本身的内容）属于反编译工具的临时占位符。正常情况下编译器生成的字节码不会包含这种无效标签。 - Exception exception; - exception; + finally + { if(br != null) if(throwable != null) try { br.close(); } - catch(Throwable throwable3) - { - throwable.addSuppressed(throwable3); + catch(Throwable throwable1) + { + throwable.addSuppressed(throwable1); } else br.close(); - throw exception; - IOException ioexception; - ioexception; + } } } ``` diff --git a/docs/java/collection/concurrent-hash-map-source-code.md b/docs/java/collection/concurrent-hash-map-source-code.md index 25860c57ee2..695fbf108fe 100644 --- a/docs/java/collection/concurrent-hash-map-source-code.md +++ b/docs/java/collection/concurrent-hash-map-source-code.md @@ -662,7 +662,7 @@ public V get(Object key) { Java7 中 `ConcurrentHashMap` 使用的分段锁，也就是每一个 Segment 上同时只有一个线程可以操作，每一个 `Segment` 都是一个类似 `HashMap` 数组的结构，它可以扩容，它的冲突会转化为链表。但是 `Segment` 的个数一但初始化就不能改变。 -Java8 中的 `ConcurrentHashMap` 使用的 `Synchronized` 锁加 CAS 的机制。结构也由 Java7 中的 **`Segment` 数组 + `HashEntry` 数组 + 链表** 进化成了 **Node 数组 + 链表 / 红黑树**，Node 是类似于一个 HashEntry 的结构。它的冲突再达到一定大小时会转化成红黑树，在冲突小于一定数量时又退回链表。 +Java8 中的 `ConcurrentHashMap` 使用的 `Synchronized` 锁加 CAS 的机制。结构也由 Java7 中的 **`Segment` 数组 + `HashEntry` 数组 + 链表** 进化成了 **Node 数组 + 链表 / 红黑树**，Node 是类似于一个 HashEntry 的结构。它的冲突再达到一定大小时`TREEIFY_THRESHOLD = 8`会转化成红黑树，在冲突小于一定数量时`UNTREEIFY_THRESHOLD = 6`又退回链表。 有些同学可能对 `Synchronized` 的性能存在疑问，其实 `Synchronized` 锁自从引入锁升级策略后，性能不再是问题，有兴趣的同学可以自己了解下 `Synchronized` 的**锁升级**。 diff --git a/docs/java/collection/linkedhashmap-source-code.md b/docs/java/collection/linkedhashmap-source-code.md index c1c59d04d1f..61ce785ffb6 100644 --- a/docs/java/collection/linkedhashmap-source-code.md +++ b/docs/java/collection/linkedhashmap-source-code.md @@ -319,6 +319,55 @@ void afterNodeAccess(Node < K, V > e) { // move node to last 看不太懂也没关系，知道这个方法的作用就够了，后续有时间再慢慢消化。 +### newNode——新节点尾插链表 + +上文介绍了 `afterNodeAccess` 如何将**已存在的节点**移动到链表尾部，那么**新插入的节点**是如何被添加到链表中的呢？ + +答案在于 `LinkedHashMap` 重写了 `HashMap` 的 `newNode` 方法。当 `HashMap` 插入新键值对时，会调用 `newNode` 创建节点对象，`LinkedHashMap` 在重写的方法中不仅创建了 `Entry` 节点，还额外调用了 `linkNodeLast` 将其链接到双向链表的尾部： + +```java +// HashMap 的 newNode 是普通实现 +Node newNode(int hash, K key, V value, Node next) { + return new Node<>(hash, key, value, next); +} + +// LinkedHashMap 重写 newNode，额外调用 linkNodeLast +Node newNode(int hash, K key, V value, Node e) { + LinkedHashMap.Entry p = + new LinkedHashMap.Entry<>(hash, key, value, e); + linkNodeLast(p); // 关键：将新节点链接到链表尾部 + return p; +} +``` + +`linkNodeLast` 方法的实现如下： + +```java +// 将节点链接到双向链表尾部 +private void linkNodeLast(LinkedHashMap.Entry p) { + LinkedHashMap.Entry last = tail; + tail = p; // tail 指向新节点 + if (last == null) + head = p; // 链表为空，head 也指向新节点 + else { + p.before = last; // 新节点的前驱指向原尾节点 + last.after = p; // 原尾节点的后继指向新节点 + } +} +``` + +**这就是 LinkedHashMap 实现插入有序的核心机制**：每次插入新节点时，通过重写 `newNode` 并调用 `linkNodeLast`，将新节点追加到双向链表尾部。这样遍历时从头节点 `head` 开始沿着 `after` 指针遍历，就能按插入顺序获取所有元素。 + +同理，`LinkedHashMap` 也重写了 `newTreeNode` 方法，确保树节点插入时同样会被链接到链表尾部： + +```java +TreeNode newTreeNode(int hash, K key, V value, Node next) { + TreeNode p = new TreeNode(hash, key, value, next); + linkNodeLast(p); + return p; +} +``` + ### remove 方法后置操作——afterNodeRemoval `LinkedHashMap` 并没有对 `remove` 方法进行重写，而是直接继承 `HashMap` 的 `remove` 方法，为了保证键值对移除后双向链表中的节点也会同步被移除，`LinkedHashMap` 重写了 `HashMap` 的空实现方法 `afterNodeRemoval`。 diff --git a/docs/java/concurrent/aqs.md b/docs/java/concurrent/aqs.md index 2ac1a44c594..8f45336ebbc 100644 --- a/docs/java/concurrent/aqs.md +++ b/docs/java/concurrent/aqs.md @@ -199,6 +199,93 @@ AQS 定义两种资源共享方式：`Exclusive`（独占，只有一个线程 一般来说，自定义同步器的共享方式要么是独占，要么是共享，他们也只需实现`tryAcquire-tryRelease`、`tryAcquireShared-tryReleaseShared`中的一种即可。但 AQS 也支持自定义同步器同时实现独占和共享两种方式，如`ReentrantReadWriteLock`。 +### 独占模式与共享模式的深入对比 + +上面简要介绍了 AQS 的两种资源共享方式，下面从多个维度对独占模式和共享模式进行系统对比，帮助更深入地理解二者的差异。 + +#### 特性对比 + +| 对比维度 | 独占模式（Exclusive） | 共享模式（Share） | +| --- | --- | --- | +| **并发度** | 同一时刻只有一个线程能获取到资源 | 同一时刻可以有多个线程同时获取到资源 | +| **获取资源入口** | `acquire(int arg)` | `acquireShared(int arg)` | +| **释放资源入口** | `release(int arg)` | `releaseShared(int arg)` | +| **需要重写的模板方法** | `tryAcquire(int)` / `tryRelease(int)` | `tryAcquireShared(int)` / `tryReleaseShared(int)` | +| **tryXxx 返回值** | `boolean`，`true` 表示获取/释放成功 | `int`（获取时），负数表示失败，0 表示成功但无剩余资源，正数表示成功且有剩余资源；`boolean`（释放时） | +| **唤醒后继节点** | 释放资源时唤醒一个后继节点 | 获取资源成功后，如果还有剩余资源，会继续唤醒后续节点（传播唤醒） | +| **Node 类型标识** | `Node.EXCLUSIVE`（`null`） | `Node.SHARED`（一个静态的 `Node` 实例） | +| **典型实现** | `ReentrantLock`、`ReentrantReadWriteLock` 的写锁 | `Semaphore`、`CountDownLatch`、`ReentrantReadWriteLock` 的读锁 | + +#### `state` 在不同同步器中的语义 + +AQS 中的 `state` 是一个通用的同步状态变量，不同的同步器赋予它不同的含义： + +| 同步器 | 模式 | `state` 的语义 | +| --- | --- | --- | +| `ReentrantLock` | 独占 | 表示锁的重入次数。`state == 0` 表示锁空闲；`state > 0` 表示锁被持有，值为重入次数 | +| `ReentrantReadWriteLock` | 独占 + 共享 | 高 16 位表示读锁的持有数量（共享），低 16 位表示写锁的重入次数（独占） | +| `Semaphore` | 共享 | 表示可用许可证的数量。每次 `acquire()` 减少，`release()` 增加 | +| `CountDownLatch` | 共享 | 表示需要等待的计数。每次 `countDown()` 减 1，到 0 时唤醒所有等待线程 | + +下面通过一个代码示例来直观感受独占模式和共享模式在使用上的区别： + +```java +import java.util.concurrent.Semaphore; +import java.util.concurrent.locks.ReentrantLock; + +public class ExclusiveVsSharedDemo { + public static void main(String[] args) { + // 独占模式：同一时刻只有 1 个线程能进入临界区 + ReentrantLock lock = new ReentrantLock(); + + // 共享模式：同一时刻最多 3 个线程能进入临界区 + Semaphore semaphore = new Semaphore(3); + + // 独占模式示例 + Runnable exclusiveTask = () -> { + lock.lock(); + try { + System.out.println(Thread.currentThread().getName() + + " 获取到独占锁，正在执行..."); + Thread.sleep(500); + } catch (InterruptedException e) { + Thread.currentThread().interrupt(); + } finally { + lock.unlock(); + } + }; + + // 共享模式示例 + Runnable sharedTask = () -> { + try { + semaphore.acquire(); + System.out.println(Thread.currentThread().getName() + + " 获取到许可证，正在执行..."); + Thread.sleep(500); + } catch (InterruptedException e) { + Thread.currentThread().interrupt(); + } finally { + semaphore.release(); + } + }; + + System.out.println("=== 独占模式（ReentrantLock）==="); + for (int i = 0; i < 5; i++) { + new Thread(exclusiveTask, "独占线程-" + i).start(); + } + + try { Thread.sleep(3000); } catch (InterruptedException e) { } + + System.out.println("\n=== 共享模式（Semaphore）==="); + for (int i = 0; i < 5; i++) { + new Thread(sharedTask, "共享线程-" + i).start(); + } + } +} +``` + +运行上面的代码可以观察到：独占模式下 5 个线程严格按顺序一个一个执行，而共享模式下最多有 3 个线程同时执行。 + ### AQS 资源获取源码分析（独占模式） AQS 中以独占模式获取资源的入口方法是 `acquire()` ，如下： @@ -929,9 +1016,296 @@ protected final boolean tryReleaseShared(int releases) { `doReleaseShared()` 方法在前文获取资源（共享模式）的部分已进行了详细的源码分析，此处不再重复。 -## 常见同步工具类 +### Condition 条件队列的工作机制 + +前面在 `waitStatus` 状态表格中提到过 `CONDITION`（值为 -2）状态，表示节点在 Condition 条件队列中等待。这里系统讲解 Condition 条件队列的工作机制。 + +#### 什么是 Condition？ + +`Condition` 是 `java.util.concurrent.locks` 包中定义的接口，它提供了类似于 `Object.wait()` / `Object.notify()` 的线程等待/通知机制，但功能更加强大和灵活。`Condition` 必须与 `Lock` 配合使用，就像 `wait/notify` 必须与 `synchronized` 配合使用一样。 + +与 `Object` 的 `wait/notify` 相比，`Condition` 的主要优势在于： + +- **支持多个等待队列**：一个 `Lock` 可以创建多个 `Condition` 实例，不同的线程可以在不同的条件上等待，实现更精细的线程协作。而 `synchronized` 只有一个等待队列。 +- **支持不响应中断的等待**：`Condition` 提供了 `awaitUninterruptibly()` 方法。 +- **支持超时等待**：`Condition` 提供了 `awaitNanos(long)` 和 `await(long, TimeUnit)` 方法，可以设定等待的截止时间。 + +#### AQS 中的两种队列 + +在 AQS 内部实际上维护了 **两种队列**： + +1. **同步队列（CLH 变体队列）**：就是前面详细分析过的双向队列，用于存放获取资源失败而等待的线程节点。 +2. **条件队列（Condition Queue）**：是一个单向链表，用于存放调用了 `Condition.await()` 方法而等待的线程节点。每个 `Condition` 实例维护一个独立的条件队列。 + +条件队列中的节点使用 `Node` 的 `nextWaiter` 指针来链接下一个节点，形成单向链表。条件队列的头节点为 `firstWaiter`，尾节点为 `lastWaiter`。 + +#### Condition 的核心工作流程 + +AQS 的内部类 `ConditionObject` 实现了 `Condition` 接口，其核心方法为 `await()` 和 `signal()`。 + +**`await()` 方法的工作流程：** + +1. 将当前线程封装为 `Node` 节点（`waitStatus` 设置为 `CONDITION`），加入到条件队列的尾部。 +2. 完全释放当前线程持有的锁（即将 `state` 值置为 0），并保存释放前的 `state` 值。 +3. 阻塞当前线程，等待被 `signal()` 唤醒或被中断。 +4. 被唤醒后，重新通过 `acquireQueued()` 进入同步队列竞争锁，并恢复之前保存的 `state` 值（重入次数）。 + +**`signal()` 方法的工作流程：** + +1. 检查调用 `signal()` 的线程是否持有锁（不持有则抛出 `IllegalMonitorStateException`）。 +2. 将条件队列中第一个等待的节点从条件队列移除。 +3. 将该节点的 `waitStatus` 从 `CONDITION` 修改为 `0`，并通过 `enq()` 方法将其加入到同步队列的尾部。 +4. 如果同步队列中前驱节点的状态异常（`CANCELLED`）或者 CAS 设置前驱节点状态为 `SIGNAL` 失败，则直接唤醒该线程。 + +`signalAll()` 方法与 `signal()` 类似，区别在于它会将条件队列中的 **所有** 节点都转移到同步队列中。 + +下面的代码示例展示了 `Condition` 的典型用法——实现一个简单的有界阻塞队列： + +```java +import java.util.LinkedList; +import java.util.Queue; +import java.util.concurrent.locks.Condition; +import java.util.concurrent.locks.ReentrantLock; + +public class SimpleBlockingQueue { + private final Queue queue = new LinkedList<>(); + private final int capacity; + private final ReentrantLock lock = new ReentrantLock(); + // 两个不同的条件队列：分别用于"队列不满"和"队列不空" + private final Condition notFull = lock.newCondition(); + private final Condition notEmpty = lock.newCondition(); + + public SimpleBlockingQueue(int capacity) { + this.capacity = capacity; + } + + /** + * 向队列中添加元素，如果队列已满则等待。 + */ + public void put(T item) throws InterruptedException { + lock.lock(); + try { + // 队列满时，在 notFull 条件上等待 + while (queue.size() == capacity) { + notFull.await(); + } + queue.offer(item); + // 添加元素后，通知在 notEmpty 条件上等待的消费者线程 + notEmpty.signal(); + } finally { + lock.unlock(); + } + } + + /** + * 从队列中取出元素，如果队列为空则等待。 + */ + public T take() throws InterruptedException { + lock.lock(); + try { + // 队列空时，在 notEmpty 条件上等待 + while (queue.isEmpty()) { + notEmpty.await(); + } + T item = queue.poll(); + // 取出元素后，通知在 notFull 条件上等待的生产者线程 + notFull.signal(); + return item; + } finally { + lock.unlock(); + } + } + + public static void main(String[] args) { + SimpleBlockingQueue blockingQueue = new SimpleBlockingQueue<>(5); + + // 生产者线程 + Thread producer = new Thread(() -> { + try { + for (int i = 0; i < 10; i++) { + blockingQueue.put(i); + System.out.println("生产: " + i); + } + } catch (InterruptedException e) { + Thread.currentThread().interrupt(); + } + }, "Producer"); + + // 消费者线程 + Thread consumer = new Thread(() -> { + try { + for (int i = 0; i < 10; i++) { + int item = blockingQueue.take(); + System.out.println("消费: " + item); + } + } catch (InterruptedException e) { + Thread.currentThread().interrupt(); + } + }, "Consumer"); + + producer.start(); + consumer.start(); + } +} +``` -下面介绍几个基于 AQS 的常见同步工具类。 +在上面的例子中，`notFull` 和 `notEmpty` 是两个独立的 `Condition` 实例，分别维护各自的条件队列。生产者在队列满时在 `notFull` 上等待，消费者在队列空时在 `notEmpty` 上等待。这种分离等待条件的设计，避免了不必要的线程唤醒，比 `synchronized` + `wait/notifyAll` 更加高效。 + +#### `await()` 核心源码分析 + +```java +// AQS 内部类 ConditionObject +public final void await() throws InterruptedException { + if (Thread.interrupted()) + throw new InterruptedException(); + // 1、将当前线程封装为 Node 节点，加入条件队列 + Node node = addConditionWaiter(); + // 2、完全释放锁，并保存释放前的 state 值 + int savedState = fullyRelease(node); + int interruptMode = 0; + // 3、如果节点不在同步队列中，则阻塞当前线程 + while (!isOnSyncQueue(node)) { + LockSupport.park(this); + if ((interruptMode = checkInterruptWhileWaiting(node)) != 0) + break; + } + // 4、被唤醒后，重新进入同步队列竞争锁 + if (acquireQueued(node, savedState) && interruptMode != THROW_IE) + interruptMode = REINTERRUPT; + if (node.nextWaiter != null) + unlinkCancelledWaiters(); + if (interruptMode != 0) + reportInterruptAfterWait(interruptMode); +} +``` + +`await()` 方法中有两个关键操作： + +- `fullyRelease(node)`：完全释放锁（而不是只释放一次），这样即使线程重入了多次锁，也能在等待期间让其他线程获取到锁。被唤醒后会通过 `acquireQueued(node, savedState)` 恢复之前的重入次数。 +- `isOnSyncQueue(node)`：判断节点是否已经被转移到同步队列。当其他线程调用 `signal()` 时，节点会从条件队列转移到同步队列，此时 `isOnSyncQueue()` 返回 `true`，线程退出 `while` 循环，开始竞争锁。 + +### 公平锁与非公平锁的性能差异分析 + +前面的源码分析中，以 `ReentrantLock` 的非公平锁为例讲解了 `tryAcquire()` 的实现。实际上 `ReentrantLock` 同时支持公平锁和非公平锁两种模式。这里深入分析二者的实现差异及其对性能的影响。 + +#### 源码层面的差异 + +`ReentrantLock` 默认使用非公平锁，通过构造参数可以切换为公平锁： + +```java +// 非公平锁（默认） +ReentrantLock unfairLock = new ReentrantLock(); +// 公平锁 +ReentrantLock fairLock = new ReentrantLock(true); +``` + +二者的核心差异在于 `tryAcquire()` 方法的实现。非公平锁的 `nonfairTryAcquire()` 前面已经分析过，下面看公平锁的实现： + +```java +// ReentrantLock.FairSync +protected final boolean tryAcquire(int acquires) { + final Thread current = Thread.currentThread(); + int c = getState(); + if (c == 0) { + // 关键差异：先调用 hasQueuedPredecessors() 判断同步队列中是否有等待更久的线程 + if (!hasQueuedPredecessors() && + compareAndSetState(0, acquires)) { + setExclusiveOwnerThread(current); + return true; + } + } + else if (current == getExclusiveOwnerThread()) { + int nextc = c + acquires; + if (nextc < 0) + throw new Error("Maximum lock count exceeded"); + setState(nextc); + return true; + } + return false; +} +``` + +**唯一的区别** 就是公平锁在 CAS 修改 `state` 之前多了一个 `hasQueuedPredecessors()` 判断： + +```java +// AQS +public final boolean hasQueuedPredecessors() { + Node t = tail; + Node h = head; + Node s; + return h != t && + ((s = h.next) == null || s.thread != Thread.currentThread()); +} +``` + +这个方法用于判断当前线程之前是否有其他线程在排队。如果有，则当前线程不能直接获取锁，必须排队等待，从而保证了 **FIFO** 的公平性。 + +而非公平锁没有这个判断，当锁刚好释放时，新来的线程可以直接通过 CAS 抢到锁，即使同步队列中已经有其他线程在等待。 + +#### 性能差异对比 + +| 对比维度 | 非公平锁（默认） | 公平锁 | +| --- | --- | --- | +| **吞吐量** | 更高。新线程有机会直接获取锁，减少了线程上下文切换 | 较低。所有线程都必须排队，增加了上下文切换的开销 | +| **线程饥饿** | 可能发生。极端情况下某些线程长时间无法获取锁 | 不会发生。严格按照请求顺序分配锁 | +| **上下文切换** | 较少。持有锁的线程释放锁后，新到达的线程可能直接获取锁，不需要唤醒队列中的线程 | 较多。每次释放锁都需要唤醒队列中的下一个线程 | +| **适用场景** | 大多数场景（对响应时间和吞吐量要求较高） | 对公平性有严格要求的场景（如资源分配、任务调度） | + +**为什么非公平锁性能通常更好？** + +关键原因在于 **减少了线程上下文切换的次数**。当持有锁的线程 A 释放锁后： + +- **非公平锁**：此时如果恰好有线程 B 正在尝试获取锁（还没有进入同步队列），线程 B 可以直接通过 CAS 获取到锁并立即执行，省去了唤醒队列中线程的开销。而队列中等待的线程被唤醒后发现锁被占用，会重新阻塞，虽然看起来"浪费"了一次唤醒，但总体上减少了线程切换次数。 +- **公平锁**：线程 B 必须排到队列尾部，然后唤醒队列头部的线程。从线程被唤醒到真正开始执行之间，存在一段 **调度延迟**（线程状态从阻塞切换到运行），在这段延迟期间锁处于空闲状态，降低了锁的利用率。 + +Doug Lea 在 `ReentrantLock` 的文档中指出：使用公平锁的程序在多线程环境下的总体吞吐量通常低于使用非公平锁的程序（即更慢），因此 `ReentrantLock` 默认使用非公平模式。但在需要保证请求处理顺序或避免线程饥饿的场景中（如连接池分配），公平锁是更好的选择。 + +下面通过代码示例来演示公平锁与非公平锁在行为上的差异： + +```java +import java.util.concurrent.locks.ReentrantLock; + +public class FairVsUnfairLockDemo { + // 分别测试公平锁和非公平锁 + private static void testLock(ReentrantLock lock, String lockType) { + System.out.println("=== " + lockType + " ==="); + Runnable task = () -> { + for (int i = 0; i < 2; i++) { + lock.lock(); + try { + System.out.println(Thread.currentThread().getName() + " 获取到锁"); + } finally { + lock.unlock(); + } + } + }; + + Thread[] threads = new Thread[5]; + for (int i = 0; i < 5; i++) { + threads[i] = new Thread(task, lockType + "-线程-" + i); + } + for (Thread t : threads) { + t.start(); + } + for (Thread t : threads) { + try { t.join(); } catch (InterruptedException e) { } + } + System.out.println(); + } + + public static void main(String[] args) { + // 非公平锁：同一个线程可能连续多次获取到锁 + testLock(new ReentrantLock(false), "非公平锁"); + + // 公平锁：线程按请求顺序交替获取锁 + testLock(new ReentrantLock(true), "公平锁"); + } +} +``` + +运行上面的代码可以观察到：非公平锁模式下，同一个线程可能连续多次获取到锁（因为它释放锁后立即又去竞争，有很大概率在队列中的线程被唤醒之前就抢到了锁）；而公平锁模式下，线程获取锁的顺序更加均匀，不会出现某个线程连续霸占锁的情况。 + +## 常见同步工具类 ### Semaphore(信号量) @@ -1610,3 +1984,4 @@ threadnum:7is finish - 从 ReentrantLock 的实现看 AQS 的原理及应用： +```` diff --git a/docs/java/concurrent/java-concurrent-questions-02.md b/docs/java/concurrent/java-concurrent-questions-02.md index f261cd10129..78c82fc9140 100644 --- a/docs/java/concurrent/java-concurrent-questions-02.md +++ b/docs/java/concurrent/java-concurrent-questions-02.md @@ -44,6 +44,49 @@ public native void fullFence(); 理论上来说，你通过这个三个方法也可以实现和`volatile`禁止重排序一样的效果，只是会麻烦一些。 +#### 4 种内存屏障类型 + +JMM（Java 内存模型）定义了 4 种内存屏障（Memory Barrier），用于控制特定条件下的指令重排序和内存可见性： + +| 屏障类型 | 指令示例 | 说明 | +| --- | --- | --- | +| **LoadLoad** | `Load1; LoadLoad; Load2` | 保证 `Load1` 的读取操作在 `Load2` 及其后续读取操作之前完成 | +| **StoreStore** | `Store1; StoreStore; Store2` | 保证 `Store1` 的写入操作对其他处理器可见（刷新到内存），先于 `Store2` 及其后续写入操作 | +| **LoadStore** | `Load1; LoadStore; Store2` | 保证 `Load1` 的读取操作在 `Store2` 及其后续写入操作刷新到内存之前完成 | +| **StoreLoad** | `Store1; StoreLoad; Load2` | 保证 `Store1` 的写入操作对其他处理器可见，先于 `Load2` 及其后续读取操作。`StoreLoad` 屏障的开销是四种屏障中最大的，它同时具有其他三种屏障的效果，因此也称为 **全能屏障（Full Barrier）** | + +#### volatile 读写操作的内存屏障插入策略 + +JMM 针对编译器制定了 `volatile` 读写操作的内存屏障插入策略，以确保在任意处理器平台上都能获得正确的 volatile 内存语义： + +**volatile 写操作的内存屏障插入策略：** + +在每个 volatile 写操作的 **前面** 插入一个 `StoreStore` 屏障，在 **后面** 插入一个 `StoreLoad` 屏障。 + +``` +StoreStore 屏障 +volatile 写操作 +StoreLoad 屏障 +``` + +- 前面的 `StoreStore` 屏障：保证在 volatile 写之前，其前面的所有普通写操作已经对任意处理器可见（刷新到主内存）。 +- 后面的 `StoreLoad` 屏障：保证 volatile 写之后，其写入的值对后续的 volatile 读/写操作可见。这是开销最大的屏障，但也是最关键的——它避免了 volatile 写与后面可能有的 volatile 读/写操作发生重排序。 + +**volatile 读操作的内存屏障插入策略：** + +在每个 volatile 读操作的 **后面** 插入一个 `LoadLoad` 屏障和一个 `LoadStore` 屏障。 + +``` +volatile 读操作 +LoadLoad 屏障 +LoadStore 屏障 +``` + +- `LoadLoad` 屏障：保证 volatile 读之后的普通读操作不会被重排序到 volatile 读之前。 +- `LoadStore` 屏障：保证 volatile 读之后的普通写操作不会被重排序到 volatile 读之前。 + +这样一来，volatile 写-读的组合就建立了一个类似于 **锁的释放-获取** 的语义：**volatile 写操作之前的所有操作结果，对于后续对该 volatile 变量的读操作之后的所有操作都是可见的。** + 下面我以一个常见的面试题为例讲解一下 `volatile` 关键字禁止指令重排序的效果。 面试中面试官经常会说：“单例模式了解吗？来给我手写一下！给我解释一下双重检验锁方式实现单例模式的原理呗！” @@ -81,6 +124,67 @@ public class Singleton { 但是由于 JVM 具有指令重排的特性，执行顺序有可能变成 1->3->2。指令重排在单线程环境下不会出现问题，但是在多线程环境下会导致一个线程获得还没有初始化的实例。例如，线程 T1 执行了 1 和 3，此时 T2 调用 `getUniqueInstance`() 后发现 `uniqueInstance` 不为空，因此返回 `uniqueInstance`，但此时 `uniqueInstance` 还未被初始化。 +#### 从内存屏障角度理解 DCL 必须使用 volatile + +上面从指令重排序的角度解释了 DCL 单例中 `uniqueInstance` 为什么需要 `volatile` 修饰。下面从内存屏障的角度进一步分析 `volatile` 是如何解决这个问题的。 + +`uniqueInstance = new Singleton();` 这行代码的三个步骤（分配内存、初始化对象、赋值引用）中，如果不加 `volatile`，步骤 2 和步骤 3 可能会被重排序为 1→3→2。加了 `volatile` 之后，由于 `uniqueInstance` 是 volatile 变量，对它的写操作（步骤 3：将引用赋值给 `uniqueInstance`）会按照前面介绍的 volatile 写的内存屏障插入策略来处理： + +1. 在 volatile 写 **之前** 插入 `StoreStore` 屏障：保证步骤 1（分配内存）和步骤 2（初始化对象）的写操作在步骤 3（赋值引用）之前完成，**禁止了步骤 2 和步骤 3 的重排序**。 +2. 在 volatile 写 **之后** 插入 `StoreLoad` 屏障：保证步骤 3 的写入结果对其他线程立即可见。 + +这样，当线程 T2 读取 `uniqueInstance` 时（volatile 读），如果发现 `uniqueInstance != null`，那么可以保证该对象一定已经被完全初始化了。 + +### volatile 与 happens-before 的关系 + +JMM 中的 happens-before 原则是判断数据是否存在竞争、线程是否安全的重要依据。`volatile` 变量的读写操作与 happens-before 原则有着密切的关系。 + +> 关于 happens-before 原则的详细介绍，可以参考 [JMM（Java 内存模型）详解](https://javaguide.cn/java/concurrent/jmm.html) 这篇文章。 + +happens-before 原则中与 `volatile` 直接相关的是 **volatile 变量规则**： + +> **对一个 volatile 变量的写操作 happens-before 于后续对该 volatile 变量的读操作。** + +也就是说，如果线程 A 写入了一个 volatile 变量，线程 B 随后读取了同一个 volatile 变量，那么线程 A 在写入 volatile 变量之前所做的所有修改（包括对非 volatile 变量的修改），对线程 B 都是可见的。 + +这个规则配合 happens-before 的 **传递性规则**（如果 A happens-before B，B happens-before C，那么 A happens-before C），可以实现一种轻量级的线程间通信。下面通过一个示例来说明： + +```java +public class VolatileHappensBeforeDemo { + private int a = 0; + private int b = 0; + private volatile boolean flag = false; + + // 线程 A 执行 + public void writer() { + a = 1; // 操作1：普通写 + b = 2; // 操作2：普通写 + flag = true; // 操作3：volatile 写 + } + + // 线程 B 执行 + public void reader() { + if (flag) { // 操作4：volatile 读 + int x = a; // 操作5：普通读，x 一定等于 1 + int y = b; // 操作6：普通读，y 一定等于 2 + System.out.println("x=" + x + ", y=" + y); + } + } +} +``` + +上面代码中，happens-before 关系链如下： + +1. 操作1、操作2 happens-before 操作3（**程序顺序规则**：同一线程中，前面的操作 happens-before 后面的操作） +2. 操作3 happens-before 操作4（**volatile 变量规则**：volatile 写 happens-before volatile 读） +3. 操作4 happens-before 操作5、操作6（**程序顺序规则**） + +根据 **传递性**：操作1、操作2 happens-before 操作5、操作6。 + +因此，当线程 B 在操作4 读取到 `flag == true` 时，线程 A 在操作3 之前对 `a` 和 `b` 的修改对线程 B 一定是可见的。这里的关键在于：**volatile 变量的写-读操作，不仅保证了 volatile 变量本身的可见性，还通过 happens-before 的传递性"顺带"保证了其前后普通变量的可见性。** + +这也解释了为什么在实际开发中，`volatile` 经常被用作 **状态标志位**（如上面例子中的 `flag`），它可以在不使用锁的情况下，安全地在线程间传递状态信息，同时保证相关数据的可见性。 + ### volatile 可以保证原子性么？ **`volatile` 关键字能保证变量的可见性，但不能保证对变量的操作是原子性的。** @@ -616,6 +720,29 @@ Open JDK 官方声明：[JEP 374: Deprecate and Disable Biased Locking](https:// - `volatile` 关键字能保证数据的可见性，但不能保证数据的原子性。`synchronized` 关键字两者都能保证。 - `volatile`关键字主要用于解决变量在多个线程之间的可见性，而 `synchronized` 关键字解决的是多个线程之间访问资源的同步性。 +#### volatile 与 synchronized 的性能对比 + +上面提到 `volatile` 是线程同步的轻量级实现，性能比 `synchronized` 要好。下面从底层原理的角度分析为什么 `volatile` 性能更好，以及在什么情况下应该选择哪个。 + +周志明在《深入理解 Java 虚拟机》中指出： + +> volatile 变量的读操作的性能消耗与普通变量几乎没有什么差别，但是写操作则可能会慢上一些，因为它需要在本地代码中插入许多内存屏障指令来保证处理器不发生乱序执行。不过即便如此，大多数场景下 volatile 的总开销仍然要比锁来得更低。 + +二者性能差异的根本原因在于底层实现机制不同： + +| 对比维度 | `volatile` | `synchronized` | +| --- | --- | --- | +| **实现层面** | 通过插入内存屏障指令实现，不涉及线程阻塞和上下文切换 | 依赖操作系统的互斥锁（Mutex Lock），涉及用户态与内核态的切换 | +| **读操作开销** | 与普通变量几乎相同 | 需要获取 monitor 锁，即使无竞争也有一定开销（偏向锁/轻量级锁 CAS） | +| **写操作开销** | 需要插入 `StoreStore` + `StoreLoad` 内存屏障，有一定开销但不会导致线程阻塞 | 需要获取和释放 monitor 锁，有竞争时会导致线程阻塞和上下文切换 | +| **竞争时的表现** | 不会导致线程阻塞，始终是非阻塞的 | 线程竞争激烈时，会频繁发生阻塞和唤醒，上下文切换开销大 | +| **功能范围** | 只能修饰变量，只保证可见性和有序性 | 可以修饰方法和代码块，同时保证可见性、有序性和原子性 | + +**选择建议：** + +- 如果只需要保证变量的可见性（如状态标志位、DCL 单例中的实例引用），优先使用 `volatile`，因为它的开销更小。 +- 如果需要保证复合操作的原子性（如 `i++`、先检查后执行等），则必须使用 `synchronized`、`Lock` 或原子类，`volatile` 无法胜任。 + ## ReentrantLock ### ReentrantLock 是什么？ diff --git a/docs/java/concurrent/java-concurrent-questions-03.md b/docs/java/concurrent/java-concurrent-questions-03.md index a13da622d83..ef3b3269bcd 100644 --- a/docs/java/concurrent/java-concurrent-questions-03.md +++ b/docs/java/concurrent/java-concurrent-questions-03.md @@ -160,6 +160,80 @@ static class Entry extends WeakReference> { 1. 在使用完 `ThreadLocal` 后，务必调用 `remove()` 方法。 这是最安全和最推荐的做法。 `remove()` 方法会从 `ThreadLocalMap` 中显式地移除对应的 entry，彻底解决内存泄漏的风险。 即使将 `ThreadLocal` 定义为 `static final`，也强烈建议在每次使用后调用 `remove()`。 2. 在线程池等线程复用的场景下，使用 `try-finally` 块可以确保即使发生异常，`remove()` 方法也一定会被执行。 +#### 为什么 Entry 的 key 要设计为弱引用？ + +这是一个经典的面试追问。很多同学知道 `ThreadLocalMap` 的 key 是弱引用，但不清楚**为什么要这样设计**，以及如果换成强引用会怎样。 + +我们先来看完整的引用链路。当一个线程使用 `ThreadLocal` 时，涉及以下引用关系： + +``` +强引用（栈/静态变量）──→ ThreadLocal 实例 + ↑ +Thread ──→ ThreadLocalMap ──→ Entry ─── key（WeakReference）──┘ + │ + └─── value（强引用）──→ 实际存储的对象 +``` + +理解了这条引用链路，我们来对比两种设计方案： + +**假设 key 使用强引用（实际没有采用）：** + +当业务代码中的 `ThreadLocal` 引用被置为 `null`（例如方法执行结束、对象被回收），此时虽然业务代码已经不再需要这个 `ThreadLocal`，但由于 `ThreadLocalMap` 的 Entry 对 key 持有**强引用**，`ThreadLocal` 实例仍然无法被 GC 回收。只要线程不终止，这个 `ThreadLocal` 和它对应的 value 都会一直存在于内存中，造成 key 和 value **都无法回收**的内存泄漏。 + +**key 使用弱引用（实际采用的方案）：** + +当业务代码中的 `ThreadLocal` 引用被置为 `null` 后，由于 Entry 的 key 是弱引用，`ThreadLocal` 实例在下次 GC 时会被回收，key 变为 `null`。此时虽然 value 仍然存在（强引用），但 `ThreadLocalMap` 在执行 `get()`、`set()`、`remove()` 等操作时，会主动探测并清理这些 key 为 `null` 的 "stale entry"（过期条目），从而释放 value 对象。 + +也就是说，**弱引用的设计是一种"兜底"防御机制**——即便开发者忘记调用 `remove()`，JVM 的 GC 配合 `ThreadLocalMap` 的自清理逻辑，仍然有机会回收泄漏的数据。而如果使用强引用，一旦忘记 `remove()`，就完全没有任何补救机会了。 + +> 需要注意的是，这种自清理机制是**被动触发**的（只在 `get`/`set`/`remove` 操作时顺便清理），并不能保证所有过期条目都被及时清理。因此，**弱引用只是降低了内存泄漏的风险，并没有彻底消除它**，手动调用 `remove()` 仍然是必须的。 + +#### 线程池场景下的特殊风险 + +上面提到内存泄漏的条件之一是"线程持续存活"。在使用 `new Thread()` 创建线程的场景下，线程执行完毕后会被销毁，其持有的 `ThreadLocalMap` 也会随之被 GC 回收，泄漏的影响相对有限。 + +但在**线程池**场景下，问题会被严重放大。线程池中的核心线程默认不会被销毁，它们会被反复复用来执行不同的任务。这意味着： + +1. **内存泄漏持续累积**：每个任务如果使用了 `ThreadLocal` 却没有清理，其 value 就会一直残留在该线程的 `ThreadLocalMap` 中。随着任务不断提交和执行，泄漏的数据会越积越多，最终可能导致 OOM。 +2. **数据污染（脏数据）**：上一个任务设置的 `ThreadLocal` 值，如果没有被清理，下一个被分配到同一线程的任务就能读取到这个残留值。这可能导致严重的业务逻辑错误，比如用户 A 的请求读取到了用户 B 的身份信息。 + +**美团技术团队的真实事故案例：** + +美团技术团队在[《Java 线程池实现原理及其在美团业务中的实践》](https://tech.meituan.com/2020/04/02/java-pooling-pratice-in-meituan.html)一文中就记录了一次因 `ThreadLocal` 使用不当引发的线上事故：在一个依赖 `ThreadLocal` 传递用户上下文的 Web 应用中，由于使用了线程池处理请求，且没有在请求结束后清理 `ThreadLocal`，导致**后续请求复用了同一线程时，读取到了前一个请求遗留的用户信息**，造成了用户数据串号的严重问题。 + +#### 阿里巴巴 Java 开发手册的强制规约 + +正因为线程池 + `ThreadLocal` 的组合如此容易踩坑，《阿里巴巴 Java 开发手册》在"并发处理"章节中对此做出了**强制**级别的要求： + +> **【强制】** 必须回收自定义的 `ThreadLocal` 变量记录的当前线程的值，尤其在线程池场景下，线程经常会被复用，如果不清理自定义的 `ThreadLocal` 变量，可能会影响后续业务逻辑和造成内存泄露等问题。尽量在代理中使用 `try-finally` 块进行回收。 + +正确的使用模式如下： + +```java +// 定义为 static final，避免重复创建 ThreadLocal 实例 +private static final ThreadLocal userContextHolder = new ThreadLocal<>(); + +public void processRequest(HttpServletRequest request) { + try { + // 在 try 块中设置值 + UserContext context = buildUserContext(request); + userContextHolder.set(context); + + // 执行业务逻辑 + doBusinessLogic(); + } finally { + // 在 finally 块中必须清理，确保无论是否发生异常都会执行 + userContextHolder.remove(); + } +} +``` + +这里有三个关键要点： + +1. **`ThreadLocal` 声明为 `static final`**：确保整个应用只有一个 `ThreadLocal` 实例，避免因重复创建导致旧实例失去强引用后 key 被回收，加剧内存泄漏。 +2. **`try-finally` 保证 `remove()` 一定被执行**：即使业务逻辑抛出异常，`finally` 块也能确保 `ThreadLocal` 被清理。 +3. **在使用完毕后立即清理，而不是在下次使用前设置**：在使用前 `set()` 虽然可以覆盖旧值解决脏数据问题，但无法解决上一次任务遗留 value 的内存占用问题。只有在用完后 `remove()`，才能同时避免内存泄漏和数据污染。 + ### ⭐️如何跨线程传递 ThreadLocal 的值？ **为什么 ThreadLocal 在异步场景下会失效？** diff --git a/docs/java/concurrent/java-thread-pool-summary.md b/docs/java/concurrent/java-thread-pool-summary.md index 100a2ff4d27..9e83f33df3a 100644 --- a/docs/java/concurrent/java-thread-pool-summary.md +++ b/docs/java/concurrent/java-thread-pool-summary.md @@ -136,6 +136,32 @@ public class ScheduledThreadPoolExecutor ![线程池各个参数的关系](https://oss.javaguide.cn/github/javaguide/java/concurrent/relationship-between-thread-pool-parameters.png) +### 线程池生命周期状态 + +`ThreadPoolExecutor` 使用 `ctl` 变量（`AtomicInteger` 类型）同时管理线程池的运行状态和工作线程数量。线程池共有 5 种状态： + +- **运行中（`RUNNING`）**：接受新任务，并处理队列中的任务。线程池创建后的初始状态。 +- **关闭（`SHUTDOWN`）**：不再接受新任务，但会继续处理队列中已有的任务。调用 `shutdown()` 后进入。 +- **停止（`STOP`）**：不接受新任务，不处理队列中的任务，并尝试中断正在执行的任务。调用 `shutdownNow()` 后进入。 +- **整理中（`TIDYING`）**：所有任务已终止，工作线程数为 0，即将执行 `terminated()` 钩子方法。 +- **已终止（`TERMINATED`）**：`terminated()` 方法执行完毕，线程池彻底终结。 + +状态只能单向流转：运行中（`RUNNING`）→ 关闭（`SHUTDOWN`）→ 整理中（`TIDYING`）→ 已终止（`TERMINATED`），或者运行中（`RUNNING`）→ 停止（`STOP`）→ 整理中（`TIDYING`）→ 已终止（`TERMINATED`）。在关闭（`SHUTDOWN`）状态下再调用 `shutdownNow()` 也会转为停止（`STOP`）。 + +`shutdown()` 是"温和关闭"——中断空闲线程，但队列中的任务仍会执行完毕。`shutdownNow()` 是"强制关闭"——尝试中断所有正在运行的线程，并将队列中未执行的任务以 `List` 返回。`terminated()` 是一个空的钩子方法，可以通过继承 `ThreadPoolExecutor` 来重写它，用于在线程池终止后做清理工作。 + +### Worker 工作线程机制 + +`ThreadPoolExecutor` 将每个工作线程封装为内部类 `Worker`。`Worker` 继承了 AQS 并实现了 `Runnable` 接口。 + +**为什么 `Worker` 要继承 AQS？** `Worker` 实现了一个**不可重入的独占锁**，用于配合 `shutdown()` 区分线程是空闲还是正在工作——正在执行任务的 Worker 持有锁，`shutdown()` 对每个 Worker 尝试 `tryLock()`，失败则说明该线程正在工作，不会被中断。 + +**Worker 的生命周期：** + +1. **创建**：`execute()` 判断需要新建线程时，调用 `addWorker()` 创建 `Worker` 实例，内部通过 `ThreadFactory` 创建线程。 +2. **运行**：线程启动后进入 `runWorker()` 的 `while` 循环，通过 `getTask()` 不断从队列取任务执行。核心线程用 `workQueue.take()`（阻塞等待），非核心线程用 `workQueue.poll(keepAliveTime, unit)`（超时等待）。 +3. **退出**：`getTask()` 返回 `null` 时 Worker 退出循环并清理。返回 `null` 的情况包括：线程池处于停止（`STOP`）状态、线程池处于关闭（`SHUTDOWN`）状态且队列为空、非核心线程等待超时、或运行时缩小了 `maximumPoolSize`。如果退出后工作线程数低于核心数，会自动补充一个新线程。 + **`ThreadPoolExecutor` 拒绝策略定义:** 如果当前同时运行的线程数量达到最大线程数量并且队列也已经被放满了任务时，`ThreadPoolExecutor` 定义一些策略: @@ -163,6 +189,20 @@ public static class CallerRunsPolicy implements RejectedExecutionHandler { } ``` +### 4 种拒绝策略的实际应用场景 + +上面介绍了 4 种内置拒绝策略的基本行为，下面结合实际生产经验，说明它们各自适合什么场景： + +**`AbortPolicy`**：适用于对任务丢失零容忍的核心业务（如支付、转账）。任务被拒绝时调用方会收到 `RejectedExecutionException`，必须在业务代码中捕获并做补偿（如重试或持久化到数据库后补偿执行）。《阿里巴巴 Java 开发手册》指出，如果不做任何配置，队列满时会直接抛异常，开发者必须显式处理。 + +**`CallerRunsPolicy`**：适用于不允许丢弃任务、且允许降低提交速度的场景。由于任务在调用者线程中执行，调用者在此期间无法提交新任务，形成了一种天然的**反压（back-pressure）**机制。美团技术团队在《Java 线程池实现原理及其在美团业务中的实践》中提到，这是他们线上业务中较常使用的拒绝策略。但需要注意：如果提交任务的线程是 Web 容器的请求处理线程（如 Tomcat 的 Worker 线程），会导致该请求响应时间显著增加，在延迟敏感的场景中需谨慎。 + +**`DiscardPolicy`**：适用于任务允许丢失的非关键路径，如日志异步写入、监控指标上报。该策略完全静默（空实现），被拒绝的任务不会留下任何痕迹，排查问题时可能难以发现任务丢失。 + +**`DiscardOldestPolicy`**：适用于只关心最新数据、旧任务可被覆盖的场景，如实时行情推送、传感器数据采集。需要注意：如果使用了 `PriorityBlockingQueue`，`poll()` 弹出的是优先级最高的任务而非最旧的任务，可能导致重要任务被误丢。 + +**生产环境中的常见做法**：以上 4 种内置策略往往不能完全满足需求。Dubbo 框架自定义了 `AbortPolicyWithReport` 策略，在抛异常之外还会将被拒绝的任务信息 dump 到本地文件，方便事后排查。美团技术团队建议对线程池的拒绝次数进行监控和告警。常见的自定义策略思路包括：将被拒绝的任务写入数据库或消息队列后续补偿消费、递增监控计数器上报 Prometheus、或者调用 `workQueue.put(r)` 阻塞等待队列有空位（Netty 中有类似实现）。 + ### 线程池创建的两种方式 在 Java 中，创建线程池主要有两种方式： @@ -740,7 +780,7 @@ Exception in thread "main" java.util.concurrent.TimeoutException #### 为什么不推荐使用`SingleThreadExecutor`？ -`SingleThreadExecutor` 和 `FixedThreadPool` 一样，使用的都是容量为 `Integer.MAX_VALUE` 的 `LinkedBlockingQueue`（无界队列）作为线程池的工作队列。`SingleThreadExecutor` 使用无界队列作为线程池的工作队列会对线程池带来的影响与 `FixedThreadPool` 相同。说简单点，就是可能会导致 OOM。 +`SingleThreadExecutor` 和 `FixedThreadPool` 一样，使用的都是容量为 `Integer.MAX_VALUE` 的 `LinkedBlockingQueue`（无界队列）。`SingleThreadExecutor` 使用无界队列作为线程池的工作队列会对线程池带来的影响与 `FixedThreadPool` 相同。说简单点，就是可能会导致 OOM。 ### CachedThreadPool diff --git a/docs/java/new-features/java25.md b/docs/java/new-features/java25.md index 451e8100f28..363b3d8bb6a 100644 --- a/docs/java/new-features/java25.md +++ b/docs/java/new-features/java25.md @@ -30,7 +30,9 @@ JDK 25 共有 18 个新特性，这篇文章会挑选其中较为重要的一些 ![](https://oss.javaguide.cn/github/javaguide/java/new-features/jdk8~jdk24.png) -## JEP 506: 作用域值 +## JDK 25 + +### JEP 506: 作用域值 作用域值（Scoped Values）可以在线程内和线程间共享不可变的数据，优于线程局部变量 `ThreadLocal` ，尤其是在使用大量虚拟线程时。 @@ -47,7 +49,7 @@ ScopedValue.where(V, ) 作用域值通过其“写入时复制”(copy-on-write)的特性，保证了数据在线程间的隔离与安全，同时性能极高，占用内存也极低。这个特性将成为未来 Java 并发编程的标准实践。 -## JEP 512: 紧凑源文件与实例主方法 +### JEP 512: 紧凑源文件与实例主方法 该特性第一次预览是由 [JEP 445](https://openjdk.org/jeps/445 "JEP 445") （JDK 21 ）提出，随后经过了 JDK 22 、JDK 23 和 JDK 24 的改进和完善，最终在 JDK 25 顺利转正。 @@ -71,7 +73,7 @@ void main() { 这是为了降低 Java 的学习门槛和提升编写小型程序、脚本的效率而迈出的一大步。初学者不再需要理解 `public static void main(String[] args)` 这一长串复杂的声明。对于快速原型验证和脚本编写，这也使得 Java 成为一个更有吸引力的选择。 -## JEP 519: 紧凑对象头 +### JEP 519: 紧凑对象头 该特性第一次预览是由 [JEP 450](https://openjdk.org/jeps/450 "JEP 450") （JDK 24 ）提出，JDK 25 就顺利转正了。 @@ -83,7 +85,7 @@ void main() { `$ java -XX:+UnlockExperimentalVMOptions -XX:+UseCompactObjectHeaders ...` ； - JDK 25 之后仅需 `-XX:+UseCompactObjectHeaders` 即可启用。 -## JEP 521: 分代 Shenandoah GC +### JEP 521: 分代 Shenandoah GC Shenandoah GC 在 JDK12 中成为正式可生产使用的 GC，默认关闭，通过 `-XX:+UseShenandoahGC` 启用。 @@ -96,7 +98,7 @@ Shenandoah GC 需要通过命令启用： - JDK 24 需通过命令行参数组合启用：`-XX:+UseShenandoahGC -XX:+UnlockExperimentalVMOptions -XX:ShenandoahGCMode=generational` - JDK 25 之后仅需 `-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational` 即可启用。 -## JEP 507: 模式匹配支持基本类型 (第三次预览) +### JEP 507: 模式匹配支持基本类型 (第三次预览) 该特性第一次预览是由 [JEP 455](https://openjdk.org/jeps/455 "JEP 455") （JDK 23 ）提出。 @@ -112,7 +114,7 @@ static void test(Object obj) { 这样就可以像处理对象类型一样，对基本类型进行更安全、更简洁的类型匹配和转换，进一步消除了 Java 中的模板代码。 -## JEP 505: 结构化并发(第五次预览) +### JEP 505: 结构化并发(第五次预览) JDK 19 引入了结构化并发，一种多线程编程方法，目的是为了通过结构化并发 API 来简化多线程编程，并不是为了取代`java.util.concurrent`，目前处于孵化器阶段。 @@ -136,7 +138,7 @@ JDK 19 引入了结构化并发，一种多线程编程方法，目的是为了 结构化并发非常适合虚拟线程，虚拟线程是 JDK 实现的轻量级线程。许多虚拟线程共享同一个操作系统线程，从而允许非常多的虚拟线程。 -## JEP 511: 模块导入声明 +### JEP 511: 模块导入声明 该特性第一次预览是由 [JEP 476](https://openjdk.org/jeps/476 "JEP 476") （JDK 23 ）提出，随后在 [JEP 494](https://openjdk.org/jeps/494 "JEP 494") （JDK 24）中进行了完善，JDK 25 顺利转正。 @@ -161,7 +163,7 @@ public class Example { } ``` -## JEP 513: 灵活的构造函数体 +### JEP 513: 灵活的构造函数体 该特性第一次预览是由 [JEP 447](https://openjdk.org/jeps/447 "JEP 447") （JDK 22）提出，随后在 [JEP 482 ](https://openjdk.org/jeps/482 "JEP 482 ")（JDK 23）和 [JEP 492](https://openjdk.org/jeps/492 "JEP 492") （JDK 24）经历了预览，JDK 25 顺利转正。 @@ -197,7 +199,7 @@ class Employee extends Person { } ``` -## JEP 508: 向量 API(第十次孵化) +### JEP 508: 向量 API(第十次孵化) 向量计算由对向量的一系列操作组成。向量 API 用来表达向量计算，该计算可以在运行时可靠地编译为支持的 CPU 架构上的最佳向量指令，从而实现优于等效标量计算的性能。 diff --git a/docs/java/new-features/java26.md b/docs/java/new-features/java26.md new file mode 100644 index 00000000000..44dbe12cd6c --- /dev/null +++ b/docs/java/new-features/java26.md @@ -0,0 +1,324 @@ +--- +title: Java 26 新特性概览 +description: 概览 JDK 26 的关键新特性与预览改动，关注 HTTP/3、GC 性能优化、AOT 缓存与语言/平台增强。 +category: Java +tag: + - Java新特性 +head: + - - meta + - name: keywords + content: Java 26,JDK26,HTTP/3,G1 GC,AOT 缓存,延迟常量,结构化并发,向量 API,模式匹配 +--- + +JDK 26 于 2026 年 3 月 17 日 发布，这是一个非 LTS（非长期支持版）版本。上一个长期支持版是 **JDK 25**，下一个长期支持版预计是 **JDK 29**。 + +JDK 26 共有 10 个新特性，这篇文章会挑选其中较为重要的一些新特性进行详细介绍： + +- [JEP 517: HTTP/3 for the HTTP Client API (为 HTTP Client API 引入 HTTP/3 支持)](https://openjdk.org/jeps/517) +- [JEP 522: G1 GC: Improve Throughput by Reducing Synchronization (G1 GC 吞吐量优化)](https://openjdk.org/jeps/522) +- [JEP 516: Ahead-of-Time Object Caching with Any GC (AOT 对象缓存支持任意 GC)](https://openjdk.org/jeps/516) +- [JEP 500: Prepare to Make Final Mean Final (准备让 final 真正不可变)](https://openjdk.org/jeps/500) +- [JEP 526: Lazy Constants (延迟常量, 第二次预览)](https://openjdk.org/jeps/526) +- [JEP 525: Structured Concurrency (结构化并发, 第六次预览)](https://openjdk.org/jeps/525) +- [JEP 530: Primitive Types in Patterns, instanceof, and switch (模式匹配支持基本类型, 第四次预览)](https://openjdk.org/jeps/530) +- [JEP 524: PEM Encodings of Cryptographic Objects (加密对象 PEM 编码, 第二次预览)](https://openjdk.org/jeps/524) +- [JEP 529: Vector API (向量 API, 第十一次孵化)](https://openjdk.org/jeps/529) +- [JEP 504: Remove the Applet API (移除 Applet API)](https://openjdk.org/jeps/504) + +下图是从 JDK 8 到 JDK 25 每个版本的更新带来的新特性数量和更新时间： + +![](https://oss.javaguide.cn/github/javaguide/java/new-features/jdk8~jdk24.png) + +## JEP 517: 为 HTTP Client API 引入 HTTP/3 支持 + +JDK 26 为 `java.net.http.HttpClient` API 正式添加了 **HTTP/3** 支持，这是一个期待已久的重要更新。 + +**HTTP/3 的优势**： + +- **基于 QUIC 协议**：HTTP/2 是基于 TCP 协议实现的，HTTP/3 新增了 QUIC（Quick UDP Internet Connections） 协议来实现可靠的传输，提供与 TLS/SSL 相当的安全性，具有较低的连接和传输延迟。你可以将 QUIC 看作是 UDP 的升级版本，在其基础上新增了很多功能比如加密、重传等等。 +- **消除队头阻塞**：HTTP/2 多请求复用一个 TCP 连接，一旦发生丢包，就会阻塞住所有的 HTTP 请求。由于 QUIC 协议的特性，HTTP/3 在一定程度上解决了队头阻塞（Head-of-Line blocking, 简写：HOL blocking）问题，一个连接建立多个不同的数据流，这些数据流之间独立互不影响，某个数据流发生丢包了，其数据流不受影响（本质上是多路复用+轮询）。 +- **更快的连接建立**：HTTP/2 需要经过经典的 TCP 三次握手过程（由于安全的 HTTPS 连接建立还需要 TLS 握手，共需要大约 3 个 RTT）。由于 QUIC 协议的特性（TLS 1.3，TLS 1.3 除了支持 1 个 RTT 的握手，还支持 0 个 RTT 的握手）连接建立仅需 0-RTT 或者 1-RTT。这意味着 QUIC 在最佳情况下不需要任何的额外往返时间就可以建立新连接。 +- **更好的移动端体验**：HTTP/3.0 支持连接迁移，因为 QUIC 使用 64 位 ID 标识连接，只要 ID 不变就不会中断，网络环境改变时（如从 Wi-Fi 切换到移动数据）也能保持连接。而 TCP 连接是由（源 IP，源端口，目的 IP，目的端口）组成，这个四元组中一旦有一项值发生改变，这个连接也就不能用了。 + +详细介绍可以阅读这篇文章：[计算机网络常见面试题总结（上）](https://javaguide.cn/cs-basics/network/other-network-questions.html)（网络分层模型、常见网路协议总结、HTTP、WebSocket、DNS 等） + +**使用方式**： + +HTTP/3 的使用非常简单，几乎不需要修改现有代码。`HttpClient` 会自动协商使用最高版本的 HTTP 协议： + +```java +HttpClient client = HttpClient.newHttpClient(); + +HttpRequest request = HttpRequest.newBuilder() + .uri(URI.create("https://example.com")) + .build(); + +// 如果服务器支持 HTTP/3，HttpClient 会自动升级使用 +HttpResponse response = client.send(request, + HttpResponse.BodyHandlers.ofString()); + +System.out.println(response.body()); +``` + +如果需要明确指定使用 HTTP/3，可以通过 `version()` 方法设置： + +```java +// 所有请求默认优先使用 HTTP/3 +HttpClient client = HttpClient.newBuilder() + .version(HttpClient.Version.HTTP_3) // 明确指定 HTTP/3 + .build(); + +// 设置单个HttpRequest对象的首选协议版本 +HttpRequest request = HttpRequest.newBuilder(URI.create("https://javaguide.cn/")) + .version(HttpClient.Version.HTTP_3) + .GET().build(); +``` + +## JEP 522: G1 GC 吞吐量优化 + +**从 JDK9 开始，G1 垃圾收集器成为了默认的垃圾收集器。** 它在延迟和吞吐量之间寻求平衡。然而，这种平衡有时会影响应用程序的性能。与面向吞吐量的 Parallel GC 相比，G1 更多地与应用程序并发工作，以减少 GC 暂停时间。但这意味着应用线程必须与 GC 线程共享 CPU 并进行协调，这种同步会降低吞吐量并增加延迟。 + +JEP 522 引入了**双卡表（Card Table）**机制： + +1. **第一张卡表**：应用线程的写屏障在更新这张卡表时**无需任何同步**，使得写屏障代码更简单、更快速。 +2. **第二张卡表**：优化器线程在后台并行处理这张初始为空的卡表。 + +当 G1 检测到扫描第一张卡表可能超过暂停时间目标时，它会原子性地交换这两张卡表。应用线程继续更新空的、原先的第二张表，而优化器线程则处理满的、原先的第一张表，无需进一步同步。 + +**性能提升效果**： + +- 在**频繁修改对象引用字段**的应用中，吞吐量提升 **5-15%** +- 即使在不频繁修改引用字段的应用中，由于写屏障简化（x64 上从约 50 条指令减少到仅 12 条），吞吐量也能提升高达 **5%** +- GC 暂停时间也有**轻微下降** + +**内存开销**： + +第二张卡表与第一张容量相同，每张卡表需要 Java 堆容量的 0.2%，即每 1GB 堆内存额外使用约 2MB 原生内存。 + +## JEP 516: AOT 对象缓存支持任意 GC + +这是 **Project Leyden** 的重要里程碑，使得提前（AOT）对象缓存能够与**任意垃圾收集器**配合使用。 + +之前在 JDK 24 中引入的 AOT 类数据共享（JEP 483）只支持 G1 垃圾收集器，无法与 ZGC 等其他 GC 配合使用。这是因为 AOT 缓存中存储的对象引用使用的是物理内存地址，而不同 GC 的内存布局和对象移动策略不同。 + +JEP 516 将对象引用的存储方式从**物理内存地址**改为**逻辑索引**： + +- 使用 GC 无关的流式格式存储缓存 +- 缓存可以在运行时被任意 GC 加载和解析 +- JVM 在加载时将逻辑索引转换为实际的内存地址 + +**性能收益**： + +- **启动时间优化**：显著减少 Java 应用的冷启动时间 +- **支持 ZGC**：低延迟的 ZGC 现在也能享受 AOT 缓存带来的启动加速 +- **云原生友好**：对于微服务和无服务器函数等启动时间敏感的场景特别有价值 + +## JEP 500: 准备让 final 真正不可变 + +这个特性为 Java 的完整性优先原则铺平道路，准备让 `final` 字段真正变得不可变。 + +从 JDK 1.0 开始，Java 的 `final` 字段实际上可以通过**深度反射**被修改： + +```java +import java.lang.reflect.Field; +import java.lang.reflect.Method; + +class Example { + private final String name = "Original"; + + public String getName() { + return name; + } +} + +// 通过反射修改 final 字段 +Example example = new Example(); +Field field = Example.class.getDeclaredField("name"); +field.setAccessible(true); + +// 移除 final 修饰符 +Field modifiersField = Field.class.getDeclaredField("modifiers"); +modifiersField.setAccessible(true); +modifiersField.setInt(field, field.getModifiers() & ~Modifier.FINAL); + +field.set(example, "Modified"); // 成功修改了 final 字段！ +System.out.println(example.getName()); // 输出 "Modified" +``` + +这种能力虽然被一些框架（如序列化库、依赖注入框架、测试工具）使用，但破坏了 `final` 的不可变性保证，也阻碍了编译器优化。 + +在 JDK 26 中，当通过深度反射修改 `final` 字段时，JVM 会**发出警告**。这是为未来版本中默认禁止此类操作做准备。 + +对于确实需要修改 `final` 字段的场景，JDK 26 提供了显式的选择机制，允许开发者在过渡期继续使用此能力，同时为未来的严格模式做好准备。 + +## JEP 526: 延迟常量 (第二次预览) + +该特性第一次预览是由 [JEP 501](https://openjdk.org/jeps/501) （JDK 25）提出，JDK 26 是第二次预览。 + +传统的 `static final` 字段在类加载时就会初始化，这会： + +- 增加启动时间。 +- 如果该常量从未被使用，则浪费内存。 +- 需要复杂的延迟初始化模式（如双重检查锁定、Holder 类模式等）。 + +JEP 526 引入了 `LazyConstant`，一种持有不可变数据的对象，JVM 将其视为真正的常量，以获得与声明 `final` 字段相同的性能。 + +```java +// 传统方式：类加载时立即初始化 +static final ExpensiveObject TRADITIONAL = new ExpensiveObject(); + +// 新方式：首次访问时才初始化 +static final LazyConstant LAZY = + LazyConstant.of(() -> new ExpensiveObject()); + +// 使用时 +ExpensiveObject obj = LAZY.get(); // 此时才初始化 +``` + +**优势**： + +- **按需初始化**：只在首次访问时初始化，提升启动性能。 +- **线程安全**：内置线程安全保证，无需手动同步。 +- **JVM 优化**：JVM 可以像对待 `final` 字段一样优化延迟常量。 +- **简化代码**：消除双重检查锁定等复杂的延迟初始化模式。 + +## JEP 525: 结构化并发 (第六次预览) + +JDK 19 引入了结构化并发，一种多线程编程方法，目的是为了通过结构化并发 API 来简化多线程编程，并不是为了取代`java.util.concurrent`，目前处于孵化器阶段。 + +结构化并发将不同线程中运行的多个任务视为单个工作单元，从而简化错误处理、提高可靠性并增强可观察性。也就是说，结构化并发保留了单线程代码的可读性、可维护性和可观察性。 + +结构化并发的基本 API 是`StructuredTaskScope`，它支持将任务拆分为多个并发子任务，在它们自己的线程中执行，并且子任务必须在主/父任务继续之前完成或者子任务随主/父任务失败而取消。 + +`StructuredTaskScope` 的基本用法如下： + +```java + try (var scope = new StructuredTaskScope()) { + // 使用fork方法派生线程来执行子任务 + Future future1 = scope.fork(task1); + Future future2 = scope.fork(task2); + // 等待线程完成 + scope.join(); + // 结果的处理可能包括处理或重新抛出异常 + ... process results/exceptions ... + } // close +``` + +结构化并发非常适合虚拟线程，虚拟线程是 JDK 实现的轻量级线程。许多虚拟线程共享同一个操作系统线程，从而允许非常多的虚拟线程。 + +**Java 26 的新变动**： + +- **Joiner 增强**：`Joiner` 接口新增 `onTimeout()` 方法，允许在超时发生时返回特定结果。 +- **返回类型优化**：`allSuccessfulOrThrow()` 现在直接返回结果列表（`List`），而非之前的子任务流。 +- **API 简化**：将 `anySuccessfulResultOrThrow()` 简化更名为 `anySuccessfulOrThrow()`。 + +## JEP 530: 模式匹配支持基本类型 (第四次预览) + +该特性第一次预览是由 [JEP 455](https://openjdk.org/jeps/455 "JEP 455") （JDK 23 ）提出。 + +模式匹配可以在 `switch` 和 `instanceof` 语句中处理所有的基本数据类型（`int`, `double`, `boolean` 等） + +```java +static void test(Object obj) { + if (obj instanceof int i) { + System.out.println("这是一个int类型: " + i); + } +} +``` + +JDK 26 对该特性进行了进一步增强： + +- 消除了与基本类型相关的多项限制，使模式匹配、`instanceof` 和 `switch` 更加统一和表达力更强。 +- 增强了无条件精确性的定义。 +- 在 `switch` 构造中应用更严格的支配性检查，使编译器能够识别并减少更广泛的编码错误。 + +这样就可以像处理对象类型一样，对基本类型进行更安全、更简洁的类型匹配和转换，进一步消除了 Java 中的模板代码。 + +## JEP 524: 加密对象 PEM 编码 (第二次预览) + +该特性第一次预览是由 [JEP 518](https://openjdk.org/jeps/518) （JDK 25）提出。 + +PEM（Privacy-Enhanced Mail）是一种广泛使用的文本格式，用于存储和传输加密对象，如证书、私钥和公钥。JEP 524 提供了一个新的 API，用于将加密对象编码为 PEM 格式，以及从 PEM 格式解码回加密对象。 + +```java +// 将密钥编码为 PEM 格式 +KeyPairGenerator kpg = KeyPairGenerator.getInstance("RSA"); +kpg.initialize(2048); +KeyPair keyPair = kpg.generateKeyPair(); + +// 编码为 PEM +String pemEncoded = PemEncoding.encode(keyPair.getPrivate()); + +// 从 PEM 解码 +PrivateKey decodedKey = PemEncoding.decode(pemEncoded); +``` + +这个 API 减少了错误风险，简化了合规性要求，并通过简化企业、云和监管需求的加密设置和集成，增强了安全 Java 应用程序的可移植性和互操作性。 + +## JEP 529: Vector API (向量 API, 第十一次孵化) + +向量计算由对向量的一系列操作组成。向量 API 用来表达向量计算，该计算可以在运行时可靠地编译为支持的 CPU 架构上的最佳向量指令，从而实现优于等效标量计算的性能。 + +向量 API 的目标是为用户提供简洁易用且与平台无关的表达范围广泛的向量计算。 + +这是对数组元素的简单标量计算： + +```java +void scalarComputation(float[] a, float[] b, float[] c) { + for (int i = 0; i < a.length; i++) { + c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f; + } +} +``` + +这是使用 Vector API 进行的等效向量计算： + +```java +static final VectorSpecies SPECIES = FloatVector.SPECIES_PREFERRED; + +void vectorComputation(float[] a, float[] b, float[] c) { + int i = 0; + int upperBound = SPECIES.loopBound(a.length); + for (; i < upperBound; i += SPECIES.length()) { + // FloatVector va, vb, vc; + var va = FloatVector.fromArray(SPECIES, a, i); + var vb = FloatVector.fromArray(SPECIES, b, i); + var vc = va.mul(va) + .add(vb.mul(vb)) + .neg(); + vc.intoArray(c, i); + } + for (; i < a.length; i++) { + c[i] = (a[i] * a[i] + b[i] * b[i]) * -1.0f; + } +} +``` + +尽管仍在孵化中，但其第十一次迭代足以证明其重要性。它使得 Java 在科学计算、机器学习、AI 推理、大数据处理等性能敏感领域，能够编写出接近甚至媲美 C++ 等本地语言性能的代码。 + +## JEP 504: 移除 Applet API + +Applet API 在 JDK 9 中被标记为废弃，在 JDK 17 中被标记为即将移除。在 JDK 26 中，Applet API 终于被**完全移除**。大快人心啊！ + +这意味着： + +- `java.applet.Applet` 类及其相关类已被删除。 +- 减少了 JDK 的安装和源代码体积。 +- 提升了应用程序的性能、稳定性和安全性。 + +Applet 技术早已过时，现代 Web 开发已完全转向其他技术栈。移除这个遗留 API 是 Java 平台现代化的必要步骤。 + +## 总结 + +JDK 26 虽然是一个非 LTS 版本，但包含了一些值得关注的重要特性： + +| 类别 | 特性 | +| -------- | ---------------------------------------------------------- | +| **网络** | HTTP/3 支持 | +| **性能** | G1 GC 吞吐量优化、AOT 缓存支持任意 GC | +| **语言** | 模式匹配支持基本类型（第四次预览）、延迟常量（第二次预览） | +| **并发** | 结构化并发（第六次预览）、向量 API（第十一次孵化） | +| **安全** | 让 final 真正不可变、PEM 编码支持 | +| **清理** | 移除 Applet API | + +Oracle 将提供更新直到 2026 年 9 月，届时将被 Oracle JDK 27 取代。 diff --git a/docs/snippets/article-header.snippet.md b/docs/snippets/article-header.snippet.md index 80097335d7d..2f7530fe164 100644 --- a/docs/snippets/article-header.snippet.md +++ b/docs/snippets/article-header.snippet.md @@ -1,5 +1 @@ -::: tip 实战项目推荐 - -[基于 Spring Boot 4.0 + Java 21 + Spring AI 2.0 开发的 AI 智能面试辅助平台 + RAG 知识库已开源，附带系统学习教程！非常适合作为学习和简历项目，学习门槛低，帮助提升求职竞争力，是主打就业的实战项目。](https://javaguide.cn/zhuanlan/interview-guide.html) - -::: +[![《SpringAI 智能面试平台+RAG 知识库》](https://oss.javaguide.cn/xingqiu/interview-guide-banner.png)](../zhuanlan/interview-guide.md) diff --git a/docs/snippets/planet2.snippet.md b/docs/snippets/planet2.snippet.md index aeeef4aee8c..edd509488f6 100644 --- a/docs/snippets/planet2.snippet.md +++ b/docs/snippets/planet2.snippet.md @@ -16,9 +16,11 @@ **我有自己的原则，不割韭菜，用心做内容，真心希望帮助到你！** 如果你感兴趣的话，不妨花 3 分钟左右看看星球的详细介绍：[JavaGuide 知识星球详细介绍](../about-the-author/zhishixingqiu-two-years.md) 。 -## 星球限时优惠 +## 加入星球（限时优惠） -这里再送一张 **30** 元的星球专属优惠券，数量有限（价格即将上调。老用户续费半价 ，微信扫码即可续费）！ +已经坚持维护**六年**，内容持续更新，虽白菜价（**0.4 元/天**）但质量很高，主打一个良心！ + +目前星球正在做活动，两本书的价格，就能让你拥有上万培训班的服务！这里再提供一张 **30** 元的优惠卷（价格马上上调，老用户扫码续费半价 ）： ![知识星球30元优惠卷](https://oss.javaguide.cn/xingqiu/xingqiuyouhuijuan-30.jpg) diff --git a/docs/system-design/security/encryption-algorithms.md b/docs/system-design/security/encryption-algorithms.md index 3e8591a78cd..52964b4b2ee 100644 --- a/docs/system-design/security/encryption-algorithms.md +++ b/docs/system-design/security/encryption-algorithms.md @@ -44,8 +44,8 @@ ps: 严格上来说，哈希算法其实不属于加密算法，只是可以用 哈希算法可以简单分为两类： -1. **加密哈希算法**：安全性较高的哈希算法，它可以提供一定的数据完整性保护和数据防篡改能力，能够抵御一定的攻击手段，安全性相对较高，但性能较差，适用于对安全性要求较高的场景。例如 SHA2、SHA3、SM3、RIPEMD-160、BLAKE2、SipHash 等等。 -2. **非加密哈希算法**：安全性相对较低的哈希算法，易受到暴力破解、冲突攻击等攻击手段的影响，但性能较高，适用于对安全性没有要求的业务场景。例如 CRC32、MurMurHash3、SipHash 等等。 +1. **加密哈希算法**：安全性较高的哈希算法，它可以提供一定的数据完整性保护和数据防篡改能力，能够抵御一定的攻击手段，安全性相对较高，但性能较差，适用于对安全性要求较高的场景。例如 SHA2、SHA3、SM3、RIPEMD-160、BLAKE2 等等。 +2. **非加密哈希算法**：安全性相对较低的哈希算法，易受到暴力破解、冲突攻击等攻击手段的影响，但性能较高，适用于对安全性没有要求的业务场景。例如 CRC32、MurMurHash3 等等。 除了这两种之外，还有一些特殊的哈希算法，例如安全性更高的**慢哈希算法**。 @@ -57,7 +57,7 @@ ps: 严格上来说，哈希算法其实不属于加密算法，只是可以用 - Bcrypt（密码哈希算法）：基于 Blowfish 加密算法的密码哈希算法，专门为密码加密而设计，安全性高，属于慢哈希算法。 - MAC（Message Authentication Code，消息认证码算法）：HMAC 是一种基于哈希的 MAC，可以与任何安全的哈希算法结合使用，例如 SHA-256。 - CRC：（Cyclic Redundancy Check，循环冗余校验）：CRC32 是一种 CRC 算法，它的特点是生成 32 位的校验值，通常用于数据完整性校验、文件校验等场景。 -- SipHash：加密哈希算法，它的设计目的是在速度和安全性之间达到一个平衡，用于防御[哈希泛洪 DoS 攻击](https://aumasson.jp/siphash/siphashdos_29c3_slides.pdf)。Rust 默认使用 SipHash 作为哈希算法，从 Redis4.0 开始，哈希算法被替换为 SipHash。 +- SipHash：它不是传统的无密钥加密哈希函数（如 SHA-256），而是带密钥的 PRF（Pseudo-Random Function）。必须配合一个随机密钥使用，才能真正具备抗碰撞攻击的能力。它的设计目的是在速度和安全性之间达到一个平衡，用于防御[哈希泛洪 DoS 攻击](https://aumasson.jp/siphash/siphashdos_29c3_slides.pdf)。Rust 默认使用 SipHash 作为哈希算法（目前是 SipHash-1-3 ），从 Redis 4.0 版本开始，字典（dict）的哈希算法从原来的 MurmurHash2 切换为 SipHash（目前是 SipHash-1-2）。 - MurMurHash：经典快速的非加密哈希算法，目前最新的版本是 MurMurHash3，可以生成 32 位或者 128 位哈希值； - …… diff --git a/docs/zhuanlan/back-end-interview-high-frequency-system-design-and-scenario-questions.md b/docs/zhuanlan/back-end-interview-high-frequency-system-design-and-scenario-questions.md index 4d66adcd0cc..af8e777b578 100644 --- a/docs/zhuanlan/back-end-interview-high-frequency-system-design-and-scenario-questions.md +++ b/docs/zhuanlan/back-end-interview-high-frequency-system-design-and-scenario-questions.md @@ -6,18 +6,99 @@ category: 知识星球 ## 介绍 -**《后端面试高频系统设计&场景题》** 是我的[知识星球](../about-the-author/zhishixingqiu-two-years.md)的一个内部小册，包含了常见的系统设计案例比如短链系统、秒杀系统以及高频的场景题比如海量数据去重、第三方授权登录。 +**《后端面试高频系统设计&场景题》** 是我的[知识星球](../about-the-author/zhishixingqiu-two-years.md)的一个内部小册，系统性地总结了后端面试中高频出现的系统设计案例和场景题。 -近年来，随着国内的技术面试越来越卷，越来越多的公司开始在面试中考察系统设计和场景问题，以此来更全面的考察求职者，不论是校招还是社招。不过，正常面试全是场景题的情况还是极少的，面试官一般会在面试中穿插一两个系统设计和场景题来考察你。 +### 为什么你需要这份小册？ -于是，我总结了这份《后端面试高频系统设计&场景题》，包含了常见的系统设计案例比如短链系统、秒杀系统以及高频的场景题比如海量数据去重、第三方授权登录。 +近年来，国内技术面试"越来越卷"。越来越多的公司（阿里、美团、字节、腾讯等）开始在面试中考察 **系统设计** 和 **场景问题**，以此来更全面地考察求职者的综合能力——不论是校招还是社招。 -即使不是准备面试，我也强烈推荐你认真阅读这一系列文章，这对于提升自己系统设计思维和解决实际问题的能力还是非常有帮助的。并且，涉及到的很多案例都可以用到自己的项目上比如抽奖系统设计、第三方授权登录、Redis 实现延时任务的正确方式。 +> 很多同学八股文背得滚瓜烂熟，但一遇到"如何设计一个秒杀系统？"这类开放性问题就懵了。 -《后端面试高频系统设计&场景题》本身是属于《Java 面试指北》的一部分，后面由于内容篇幅较多，因此被单独提了出来。 +**系统设计和场景题的考察特点**： + +- ✅ 没有标准答案，重点考察思维过程和架构能力 +- ✅ 考察对高并发、高可用、分布式等技术的综合运用 +- ✅ 考察解决实际问题的能力和工程经验 +- ⚠️ 正常面试不会全是场景题，一般会穿插 1-2 道来考察你 + +于是，**《后端面试高频系统设计&场景题》** 小册就诞生了！ + +### 这份小册能带给你什么？ + +**1. 面试加分项** + +系统设计和场景题回答得好，面试官会对你印象非常好！这类问题稍微准备就能脱颖而出。 + +**2. 提升系统设计思维** + +即使不是准备面试，这份小册也能帮助你建立系统设计的思维框架，提升解决实际问题的能力。 + +**3. 实战落地参考** + +涉及到的很多案例都可以直接用到自己的项目上，比如： + +- 第三方授权登录（微信/QQ 登录） +- Redis 实现延时任务的正确方式 +- 动态线程池的设计与实现 +- 分布式锁的多种实现方案 ## 内容概览 +### 📐 系统设计案例 + +| 主题 | 核心知识点 | +| -------------------------------------- | -------------------------------------------------- | +| ⭐ **如何设计一个动态线程池？** | 线程池参数动态调整、监控告警、拒绝策略、优雅停机 | +| **如何设计一个站内消息系统？** | 消息推送、未读数统计、WebSocket、消息队列 | +| **如何设计微博 Feed 流/信息流系统？** | 推拉模型、Timeline、智能推荐、读写扩散、缓存策略 | +| **如何设计一个排行榜？** | Redis Sorted Set、实时更新、分页查询、海量数据排序 | +| **几种典型的系统设计案例（整理补充）** | 点赞、优惠卷、红包等综合案例分享 | + +### 🎯 高频场景题 + +| 主题 | 核心知识点 | +| --------------------------------------- | ----------------------------------------------------- | +| ⭐ **订单超时自动取消如何实现？** | 延时队列、定时任务、状态机、幂等性保障 | +| **如何基于 Redis 实现延时任务？** | 过期事件监听 vs Redisson DelayedQueue、时效性、可靠性 | +| ⭐ **如何解决大文件上传问题？** | 分片上传、断点续传、秒传、并发上传、文件校验 | +| **如何实现 IP 归属地功能？** | IP 库选择、离线库 vs 在线接口、性能优化 | +| **如何统计网站 UV？** | PV/UV/VV/IP 概念、HyperLogLog、去重统计 | +| ⭐ **几种典型的后端面试场景题（补充）** | 限流、幂等、缓存穿透等综合场景 | + +### 🔐 认证安全与风控 + +| 主题 | 核心知识点 | +| ----------------------------------- | -------------------------------------------- | +| ⭐ **项目敏感词脱敏是如何实现的？** | 脱敏策略、正则匹配、性能优化、动态配置 | +| ⭐ **如何安全传输和存储密码？** | 加盐哈希、BCrypt、HTTPS、防重放攻击 | +| **如何实现第三方授权登录？** | OAuth 2.0 协议、授权码模式、Token 机制、JWT | +| **验证码登录场景怎么设计？** | 验证码生成、存储、校验、防刷、有效期管理 | +| **多次输错密码后如何限制登录？** | 限流策略、Redis 计数器、滑动窗口、分布式限流 | + +### 📊 大数据量场景 + +| 主题 | 核心知识点 | +| ---------------------------------------------- | ----------------------------------------- | +| ⭐ **40 亿个 QQ 号，限制 1G 内存，如何去重？** | 位图、布隆过滤器、分治思想、外部排序 | +| ⭐ **日活上亿，如何保证推荐视频不重复？** | 布隆过滤器、Redis Set、去重策略、空间优化 | +| ⭐ **大数据 Top K 问题** | 堆排序、快速选择、分治、MapReduce | + +### 🔄 并发控制与分布式一致性 + +| 主题 | 核心知识点 | +| -------------------------------------- | --------------------------------------- | +| **多位骑手抢一个订单如何保证不重复？** | 分布式锁、乐观锁、Redis SETNX、并发控制 | +| **发生提现失败（退单）时怎么处理？** | 补偿机制、幂等设计、状态回滚、对账系统 | + +## 内容预览 + ![《后端面试高频系统设计&场景题》](https://oss.javaguide.cn/xingqiu/back-end-interview-high-frequency-system-design-and-scenario-questions-fengmian.png) +## 适合人群 + +- 🎓 **校招求职者**：应对大厂系统设计面试 +- 👨‍💻 **社招跳槽者**：提升架构设计能力，拿到更好的 offer +- 🔧 **初中级工程师**：学习系统设计思维，提升解决实际问题的能力 +- 📚 **技术爱好者**：了解常见系统的设计原理 +