HRunning

Hugo ｜ to do list

Thu, 27 Nov 2025 11:04:45 +0800

📝 博客待办清单

🔥 P0

让博客可以在google、百度等搜索引擎中被收录
- 提交 google sitemap
- 提交百度 sitemap,百度提交sitemap时需要备案号才能增加提交次数
优化网站访问速度
- 开启 BBR 拥塞控制 net.ipv4.tcp_congestion_control = bbr

🛠 p1

开发agent 同时发布上传yuque、csdn、weichat
- yuque api token 需要付费
- csdn 目前没有找到合适的api
美化网站右侧边栏添加优秀文章,根据访问量去统计
单独制作首页，可以参考https://www.shaohantian.com/
SEO 搜索结果片段优化，提高搜索结果的美观性
写关于我的一些说明
开发管理平台
增加常用工具列表

✅Archived - 已上线功能

增加评论功能
- 评论功能迁移到waline
- 评论通知 wechat、email 等渠道
完善关键字搜索功能
添加文章字数统计
添加英文站，中英文文章由作者分别维护
- 页眉网站统计信息适配英文版
- 文章顶部字数统计、阅读量统计适配英文版
- 左侧边栏切换按钮由下拉框改为直接切换
美化浏览器顶层图标
首页和文章添加"返回顶部"功能
服务器部署网站服务器不在国内可以先不备案域名：hangops.top，首年 ¥14，续费 ¥32
部署监控系统
- 部署prometheus
- 部署grafana(https://monitor.hangops.top/)
添加网站访问统计
- 统计网站访问量
- 统计文章访问量
备份blog mysql 数据库到cos 存储桶

内容相关

目录结构如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


- 运维
 - Mysql
 - Redis
 - Kafka
 - ansible
 - k8s
 - aws
 - Linux
 - Docker
 - prometheus
 - Terraform

- 编程
 - Python
 - Shell
 - Go
 - 数据结构
 - 算法

- 专题
 - 博客相关
 - 面试相关
 - Liunx 性能优化
 - Mysql 实战

Brainstorming Skill｜实现前的设计与需求分析

Tue, 08 Sep 2026 00:00:00 +0800

技能定位

Brainstorming 是一个强制性的前置设计与需求分析技能。它通过协作式对话，把用户的初步想法逐步转化为结构化、可执行的设计方案与需求文档。

它要解决的是“想法已经很清楚，所以可以直接开始做”的常见误区。即使需求看起来简单，也应先经过设计阶段，明确目标、场景、约束、候选方案和取舍，从而减少实现偏差与后续返工。

核心规则

在设计文档完成并得到用户确认之前，禁止执行实现类操作，包括：

编写代码
初始化项目
修改现有文件
创建数据库或基础设施
执行部署或其他落地操作

Brainstorming 阶段的产物应该是一份用户可以审阅和确认的方案，而不是半成品实现。

模板一：新功能开发

适合在规划一个新功能、模块或产品能力时使用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


帮我头脑风暴一下如何实现[功能名称]。

背景：
- 当前系统状态：[简要描述现有架构/相关模块]
- 目标用户/场景：[谁会用、什么时候用]
- 已知约束：[性能要求、兼容性、截止时间等]

我希望探索的方向：
1. [方向A]
2. [方向B]
3. 其他你觉得值得考虑的方案

请帮我从多个角度分析利弊。

使用这个模板时，最好补充现有系统的关键边界，例如哪些模块不能改、哪些接口必须兼容，以及功能上线后如何判断是否达到目标。

模板二：技术方案选型

适合在多个技术方案之间进行比较和决策时使用。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


帮我头脑风暴一下[技术决策]的选型方案。

需求场景：
- 核心需求：[必须满足的功能点]
- 规模预期：[数据量/并发量/团队规模]
- 现有技术栈：[当前用了什么]

评估维度：性能、开发效率、社区生态、学习曲线、长期可扩展性

候选方案（如果有）：[A、B、C]

如果暂时没有候选方案，也可以只描述需求场景，让 Brainstorming 先帮助建立候选清单，再根据统一的评估维度进行比较。

产出检查清单

一份可以进入实现阶段的设计文档，至少应回答以下问题：

要解决的具体问题是什么？
谁会使用它，在哪些场景下使用？
成功标准和验收方式是什么？
有哪些可行方案，它们的主要取舍是什么？
推荐方案为什么适合当前场景？
有哪些约束、风险和待确认事项？
用户确认后，第一步实现工作是什么？

参考链接

字节跳动 Brainstorming Skill 参考文档

Image2 提示词｜构建视觉隐喻的高级概念海报

Tue, 08 Sep 2026 00:00:00 +0800

这份提示词用于 Image2 生成概念海报。重点是先理解文字的含义与情绪，再让文字和图像共同构成一个完整的视觉表达。

使用方法

复制下方完整提示词，填写末尾的「核心文字 / 单词 / 词组 / 字母」。背景、补充语境和情绪倾向可以按需调整；默认文字语言为中文，情绪倾向为「专业 / 压迫感 / 醒目」。

完整提示词

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87


你要生成的不是一个单词放大后贴在画面上的字效海报，而是一张“基于词语含义自动构建视觉隐喻”的高级概念海报。

你的核心任务是：
用户会提供一个字、一个词、一个词组、一个短句，或一组字母。你需要先真正理解这个文字内容的表层含义、情绪气质、隐含象征、文化联想、心理感受与语义张力，再把这些理解转译成一张极简、强概念、强传播力、强视觉记忆点的图形艺术海报。

这张海报必须让人一眼就感受到这个词语“为什么是这样被表达的”，而不是只看到漂亮画面却无法理解词义。画面要做到“文字本身就是主题，图像是对文字的深化表达，二者共同组成一个完整的视觉句子”。

一、先理解词语，再生成画面
在动手生成之前，先智能分析用户输入内容，包括但不限于：

1. 这个词语最核心的字面含义是什么。
2. 这个词语在情绪上偏向温柔、冷峻、危险、孤独、浪漫、压迫、希望、纯真、欲望、秩序、冲突、疏离、自由、沉默、毁灭、重生等哪种倾向。
3. 这个词语是否具有双关、反差、张力、隐喻、悖论、社会性、哲学性或情感深度。
4. 这个词语最适合被转译成哪一种视觉逻辑：人物关系、物体关系、动作关系、空间关系、对比关系、象征关系、冲突关系、秩序关系、荒诞关系、诗意关系等。
5. 如果这个词语较抽象，不要直接做空洞抽象图案，而要找到能够承载其含义的具体视觉载体。
6. 如果这个词语较具体，也不要只做字面插图，而要通过构图、尺度、关系、反差与氛围，让它变得更有思想和记忆点。

二、画面构图逻辑
整体画面必须极简、明确、有概念感，构图要干净而有力量，不能杂乱，不能像普通商业插画，不能堆砌太多元素。

优先采用以下构图思路：

1. 大字作为画面的核心骨架。用户输入的文字、单词或词组应成为画面中的主视觉文字主体，通常以大尺寸出现，占据画面重要区域，具有强识别性与压迫感。
2. 图像元素不是随意摆放，而是要与文字产生关系。它们可以站在字前、嵌入字中、与字形成互动、切割字形、借字的空间形成叙事，或在视觉上与字构成强烈对照。
3. 整体元素数量要克制。通常控制在少量关键主体之内。宁可少而准，也不要多而散。
4. 画面要有明确主次关系：文字是第一视觉层，图像叙事是第二视觉层，细小说明文字是第三视觉层。
5. 留白要聪明，不是空，而是让画面更有呼吸感、更有判断力、更有设计感。
6. 构图应尽量稳定、简洁、好读，并具备“海报感”，而不是像一张普通插画截图。

三、图像表达逻辑
根据词语的意义，自动选择最有代表性的视觉表达方式。图像表达应遵循以下原则：

1. 优先选择能够浓缩词义的单一强画面，而不是平铺直叙。
2. 可以通过人物之间的关系、人物与物体的关系、尺度反差、方向关系、距离关系、遮挡关系、动作瞬间等方式表达词义。
3. 画面应具有隐喻性，但不能晦涩到完全无法理解。
4. 表达要巧妙，要有“看到后会心一击”的感觉，让观众觉得画面和这个词是高度绑定的。
5. 不要仅仅追求美感，更要追求“准确地说出了这个词的感觉”。
6. 如果词义具有冲突性、悖论性或反差感，可以通过画面中的对立元素强化这种张力。
7. 如果词义更偏诗意、情感、记忆、哲思，可以使用更含蓄、更留白、更克制的图像策略。

四、视觉风格要求
整体风格为高级图形艺术海报，具有拼贴感、丝网印刷感、石版印刷感或版画式质感，但不要做得过脏过乱。要保留一种清晰、克制、硬朗、概念化的印刷纸张气质。

风格要求：

1. 具有强烈平面设计感，而不是普通三维插画。
2. 画面应有干净统一的色彩逻辑，颜色数量不宜过多。
3. 可使用高饱和主背景色配合大面积浅色文字，形成强对比。
4. 质感可带有细微颗粒、纸张纹理、印刷噪点、轻微做旧感，但整体仍需清爽、利落、高级。
5. 人物或物体细节要清楚，但整体仍然服从平面海报的统一调性。
6. 不要做成廉价模板，不要出现低级拼贴感，不要做成广告页，不要做成普通电商排版。

五、文字排版逻辑

1. 用户输入的文字内容必须作为核心标题，大且醒目。
2. 如果用户输入的是英文单词或字母组合，保留原文，确保字形强烈、清晰、具有视觉冲击力。
3. 如果用户输入的是中文词语或短句，可以根据整体设计决定是否直接使用中文大字，或采用更适合的方式排布，但必须保证其是画面核心。
4. 可以在画面左下角、右下角或其他克制位置加入一句小型辅助短句，用来深化主题，但必须非常简洁且自然。
5. 还可以加入少量极小号的辅助信息、编号、署名等内容，仅在非常相关的情况下用来增强海报的艺术感，避免过多无关内容。
6. 所有文字都要像从画面中生长出来的一样，不能像后期随便贴上去。

六、成图目标
最终生成的海报必须满足以下结果：

1. 一眼看上去极简、强烈、完整、有高级感。
2. 能让人快速感受到这个词语的情绪和内涵。
3. 图与字之间存在强关联，形成一种聪明、准确、耐看的视觉表达。
4. 既有平面设计的理性控制，也有艺术表达的情绪力度。
5. 具有传播性、海报感、收藏感、展览感。
6. 不能只是“把词画出来”，而是要“把词的精神状态视觉化”。

七、执行原则

1. 不要机械重复固定模板，要根据用户输入智能变化。
2. 但整体仍需保持极简、概念化、强排版、强识别度的统一品质。
3. 构图要合理，画面要克制，表达要巧妙。
4. 不要过度解释，不要加入多余元素，不要让画面显得拥挤。
5. 任何视觉元素都必须服务于词语表达，不能为了好看而偏离主题。

请基于以上原则，生成一张围绕用户输入内容展开的高级概念海报。

用户输入内容：
背景：
核心文字 / 单词 / 词组 / 字母：
文字语言：中文
可选补充语境：
可选情绪倾向：专业 / 压迫感 / 醒目

Hugo ｜如何让搜索引擎检索到博客

Mon, 15 Dec 2025 19:45:07 +0800

部署完博客后，需要让搜索引擎检索到博客。

google

获取Measurement ID

google 分析官方网站在 google 分析中，每个网站都有一个唯一的 Measurement ID，格式为 G-XXXXXXXXXX。这个 ID 用于将网站的访问数据发送到 google 分析。

在hugo.yaml 中添加如下配置：

如果你是yaml 格式，注意要是最顶级的配置

1

googleAnalytics: G-xxxx # <--- 换成你的 Measurement ID

提交siteMap

siteMap 是一个 xml 文件，用于告诉搜索引擎你的网站有哪些页面。

Hugo 会在生成和部署网站时在 public 文件夹根目录下自动生成 sitemap.xml 文件

登录谷歌搜索控制台。在验证所有权的选项中选择 “Google Analytics”，输入你的 Measurement ID 即可验证所有权。

下面就是已经成功提交的截图

如何验证文章已经被Google 收录

对于一个新站，Google 可能需要几天甚至几周才能把所有页面全部收录

Google Search Console 验证

直接在顶部的搜索框查询，输入你的文章链接，即可验证是否被收录。

也可以直接点击请求编入索引，请求 Google 收录你的文章。

google 搜索验证

tips:

验证收录可能需要几天甚至几周才能完成。
文章的标题尽可能增加关键词密度，更加吸晴，让用户有点击的欲望。

百度

登录百度搜索控制台
按照要求添加域名后，使用普通收录推送资源

提交 sitemap.xml 文件时，需要备案号，这里先不添加。
api 提交每天会有条数限制

refs

https://hyrtee.github.io/2023/start-blog/#refs

Hugo ｜ Waline 评论系统私有化部署

Sun, 14 Dec 2025 17:53:12 +0800

Waline 评论系统

博客原本使用github giscus 作为评论系统，现在迁移至 Waline 评论系统。

支持匿名评论（无需登录）
UI 简洁美观
可以配置邮箱/weixin 接收通知

本地部署(Waline)

docker-compose 部署

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42


version: '3'

services:
 waline:
 image: lizheming/waline:latest
 container_name: waline-standalone
 restart: always
 ports:
 - "8360:8360"
 environment:
 - MYSQL_HOST=blog-stats-db 
 - MYSQL_PORT=3306
 - MYSQL_DB=waline_db 
 - MYSQL_USER=root
 - MYSQL_PASSWORD=xxx
 - MYSQL_CHARSET=utf8mb4
 - MYSQL_SSL=false
 - TABLE_PREFIX=wl_

 - TZ=Asia/Shanghai
 - LANG=zh_CN.UTF-8
 - JWT_SECRET=Standalone_Waline_Secret_2025

 # --- 通知配置 ---
 - SITE_NAME=Hangliuc
 - SITE_URL=https://hangops.top

 # 163
 - SMTP_SERVICE=163
 - SMTP_USER=iliuhang@163.com
 - SMTP_PASS=xxxxx
 - SMTP_SECURE=true
 - AUTHOR_EMAIL=iliuhang@163.com
 - SENDER_EMAIL=iliuhang@163.com

 networks:
 - ext-blog-net

networks:
 ext-blog-net:
 external: true
 name: blog-stats_blog-net  #因为 Waline 和 MySQL 不在同一个 docker-compose.yaml 文件里，它们默认是隔离的。需要让 Waline 加入到 MySQL 所在的网络中。

使用时请先导入 waline.sql 以完成表和表结构的创建，之后在项目中配置如下环境变量。 Waline 数据库配置

1

docker exec -i blog-stats-db mysql -uroot -p'xxxxx' -Dwaline_db < waline.sql

Nginx 反向代理

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


server {
 if ($host = comment.hangops.top) {
 return 301 https://$host$request_uri;
 } # managed by Certbot


 listen 80;
 server_name comment.hangops.top;

 # 强制跳转 HTTPS (可选，建议加上)
 return 301 https://$host$request_uri;


}

server {
 listen 443 ssl http2;
 server_name comment.hangops.top;

 ssl_certificate /etc/letsencrypt/live/comment.hangops.top/fullchain.pem;
 ssl_certificate_key /etc/letsencrypt/live/comment.hangops.top/privkey.pem;

 location / {
 proxy_pass http://127.0.0.1:8360;

 # 必须带上的 Header，否则 Waline 无法获取用户真实
 proxy_set_header Host $host;
 proxy_set_header X-Real-IP $remote_addr;
 proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
 proxy_set_header X-Forwarded-Proto $scheme;
 }

 ssl_certificate /etc/letsencrypt/live/comment.hangops.top/fullchain.pem; # managed by Certbot
 ssl_certificate_key /etc/letsencrypt/live/comment.hangops.top/privkey.pem; # managed by Certbot
}

Hugo 配置

Waline 组件配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


params:
 comments:
 enabled: true
 provider: waline
 waline:
 serverURL: https://comment.hangops.top
 pageview: true # 开启阅读量
 requiredMeta:
 - nick
 - mail 

Hugo ｜如何自定义实现网站统计功能

Thu, 11 Dec 2025 14:23:32 +0800

一些实现方式

目前看到网上关于网站统计功能的实现方式：

基于busuanzi js的统计功能
基于Waline 的统计功能
基于服务器端的统计功能

关于上面的两种方式大家可以自行在网上搜索，这里就不展开讲了，主要讲一下基于自行服务端的统计功能。

基于服务器端的统计功能

优点

数据源真实可靠（全部来自你自己的数据库）
访问量可以根据业务逻辑定义
可以进行强一致性统计（文章访问量、文章数量、评论数量等）
不依赖第三方服务
后续可以接入监控告警系统，实时观察
后续可以在自研管理平台展示

目前统计功能

网站访问量
文章访问量
文章总访问量
网站运行时间
….

实现方式

采用gin web 框架 https://github.com/gin-gonic/gin

使用 GORM 做数据库对象关系映射 https://github.com/go-gorm/gorm

以处理POST /api/article/visit，其他接口处理基本相同

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


func (r *articleRepo) IncreaseViewCount(path string) (int64, error) {
 // 1. 执行 Upsert (存在则更新，不存在则插入)，体现原子性操作，避免并发问题
 // SQL: INSERT INTO article_stats ... ON DUPLICATE KEY UPDATE view_count = view_count + 1
 err := r.db.Clauses(clause.OnConflict{
 Columns: []clause.Column{{Name: "path"}},
 DoUpdates: clause.Assignments(map[string]interface{}{
 "view_count": gorm.Expr("view_count + 1"),
 }),
 }).Create(&model.ArticleStat{Path: path, ViewCount: 1}).Error

 if err != nil {
 return 0, err
 }

 // 2. 查出最新的值返回
 var stat model.ArticleStat
 err = r.db.Select("view_count").Where("path = ?", path).First(&stat).Error
 return stat.ViewCount, err
}

前端逻辑上报/article/visit 接口时如果是首页(/)或者分页(/page/1)或者搜索(/search/query)，也会添加到文章计数，这里排除了这个bug

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37


 <script>
 (function() {
 const isLocal = ["localhost", "127.0.0.1"].includes(window.location.hostname);

 const API_URL = isLocal
 ? "http://localhost:8080/api/article/visit"
 : "https://hangops.top/api/article/visit";

 const path = window.location.pathname;
 // 如果是首页(/)或者分页(/page/1)或者搜索(/search/query)，直接什么都不做
 if (path === "/" ||
 path.includes("/page/") ||
 path.includes("/search/")) {
 return;
 }

 fetch(API_URL, {
 method: 'POST',
 headers: { 'Content-Type': 'application/json' },
 body: JSON.stringify({ path: path })
 })
 .then(response => response.json())
 .then(data => {
 const container = document.getElementById("article_views_container");
 const viewEl = document.getElementById("article_views");

 if (container && viewEl && data.views) {
 viewEl.innerText = data.views;

 container.style.display = "flex";
 }
 })
 .catch(err => {
 console.error("阅读量获取失败:", err);
 });
 })();
 </script> 

Hugo ｜本地服务器部署

Sun, 07 Dec 2025 18:31:24 +0800

以前采用的是github pages部署网站，现在进行服务器部署网站。

安装基础软件

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 更新系统并安装 EPEL 源
sudo yum update -y
sudo yum install epel-release -y

# 安装 Nginx, Git, 和 Certbot
sudo yum install nginx git certbot certbot-nginx -y

# 启动 Nginx 并设置开机自启
sudo systemctl start nginx
sudo systemctl enable nginx

# 创建目录
sudo mkdir -p /var/www/hangops

sudo chown -R root:root /var/www/hangops
sudo chmod -R 755 /var/www/hangops

配置 Nginx 与 HTTPS

1
2
3
4
5
6


sudo vi /etc/nginx/conf.d/hangops.top.conf

# 检查语法是否正确
sudo nginx -t
# 如果显示 successful，则重启
sudo systemctl reload nginx

nginx 配置

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


server {
 listen 80;
 server_name hangops.top www.hangops.top;

 root /var/www/hangops;
 index index.html;

 # 核心：处理 Hugo 的路由（防止刷新 404）
 location / {
 try_files $uri $uri/ =404;
 }

 # SRE 优化：开启 Gzip 压缩，加速访问
 gzip on;
 gzip_min_length 1k;
 gzip_comp_level 5;
 gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
}

申请 HTTPS 证书

sudo certbot –nginx -d hangops.top -d www.hangops.top

配置 GitHub 自动部署 (CI/CD)

看仓库源码即可

SRE面试题汇总 | Database

Sat, 06 Dec 2025 18:42:12 +0800

mysql

mysql 查询突然变得很慢，需要怎么排查

检查查询本身

查看SQL查询是否可以优化，比如使用合适的索引、避免全表扫描等。
复杂的JOIN操作：确认是否有多个大的表连接，或者是不必要的复杂操作

查看数据库性能

慢查询日志：启用并查看慢查询日志（slow_query_log）。查看最近哪些查询执行时间较长。

检查系统负载

系统资源：查看CPU、内存、磁盘IO、网络等资源是否有瓶颈，可以通过 top 或 htop 等工具监控。磁盘IO：查看磁盘读写是否成为瓶颈。可以用 iostat 或 vmstat 等工具查看磁盘IO情况。

检查锁和并发问题

锁情况：查看是否有锁等待或死锁问题。使用以下SQL语句查看当前的锁状态：如果有很多线程处于“Locked”状态，可能需要进一步分析锁的来源和解决方法。

网络延迟

如果是远程连接MySQL，确认网络连接是否稳定，延迟是否较高。

redis

热 Key、大 Key 问题

热key问题

热key：指被频繁访问的key，可能导致数据库性能下降。

影响：

CPU 集中在一个 Redis 节点
QPS 不均匀，集群负载失衡
延迟飙升、请求超时
导致节点触发 failover

解决方案

业务层分流/分桶将热请求拆成多个 key，提高并发承载。
增加缓存层：本地缓存 + Redis 二级缓存，减少对 Redis 的直接访问
使用多 Key 拆分读压力，一个热门大 key 分成多个子 key
Redis Proxy 层热点保护，代理层可识别热点并做降级
客户端本地限流 + 降级

大key问题

大key：指key对应的值非常大，占用了大量的内存空间。

影响：

迁移槽时（CLUSTER ADDSLOTS/MIGRATE）非常慢
可能阻塞 Redis 主线程
删除时触发阻塞（del O(n) 操作
压垮网络带宽
读写延迟变大
Failover 恢复慢

解决方案

业务层拆分：将大 key 拆分成多个小 key，每个小 key 只存储一部分数据。
分页读取：不使用 hgetall/smembers/zrange，使用scan / 分段取
提前限制 value 的大小：在服务侧做 key 大小限制
避免在 Redis 存储日志、消息、长文本

如何发现大key

Redis的SCAN命令
redis-cli -h 127.0.0.1 -p 6379 —bigkeys
开源工具Redis RDB Tools，分析RDB文件，扫描出Redis大key。

kafka

消费堆积如何处理

消息堆积原因

生产者短时间内生产大量消息到Topic，消费者无法及时消费。
消费者的消费能力不足（消费者并发低、消息处理时间长），导致消费效率低于生产效率。
消费者异常（如消费者故障、消费者网络异常等）导致无法消费消息。
Topic分区设置不合理，或新增分区无消费者消费。
Topic频繁重分配导致消费效率降低。

解决方法

从消息堆积的原因看，消息堆积问题可以从消费者端、生产者端和服务端三个方面进行处理。

消费者端
- 根据实际业务需求，合理增加消费者个数（消费并发度），确保分区数/消费者数=整数，建议消费者数和分区数保持一致。
- 提高消费者的消费速度，通过优化消费者处理逻辑（减少复杂计算、第三方接口调用和读库操作），减少消费时间。
- 增加消费者每次拉取消息的数量：拉取数据/处理时间 >= 生产速度。
生产者端
- 生产消息时，给消息Key加随机后缀，使消息均衡分布到不同分区上。
服务端
- 合理设置Topic的分区数，在不影响业务处理效率的情况下，调大Topic的分区数量。
- 当服务端出现消息堆积时，对生产者进行熔断，或将生产者的消息转发到其他Topic。

SRE面试题汇总 | K8s

Sat, 06 Dec 2025 18:15:30 +0800

各模块如何与 API Server 通信

集群内的各个功能模块通过API Server将信息存入etcd，当需要获取和操作这些数据时，则通过API Server提供的REST接口（用GET、LIST或WATCH方法）来实现，从而实现各模块之间的信息交互。

Kubernetes中各模块通过标准的HTTP/HTTPS请求与API Server交互，通过认证和鉴权机制保证安全性，并利用Watch机制实现实时的资源状态监控与同步。

kubelet 监控 Worker 节点如何实现

1
2
3
4
5
6
7
8
9


Linux 内核
 ↓
cAdvisor 采集容器与节点指标
 ↓
kubelet 处理、聚合、判断节点状态
 ↓
apiserver + metrics server 汇总
 ↓
kubectl top / HPA / 调度器 决策

集群节点规模上千时的注意事项

官方文档https://kubernetes.io/zh-cn/docs/setup/best-practices/cluster-large/

kubeconfig 存放的内容

有关集群、用户、命名空间和身份验证机制的信息

kube-proxy 的作用

核心职责维护 Service 的转发规则 kube-proxy 监听 API Server 中 Service、Endpoints/EndpointSlice 的变化，在节点上维护 iptables 或 IPVS 规则，实现 Service 到后端 Pod 的流量转发。

类型

iptables：默认模式，使用 iptables 规则实现 Service 转发。
IPVS：基于Linux 内核 IPVS 进行四层负载均衡，性能高，规则更新快。

Scheduler 调度流程

监听与获取 (Listen & Get)

Scheduler 监听 K8s API Server，发现未绑定到节点的 Pod
通过 Informer 机制，从本地缓存获取 Pod 和 Node 的实时信息，提高效率

预选阶段 (Predicates/Filter)

快速过滤掉不满足条件的节点，减少后续计算量
节点资源（CPU, Memory）、Node Selector/Affinity/Anti-Affinity、Taints/Tolerations、Pod 预留等。得到一个通过所有过滤器的“候选节点”列表。

优选阶段 (Priority)

打分：为通过预选的节点打分，评估其“好坏”。
节点资源利用率、负载均衡、拓扑位置（如优先同一机架/区域）。结果: 得到一个按分数降序排列的节点列表

绑定阶段 (Bind)

选择得分最高的节点
将选择结果写入本地缓存 (Scheduler Cache)，记录资源占用，并尝试预留资源。
异步调用 API Server，更新 Pod 的 spec.nodeName，将 Pod 绑定到选定节点。
Kubelet 监听到 Pod 绑定事件后，开始创建容器

Pod 的启动流程

用户通过kubectl或其他工具提交pod的yaml配置到API Server
API Server 收到请求后，将配置存储到etcd中
Scheduler 根据调度策略，将 Pod 绑定到合适的节点
Kubelet 监听到 Pod 绑定事件后，开始创建容器
- 拉取镜像
- 创建sandbox，sandbox中所有容器共享网络和存储命名空间
- 调用容器运行时创建pod中的容器
- 如果有init容器，kubelet先于应用容器启动他们
- aws-node 创建pod网卡，分配IP地址
容器启动后，Kubelet 向 API Server 发送状态更新
API Server 收到更新后，将状态存储到etcd中
用户通过kubectl或其他工具查询 Pod 状态时，API Server 从etcd中获取最新状态并返回

Pod DNS 解析失败排查

检查 Pod 内部和配置

kubectl exec -it – nslookup kubernetes.default 集群内部 DNS 故障
kubectl exec -it – curl https://www.google.com 上游 DNS 或 CoreDNS 配置问题
检查 DNS Policy：查看 Pod YAML，确保 dnsPolicy (如 ClusterFirst) 配置正确. Default: Pod 从运行所在的节点继承域名解析配置 ClusterFirst: Pod 先从集群内部 DNS 解析，失败后再使用节点 DNS 配置

检查coredns

检查core dns 负载
检查coredns configmap forward

排查 kube-proxy DNS 的流量是 Pod → kube-proxy → CoreDNS Pod
检查 CNI 网络插件
是否使用了 Istio / Linkerd / Envoy sidecar

Pod 的常见调度方式

默认调度器（Default Scheduler）
节点选择器（Node Selector）
亲和性和反亲和性（Affinity and Anti-Affinity）
污点和容忍度（Taints and Tolerations）
资源请求和限制（Resource Requests and Limits）
Pod 拓扑调度（Pod Topology Spread）：不同节点/机架均匀分布
抢占调度（Preemption）

Pause 容器的用途

Pause 容器唯一的作用是保证即使 Pod 中没有任何容器运行也不会被删除，因为这时候还有 Pause 容器在运行。

网络命名空间隔离
进程隔离
资源隔离
生命周期管理

Pod 健康检查失败可能的原因和排查思路

探针配置问题
应用未启动/响应慢：超出initialDelaySeconds，进程退出 (CrashLoopBackOff)
资源限制：CPU/内存不足，导致Kubelet无法正常运行检查
网络问题：容器无法访问外部服务，如DNS解析失败
依赖不可用：数据库、缓存等依赖服务未就绪
数据库、缓存等依赖服务未就绪

排查思路

kubectl describe pod
kubectl logs
检查健康检查配置
进入容器内部排查
- 使用curl, wget测试HTTP探针路径。
- netstat -tulnp或ss -tulnp确认端口是否监听
检查资源与节点

Pod 之间访问不通怎么排查

Pod 的几种常见状态

Pod Phase

Running
Succeeded Job 完成、CronJob 完成
Failed 程序崩溃、容器启动失败
Pending 资源不足、NodeSelector 无匹配、拉镜像慢
Unknown kubelet 无法上报状态，节点掉线、网络中断

创建/调度相关

ContainerCreating 容器正在创建容器，拉取镜像
PodInitializing 容器正在初始化，执行 init 容器
ImagePullBackOff 拉镜像失败（认证问题、镜像不存在）
ErrImagePull 同上，比 BackOff 更早期

运行中异常

CrashLoopBackOff 容器崩溃后，kubelet 会根据 backoff 策略（默认 10s 后重试）重启容器
OOMKilled 容器内存超出限制，被 kubelet 强制kill
BackOff 多次失败后进入退避（如 init 容器失败）
CrashLoopBackOff 主容器不断崩溃重启
CreateContainerConfigError 容器创建配置错误（如挂载卷不存在）
Error 容器非0退出（但不一定重启策略触发失败）

退出/终止

Terminating 容器正在终止（如删除 pod）
Completed 容器正常退出（如主容器退出）
Failed 容器非0退出，且重启策略为 Never

SRE面试题汇总 | Docker

Sat, 06 Dec 2025 09:56:07 +0800

容器技术的基础原理

容器技术的基础原理是基于 Linux 内核的 Namespace、Cgroups、Rootfs、Capabilities 和 Seccomp 等机制。

它主要解决了应用运行环境不一致的问题：将应用、依赖和配置打包为可复用的镜像，再以隔离的进程方式运行。

容器镜像通常利用 Linux 的 Union FS 能力，将基础系统、运行库、应用文件和配置等内容以分层方式组织起来。容器启动时，运行时会把镜像层和可写层组合成容器的 Rootfs。

如何减小 Dockerfile 生成的镜像体积？

使用更小的基础镜像
将构建环境与运行环境分离，使用多阶段构建：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


# 第一阶段：编译
FROM golang:1.22-alpine AS builder
WORKDIR /app
COPY . .
RUN CGO_ENABLED=0 go build -trimpath -ldflags="-s -w" -o /out/app .

# 第二阶段：运行
FROM alpine:3.19
COPY --from=builder /out/app /usr/local/bin/app
CMD ["/usr/local/bin/app"]

及时清理构建缓存和临时文件，并让 apt、yum、apk 的缓存不要进入最终镜像层。例如 Debian/Ubuntu 可以使用 --no-install-recommends。
合并关联的 RUN 指令，避免清理操作发生在下一层，导致缓存仍然保留在镜像历史中。
最终运行阶段只复制必要的二进制文件、配置和证书，不要复制整个源码目录。
使用 .dockerignore 排除 .git、测试数据、日志、构建产物和本地依赖等无关文件。
根据程序依赖选择基础镜像。Alpine 不一定适合所有程序，使用 C/C++ 或 CGO 时要注意 musl/glibc 兼容性；使用 scratch 或 distroless 时还要补充 CA 证书、时区等运行时文件。

容器网络模式

网络模式	特点	典型场景
`bridge`	默认模式，容器拥有独立的 Network Namespace 和 IP，通过网桥通信；外部通常通过端口映射访问	普通 Web 服务、微服务，最常用
`host`	容器直接使用宿主机网络栈，没有独立的网络 Namespace，不经过常规 NAT	对网络性能或端口可见性要求较高的场景
`none`	只保留 loopback，不配置外部网络，需要应用自行配置网络	强隔离或自定义网络实验
`container:<name\|id>`	与另一个容器共享 Network Namespace，共享 IP、端口和 `localhost`	Sidecar、多容器协作

container 模式下，两个容器访问对方通常使用 localhost 和共享端口，而不是把它们当成拥有两个独立 IP 的容器。

Docker、镜像和 container 的区别

Docker / Docker Engine：容器平台和容器引擎，负责镜像构建、容器创建与管理、网络、Volume 等能力。
镜像（Image）：只读的分层模板，包含应用程序及其依赖、文件系统和默认配置，本身不是正在运行的进程。
容器（Container）：镜像启动后的运行实例，本质上是一组被 Namespace 和 Cgroups 隔离、限制和管理的进程。
containerd：负责镜像传输与存储、容器生命周期等核心工作的容器运行时；Docker Engine 内部也会使用 containerd。

为什么 Kubernetes 从 Docker Engine 转向 containerd？

Kubernetes 真正需要的是符合 CRI（Container Runtime Interface）的容器运行时，而 Docker Engine 是一个包含镜像构建、网络、Volume、Swarm 等能力的完整平台，并没有直接面向 kubelet 的原生 CRI 接口。

架构层面的原因

使用 Docker Engine 时，kubelet 启动容器通常需要经过 dockershim 转换层：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


kubelet
 │ 调用 CRI
 ▼
dockershim（Kubernetes 维护的 CRI 转换层）
 │ 调用 Docker Engine API
 ▼
Docker Engine
 │ 调用 containerd API
 ▼
containerd
 │ 调用 OCI Runtime
 ▼
runc（以 runc 为例）
 └─> 创建 Linux 容器（Namespace、Cgroups、Rootfs 等）

Docker Engine 的很多平台能力对 kubelet 并不是必需的。
dockershim 负责把 Kubernetes 的 CRI 调用转换为 Docker Engine API 调用，增加了维护成本和中间环节。
真正创建 Linux 容器的通常仍是 containerd 加 OCI Runtime，例如 runc。

当 kubelet 直接通过 CRI 使用 containerd 时，调用链可以简化为：

1
2
3
4
5
6
7
8


kubelet
 │ 调用 CRI
 ▼
containerd（CRI 插件）
 │ 调用 OCI Runtime
 ▼
runc（以 runc 为例）
 └─> 创建 Linux 容器（Namespace、Cgroups、Rootfs 等）

减少维护成本

Kubernetes 1.24 移除了内置的 dockershim，不再在 Kubernetes 项目中维护 Docker Engine 的适配层。这里的含义不是 Kubernetes 强制所有集群使用 containerd，containerd、CRI-O 等符合 CRI 的运行时都可以使用；containerd 只是常见选择之一。

性能与稳定性

直接使用 CRI 运行时可以减少适配层和组件数量，降低维护复杂度，并可能减少额外的调用开销。但实际性能和稳定性还取决于运行时版本、CNI、存储驱动、镜像配置和工作负载，不能简单认为“少一层调用”就一定带来显著性能提升。

科学上网

Fri, 05 Dec 2025 16:38:33 +0800

本文内容仅用于个人学习和访问公开技术资料。请遵守所在地区的法律法规，以及云服务商和网络服务商的使用条款。

安装服务端：3x-ui

当前使用 3x-ui 管理 Xray 服务。它提供 Web 控制面板，可以创建和管理 VMess、VLESS、Trojan、Shadowsocks、WireGuard 等多种协议，并生成客户端配置、二维码和订阅链接。

安装

3x-ui GitHub 官方仓库

创建入站并获取客户端配置

使用安装结果中的地址和凭据登录 3x-ui 面板。
进入 入站 (Inbounds)，新建一个入站配置。本文以 VMess 为例；端口、UUID、传输方式以及 TLS/Reality 等参数按自己的域名和服务器配置填写。
保存配置后，在客户端列表中复制订阅链接，或使用面板生成的二维码、分享链接。
将订阅链接或二维码导入客户端。客户端连接参数必须与 3x-ui 面板中的入站配置完全一致。

订阅链接、服务器地址、端口和 UUID 都属于敏感配置，不要提交到公开仓库、博客或聊天群。如果订阅链接已经泄露，请在面板中重新生成或撤销对应客户端。

客户端使用

iOS

客户端选择和下载可参考 V2Ray 客户端整理。当前使用 V2Box 时，中国区 App Store 可能无法直接下载，需要根据自己的账号地区选择可用客户端，并遵守相关服务条款。

配置方式优先选择从 3x-ui 导出的二维码或分享链接直接导入。手动添加时，可以按以下方式填写：

协议 (Protocol)：选择 VMess
服务器、端口、UUID：填写 3x-ui 入站配置中的值
传输方式、TLS、Host、Path 等：与面板生成的客户端配置保持一致

导入完成后，选择该配置并连接；不要把服务器管理面板的用户名和密码填入客户端。

Android

推荐使用 NekoBoxForAndroid，也可以从其 Releases 页面下载对应版本。

打开 NekoBox 后，可以通过二维码、vmess:// 分享链接或订阅链接导入配置。导入后选择节点，启动 VPN，并访问一个可信的测试页面确认连接是否正常。

macOS

推荐使用 Clash Verge Rev，安装包位于其 Releases 页面。

使用 3x-ui 订阅时：

在 3x-ui 面板中复制客户端订阅链接。
在 Clash Verge Rev 的订阅页面，将链接粘贴到“订阅文件链接”输入框。
点击新建或导入，等待配置下载完成。
更新订阅后，选择对应配置，并在代理页面选择节点。
根据需要开启系统代理，选择规则模式或全局模式，然后访问可信网站测试。

如果只有单条 VMess 链接而没有 Clash 订阅，可使用在线订阅转换工具转换格式。订阅链接通常包含访问凭据，在线转换前应确认服务可信；更稳妥的方式是使用本地转换工具，并在使用临时订阅后及时撤销旧链接。

参考资料

旧版 V2Ray 搭建教程：仅作背景参考，当前服务端安装以 3x-ui 官方文档为准。
3x-ui 官方仓库

SRE面试题汇总 | Monitoring

Fri, 05 Dec 2025 13:38:56 +0800

监控指标类型及应用场景

Prometheus 中常见的指标类型包括 Counter、Gauge、Histogram 和 Summary。选择指标类型时，要结合指标是否单调递增、是否需要聚合，以及是否需要计算分位数来判断。

Counter：计数器

用于记录请求次数、错误次数、完成任务数等事件数量。

特点：在单个进程生命周期内单调递增，只能增加不能减少；进程重启后通常会从 0 重新开始，Prometheus 的 rate、increase 等函数可以处理这类 Counter 重置。
场景：请求总数、错误总数、已完成任务总数。

Gauge：计量器

用于记录某一时刻的数值，例如内存使用量、CPU 使用率、磁盘空间和队列长度。

特点：可以增加，也可以减少，数值会随时间上下变化。
场景：CPU、内存、磁盘、网络流量、在线人数、队列长度。

Histogram：直方图

用于记录请求延迟、响应大小等样本的分布情况。应用需要预先定义 bucket，例如 10ms、50ms、100ms 和 500ms，Prometheus 根据 bucket 在服务端计算分位数。

可以聚合多个实例的 bucket，计算整个服务的全局 p95、p99。
适合业务接口延迟、任务耗时和响应大小等分布监控。

1
2
3
4


histogram_quantile(
 0.99,
 sum by (le) (rate(http_request_duration_seconds_bucket[5m]))
)

Summary：摘要

Summary 不需要预先定义 bucket，而是在客户端或应用进程内维护 quantile，并将计算结果暴露给 Prometheus。

适合每个实例独立统计的场景。
不适合聚合跨实例的全局分位数。例如 10 个 Pod 各自暴露 p99，Prometheus 不能直接对这 10 个 p99 再计算出整个服务的准确 p99。
Summary 的 _sum 和 _count 可以参与聚合计算平均值，但分位数本身通常不能直接聚合。

生产环境中，如果需要计算整个服务的全局分位数，通常优先选择 Histogram；如果只关心单个实例的本地分布，Summary 也可以使用。

黄金指标

常见的四类黄金指标是 Latency、Traffic、Errors 和 Saturation：

延迟（Latency）：请求从开始到结束耗费的时间，通常关注 p50、p95、p99。

1

histogram_quantile(0.95, sum by (le) (rate(http_request_duration_seconds_bucket[5m])))

流量（Traffic）：系统承载的请求量或业务量，常用 QPS 表示。
1

sum(rate(http_requests_total[5m])) by (handler)

错误率（Error Rate）：失败请求占总请求的比例。

1
2
3


sum(rate(http_requests_total{status=~"5.."}[5m]))
/
sum(rate(http_requests_total[5m]))

饱和度（Saturation）：资源接近容量上限的程度，例如 CPU、内存、连接池、线程池和队列的使用情况。具体 PromQL 要根据采集的指标定义，不能只用一个通用表达式代替所有资源。

rate 与 irate 的区别

rate：根据指定时间窗口内的多个样本计算平均每秒增长率，结果更平滑，适合趋势分析和告警。
irate：只使用时间窗口内最后两个样本计算瞬时增长率，对短期突发变化非常敏感，适合实时看板或快速观察突发流量。

告警通常优先使用 rate，并结合较短的 for 持续时间减少误报。irate 并不是绝对不能用于告警，但需要确认采样间隔、窗口长度和业务波动都适合，否则容易因单个采样点抖动而频繁触发。

如何对采集指标进行过滤？

在 Prometheus 或 vmagent 中，常见的过滤位置如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


Exporter / Kubernetes / AWS 云监控
 │
 ▼
 vmagent
 │
 ├─ relabel_configs
 │ 抓取前，处理 Target 标签和目标地址
 │
 ├─ 发起 HTTP 请求抓取 /metrics
 │
 ├─ metric_relabel_configs
 │ 抓取后，处理每条时序样本
 │
 ├─ write_relabel_configs
 │ Remote Write 发送前，过滤即将写出的时序
 │
 ▼
 vminsert
 │
 ▼
 vmstorage

relabel_configs：发生在抓取前，常用于修改目标标签、替换地址、按环境过滤 Target。
metric_relabel_configs：发生在抓取后，作用于每条指标，适合丢弃不需要写入的高基数指标或标签。
write_relabel_configs：发生在 Remote Write 发送前，可按目标远程存储过滤时序。

过滤规则要谨慎使用，尤其要关注高基数标签、误删核心指标以及规则变更后的数据缺口。

Prometheus 服务发现方式

Service Discovery（SD）用于自动发现需要抓取的 Target。常见方式包括静态配置、文件服务发现、Kubernetes SD、Consul SD 和云厂商 SD。

静态配置

适合 Target 数量少、地址变化不频繁的场景：

1
2
3
4
5
6


scrape_configs:
 - job_name: node
 static_configs:
 - targets:
 - 10.0.0.1:9100
 - 10.0.0.2:9100

File SD：文件服务发现

由外部系统生成 JSON 或 YAML 文件，Prometheus 定期读取文件中的 Target：

1
2
3
4
5


scrape_configs:
 - job_name: node
 file_sd_configs:
 - files:
 - /etc/prometheus/*.json

Kubernetes SD

Prometheus 通过 Kubernetes API 发现 Pod、Service、Node 等对象，再配合 relabel 选择需要抓取的目标：

1
2
3
4
5


scrape_configs:
 - job_name: kubernetes-pods
 honor_labels: true
 kubernetes_sd_configs:
 - role: pod

实际使用时还需要配置 Kubernetes API 访问权限，并通过 relabel_configs 过滤 Namespace、Annotation 或 Label。

Consul SD

服务注册到 Consul 后，Prometheus 根据服务标签和健康状态自动发现目标：

1
2
3
4
5


scrape_configs:
 - job_name: consul-services
 consul_sd_configs:
 - server: 10.151.91.180:8500
 datacenter: dc1

AWS EC2 SD

在 AWS 环境中可以通过 EC2 服务发现获取实例信息，通常使用实例角色提供权限，避免把 Access Key 直接写入配置文件：

1
2
3
4
5


scrape_configs:
 - job_name: ec2-node
 ec2_sd_configs:
 - region: ap-southeast-1
 port: 9100

Target 监控不到如何排查？

先从 Prometheus 的 /targets 页面或 API 查看 Target 处于哪一种状态：

1

curl http://prometheus:9090/api/v1/targets

Target 不存在

检查 static_configs、File SD 文件和服务发现配置是否生效。
检查 Prometheus 或 vmagent 是否有权限访问 Kubernetes API、Consul 或云厂商 API。
检查 relabel_configs 是否误删了 Target，尤其是 action: drop 和 action: keep。
如果使用 File SD，确认文件路径、JSON/YAML 格式和文件权限正确。

Target 存在但状态为 DOWN

从 Prometheus 或 vmagent 所在的 Pod/主机执行 curl，确认目标地址和端口可达。
检查 metrics_path、scheme、端口、HTTP 认证和 TLS 证书配置。
检查安全组、防火墙、NetworkPolicy、Service 和 Endpoints 是否放行流量。
查看 Target 的 Last Error，区分连接拒绝、连接超时、DNS 失败、TLS 失败和返回非 2xx。

Target UP 但查询不到指标

直接访问目标的 /metrics，确认指标确实被应用或 Exporter 暴露。
检查 metric_relabel_configs 或 Remote Write 过滤规则是否丢弃了指标。
检查 PromQL 中的指标名、Label、时间范围和数据源是否正确。
检查 Grafana 数据源、远程存储写入链路和数据保留策略。

排障时要先确认“Target 是否存在”，再确认“是否能抓取”，最后确认“指标是否被写入和查询”，不要一开始就只看 Grafana 面板。

SRE面试题汇总 | Network

Thu, 04 Dec 2025 19:36:01 +0800

OSI 七层模型

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


发送端（电脑A） 接收端（电脑B）
+----------------+ +----------------+
| 应用层：Data | | 应用层：Data |
| "Hi" | | "Hi" |
+-------+--------+ +-------^--------+
 | |
| 表示层：Data + 表示头 表示层：Data（剥离表示头）
+-------+--------+ +-------^--------+
 | |
| 会话层：Data + 会话头 会话层：Data（剥离会话头）
+-------+--------+ +-------^--------+
 | |
| 传输层：Segment（Data + 端口头） 传输层：Data（剥离端口头）
+-------+--------+ +-------^--------+
 | |
| 网络层：Packet（Segment + IP头） 网络层：Segment（剥离IP头）
+-------+--------+ +-------^--------+
 | |
| 数据链路层：Frame（Packet + MAC头 + CRC）数据链路层：Packet（剥离MAC头+CRC）
+-------+--------+ +-------^--------+
 | |
| 物理层：Bits（Frame转换） 物理层：Frame（Bits转换）
+-------+--------+ +-------^--------+
 | |
 +---------------------------------------+
 物理介质（网线/无线）

OSI 层	核心功能	关键设备 / 组件
应用层	提供应用程序之间的通信	浏览器、FTP客户端、SMTP客户端
表示层	数据的表示和转换	加密、压缩
会话层	管理会话连接	会话ID
传输层	端到端通信	TCP、UDP
网络层	跨网络路由与 IP 地址识别	路由器、三层交换机
数据链路层	帧传输与 MAC 地址识别	网卡、交换机
物理层	比特流传输	网线、光纤

HTTP/1.1 和 HTTP/2 的区别

特性	HTTP/1.1	HTTP/2
传输开销	文本传输，开销较大	二进制流传输，开销更小
多路复用	HTTP/1.1 管线化实践有限，通常需要多个连接并行请求	单个 TCP 连接上可以同时承载多个数据流，减少队头阻塞
服务器推送	不支持	协议支持，但主流浏览器中的实际使用已比较有限
标头压缩	不压缩或简单压缩，冗余信息多	使用 HPACK 压缩，减少冗余，提高加载速度

TCP 协议

TCP 的连接状态

ESTABLISHED 的字面含义是“已建立、已确立”。在 TCP 状态机中，它表示三次握手已经完成，双方可以正常收发数据，并不表示连接已经建立了很长时间或已经投入使用很久。

下面这张图补充了 TCP 从建立连接到关闭连接的主要状态变化：

建立连接：客户端从 SYN_SENT 开始，服务器从 LISTEN 进入 SYN_RCVD；第三次握手完成后，双方都进入 ESTABLISHED。
主动关闭的一方：通常依次经历 FIN_WAIT_1、FIN_WAIT_2、TIME_WAIT，最后进入 CLOSED。
被动关闭的一方：收到 FIN 后进入 CLOSE_WAIT，应用关闭连接后发送 FIN，再进入 LAST_ACK，收到 ACK 后进入 CLOSED。
TIME_WAIT：主动关闭方为确保最后的 ACK 能够重传，并让旧报文在网络中自然过期而暂时保留连接状态，通常持续约两个最大报文段寿命（2MSL）。

客户端出现大量 `TIME_WAIT` 的原因

短连接过多
- HTTP Keep-Alive 未开启
- 使用 HTTP/1.0 或 Connection: close
- 数据库、Redis、RPC 连接池没有复用
- 连接池配置过小或配置错误
请求量或连接创建速率很高，例如高 QPS 场景。
超时、重试或熔断配置不合理，导致连接反复建立和关闭。
负载均衡代理配置不合理，例如负载均衡器、Nginx 或网关的 idle timeout 不匹配，导致连接频繁断开和重建。

为什么 TCP 是三次握手

TCP 三次握手的目的，是在正式传输数据之前，让通信双方确认彼此具备收发能力，并协商连接参数（如初始序列号），建立可靠连接。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Client Server

SYN(seq=100)
---------------------------->

 SYN(seq=500)
 ACK=101
<----------------------------

ACK=501
---------------------------->

Connection Established

第一次握手，客户端发送 SYN 报文，请求建立连接，并携带自己的初始序列号。

第二次握手，服务器收到后返回 SYN+ACK，一方面确认客户端的 SYN，另一方面发送自己的初始序列号。

第三次握手，客户端发送 ACK，确认服务器的 SYN。至此，双方进入 ESTABLISHED 状态，可以开始可靠的数据传输。

为什么不是 2 次握手

两次握手只能让服务器确认收到了客户端的 SYN，不能让客户端确认服务器已经收到自己的报文，也不能让服务器确认客户端已经收到了自己的 SYN+ACK。若网络中存在延迟到达的旧 SYN，服务器还可能为一个实际上已经失效的请求分配连接资源，形成半连接或错误连接。

为什么不是 4 次或更多？

3 次已经足以建立连接，4 次或更多次握手会增加复杂性和资源浪费

TCP 的核心特点

面向连接
保证数据可靠到达
具有重传机制
保证数据有序
具有流量控制
具有拥塞控制

UDP 的核心特点

无连接
不保证送达
通常不负责重传
延迟较低、开销较小

什么是滑动窗口？

发送方不需要每发送一个数据段就等待 ACK，而是可以在窗口允许的范围内连续发送多个数据段。接收方通过 ACK 和接收窗口（rwnd）通知发送方哪些数据已经收到、还能接收多少数据，发送窗口会随着 ACK 的到来不断向前滑动，因此称为滑动窗口。

实际可发送的数据量还会受到拥塞窗口（cwnd）的限制，因此有效发送窗口通常取 min(rwnd, cwnd)。

DNS 解析流程

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71


客户端访问域名
例如：www.example.com
 │
 ▼
1. 查询浏览器 DNS 缓存
 │
 ├─ 命中
 │ └─ 返回 IP 地址
 │
 └─ 未命中
 │
 ▼
2. 查询操作系统 DNS 缓存
 │
 ├─ 命中
 │ └─ 返回 IP 地址
 │
 └─ 未命中
 │
 ▼
3. 查询 hosts 文件
 Linux：/etc/hosts
 Windows：hosts 文件
 │
 ├─ 命中
 │ └─ 返回 IP 地址
 │
 └─ 未命中
 │
 ▼
4. 向配置的 DNS Resolver 发起查询
 /etc/resolv.conf 中的 nameserver
 例如本地路由器、运营商 DNS、公共 DNS
 │
 ▼
5. DNS Resolver 查询自身缓存
 │
 ├─ 命中
 │ └─ 根据 TTL 返回 IP 地址
 │
 └─ 未命中
 │
 ▼
6. DNS 迭代查询
 │
 ▼
 根 DNS 服务器
 │
 ▼
 顶级域 DNS 服务器
 例如：.com、.cn
 │
 ▼
 权威 DNS 服务器
 例如：Route 53
 │
 ▼
 获得域名对应的 IP 地址
 │
 ▼
7. Resolver 将结果返回客户端
 同时根据 TTL 进行缓存
 │
 ▼
8. 客户端拿到 IP 地址
 │
 ▼
9. 发起 TCP 三次握手
 │
 ▼
10. 建立连接并开始传输数据

Route 53 可能位于流程中的两环：

在公网域名解析流程中，Route 53 通常位于：权威 DNS 服务器（迭代查询）

Route 53 VPC Resolver：递归 DNS Resolver（/etc/resolv.conf）

Cookie、Session、Token

三者都是状态管理或身份认证中常见的机制，区别可以从以下几个方面理解：

机制	主要存储位置	请求中如何携带	典型特点
Cookie	客户端浏览器	浏览器按域名和路径自动携带	适合浏览器会话；可设置 `HttpOnly`、`Secure`、`SameSite`
Session	服务端，客户端通常只保存 Session ID	Session ID 通常放在 Cookie 中	服务端保存状态，便于主动失效，但需要处理共享存储或会话粘滞
Token	通常由客户端保存，服务端负责校验	常放在 `Authorization` 请求头中	适合 API、移动端和服务间认证；可设计为无状态或配合服务端存储

Cookie、Session、Token 的安全性都取决于具体实现，Token 并不天然加密。JWT 默认是编码和签名，不能把其中的内容当作机密数据；需要保密时应使用加密或避免放入敏感信息。
Cookie 不是“天然不安全”：认证 Cookie 通常应设置 HttpOnly、Secure 和合适的 SameSite，同时防范 CSRF 和 XSS。
Token 也不是天然支持跨域。跨域请求仍受 CORS、Cookie 的 SameSite/Domain、请求头配置等规则约束；使用 localStorage 保存 Token 时，还要重点防范 XSS。
Cookie 常用于登录状态、用户偏好和会话保持；Session 适合购物车、表单流程等服务端状态较多的场景；Token 常用于 API 访问控制、SSO 和移动应用认证。

HTTP 状态码和原因

一些高频考察的状态码：

200 OK：请求成功。
201 Created：资源创建成功，常见于 POST 请求。
301 Moved Permanently：资源已永久移动，常用于域名或 URL 迁移。
302 Found：临时重定向，常用于登录跳转；具体语义还要结合请求方法和客户端行为判断。
400 Bad Request：请求格式、参数或协议不符合要求。
401 Unauthorized：未认证或认证信息无效；不是“没有权限”的唯一表示。
403 Forbidden：服务器理解请求，但拒绝执行，例如 Token 有效但权限不足。
404 Not Found：请求的资源不存在，或服务端不希望暴露其是否存在。
429 Too Many Requests：请求频率超过限制。
500 Internal Server Error：服务端发生未被更具体状态码描述的异常。
502 Bad Gateway：网关或反向代理从上游服务收到无效响应，或无法正确解析上游响应。
503 Service Unavailable：服务暂时不可用，可能处于过载、维护或没有可用实例的状态。
504 Gateway Timeout：网关等待上游响应超时。

🔥502、503、504的区别

1
2
3
4
5


客户端
 ↓
网关 / Nginx / Load Balancer
 ↓
上游服务

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


客户端请求
 │
 ▼
网关连接上游
 │
 ├─ 上游连接失败或返回非法响应
 │ └─ 502
 │
 ├─ 没有健康的上游实例
 │ └─ 503
 │
 ├─ 上游处理很慢，超过网关超时时间
 │ └─ 504
 │
 └─ 正常返回
 └─ 返回上游实际响应

状态码	含义	典型场景
502 Bad Gateway	网关从上游收到无效响应	上游进程崩溃、连接被重置、响应格式错误、协议或 TLS 握手异常
503 Service Unavailable	当前没有可用服务处理请求	服务过载、正在发布、实例全部不健康、线程池/连接池耗尽、限流或熔断
504 Gateway Timeout	网关等待上游响应超时	上游处理太慢、数据库查询慢、网络延迟、网关超时时间过短

Linux 网络丢包排查

排查链路：

1

应用 → 系统调用 → Linux 网络栈 → 网卡队列 → 云网络 → 外部链路 → 对端

从应用和连接现象开始

查看应用日志，确认是连接超时、连接被拒绝、读超时，还是接口 QPS 突增。
使用 curl、wget 或业务客户端复现，区分 DNS、TCP、TLS 和 HTTP 哪一层失败。
用 ss 查看连接状态，用 tcpdump 验证报文是否发出、是否收到响应：

1
2
3


ss -s
ss -antp
sudo tcpdump -i eth0 host <peer-ip> -w app.pcap

检查网卡、内核网络栈和 CPU

1
2
3
4
5


ip -s link show dev eth0
ethtool -S eth0
ethtool -g eth0
netstat -s
nstat -az

常见指标含义：

指标	含义	常见原因
`rx_dropped`	接收丢包	网卡或内核接收队列满、策略丢弃
`rx_errors`	接收错误	CRC、帧格式或驱动错误
`tx_errors`	发送错误	网卡、驱动或链路异常
`rx_no_buffer`	接收缓冲不足	突发流量或处理不及时
`rx_over_errors`	接收队列溢出	CPU、软中断或队列处理能力不足

检查内核队列和 TCP 缓冲区：

1
2
3
4
5


sysctl net.core.netdev_max_backlog
sysctl net.core.rmem_default
sysctl net.core.wmem_default
sysctl net.ipv4.tcp_rmem
sysctl net.ipv4.tcp_wmem

如果丢包伴随 CPU 较高，还要观察软中断和网卡多队列配置：

1
2
3
4


mpstat -P ALL 1
cat /proc/interrupts
ethtool -l eth0
ethtool -k eth0

检查路由、防火墙和网络路径

1
2
3
4
5
6


ip addr
ip route get <target-ip>
ip neigh
ping -c 4 <target-ip>
mtr -rwzbc 100 <target-ip>
traceroute <target-ip>

注意：ping 或 mtr 丢包不一定代表业务 TCP 丢包，部分设备会限制 ICMP 或降低 ICMP 优先级，最终仍应结合业务端口和抓包判断。

检查端口监听、防火墙和连接跟踪：

1
2
3
4


ss -lntp
sudo nft list ruleset
sudo iptables -L -n -v
sudo conntrack -S

用抓包定位丢包位置

1
2
3
4
5


# 本机抓取指定主机和端口的报文
sudo tcpdump -i eth0 -nn host <peer-ip> and port 443 -w local.pcap

# 只看 TCP 握手、重传和连接关闭相关信息
sudo tcpdump -i eth0 -nn 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0'

通过比较客户端、代理和对端的抓包，可以判断是“本机没有发出”“对端没有收到”“对端已回复但中间丢失”，还是“应用收到报文但处理超时”。云环境中还要结合云厂商的网卡、负载均衡器和安全组指标。

其他常用工具

sar -n DEV 1：查看网卡吞吐和错误统计。
sar -n TCP,ETCP 1：观察 TCP 建连、重传和失败情况。
iperf3：在两台受控主机之间验证带宽、延迟和吞吐能力。
ethtool：查看网卡协商、Ring Buffer、Offload 和硬件统计。

常见网络排查命令

上面的内容是按丢包链路排查，下面按命令类别整理一份面试和实际排障时常用的速查表。

网卡、IP、路由

命令	作用	重点关注	常见问题
`ip addr`	查看网卡和 IP	IP、子网、网卡状态	IP 配置错误、网卡未启用
`ip link`	查看网卡链路状态	`UP`、`DOWN`	网卡或链路故障
`ip route`	查看路由表	默认路由、目标网段	路由缺失、网关错误
`ip route get 8.8.8.8`	查看访问目标 IP 的实际路径	出口网卡、网关、源 IP	流量走错出口
`ip neigh`	查看 ARP 邻居	`REACHABLE`、`FAILED`	ARP 异常、网关不可达
`ip -s link`	查看网卡收发包统计	`errors`、`dropped`、`overruns`	网卡丢包、驱动异常

DNS 解析

命令	作用	重点关注	常见问题
`dig example.com`	查询域名解析	A、AAAA、CNAME、TTL	解析记录错误
`dig @8.8.8.8 example.com`	指定 DNS 查询	不同 DNS 返回结果	DNS 污染或 DNS 不一致
`dig +trace example.com`	查看完整迭代过程	根 DNS、顶级域、权威 DNS	委派链路异常
`getent hosts example.com`	按系统实际流程解析	hosts、NSS、系统 DNS	程序和 `dig` 结果不一致
`cat /etc/resolv.conf`	查看 DNS 配置	`nameserver`	DNS Server 配置错误
`cat /etc/hosts`	查看本地映射	是否存在错误记录	hosts 覆盖了正确解析

网络连通性和路径

命令	作用	重点关注	常见问题
`ping -c 4 8.8.8.8`	测试 IP 连通性	延迟、丢包	网络不通、链路丢包
`traceroute 8.8.8.8`	查看网络路径	从哪一跳开始异常	路由或中间设备问题
`tracepath 8.8.8.8`	查看路径和 MTU	MTU、路径变化	MTU 不匹配
`mtr -rw 8.8.8.8`	持续测试路径质量	丢包、延迟	链路抖动、网络拥塞
`nc -vz 10.0.0.10 8080`	测试 TCP 端口	是否能建立连接	防火墙、端口未监听

ping 不通不一定代表服务不可用，因为 ICMP 可能被防火墙禁止；排查业务时还要使用目标端口进行验证。

端口和 TCP 连接

命令	作用	重点关注	常见问题
`ss -lntup`	查看监听端口和进程	监听地址、端口、PID	服务未监听、只监听 `127.0.0.1`
`ss -antp`	查看所有 TCP 连接	TCP 状态、对端地址	连接堆积、连接泄漏
`ss -s`	查看连接汇总	`ESTABLISHED`、`TIME-WAIT`、`CLOSE-WAIT`	连接数量异常
`ss -ant state time-wait`	查看 TIME_WAIT	数量、对端分布	短连接过多、临时端口耗尽
`ss -ant state close-wait`	查看 CLOSE_WAIT	数量是否持续增长	应用没有及时 close
`lsof -i :8080`	查看端口占用进程	PID、进程名	端口被错误进程占用
`fuser -n tcp 8080`	查看端口对应进程	PID	快速定位端口进程

HTTP、HTTPS 和应用层

命令	作用	重点关注	常见问题
`curl -v http://example.com`	查看 HTTP 访问过程	请求头、响应头、状态码	502、503、504、重定向
`curl -I https://example.com`	只查看响应头	HTTP 状态、`Location`、`Server`	网关、重定向、服务状态
`curl -k -v https://example.com`	排查 HTTPS/TLS	证书、TLS 握手、协议版本	证书错误、TLS 握手失败
`curl -o /dev/null -sS -w '时间统计' https://example.com`	查看分阶段耗时	DNS、TCP、TLS、TTFB、总耗时	定位请求慢在哪个阶段

其中，curl -w 可以输出 %{time_namelookup}、%{time_connect}、%{time_appconnect}、%{time_starttransfer} 和 %{time_total} 等字段，用来拆分请求耗时。

tcpdump 抓包

命令	用途	重点观察
`tcpdump -nn -i any host 10.0.0.10`	抓取指定 IP 流量	是否有请求和响应
`tcpdump -nn -i eth0 port 8080`	抓取指定端口流量	TCP 建连、数据传输
`tcpdump -nn -i any 'tcp[tcpflags] & tcp-syn != 0'`	查看 SYN	是否发出 SYN、是否收到 SYN-ACK
`tcpdump -nn -i any 'tcp[tcpflags] & tcp-rst != 0'`	查看 RST	谁重置了连接
`tcpdump -nn -i any 'tcp[tcpflags] & tcp-fin != 0'`	查看 FIN	谁主动关闭连接
`tcpdump -nn -i any -c 100 -s 0 -w /tmp/test.pcap port 8080`	抓取并保存报文	后续使用 Wireshark 分析
`tcpdump -nn -r /tmp/test.pcap`	读取抓包文件	离线分析报文

tcpdump 参数含义

参数	含义
`-i eth0`	指定抓包网卡
`-i any`	抓取所有网卡，Linux 常用
`-n`	不把 IP 解析成域名
`-nn`	不解析 IP，也不把端口解析成服务名
`-c 100`	抓取 100 个报文后退出
`-s 0`	抓取完整报文，避免内容被截断
`-v`、`-vv`、`-vvv`	显示更多详细信息
`-A`	以 ASCII 显示报文内容
`-X`	同时显示十六进制和 ASCII
`-w file.pcap`	保存为抓包文件
`-r file.pcap`	读取抓包文件
`-tttt`	显示完整可读时间
`-e`	显示 MAC 地址等二层信息

tcpdump 过滤条件

条件	含义
`host 10.0.0.10`	来源或目标是指定 IP
`src host 10.0.0.10`	来源 IP 是指定 IP
`dst host 10.0.0.10`	目标 IP 是指定 IP
`port 8080`	来源或目标端口是 8080
`src port 8080`	来源端口是 8080
`dst port 8080`	目标端口是 8080
`tcp`	只抓 TCP
`udp`	只抓 UDP
`icmp`	只抓 ICMP
`and`	并且
`or`	或者
`not`	排除

网络性能和协议统计

命令	作用	重点关注	常见问题
`sar -n DEV 1`	查看网卡流量	收发速率、错误、丢包	带宽打满、网卡异常
`sar -n TCP,ETCP 1`	查看 TCP 统计	建连、关闭、重传	TCP 重传、连接失败
`nstat`	查看协议栈统计	Retrans、RST、失败	内核协议栈异常
`ethtool -S eth0`	查看网卡底层统计	CRC、队列、丢包	网卡驱动或硬件问题
`iperf3 -s` / `iperf3 -c <IP>`	测试两台机器吞吐	带宽、重传	链路带宽不足

防火墙、连接跟踪和内核参数

命令	作用	重点关注	常见问题
`nft list ruleset`	查看 nftables 规则	DROP、REJECT	防火墙拦截
`iptables -L -n -v`	查看 iptables 规则和命中数	DROP、REJECT、计数	规则误拦截
`conntrack -S`	查看连接跟踪状态	是否接近容量上限	NAT 表满
`sysctl net.ipv4.ip_local_port_range`	查看临时端口范围	端口数量	临时端口耗尽
`sysctl -a \| grep tcp`	查看 TCP 内核参数	backlog、重传、端口复用	内核参数配置不合理

长连接、短连接、WebSocket 的区别和使用场景

短连接

客户端与服务器之间的连接在一次请求完成后关闭。HTTP/1.0 默认倾向于短连接；HTTP/1.1 通常使用 Keep-Alive，因此不能简单把“HTTP 请求”都等同于短连接。

适合交互频率低、请求完成后不需要保持连接的场景。
连接建立和关闭成本较高，高并发场景通常会配合连接池或连接复用。

长连接

一次 TCP 连接中可以进行多次请求和响应，减少频繁建立连接的开销。HTTP/1.1 默认支持持久连接，MySQL、Redis 等客户端也通常通过连接池复用连接。

适合频繁请求、连接建立成本较高或需要保持会话的场景。
需要合理设置空闲超时、最大连接数和心跳，否则可能积累大量空闲连接。

WebSocket

WebSocket 通常先通过 HTTP Upgrade 建立连接，随后在同一条 TCP 连接上进行全双工通信，服务器可以主动向客户端推送数据。

适合在线协作、即时消息、实时行情、在线游戏和部分 IoT 场景。
如果只是客户端周期性拉取数据，短轮询或 SSE 可能更简单；选型要结合通信方向、连接规模和代理兼容性。

MAC 地址和 IP 地址如何转换

在 IPv4 局域网中，ARP 用于根据目标 IP 查询下一跳的 MAC 地址，并通过 ARP 缓存保存映射关系。IPv6 不使用 ARP，而是使用邻居发现协议（NDP）。

以同一局域网内通信为例：

源主机查看 ARP 缓存；没有记录时，广播 ARP Request，携带源 IP、源 MAC 和待查询的目标 IP。
目标主机发现请求中的目标 IP 是自己后，单播返回 ARP Reply，携带自己的 IP 和 MAC；两端也会根据报文更新缓存。
源主机拿到目标 MAC 后，把 IP 数据包封装成以太网帧发送。

如果目标 IP 不在本地网段，源主机查询的不是目标主机 MAC，而是默认网关的 MAC，然后由路由器逐跳转发。

LVS、Nginx、HAProxy 的区别和使用场景

LVS：主要工作在四层，通过 IP、端口等信息转发 TCP/UDP 流量，性能和吞吐能力强，常用于大规模集群的基础负载均衡。
Nginx：主要工作在七层，擅长 HTTP/HTTPS 反向代理、静态资源、TLS 终止、基于域名或 URL 的路由；stream 模块也可以代理部分 TCP/UDP 流量。
HAProxy：同时支持四层和七层代理，健康检查、连接管理和负载均衡能力较强，常用于高性能 TCP 或 HTTP 代理场景。

实际架构中经常组合使用，例如 LVS 做四层流量分发，Nginx 或 HAProxy 在后端做七层路由和业务治理。

常见的负载均衡算法

轮询（Round Robin）：按顺序将请求分配给后端实例，适合实例配置相近的场景。
加权轮询（Weighted Round Robin）：按权重分配流量，适合实例规格不同或需要灰度的场景。
最少连接（Least Connections）：优先转发到当前连接数较少的实例，适合请求耗时差异较大的场景。
加权最少连接：同时考虑实例权重和连接数。
随机（Random）：随机选择一个后端实例处理请求。
加权随机（Weighted Random）：按照后端权重比例随机选择实例。
IP Hash / 一致性哈希：让同一客户端或同一 Key 尽量落到同一实例，适合需要会话粘滞的场景，但要注意实例扩缩容和热点问题。
随机或最短响应时间：根据随机结果或历史延迟选择后端，具体效果依赖实现和监控数据。

ALB 和 NLB 的区别

以下以云厂商常见的命名方式为例，不同厂商的具体能力和限制可能不同：

项目	ALB	NLB
工作层级	七层，通常处理 HTTP/HTTPS	四层，通常处理 TCP/UDP，也可能支持 TLS
路由依据	域名、URL、请求头、Cookie 等	IP、端口和连接
典型能力	URL 路由、TLS 终止、重写、WAF 集成	高吞吐、低延迟、长连接和静态 IP 等
适用场景	Web、API、微服务网关	数据库代理、TCP 服务、实时通信和高并发连接

CDN 常见面试题

CDN 如何实现就近访问？

用户访问加速域名时，通常先通过 DNS 或 GSLB 将请求调度到合适的 CDN 节点。调度时会综合地域、运营商、节点健康状态、负载和网络质量等信息。节点命中缓存时直接返回，未命中时向源站回源并缓存响应。

为什么域名要使用 CNAME？

业务域名通过 CNAME 指向 CDN 厂商提供的调度域名，厂商就可以根据实时节点状态和网络情况返回合适的节点 IP。直接配置固定 IP 会失去动态调度和故障切换能力。

什么情况下 CDN 会回源？

缓存未命中（Cache MISS）。
缓存已过期，或通过 ETag / Last-Modified 校验后需要重新获取内容。
源站通过 Cache-Control 指定不缓存，或请求携带了会绕过缓存的条件。
动态请求、个性化请求，或 CDN 配置为不缓存的资源。

CDN 缓存由哪些 HTTP 头控制？

Cache-Control: max-age=3600：指定浏览器缓存 3600 秒。
Cache-Control: s-maxage=3600：指定共享缓存（如 CDN）缓存 3600 秒，可以让浏览器较快更新，同时避免 CDN 频繁回源。
no-cache：可以缓存，但使用前必须向源站重新验证。
no-store：不应存储响应内容。
ETag、Last-Modified：用于条件请求和协商缓存，减少重复传输。

Purge 和 Preload 有什么区别？

Purge（刷新/清除缓存）：删除 CDN 节点上的旧缓存，使后续请求重新回源。
Preload（预热）：提前把资源从源站拉取到 CDN 节点，降低首次访问的回源延迟。

如何处理缓存击穿、缓存雪崩和热点 Key？

为不同资源设置合理且带随机抖动的 TTL，避免大量缓存同时过期。
对热点资源使用多级缓存、源站保护或请求合并，避免大量请求同时回源：

1
2
3
4
5
6
7
8
9


User
 ↓
L1 Edge
 ↓
L2 Regional Cache
 ↓
Origin Shield
 ↓
Origin

Origin Shield：CDN 和源站之间的一层集中缓存或回源保护层，减少多个边缘节点同时访问源站。
请求合并：将大量相同资源请求合并为一个回源请求，其他请求共享结果。
Singleflight：针对相同 Key，只允许一个请求真正执行，其他请求等待并共享结果。
对必须实时更新的内容采用版本化 URL、精确刷新和灰度发布，减少大范围清缓存。
对源站增加限流、熔断和降级，防止 CDN 回源流量压垮应用。

SRE面试题汇总 | SRE

Thu, 04 Dec 2025 18:06:35 +0800

SLA、SLO、SLI

SLI（Service Level Indicator）：服务水平指标，用于量化衡量服务表现，例如成功率、延迟和可用性等。
SLO（Service Level Objective）：服务水平目标，是针对某个 SLI 设定的目标值，必须明确统计周期或时间窗口，例如“按月统计的可用性不低于 99.9%”。
SLA（Service Level Agreement）：服务水平协议，是服务提供方与客户之间约定的服务标准，通常包含 SLO 以及未达标时的补偿或处理方式。

简单来说，SLI 用于衡量实际表现，SLO 是公司内部设定的服务目标，SLA 则是对客户的外部承诺。

MTTR

MTTR：平均故障修复时间（Mean Time to Repair）

MTTR = 故障修复总时长 ÷ 故障次数

如何降低 MTTR？

监控

完善监控告警体系
- 业务指标监控
- 系统指标监控
告警降噪
- 告警分级：P1、P2、P3
- 告警升级：当某告警等级为 P2，且在 1 小时内未被处理（未关闭、未屏蔽等）时，自动升级为 P1
- 告警间隔：设置合理的重复通知间隔，避免同一告警频繁发送
- 告警淹没：设置合理的告警策略，避免告警过多导致重要告警被忽略

快速定位

标准化排障 SOP
- CPU、内存飙高怎么查
- ELB 5xx 怎么查
- Pod CrashLoop 怎么查
自动抓取现场信息
- C++ core dump
统一日志平台
- ELK / Loki
全链路追踪

快速修复

灰度发布 / 金丝雀发布
配置中心（Apollo）+ 动态切流（必要时像开关一样关闭某个模块）
自动扩容（根据业务流量自动扩容，例如 HPA）
脚本化修复
- 一键重启
- 一键清理 DNS 缓存
- ……

高可用部署

服务多实例和多 AZ 部署
自动故障转移

持续演练 & 可靠性测试

混沌工程（提前演练故障）
增加缺失监控点
持续复盘并完善故障应急预案

SRE面试题汇总 | Linux

Wed, 03 Dec 2025 10:56:44 +0800

CPU 使用率很高，怎么排查？

首先通过 top、ps 等命令，定位占用 CPU 最高的进程。
使用 top -Hp <PID>，定位进程中占用 CPU 最高的线程。
导出并分析线程堆栈。以 Java 为例，可以将线程 ID 转换为十六进制，再在 jstack 输出中匹配对应的线程，定位具体的方法和类。
1 2

printf "%x\n" 1235 jstack <PID>
常见原因及处理方式：
- 死循环或密集计算： 代码中存在 while (true) 等没有退出条件的循环，或复杂的递归与大规模计算，需要优化算法或修复代码逻辑。
- 频繁垃圾回收（GC）： 内存不足或对象创建过于频繁，导致 Full GC 频繁触发，CPU 花费大量时间在垃圾回收上，可以使用 jstat -gcutil 进一步确认。
- 高并发请求冲击： 系统本身没有故障，只是瞬时流量过大，超出了服务器的负载能力，需要考虑限流、扩容或优化请求处理逻辑。

CPU 性能指标速查

字段	含义	高负载场景	常见原因	排查工具与解决思路
`us`	用户态 CPU 时间占比	应用程序本身消耗了大量 CPU	大量计算、QPS 增加、死循环、频繁 GC	使用 `top -H -p <PID>`、`perf top` 及语言自带工具（如 Go 的 `pprof`、Java 的 `jstack`）；优化算法、修复死循环或横向扩容
`sy`	内核态 CPU 时间占比	CPU 主要消耗在内核层面	大量系统调用（`open/read/write/futex`）、频繁创建和销毁线程、上下文切换过多	使用 `strace -c -p <PID>`、`vmstat 1`、`pidstat -w`；减少锁竞争，使用连接池/线程池，批量处理 I/O
`ni`	由 nice 调整过的用户态进程所消耗的 CPU	低优先级后台任务占用 CPU	批处理任务、备份脚本等	通常属于预期行为；可通过调整任务执行时间或 Nice 值进行控制
`id`	空闲 CPU 时间占比	`id` 很低表示 CPU 忙	CPU 容量不足或存在突发流量	结合 `us`、`sy`、`wa` 等指标判断 CPU 忙碌原因
`wa`	等待 I/O 的 CPU 时间占比	CPU 主要在等待 I/O 完成	磁盘 IOPS 瓶颈、同步刷盘、磁盘故障导致延迟升高	使用 `iostat -xz 1`、`pidstat -d`、`iotop`；排查磁盘、存储和 I/O 调用
`hi`	硬件中断时间占比	CPU 花费大量时间处理网卡、磁盘等硬件中断	网络流量或硬件中断过多	使用 `cat /proc/interrupts` 查看中断分布；配置网卡多队列和 `irqbalance`
`si`	软件中断时间占比	CPU 花费大量时间处理软件中断	常见于网络包量大、TCP 连接建立和销毁频繁，也可能与定时器或块设备 I/O 有关	使用 `mpstat -I SUM -P ALL 1`、`sar -n DEV 1`；优化网络连接复用、RPS/RFS 和相关内核参数
`st`	被虚拟机宿主机占用的 CPU 时间占比	虚拟机拿不到足够的 CPU	宿主机超卖或其他虚拟机争抢资源	联系云厂商排查宿主机负载，或迁移到其他节点/独占实例

CPU 使用率不高，但 Load 很高

CPU 使用率不高但 Load 很高，通常说明有大量进程处于可运行状态（R），或处于不可中断睡眠状态（D）。D 状态通常与磁盘、网络存储等 I/O 等待有关，也需要关注锁竞争、NFS 和文件系统问题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56


Load 高
 │
 ▼
1. 先确认是否真的异常
 uptime / nproc
 │
 ├─ 1min 高，5/15min 低
 │ └─ 可能是瞬时突发
 │ 检查流量、定时任务、发布、批处理
 │
 └─ 1/5/15min 都高
 或 Load 持续高于 CPU 核数 / 历史基线
 │
 ▼
2. 查看 CPU 是总体高、单核高，还是不高
 top
 mpstat -P ALL 1 5
 │
 ├─ 某个 CPU Core 很高
 │ └─ 单核或绑核问题
 │ 检查热点线程、CPU affinity、taskset
 │
 ├─ 所有 CPU Core 都高
 │ └─ CPU 容量不足
 │ 检查高 CPU 进程、线程和业务流量
 │ top -H / pidstat -u -t 1
 │
 └─ 总体和单核 CPU 都不高
 └─ 重点排查资源等待
 │
 ▼
3. 使用 vmstat 对问题分类
 vmstat 1 5
 │
 ├─ b（不可中断进程）高或 wa（I/O 等待）高
 │ └─ 大量任务阻塞或等待 I/O
 │ 进入「I/O 排查」
 │
 ├─ si / so 持续较高
 │ └─ 发生 Swap
 │ free -h
 │ swapon --show
 │ 排查内存不足
 │
 ├─ st 高
 │ └─ 虚拟机被宿主机抢占 CPU
 │ 排查宿主机超卖和资源争抢
 │
 ├─ r 高（等待运行的进程数），但 CPU 使用率不高
 │ └─ 任务等待 CPU，但 CPU 没有充分利用
 │ 检查 CPU affinity、容器 CPU quota、
 │ CPU throttling 和虚拟机 steal time
 │
 └─ r、b、wa、si/so、st 都不明显
 └─ 延长采样时间，并检查 D 状态、
 锁竞争、NFS、文件系统和驱动

I/O 排查

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41


I/O 排查
 │
 ▼
4. 查看是否存在大量 D 状态进程
 ps -eo pid=,ppid=,stat=,pcpu=,wchan:25=,comm= |
 awk '$3 ~ /^[DR]/'
 或 top -H
 │
 ├─ 没有大量 D 状态
 │ └─ 继续检查 R 状态、CPU 调度和 cgroup 限制
 │
 └─ 存在大量 D 状态
 │
 ▼
5. 查看进程卡在哪个内核等待点
 cat /proc/<PID>/wchan
 cat /proc/<PID>/stack
 │
 ▼
6. 检查磁盘和存储性能
 iostat -xz 1
 pidstat -d 1
 iotop
 │
 ├─ await、aqu-sz、%util 较高
 │ └─ 磁盘或底层存储性能不足
 │ 检查 IOPS、吞吐、队列、慢盘、云盘、RAID、Ceph、SAN
 │
 ├─ 本地磁盘或云盘
 │ └─ df -h
 │ df -i
 │ dmesg -T
 │ journalctl -k
 │
 ├─ NFS、EFS、Ceph 或其他网络存储
 │ └─ findmnt / mount
 │ 检查网络延迟、挂载状态和远端存储服务
 │
 └─ 磁盘指标正常
 └─ 继续排查锁竞争、文件系统、网络存储
 以及内核或驱动异常

进程、线程、协程

进程：操作系统分配资源的基本单位，一个进程可以拥有多个线程，并拥有独立的地址空间和资源。
线程：进程内的执行单位，同一进程中的线程共享进程的大部分资源，但拥有独立的栈和寄存器状态。
协程：由用户态运行时调度的轻量级执行单元，不直接由内核调度，通常运行在线程之上。

Linux 中的进程优先级与设置方法

进程的优先级决定了其获取 CPU 时间片的顺序。优先级更高（数值更低）的进程会优先获取 CPU 时间片。对于普通进程，Nice 值会影响其调度优先级，范围是 -20（最高优先级）到 19（最低优先级）。实时进程还使用独立的实时优先级。默认情况下，进程的 Nice 值为 0。

nice 命令：nice 命令用于启动一个进程，并设置其 Nice 值。例如，nice -n 10 command 会以 Nice 值为 10 来启动 command。
renice 命令：renice 命令用于修改已经在运行的进程的 Nice 值。例如，renice +5 -p 1234 会将 PID 为 1234 的进程的 Nice 值增加 5。需要注意的是，只有 root 用户或具备 CAP_SYS_NICE 权限的进程才能降低 Nice 值、提高调度优先级。
在代码中调用 nice() 或 setpriority() 函数：如果你正在编写一个程序，你可以在代码中调用 nice() 或 setpriority() 函数来改变你的进程的优先级。

什么是僵尸进程

僵尸进程是指一个已经终止运行、但父进程尚未回收其退出状态的进程。此时内核仍会保留少量进程描述信息，供父进程通过 wait() 等系统调用读取；进程占用的大部分资源已经释放。

什么是中断

中断是系统用来响应硬件设备请求的一种机制，会打断进程的正常调度和执行，然后调用内核的中断处理程序来响应设备的请求。取外卖案例，不用苦苦等待，打电话的动作就是中断。中断是一种异步处理机制，可以提高系统的并发处理能力。

软中断、硬中断、不可中断进程

Linux 通常将中断处理分为上半部分和下半部分：上半部分直接处理硬件请求，特点是快速执行（硬中断）。下半部分延后处理耗时工作，特点是延迟执行（软中断或其他下半部机制）。不可中断进程（D 状态）表示进程正在等待某些不可中断的内核操作，常见于 I/O 等待。进程长时间处于 D 状态，通常需要排查存储、网络文件系统或驱动问题。

进程间通信的方式及其使用场景

管道（Pipe）和命名管道（Named pipe）：管道通常用于具有父子关系的进程间通信；命名管道可以用于没有亲缘关系的进程。它们主要用于数据的流式传输，双向通信通常需要两个管道或使用 Socket。
消息队列（Message Queue）：消息队列是一种列表结构，可以存储要发送的消息。进程可以向消息队列中添加消息，也可以从中读取消息。消息队列常用于不同进程间的数据交换和同步。
共享内存（Shared Memory）：共享内存是最快的 IPC 方式，它允许两个或多个进程访问同一块内存区域。这种方式常用于大量数据的交换。
信号（Signal）：信号是一种异步的通信方式，用于通知接收进程某个事件已经发生。例如，当一个进程结束时，它会发送一个 SIGCHLD 信号给其父进程。
套接字（Socket）：套接字可以用于不同机器之间的进程通信，也可以用于同一机器上的进程通信。它支持 TCP、UDP 等多种协议，常用于网络通信。
信号量（Semaphore）：信号量主要用于解决竞态条件，保护关键资源的访问。当多个进程需要访问同一资源时，可以使用信号量进行同步。
文件锁（File Locking）：文件锁可以用于控制多个进程对同一文件的访问。当一个进程正在访问某个文件时，其他进程必须等待，直到该进程释放了文件锁。

cgroup 中限制 CPU 的方式有哪些

cgroups 是 control groups（控制组）的缩写，是 Linux 内核提供的资源管理机制，可以限制、控制和隔离进程使用的 CPU、内存、磁盘 I/O 等资源。常见的 CPU 限制方式有两种：

基于 CPU 配额的硬限制：cgroup v1 使用 cpu.cfs_quota_us 和 cpu.cfs_period_us，cgroup v2 使用 cpu.max，限制进程在一个周期内最多使用的 CPU 时间。
基于相对权重的限制：cgroup v1 使用 cpu.shares，cgroup v2 使用 cpu.weight，用于 CPU 竞争时按比例分配资源，并不是绑定到固定的 CPU 核心。

内存中的 Buffers 与 Cached 的区别

设计目的是提升系统的 I/O 性能。

Buffers 是内核块设备缓冲区使用的内存，对应 /proc/meminfo 中的 Buffers 值。 Cache 是内核页缓存和可回收 Slab 使用的内存，对应 /proc/meminfo 中的 Cached 与 SReclaimable 等字段。

Buffers 是用于临时存储待写入硬盘的数据，而 Cached 是用于存储已经从硬盘读取的数据，以便快速访问。 Buffer 是对磁盘数据的缓存。而 Cache 是文件数据的缓存，它们既会用在读请求中，也会用在写请求中。

Linux是尽可能使用内存原则，内存会把剩余的空间申请为cache，而cache不属于free，当系统运行时间很长，我们会发现cache很大。

当我们看到系统内存使用率很高，free几乎为0时，并不代表系统内存容量有瓶颈！只是系统充分发挥了内存作用。而当有进程需要申请大文件内存时，内核会将部分cache空间回收，回收的内存再分配给进程程序使用。

栈内存和堆内存的区别

栈内存（Stack）特点：栈内存是自动分配和释放的，具有先进后出（LIFO，Last In First Out）的特性。栈内存中的变量会在函数调用时创建，并在函数返回时自动销毁。其管理由编译器控制，因此效率较高。用途：通常用于存储局部变量、函数参数等临时数据。栈内存的分配通常很快，因为它只是调整一个指针来跟踪当前的栈顶位置。优点：内存分配和释放速度快，不容易产生内存碎片。缺点：栈内存的大小通常有限，不能用于存储大量数据或长时间使用的数据。
堆内存（Heap）特点：堆内存是动态分配的，大小不固定，需要程序员手动分配和释放。如果忘记释放，可能会导致内存泄漏。它没有严格的先进后出的顺序，可以在程序的任何位置请求内存分配。用途：用于存储需要动态分配的大量数据，如对象、全局数据等。通过 malloc() 或 new 等操作分配，通过 free() 或 delete 等操作释放。优点：适合长时间使用的数据或较大的数据结构，比如链表、树等。堆内存的大小相对栈来说几乎是无限的（受制于物理内存和系统限制）。缺点：由于需要手动管理，堆内存分配和释放速度较慢，且容易导致内存碎片。

区别总结：

生命周期：栈内存中的数据在函数调用期间有效，而堆内存的数据在手动释放前一直有效。
分配方式：栈是由系统自动分配和管理，堆是由程序员动态分配和管理。
效率：栈内存效率高，堆内存分配和释放较慢

进程最大数、最大线程数、进程打开的文件数，怎么调整

查看当前限制

以下限制针对当前 Shell 或当前用户会话：

1
2
3


ulimit -a
ulimit -u # 当前用户可创建的进程/线程数
ulimit -n # 单个进程可打开的文件描述符数

调整最大文件数

临时生效 ulimit -n 65535

永久生效 sudo vim /etc/security/limits.conf

添加如下内容

soft nofile 65535
hard nofile 65535

调整最大进程数 / 最大线程数

临时生效 ulimit -u 65535

永久生效 sudo vim /etc/security/limits.conf

添加如下内容

soft nproc 65535
hard nproc 65535

注意事项

soft 软限制：当前会话实际生效的限制，用户可以将它提高到 hard 限制以内。 hard 硬限制：软限制可以达到的上限，通常只有 root 或具备相应权限的用户才能提高。

/etc/sysctl.conf 用于配置系统级内核参数，可通过 sysctl -p 立即加载，通常不需要重启。 /etc/security/limits.conf 用于配置用户级限制，通常需要重新登录才能对新会话生效；systemd 服务还需要在 unit 中配置对应的 LimitNOFILE、TasksMax 等参数。

Load 和 CPU 使用率的区别

Load 平均负载是指一段时间内，处于可运行状态（R）和不可中断睡眠状态（D）的任务数的平均值。 CPU 使用率是指一段时间内，CPU 用于处理任务的时间占总时间的比例。

最理想的情况：平均负载接近 CPU 核心数，每个核心上都有一个可运行任务。

1
2
3
4
5
6


查看CPU核心数
grep 'model name' /proc/cpuinfo | wc -l


uptime
 06:44:50 up 190 days, 22:44, 4 users, load average: 0.42, 0.14, 0.04

两者之间关系

CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的
I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高
大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高

du、df 查看磁盘结果不一致

系统中可能存在大量被删除的文件（僵尸文件），且有运行的进程在使用这些文件的句柄。

当一个文件被删除后，如果有进程仍然打开着该文件，du 不会统计这部分空间，因为文件已经从目录结构中移除；然而，df 会统计这部分空间，因为磁盘空间实际上还被占用。

解决方法

重启相关服务：重启仍持有文件句柄的进程，释放已删除文件占用的空间。生产环境应优先采用平滑重启。
查找并关闭进程：使用 lsof 或 fuser 等工具查找并关闭使用僵尸文件的进程。
1

lsof | grep deleted
如果暂时不能重启进程，可以结合业务情况，通过进程自身的日志切割或文件截断机制释放空间；不要重复删除已经显示为 deleted 的文件。

硬链接和软链接的区别

硬链接和软链接是两种不同类型的文件系统链接，用于在目录之间共享文件。

硬链接：

a. 具有相同inode节点号的多个文件互为硬链接文件； b. 硬链接文件是文件的另一个入口 c. 可以通过给文件设置硬链接文件来防止重要文件被误删； d. 删除硬链接文件或者删除源文件，文件实体不会被删除，只有都删除才会生效

软连接：

a. 软链接类似windows系统的快捷方式 b. 软链接里面存放的是源文件的路径，指向源文件 c. 删除源文件，软链接依然存在，但无法访问源文件内容 d. 软链接和源文件是不同的文件，文件类型也不同，inode号也不同；

LVM 怎么划分

创建物理卷（PV）
创建卷组（VG）
创建逻辑卷（LV）
格式化逻辑卷（LV）
挂载逻辑卷（LV）

在公有云运维中，很少见到使用 LVM 划分云盘，这属于常见情况。

云盘可以直接扩容，不需要 LVM 的 PV/VG/LV
传统环境中，LVM 与 RAID 可以配合使用，但二者职责不同；云盘底层通常已经提供多副本和冗余能力
Kubernetes 弱化了主机侧 LVM 的使用，容器数据通常通过 PVC 管理

常见的 RAID 有哪些，使用场景是什么

常见的 RAID 级别有以下几种：

RAID 0：striping（条带化），将数据分成多个块，并行写入多个磁盘，提高读写速度。但不提供数据冗余，一旦磁盘故障，数据将丢失。
RAID 1：mirroring（镜像），将数据在多个磁盘上进行镜像备份，提供数据冗余。但写入速度受限于较慢的磁盘。
RAID 5：striping with parity（条带化加校验），将数据分成多个块，并行写入多个磁盘，同时存储校验信息，可容忍一块磁盘故障，但写入会产生额外的校验开销。
RAID 6：striping with double parity（条带化加双校验），在 RAID 5 的基础上增加一组校验信息，可容忍两块磁盘故障。

使用场景：

RAID 0：用于对性能要求较高的场景，如数据库、视频编辑等。
RAID 1：用于对数据冗余要求较高的场景，如企业关键数据存储。

如何创建和管理自定义 systemd 服务

自定义服务配置文件位置：/etc/systemd/system/

创建或者修改单元文件后需要重新加载配置生效 sudo systemctl daemon-reload

Linux 系统中 `/proc` 是做什么的

用户和内核交互的接口，性能工具数据（top、free、ps）的来源

1
2
3
4
5


启动当前进程的完整命令：
/proc/<进程号>/cmdline

当前进程的环境变量列表：
/proc/<进程号>/environ

/proc 中的部分文件使用 NUL 字符分隔内容，例如 cmdline，需要转换后才能按行阅读：

1

cat /proc/3824/cmdline | tr '\0' '\n'

lsof 命令使用场景

查看某个进程打开的文件 lsof -p 1234
查看哪个进程正在使用特定端口 lsof -i :80
查看所有网络连接 lsof -i
查看某个用户打开文件 lsof -u username
文件已经被删除，但仍然被某个进程占用 lsof | grep deleted

面试 | 滴滴运维开发工程师

Tue, 02 Dec 2025 15:20:45 +0800

TCP 的连接方式

502、504区别

常用的网络命令

如何查看80端口的进程ID

你对稳定性方面做了哪些东西

面试 | 智谱华章运维工程师

Tue, 02 Dec 2025 15:20:29 +0800

ls 按照时间排序

两个文件如何按照行diff

awk 获取最后一行

k8s 中几种探针方式

k8s集群组件

创建 pod 的过程

ingrss 创建方式

dockerfile 中 add 、copy区别

如何减少镜像体积

如何将运行的容器打印成镜像

CICD的设计流程

面试 | 百度信息安全运维

Tue, 02 Dec 2025 15:19:58 +0800

pod 可能存在哪些状态

你们告警架构

Counter和Gauge 区别？什么场景下用Counter

502、504区别

192.168.1.0/25 所有的IP地址范围

一台机器如何放行80，拒绝所有端口

python 使用装饰器统计函数运行时间

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


import time
from functools import wraps

def timer_decorator(func):
 @wraps(func) # 保留原函数的元信息
 def wrapper(*args, **kwargs):
 start_time = time.perf_counter() # 高精度计时开始
 result = func(*args, **kwargs) # 执行原函数并获取结果
 end_time = time.perf_counter() # 计时结束
 elapsed = end_time - start_time
 print(f"函数 {func.__name__} 执行耗时: {elapsed:.4f} 秒")
 return result # 返回原函数结果
 return wrapper


@timer_decorator
def add_numbers(a, b):
 time.sleep(0.5) # 模拟耗时操作
 return a + b

# 调用函数，自动计时
sum_result = add_numbers(3, 4)
print(f"计算结果: {sum_result}")

面试 | 字节国际电商

Tue, 02 Dec 2025 15:19:21 +0800

一轮面试

k8s 中几种探针方式

跨region 双写、三写数据一致性问题

pod 资源节点抢占解决方案

k8s 服务中扩缩怎样实现

一次troubleshooting

报警架构如何做的

当前工作中的存在的痛点

你会关注业务哪些指标

广告竞价返回的数据格式

一道力扣题复原IP地址

SRE面试题汇总 | 面试专题的一些规划

Tue, 02 Dec 2025 15:06:33 +0800

面试经历
liunx
container && k8s
network
database
Prometheus
program
SRE
…..

部分面试题来自崔亮的博客

https://www.cuiliangblog.cn/detail/article/89

mysql 常用命令

Mon, 01 Dec 2025 21:14:56 +0800

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


-- 切换到mysql数据库
MySQL [(none)]> use mysql;

-- 用户查看
MySQL [mysql]> SELECT user FROM user;

-- 查看用户拥有权限
MySQL [mysql]> show grants for user;


-- 创建用户
mysql> CREATE USER 'xxx'@'%' IDENTIFIED BY 'xxxx';


-- 授权
mysql> GRANT SELECT, INSERT, UPDATE, DELETE ON 数据库.数据表 TO user@'%';

-- 删除用户

mysql> DROP USER XXX

ASG Node 数据盘挂载失败

Mon, 01 Dec 2025 11:45:14 +0800

问题背景

data 数据盘挂载失败，日志文件会写入根盘，导致磁盘多次报警

内核还没有来得及刷新分区表生成 /dev/nvme1n1p1 设备文件，就执行mkfs 命令，导致格式化失败。

解决方法

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


...
yum install parted -y
mkdir -p /data
parted -s /dev/nvme1n1 -- mklabel gpt
parted -s /dev/nvme1n1 -- mkpart primary ext4 0% 100%
partprobe /dev/nvme1n1
udevadm settle
while [ ! -e /dev/nvme1n1p1 ]; do sleep 1; done
mkfs -t ext4 /dev/nvme1n1p1
mount /dev/nvme1n1p1 /data
echo '/dev/nvme1n1p1 /data ext4 defaults 0 0' >> /etc/fstab
...

parted 中 0 与 0% 的区别

0：表示强制要求分区从磁盘的第 0 个字节/扇区开始。
0%：自动对齐，最佳对齐点开始分区。parted 会自动跳过前面的保留空间，通常将起始位置设定在扇区 2048 开始。

partprobe /dev/nvme1n1

通知内核（Kernel）立即重读分区表

udevadm settle

阻塞（暂停）脚本执行，直到 udev 处理完所有设备事件。所有设备文件都创建好，脚本才能继续执行。

用户数据脚本

用户脚本位置： /var/lib/cloud/instance/user-data.txt

日志位置： /var/log/cloud-init-output.log

Hugo ｜基础规划和使用方法

Thu, 27 Nov 2025 15:16:29 +0800

Hugo 目录结构

content/: 存放你的 Markdown 文章（数据库）。

layouts/ & themes/: 存放前端代码（HTML/CSS 模版）。

static/: 存放图片、CNAME 文件等静态资源。

hugo.toml (或 .yaml/.json): 整个站点的配置文件（相当于 k8s 的 configmap）

评论系统

Giscus 评论系统 https://giscus.app/zh-CN

hugo.yaml

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


params:
 # ... 其他配置 ...

 comments:
 enabled: true
 provider: giscus  # <--- 将默认的 disqus 改为 giscus

 giscus:
 repo: hangliuc/blog-hugo  # <--- 换成你的 "用户名/仓库名"
 repoID: "R_kgD..." # <--- 填入第二步获取的 data-repo-id
 category: "Announcements" # <--- 你选择的分类名
 categoryID: "DIC_kw..." # <--- 填入第二步获取的 data-category-id
 mapping: pathname
 lightTheme: light
 darkTheme: dark_dimmed
 reactionsEnabled: 1
 emitMetadata: 0

除此之外需要去GitHub 授权 Giscus 评论系统参考链接 https://giscus.app/zh-CN

分类和标签

Categories (分类)：像文件夹一样，通常是树状、排他性的。一篇文章通常属于 1-2 个分类（例如“运维”、“容器化”）。

Tags (标签)：像便利贴一样，是扁平、描述性的。一篇文章可以有多个标签（例如“Docker”、“网络”、“Troubleshooting”、“Linux”）。

一些可用链接

图标下载网站 https://tabler.io/icons

一些使用 hugo-theme-stack 搭建的优秀网站

https://liuhouliang.com/categories/web/

https://blog.reincarnatey.net/

https://zfj1441.com/archives/

https://hyrtee.github.io/2023/start-blog/#%E8%AF%84%E8%AE%BA

https://www.shaohantian.com/

Vim 使用技巧

Thu, 27 Nov 2025 11:02:53 +0800

vim 常用命令

光标移动

h 或退格：左移一个字符
l 或空格：右移一个字符
j：下移一行
k：上移一行
gj：移动到一段内的下一行
gk：移动到一段内的上一行
+ 或 Enter：移至下一行第一个非空白字符
-：移至上一行第一个非空白字符
w：前移一个单词，停在下一个单词开头
W：前移一个单词（忽略部分标点）
e：前移一个单词，停在下一个单词末尾
E：前移一个单词，停在标点（如有）
b：后移一个单词，停在上一个单词开头
B：后移一个单词（忽略部分标点）
(：前移 1 句
)：后移 1 句
{：前移 1 段
}：后移 1 段
gg：到文件头部
G：到文件尾部
$：到行尾
0：到行首

翻屏

Ctrl + f：下翻一屏
Ctrl + b：上翻一屏
Ctrl + d：下翻半屏
Ctrl + u：上翻半屏
Ctrl + e：向下滚动一行
Ctrl + y：向上滚动一行
n%：到文件 n% 位置
zz：当前行移到屏幕中央
zt：当前行移到屏幕顶端
zb：当前行移到屏幕底端

插入

I：在当前行第一个非空字符前插入
gI：在当前行第一列插入
a：在光标后插入
A：在当前行末尾插入
o：在下方新建一行插入
O：在上方新建一行插入
:r filename：在当前位置插入另一个文件内容
:[n]r filename：在第 n 行插入另一个文件内容

剪切和复制

[n]x：剪切光标右边 n 个字符（相当于 d[n]l）
[n]X：剪切光标左边 n 个字符（相当于 d[n]h）
y：复制可视模式下选中的文本
yy 或 Y：复制整行
y[n]w：复制 n 个词
y[n]l：复制光标右边 n 个字符
y[n]h：复制光标左边 n 个字符
y$：从光标到行尾复制
y0：从光标到行首复制
:m,ny：复制第 m 到 n 行
y1G 或 ygg：复制光标以上所有行
yG：复制光标以下所有行
d：删除（剪切）可视模式下选中的文本
d$ 或 D：删除到行尾
d[n]w：删除 n 个单词
d[n]l：删除光标右边 n 个字符
d[n]h：删除光标左边 n 个字符
d0：删除到行首
p：在光标后粘贴
P：在光标前粘贴

查找和替换

/something：向后查找 something
?something：向前查找 something
n：向后查找下一个
N：向前查找下一个
s/old/new：替换当前行第一个 old
s/old/new/g：替换当前行所有 old
%s/old/new/g：替换整个文件的所有 old

技巧

:set paste：解决粘贴时格式错乱问题

Containerd命令行管理工具

Thu, 27 Nov 2025 10:51:50 +0800

Containerd 命令行管理工具

Kubernetes 从 Docker 转向 containerd 的原因

架构层面的原因

kubelet 启动一个容器的流程:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


kubelet
 │
 │ (调用 CRI 接口)
 ▼
dockershim (K8s 维护的 CRI 转换层)
 │
 │ (调用 Docker Engine API)
 ▼
Docker Engine
 │
 │ (调用 containerd API)
 ▼
containerd
 │
 │ (调用 OCI 接口)
 ▼
runc (OCI runtime)
 │
 └─> 真正创建 Linux 容器 (namespace, cgroups, rootfs...)

Docker Engine 是一个完整平台（构建镜像、管理网络、Volume、Swarm 等），这些对 K8s 来说都是多余的。
dockershim 只是为了把 CRI（K8s 语言）翻译成 Docker API（Docker 语言）。
实际执行容器的，依然是 containerd + runc。

当 kubelet 直接使用 containerd 时，调用链简化为：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


 kubelet
 │
 │ (调用 CRI 接口)
 ▼
containerd (内置 CRI 插件)
 │
 │ (调用 OCI 接口)
 ▼
runc (OCI runtime)
 │
 └─> 真正创建 Linux 容器 (namespace, cgroups, rootfs...)

减少维护成本

kubernetes 从 1.24 开始，默认使用 containerd 作为容器运行时。不再去维护中间dockershim

性能提升

少一层调用，性能和稳定性更好。

ctr – Containerd自带的命令行管理工具

1
2


# 列出所有命名空间
sudo ctr namespaces list

1
2


# 镜像相关命令
sudo ctr -n=k8s.io images -h

ctr 上传、拉取镜像时不支持登陆认证，只能通过–user携带用户密码操作

1
2
3


sudo ctr -n=k8s.io images pull \
 --user <username>:<password> \
 myregistry.example.com/myrepo/nginx:latest

nerdctl (最接近docker CLI)

基本和docker CLI命令一致，只是在命令前添加了nerdctl前缀

安装nerdctl

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


#!/bin/bash
set -e

VERSION=${VERSION:-2.2.0}

# 自动识别架构
ARCH=$(uname -m)
if [[ "$ARCH" == "x86_64" ]]; then
 ARCH="amd64"
elif [[ "$ARCH" == "aarch64" ]]; then
 ARCH="arm64"
else
 echo "Unsupported architecture: $ARCH"
 exit 1
fi

DOWNLOAD_URL="https://github.com/containerd/nerdctl/releases/download/v${VERSION}/nerdctl-${VERSION}-linux-${ARCH}.tar.gz"

echo "Downloading nerdctl v$VERSION for $ARCH"
wget "$DOWNLOAD_URL" -O nerdctl.tgz

echo "Extracting..."
tar -xzf nerdctl.tgz

# 解压后会得到 nerdctl、containerd、runc 等二进制
# 一般 nerdctl 位于当前目录的 nerdctl
TARGET_DIR="/usr/local/bin"

echo "Moving binaries to $TARGET_DIR (require sudo)"
sudo mv nerdctl "${TARGET_DIR}/"


echo "Cleaning up…"
rm -f nerdctl.tgz

echo "🎉 nerdctl installation completed!"
echo "Version check:"
sudo ${TARGET_DIR}/nerdctl --version

To list local Kubernetes containers:

1

nerdctl --namespace k8s.io ps -a

容器网络影响宿主机入网问题排查

Wed, 26 Nov 2025 10:38:20 +0800

容器网络影响宿主机入网问题排查

问题描述

发现172.27.0.0/16，172.26.0.0/16 网段的服务无法访问宿主机的服务

问题排查

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15


docker network ls
NETWORK ID NAME DRIVER SCOPE
8eacdcbf22d7 7b-full_default bridge local
f22af6f77037 bridge bridge local
4a56201be716 host host local
6e36d25cdbb0 llama2-13b-lora_default bridge local
fb2839792d18 llama3-8b_lora_default bridge local
d1f916892b02 none null local
2c9c2578ecce tgi_default bridge local
446845acbad5 v2-9b_default bridge local
d1301d605f3c v2-27b-it_default bridge local
c3d523d51ee4 v3-8b_default bridge local
1d3cf7bd9665 v4-9b_default bridge local
59aecf59ca81 v31-8b_default bridge local
42cca879c18f webui-docker_default bridge local

发现1d3cf7bd9665、1d3cf7bd9665占用了172.27.0.0/16，172.26.0.0/16 网段，导致路由冲突。Linux 内核的路由机制会优先选择最匹配的路由，它会覆盖默认路由，流量会被错误的流向docker。

解决方法

修改docker 配置，不使用冲突网段

1
2
3
4
5
6
7
8
9


{
 "bip": "192.168.100.1/24",
 "default-address-pools": [
 {
 "base": "192.168.200.0/20",
 "size": 24
 }
 ]
}

创建容器时使用特定网络

docker network create –subnet=xx.xx.xx.xx/24 my_custom_network

如果必须保留冲突网段，修改宿主机路由，让外部网络优先

1
2


ip route del 172.27.0.0/16
ip route add 172.27.0.0/16 via <外部网关> metric 100

ansible | 缓存ssh密钥避免每次输入密码

Tue, 26 Nov 2024 10:00:00 +0800

背景

使用ansible时，为了避免每次执行任务都需要输入ssh密码，我们可以缓存ssh密钥。

ansible 缓存ssh密钥

启动 ssh-agent 后台程序

eval “$(ssh-agent -s)”

将密钥添加至 ssh-add，只输入一次密码

ssh-add ~/.ssh/xxx

验证密钥是否缓存成功

ssh-add -l

Hello World

Sun, 26 Nov 2023 10:00:00 +0800

这是我的第一篇 Hugo 博客！

为什么选择 Hugo？

作为 SRE，我喜欢静态二进制文件的简单和纯粹。

Hugo 目录结构

content/: 存放你的 Markdown 文章（数据库）。

layouts/ & themes/: 存放前端代码（HTML/CSS 模版）。

static/: 存放图片、CNAME 文件等静态资源。

hugo.toml (或 .yaml/.json): 整个站点的配置文件（相当于 k8s 的 configmap）

关于我

Mon, 01 Jan 0001 00:00:00 +0000

👋 你好！

我是 Liu Hang，一名 SRE。

💻 Site Reliability Engineer | ☁️ Cloud Native Enthusiast

“Automate everything, monitor the rest.”

🛠️ 技术栈

❔ 为什么做这个博客

构建私有知识库，记录工作中遇到的问题和解决方法，把一次经验转为长期可复用资产。尽量避免更新一些基础的知识，这些问题通过浏览器搜索/AI获取即可，增强搜索知识的能力。
在搭建过程中也对之前的技术进行了融合再学习，docker、nginx、certbot… 对于工作生产环境，一些基础知识可能并不会用到（比如 nginx 配置、docker-compose 、Go 语言等），但是在搭建过程中也会遇到一些问题，解决途中有一些新的领悟。
从0-1实践一个完整小项目，比如监控告警系统、ELK日志、CDN 加速与缓存策略等。
当然也可以作为简历展示，和各个技术平台进行融合，提升自己的技术水平和商业变现能力。

如果有什么建议或者问题，欢迎评论或者联系我。

🚂 博客架构

目前关于blog 的一些todo todo.md

📫 联系我

Email: iliuhang@163.com
Github: @hangliuc
weichat：hangliuc-
csdn：hangliuc

归档

Mon, 01 Jan 0001 00:00:00 +0000

搜索

Mon, 01 Jan 0001 00:00:00 +0000

HRunning

Hugo ｜ to do list

📝 博客待办清单

🔥 P0

🛠 p1

✅Archived - 已上线功能

内容相关

Brainstorming Skill｜实现前的设计与需求分析

技能定位

核心规则

推荐工作流程

模板一：新功能开发

模板二：技术方案选型

产出检查清单

参考链接

Image2 提示词｜构建视觉隐喻的高级概念海报

使用方法

完整提示词

Hugo ｜ 如何让搜索引擎检索到博客

google

获取Measurement ID

提交siteMap

如何验证文章已经被Google 收录

Google Search Console 验证

google 搜索验证

百度

refs

Hugo ｜ Waline 评论系统私有化部署

Waline 评论系统

本地部署(Waline)

docker-compose 部署

Nginx 反向代理

Hugo 配置

Hugo ｜ 如何自定义实现网站统计功能

一些实现方式

基于服务器端的统计功能

优点

目前统计功能

实现方式

Hugo ｜ 本地服务器部署

安装基础软件

配置 Nginx 与 HTTPS

申请 HTTPS 证书

配置 GitHub 自动部署 (CI/CD)

SRE面试题汇总 | Database

mysql

mysql 查询突然变得很慢，需要怎么排查

检查查询本身

查看数据库性能

检查系统负载

检查锁和并发问题

网络延迟

redis

热 Key、大 Key 问题

热key问题

大key问题

kafka

消费堆积如何处理

消息堆积原因

解决方法

SRE面试题汇总 | K8s

各模块如何与 API Server 通信

kubelet 监控 Worker 节点如何实现

集群节点规模上千时的注意事项

kubeconfig 存放的内容

kube-proxy 的作用

类型

Scheduler 调度流程

Pod 的启动流程

Pod DNS 解析失败排查

Pod 的常见调度方式

Pause 容器的用途

Pod 健康检查失败可能的原因和排查思路

Pod 之间访问不通怎么排查

Pod 的几种常见状态

SRE面试题汇总 | Docker

容器技术的基础原理

如何减小 Dockerfile 生成的镜像体积？

容器网络模式

Docker、镜像和 container 的区别

Hugo ｜如何让搜索引擎检索到博客

Hugo ｜如何自定义实现网站统计功能

Hugo ｜本地服务器部署

客户端出现大量 `TIME_WAIT` 的原因